Changes

Jump to navigation Jump to search

Save disk space for ISOs

818 bytes added, 20:27, 27 September 2019
massive rewording for the first few sections
ISOs are faithful software recreations of game disksdiscs. However, at with disc sizes ranging from 700 MB (CD) / , 1.4 GB (GC Mini-DVD) / , 4.7 GB (single-layered DVD) / , and 25 GB (Blu-Ray), they can get pretty taxing to disk for storage, as especially when newer generations of consoles comegames are getting bigger in file sizes.
It wouldn't be so bad if not for the fact that the actually useful game data itself is often times only a fraction of that data the actual disc size - for instance, the ''Super Mario 25th Anniversary '' Wii disk disc itself is a 4.7GB game with , when really the actual game data is only a single SNES rom and nothing else ROM (12 MB of useful data, to be precise)and nothing else. So naturallyNaturally, one would want to trim the this extra "fat " as much as possible. This , which is what this improved version of a previous guide page aims to help forto achieve. Most of the information here is based partially on this [https://www.reddit.com/r/emulation/comments/3g933n/guide_reduce_the_size_of_your_ps2_gc_wii_x360_ds/ guide].
'''How does one lighten ISO / ROM dumps? '''
There are many ways. Some , some methods alter the dump copy data foreverwhile others can be converted back and forth with generally no lost. Some conversion are only playable on only some specific emulators. And many light dumps are unplayable and may not work on real hardware (though a bunch are). All depending on the method console and the consolemethod used. So you might want It's important to consider take all of this into consideration beforeattempting as most of these are console-specific.
This page was based partially on this [https://www.reddit.com/r/emulation/comments/3g933n/guide_reduce_the_size_of_your_ps2_gc_wii_x360_ds/ guide]. Archive-quality dump means dumps are ones that the resulting compressed dump, when reverted converted back to its original state, will be have the same checksum as the official uncompressed release. Compressions that can't be reversed, or those that can be but will have missing or altered content, whether it interferes with functionality (rebuilt table of content) or not, are not archive -quality dumps. For example, the WBFS format , used for shrinking Wii discs, is not archive -quality since it may be missing padding content and upgrade partitions (which have their uses in 3DS/Wii modding) compared to an intact , uncompressed dump.
==Applicable to All Platforms==
===Audio-CD===
Sega-CD, PC-Engine, PlayStation, Sega Saturn... what did do these all have in common was their reliance on the ? They all use a regular CD format. ! Game developers often stored often orchestrated/Redbook music and occasionally voice acting, other sounds using the Audio-CD format. Of course, the CD contained also game data. But but it was terribly inefficient when it comes to disk disc storageas it also had to store the actual game along with the sound files. Even To put it in perspective, a 700 MB CD containing nothing but Audio-CD data can hold at most around 80 minutes worth of sound data.  That's why devs no longer , meaning games that used it, preferring custom audio formats included a lot sounds where limited in the "game data" part of the disksize. By the time the PS1 gen came, the Audio-CD part was just used for messages like "Don't put this in a CD player, dumb user!" and little else (exceptions exist, of course!)
* '''Full Dump:''' <br />BIN/ISO + CUE<br />BIN/ISO is the full disk data, including Since then developers no longer use Audio-CD sound data format and instead prefer custom audio formats that come included in the "game data<br />CUE is " part of the datasheet file* '''Light Dump:''' <br />ISO + MP3/WAV + CUE <br />ISO is disc. By the disk data with only time the game data<br />MP3/WAV is the sound data from PS1 generation came, the Audio-CDpart was just used for messages like "Don't put this in a CD player!" and little else (exceptions exist, but these formats take much less disk space<br />CUE is the datasheet fileof course!)
* '''Full Dump:''' <br>BIN/ISO + CUE
<br>BIN/ISO is the full disc data, including Audio-CD sound data and game data
<br>CUE is the datasheet file
* '''Light Dump:''' <br>ISO + MP3/WAV + CUE
<br>ISO is the disc data with only the game data
<br>MP3/WAV is the sound data from the Audio-CD, but these formats take much less disk space
<br>CUE is the datasheet file
* '''Archive-quality dump?''' No (unless audio is converted to and from uncompressed formats, which is unlikely)
* '''Gain:''' Several hundreds of MBs to just a few dozens, depending on how much this specific game relies on the Audio-CD sound format
* '''Can be reverted?''' Yes, just burn the ISO+MP3/WAV+CUE again using a CD burner tool (ImgBurner) either to a physical disk or as an ISO+BIN file. Lossy audio formats will result in data loss.
* '''Playable on Hardware?''' No, but can be reverted to be
* '''Playable on Emulators?''' Yes (use virtual drive if needed). Some aren't compatible with MP3 so convert to WAV with MP32WAV , if that's the case, convert them to WAV with MP32WAV. You may need Sega Cue Maker.
Examples:
M3U (playlist) files may be used too for this distribution scheme.
Sometimes dumps that come this way may not work on some emulators. This is often due to either an incorrect CUE files sometimes using the wrong filenames or using MP3 files instead of WAV files.
===Padding===
Devs often have their games much, much bigger than they need to be. They put by putting in accessible garbage data in the diskdisc. Garbage data isn't useful game data and is just bloats used to bloat the disk disc size. It's either a sequence of 00/FF (you know what's inside a file if you open it with a hex editor) or randomized garbage , random data, unused/cut content left during development, and in rare cases, datathat is completely unrelated to the game itself. An example of this is ''Shrek SuperSlam'' on the PS2 which has a working copy of ''Tony Hawk's Underground 2'' for the PSP hidden in the root of the disc.
Its The purpose of doing this can be to fill in some spots in on the disk disc so that specific parts of the game 's data are in specific certain areas of the disk (like the borders) and hence disc. This is done to increase the drive's reading speed is so that it's quick enough in these certain spots for the game to work properly. It's in the your best of your interests interest not to mess with this data arrangement (referred to as LBA and TOC in the case of GC/Wii/PS2/PSP) or else as it might break the game might not even work in some cases (it might in others though).
BUT-- the most common bar none use Another reason for this is having garbage data can be to screw with pirates and people , who download ISOs off /upload these games online sharing websites, by making the ISO bigger and harder to downloadstore. Some go a little step further and make that scramble the garbage data, not instead of just being a sequence of 00/FF , to make the ISO much, much harder to compress using regular archive formats like zip/, 7zip/, rar.., etc. You might be overjoyed to learn this has become the industry standard nowadays.
Many compression schemes remove or simplify padding patterns to allow for easier compression.
* '''Can be reverted?''' Yes, using extractcd (included with MAME)
* '''Playable on Hardware?''' No.
* '''Playable on Emulators?''' Only MAME and DEmul. Some libretro cores for other emulators started adding are starting to add support.
* '''Can process multi track bin files?''' Yes.
MAME uses the CHD format for disc images in general and includes tools to convert from back and to itforth. It uses 7zip's LZMA compression on the game data and lossless FLAC compression for the audio data to optimize compression even further than with the using BIN+CUE+MP3/WAV data separation alone.
Placing '''Instructions'''Place chdman .exe and extractcd in the same directory as the dumps you want to compress (dumps must be in BIN+CUE format, ). Open Command Prompt and navigate to the directory where you placed chdman.exe and input one of the following command-line instructions can be used:
* BIN/CUE to CHD: <code>for %i in (*.cue) do chdman createcd -i "%i" -o "%~ni.chd"</code> (Windows)
* CHD to BIN/CUE: <code>for %i in (*.chd) do chdman extractcd -i "%i" -o "%~ni.cue"</code> (Windows)
Alternatively, if you only need to do one file you can use this: <code>chdman createcd -i "<FILENAME>.cue" -o "<FILENAME>.chd"</code>
If you have one of the European PSX games that feature features LibCrypt copy protection, then you will have a .sbi file in addition to the .bin/cue file. The CHD creation process doesn't process the .sbi file. Thus, you You will still need to have the .sbi file in the same directory as the.game file (in this case, the newly created CHD file for the game ) in order to run.
==PlayStation 1==
344
edits

Navigation menu