Changes

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.

* '''Gain:''' Several hundreds of MBs to just a few dozendozens, 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 a an ISO+BIN file. Lossy audio formats will result in data loss.

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.

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.

If you have one of the European PSX games that features feature 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.

* '''Can be reverted?''' Yes. Using the same tool, to generate BIN+CUE files. There's data loss, although it's negligible in terms of functionality.

* '''Playable on Emulators?''' Retroarch, PCSX-R , and ePSXe.

Often, you can open the ISO in UltraISO and find the dummy files. Sometimes they're obvious obviously looking files like DUMMY.BIN, DATA0.BIN (or .DAT), DUMMY.DAT, etc. Or folders named "PADDING" and stuff like that. You can look into the files (with a hex editor) to see if they're obvious padding data (full of 00/FF, though sometimes it's not as obvious).

However, you must never mess with LBA and TOC when removing padding. So you try to change the size of the padding file inside the ISO to 0 MB, or alter it directly with a hex editor so that it's all zeroed out.

Use 7zip ("Add to archive..." then choose to gzip) or Pigz (multi-threaded, much faster compression) to generate gzip archives containing the ISO file in question. PCSX2 will build an index of each gzip compressed game it loads (as a file in the same directory as the gzip archive), so after the first time where you'll have to wait for the decompression, in all subsequent times there is no speed difference between playing an uncompressed and compressed game. Of course, you can extract the ISO back from the GZIP archive.

People used to resort to WiiScrubber (Wii) and GCM Utility (GC) to scrub/trim games to end up with dumps that while they had no immediate size change, their randomized garbage data (like "dummy", "padding" or "znull") was still there but zeroed out making archived dumps using zip/7zip/rar formats have stunning gains (from 1.4GB uncompressed to 26MB zipped for Animal Crossing for example!). Of course , the file still needed to be uncompressed to its full size everytime you wanted to play it.

Trimming and scrubbing (in Wiiscrubber terms) aren't the same! While they both are terms for "zeroing garbage data" to make it more compression-friendly, trimming does not just that like scrubbing, but takes the extra step of relocating the garbage data to the end of the file, hence altering its TOC and requiring the disc to be fakesigned, for a not-so-big compression gain. Hence why scrubbing is by far the most authentic and safe way to solve the garbage data problem.

* '''Gain:''' Immediate (ISO dump size lowers). Considerable, depending on the game.* '''Tools Used:''' Dolphin; right -click the game(s) in the games list and select "Compress ISO..." ("Compressed selected ISOs..." if more than one is selected)* '''Can be reverted?''' Yes. You can right-click on the GCZ-compressed (in blue) ISOs in Dolphin and choose "Uncompress selected ISOs". Garbage data for Wii titles will be zeroed out and thus different from the official dump, but will have no effect on gameplay in most cases.

* '''Gain:''' Immediate (ISO dump size lowers). Considerable, depending on the game.

* '''Gain:''' Immediate (ISO dump size lowers): Around 50% gain usually (depending on the game)

* '''Can be reverted?''' Yes. The wud tool includes a decompression utility, which recreates the original file.

By Exzap, CEMU's author ([http://gbatemp.net/threads/wii-u-image-wud-compression-tool.397901/ release thread]). The tool detects duplicate sectors and only stores them once: all the empty ranges end up removed, storing only ranges which contain file or filesystem data. Of course , the original ISO can be reconstituted.

It's certainly better than keeping 8.5GB images, but the conversion is too substantial and irreversible to be suitable for archival purposes, since it affects data structure tables as well.

* '''Tools Used:''' ISO2GOD (also a "Games on Demand" X360 image convertorconverter). <br />Under Settings, set the output and rebuild path to the same location. Check "Always save rebuilt ISO" and set Padding to "Full (ISO Rebuild)", then save changes.<br />"Add ISO", and press "Convert". Keep generated ISO, and delete generated folder.

Of course, there are also the devs who don't merely use garbage data for padding, but also bloat the game data part. For instance, many PSP JRPGs have a specific FMV movie duplicated a dozen times, and the Megaman Collection on GC stores its sound data using an uncompressed format bringing the size of that portion alone to 1GB. In many of these cases, there's just not much you can do about it without destructively altering game data.

* If a game has multiple quests, they delete some characters / quests they don't like. Especially seen in compilations and stuff with demos included.