Changes

Jump to navigation Jump to search

Save disk space for ISOs

1,616 bytes added, 23:46, 21 September 2017
no edit summary
Archive-quality dump means that the resulting compressed dump, when reverted back to its original state, will be 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 is not archive quality since it will 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 these have in common was their reliance on the regular CD format. Game developers stored often orchestrated/Redbook music and occasionally voice acting, using the Audio-CD format. Of course, the CD contained also game data. But it was terribly inefficient when it comes to disk storage. Even 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 used it, preferring custom audio formats included in the "game data" part of the disk. 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!)
* Captain Tsubasa (SCD): 512 MB > 146 MB (Game Data) + 3 MB (audio as MP3) > (as 7zip) 34 MB (Game Data) + 3 MB (audio)
=Padding=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 incorrect CUE files sometimes using wrong filenames, or MP3 files instead of WAV files.
===Padding===
Devs often have their games much, much bigger than they need to be. They put garbage data in the disk. Garbage data isn't game data and just bloats the disk 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 data.
BUT-- the most common bar none use for this is to screw with pirates and people who download ISOs off online sharing websites, by making the ISO bigger and harder to download. Some go a little step further and make that garbage data not just a sequence of 00/FF to make the ISO much, much harder to compress using regular archive formats like zip/7zip/rar... 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.
 
===CHD Compression===
* '''Archive-quality dump?''' Yes
* '''Gain:''' Immediate
* '''Tools Used:''' chdman (included with MAME)
* '''Can be reverted?''' Yes, using extractcd (included with MAME)
* '''Playable on Hardware?''' No.
* '''Playable on Emulators?''' Only MAME. Some libretro cores for other emulators started adding support.
 
MAME uses the CHD format for disc images in general and includes tools to convert from and to it. 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 BIN+CUE+MP3/WAV data separation alone.
 
Placing chdman and extractcd in the same directory as dumps in BIN+CUE format, 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 extractcd -i "%i" -o "%~ni.cue"</code> (Windows)
 
If you have one of the European PSX games that features LibCrypt copy protection, you have a .sbi file in addition to the .bin/cue file. The CHD creation process doesn't process the .sbi file. Thus, you will need the .sbi file in the same directory as the .CHD file for the game to run.
==PlayStation 1==
126
edits

Navigation menu