Emulation General Wiki

Save disk space for ISOs: Difference between revisions

undoBabyclav (talk | contribs)
57 edits
VisualWikitext
Created page with "ISOs are faithful software recreations of game disks. However, at 700 MB (CD) / 1.4 GB (GC Mini-DVD) / 4.7 GB (single-layered DVD) / 25 GB (Blu-Ray), they can get pretty taxin..."
 
Babyclav (talk | contribs)
57 edits
udfps fact
 
(374 intermediate revisions by more than 100 users not shown)
Line 1: Line 1:
ISOs are faithful software recreations of game disks. However, at 700 MB (CD) / 1.4 GB (GC Mini-DVD) / 4.7 GB (single-layered DVD) / 25 GB (Blu-Ray), they can get pretty taxing to disk storage, as newer generations of consoles come.  
Disc images (commonly known as ISOs, but ISO is actually a specific format) are faithful software recreations of game discs (when made correctly). However, with disc sizes ranging from 700 MB (CD), 900 MB (PSP single-layered UMD), 1 GB (DC GD), 1.46 GB (GCN Mini-DVD), 1.8 GB (PSP dual-layered UMD), 4.7 GB (single-layered DVD), 8.5 GB (dual-layered DVD), 25 GB (single-layered Blu-Ray), and 50 GB (dual-layered Blu-Ray), they can get pretty taxing for storage, especially when newer generations of consoles games are getting bigger in file sizes.  


It wouldn't be so bad if not for the fact that the actually useful game data is often only a fraction of that data size - for instance, the Mario 25th Anniversary Wii disk is a 4.7GB game with only a single SNES rom and nothing else (12 MB of useful data, to be precise). So naturally, one would want to trim the extra fat as much as possible. This is what this improved version of a previous guide aims to help for.
It wouldn't be so bad if not for the fact that the game data itself is often times only a fraction of the actual disc size - for instance, the ''Super Mario 25th Anniversary'' Wii disc itself is a 4.7GB, when really the actual game data is only a single SNES ROM (12 MB of useful data, to be precise) and nothing else. Naturally, one would want to trim this extra "fat" as much as possible, which is what this page aims to help to 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?  
'''How does one lighten ISO / ROM dumps?'''


There are many ways. Some alter the dump copy forever. Some are playable on only some specific emulators. And many light dumps are unplayable on real hardware (though a bunch are). All depending on the method and the console. So you might want to consider all of this before.
There are many ways, some methods alter the data forever while others can be converted back and forth with generally no loss. Some conversions are only playable on specific emulators and may not work on real hardware depending on the console and the method used. It's important to take all this into consideration before attempting as most of these are console-specific.


==Audio-CD==
'''[[Ripping_games#Preservation_Priority_(Recommended_Workflow)|Archive-quality]]''' dumps are ones that when converted back to its original state, will 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. 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.


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.
=Optical disc images=
==Before we begin==
*We highly recommend to read our [[Ripping games|ripping games]] and [[Home media players]] pages first for learning the proper way to ripping discs and using best image file formats for preserving optical disc images in the first place before reducing the filesize using compression methods and formats mentioned in this page.


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.  
*We also recommend [https://www.how2shout.com/how-to/how-to-install-7-zip-on-windows-11-or-10-with-single-command.html#:~:text=Step%204%3A%20Add%207%2DZip%20to%20System%20Path adding 7z's path to environment's Path variable] to make any 7z script work from cmd., or you can replace "7z" in the script with full path of the 7z.exe.


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!)
;Audio-CD & Mixed-Mode Discs
PCs, Sega-CD, PC-Engine, PlayStation, and Sega Saturn all have one thing in common: they use the standard CD-ROM format. Early game developers frequently stored game soundtracks as standard Red Book Audio-CD tracks alongside the game's data track. This is commonly known as a "Mixed-Mode CD". Because Red Book audio is completely uncompressed (16-bit, 44.1kHz stereo), it is highly inefficient for storage. A standard 700 MB CD can only hold about 80 minutes of audio, meaning games utilizing heavy CD audio soundtracks had drastically less room for actual game data.  To maximize storage efficiency, developers gradually abandoned Red Book audio in favor of compressed, custom audio formats stored directly within the game's data track. By the fifth generation of consoles ([[PlayStation emulators|PS1]] & [[Sega Saturn emulators|Saturn]]), the Audio-CD portion of a disc was frequently reduced to a single warning track advising users not to play the disc in a conventional [[Home media players|home stereo]] ("Do not play this in a conventional CD player"). Despite this shift, several prominent titles continued to rely heavily on Red Book audio like ''Vib-Ribbon'' and ''Wipeout'' (PS1), or ''Battle Garegga'' and ''Daytona USA'' (Saturn).


* '''Full Dump:'''  
Because Mixed-Mode CDs contain multiple tracks, they '''cannot''' be properly archived using standard <tt>.iso</tt> files (which only support a single data track). Instead, data-dumping software typically utilizes one of two methods:
</br>BIN/ISO + CUE
* '''[[Ripping_games#Disc-based|Full Dump]]:'''
</br>BIN/ISO is the full disk data, including Audio-CD sound data and game data
** <tt>.bin</tt>: A raw, sector-by-sector image of the entire disc containing game data, audio tracks, and system data. To qualify as a true full dump, the disc must be ripped in RAW mode (Mode 2/2352), which captures the full 2,352 bytes per sector data across all tracks. Standard 2048-byte sector rips are "cooked" and ''not'' considered RAW or full dumps, as they discard this critical error correction data, making them unsuitable for digital preservation.
</br>CUE is the datasheet file
** <tt>[[cue|.cue]]</tt>: A text metadata file (cue sheet) that instructs the emulator or disc burner exactly where each data and audio track begins and ends.
* '''Light Dump:'''
** <tt>.sbi</tt>: A subchannel data file. Because standard 2352-byte RAW rips do not include the 96 bytes of subchannel data (which would require a non-standard 2448-byte sector that crashes most emulators), separate sidecar files are used. As noted in the [[Ripping games]] guide, certain European PlayStation (PSX) games utilize LibCrypt copy protection stored in these subchannels; for these titles, an accompanying <tt>.sbi</tt> file is required alongside the <tt>.bin/.cue</tt> files in the same directory.
</br>ISO + MP3/WAV + CUE  
* '''Light Dump (ISO + MP3/FLAC/WAV + CUE):'''
</br>ISO is the disk data with only the game data
** <tt>.iso</tt>: Contains ''only'' the data track of the game, typically stripped down to standard 2048-byte user data sectors.
</br>MP3/WAV is the sound data from the Audio-CD, but these formats take much less disk space
** <tt>.mp3/.flac/.wav</tt>: The audio tracks ripped as separate files to save space.
</br>CUE is the datasheet file
** <tt>[[cue|.cue]]</tt>: A modified cue sheet pointing to the separate audio files.


* '''Gain:''' Several hundreds of MBs to just a few dozen, depending on how much this specific game relies on the Audio-CD sound format
;Light Dump
* '''Tools Used:''' Load the BIN+CUE using a virtual drive, then use a CD dumping tool
* '''[[Ripping_games#Preservation_Priority_(Recommended_Workflow)|Archive-quality dump]]?''' No. Even if the audio is kept pristine using a lossless format like FLAC, a Light Dump strips away precise track gaps, write offsets, and subchannel data (like CD-Text or copy protection). It is a preservation compromise for storage saving, not a true archival dump.
* '''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 ISO+BIN file.
* '''Gain:''' Saves several hundred megabytes, depending on how much of the disc was dedicated to red-book audio.
* '''Playable on Hardware?''' No, but can be reverted to be
* '''Tools Used:''' Virtual drive mounters (Daemon Tools, CDEmu) combined with CD ripping software (EAC, TurboRip).
* '''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. You may need Sega Cue Maker.
* '''Can be reverted?''' Partially. If the audio was saved in a lossless format (FLAC/WAV), the audio data itself can be restored bit-for-bit. However, if compressed to MP3, the quality loss is permanent. Furthermore, original disc subchannel structures and offsets cannot be perfectly recreated from a Light Dump.
* '''Playable on Hardware?''' Not directly in this format. It must be recompiled and burned back to a physical CD-R as a BIN/CUE structure.
* '''Playable on Emulators?''' Most modern emulators support loading via the <tt>.cue</tt> file, though emulator support for compressed audio formats (like MP3 or FLAC) varies. If an emulator fails to play the music, the tracks must be converted back to uncompressed WAV, and the <tt>.cue</tt> file edited to reflect the change.


Examples:
Examples:
* Princess Crown (SAT): 574 MB >  
* Princess Crown (SAT): 574 MB > 72 MB (Game Data) + 50 MB (Audio-CD data in MP3 format)
* 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.


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.
Sometimes dumps that come this way may not work on some emulators. This is often due to either an incorrect CUE files using the wrong filenames or using MP3 instead of WAV.


Its purpose can be to fill in some spots in the disk so that specific parts of game data are in specific areas of the disk (like the borders) and hence the drive's reading speed is quick enough in these spots for the game to work properly. It's in the best of your interests not to mess with this data arrangement (referred to as LBA and TOC in the case of GC/Wii/PS2/PSP) or else the game might not even work in some cases (it might in others though).
;Padding
Devs often have their games much, much bigger than they need to be by putting in accessible garbage data in the disc. Garbage data isn't useful game data and is just used to bloat the 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), random data, unused/cut content left during development, and in rare cases, data that 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.


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.
The purpose of doing this can be to fill in spots on the disc so that specific parts of the game's data are in certain areas of the disc. This is done to increase the drive's reading speed so that it's quick enough in certain spots for the game to work properly. It's in the your best interest not to mess with this data arrangement (referred to as LBA and TOC in the case of GC/Wii/PS2/PSP) as it might break the game in some cases.


Of course, there are also the devs who don't merely use garbage data, but also bloat in-game data. For instance, Tengai Makyou IV PSP has 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, so these cases won't be addressed here.
Another reason for having garbage data can be to screw with pirates, who download/upload these games online, by making the ISO bigger and harder to store. Some go a step further and scramble the garbage data, instead of just being a sequence of 00/FF, to make the ISO 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.


Let's go back to normal padding then, and how to remove it:
Many compression schemes remove or simplify padding patterns to allow for easier compression.


===DreamCast===
;Full dump to CHD Compression
* '''[[Ripping_games#Preservation_Priority_(Recommended_Workflow)|Archive-quality dump]]?''' Probably no (because of bugs and missing unimplemented directives<ref>http://problemkaputt.de/psxspx-cdrom-disk-images-chd-mame.htm#CHD_Notes</ref><ref>[https://github.com/mamedev/mame/issues?q=is%3Aissue%20state%3Aopen%20CD%20chd mame issues for chdman tool]</ref> MAME uses the CHD format for disc images in general and includes tools to convert back and forth. Before MAME v145, CHD was in version 4 and it bumped to version 5 from MAME v146 and further. The CHDv5 uses 7zip's LZMA compression on the game data and lossless FLAC compression for the audio data to optimize compression even further than using BIN+CUE+MP3/WAV data separation alone. CHDv5 is lossy until all the bugs are resolved.
* '''Gain:''' Immediate
* '''Tools Used:'''  chdman (included with MAME) ([https://github.com/DesertDoggy/CHDlite/ CHDlite)](Basically a CHDman wrapper with added functions), [https://play.google.com/store/apps/details?id=it.ottaviomiele.chd CHDroid] (for Android), [https://romtools.io/ ROM Tools] (web-based), [https://chd.emulationonline.com/ CHD Creator] (web-based, for converting bin/cue to chd)
* '''Can be reverted?''' Partially. Use extractcd (included with MAME), CHDroid. Multi-track bin files will be combined and chdman will not split the files back when extracting.<ref>http://github.com/mamedev/mame/issues/10308</ref><ref>[https://old.reddit.com/r/emulation/comments/1kdpx87/ymir_a_new_sega_saturn_emulator_for_windowslinux/mqjy0rk/ amroamroamro's comment about chdman for CDs]</ref>
* '''Playable on Hardware?''' No.
* '''Playable on Emulators?''' MAME, DuckStation, PCSX2, PPSSPP, DEmul, NO$PSX, Xemu, Xenia, RPCS3, Cxbx-Reloaded. Some [https://github.com/search?q=repo%3Alibretro%2Flibretro-core-info%20chd&type=code libretro cores] for other emulators are starting to add support.
* '''Can process multi-track bin files?''' Yes.


'''Instructions:'''
Place the chdman executable and extractcd in the same directory as the dumps you want to compress (dumps must be in BIN+CUE format or GDI). Open Command Prompt or a terminal emulator and navigate to the directory where you placed the chdman executable and input one of the following:
* BIN/CUE-GDI to CHD:
Windows: for /R %i in (*.cue, *.gdi) do chdman createcd -i "%i" -o "%~ni.chd"
Linux: for i in *.(cue|gdi); do chdman createcd -i "$i" -o "${i%.*}.chd"; done
* CHD to BIN/CUE:
Windows: for /R %i in (*.chd) do chdman extractcd -i "%i" -o "%~ni.cue"
Linux: for i in *.chd; do chdman extractcd -i "$i" -o "${i%.*}.cue"; done
Alternatively, if you only need to do one file you can simply drag and drop the file on <code>chdman.exe</code>, or use this: <code>chdman createcd -i "<FILENAME>.cue" -o "<FILENAME>.chd"</code>


===GameCube===
==PlayStation==
Dolphin can't play game dumps off compressed archives.  
{| class="wikitable sortable mw-collapsible"
|+PlayStation/PSX Disc-Saving Formats Overview
!
! colspan="2" |ECM
! colspan="3" |PBP
!CHD
|-
|'''Archive Quality?'''
| colspan="2" |No.
| colspan="3" |No.
|[[#Before_we_begin|Probably no]].
|-
|'''Gain?'''
| colspan="2" |When compressed.
| colspan="3" |Immediate.
|Immediate. (Best.)
|-
|'''Revertable?'''
| colspan="2" |Lossy.
| colspan="3" |Lossy.
|[[#Before_we_begin|Probably no]].
|-
|'''Hardware Playable?'''
| colspan="2" |No.
| colspan="3" |(PSP's PSX environment, only.)
|No.
|-
|'''Emulator Playable?'''
|ePSXe
|PCSX-R
|DuckStation
|ePSXe
|PCSX-R
|Seven known. See below.
|}


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.
===ECM===
* '''Archive-quality dump?''' No (removes error correction data permanently)
* '''Gain:''' Not Immediate (ISO size doesn't change). ECM only zeroes out redundant error correction data, but in some rare cases this data may be used for anti-piracy, hence corrupting the dump! However it does achieves drastic size reductions when compressed to an archive format (7zip/gzip/zip) .
* '''Tools Used:'''  PakkISO or ECM Tools. Drag-and-drop the ISO onto the specified tool, then compress it with 7zip.


However compressed formats incorporating the "padding zeroing" part were made since then, and Dolphin supports them! (Of course, if you're into modding/rom-hacking games, the previous tools might be of interest to you, but this is a story for another time...)
* '''Can be reverted?''' Yes, using the same tools (unECM), however there is data loss (error correction data) which can damage a select few games. Check the hash with Redump to make sure nothing was altered.
* '''Playable on Hardware?''' No.
* '''Playable on Emulators?''' Only on recent SVN builds of PCSX-R and ePSXe (they also support 7zip/gzip/zip archives so use them with ECM).


====GCZ (Dolphin native archive format) - GC/Wii====
===PBP (PSP Format for PS1 Images)===
* '''Gain:''' Immediate (ISO dump size lowers). Considerable, depending on game.
* '''Archive-quality dump?''' No
* '''Tools Used:''' Dolphin emulator
* '''Gain:''' Immediate (ISO size decreases a lot).
</br>You need to add the games in your game list under Dolphin (Configuration/Paths).
* '''Tools Used:''' [https://www.reddit.com/r/PSP/wiki/psx2psp PSX2PSP], Popstation MD GUI, [https://github.com/sahlberg/pop-fe POP-fe] (PS3-friendly), ...
</br>Select game in game list (you can hold Shift and select multiple ones).
* '''Can be reverted?''' Yes. For homemade EBOOTs it can be done by using the same tool to generate the BIN+CUE files. For commercial releases from PSN you will have to use [https://github.com/xdotnano/PSXtract PSXtract]. There's data loss, but it's negligible in terms of functionality.
</br>Right-click and choose "Compress selected ISOs". Choose a directory.
* '''Playable on Hardware?''' On PSP, not on PS1.
</br>It saves a compressed GCZ copy. You might want to delete the original uncompressed ISO.
* '''Playable on Emulators?''' PCSX-R, DuckStation and ePSXe. PlayStation 3's ps1_netemu can also use it after packaging it into a PS1 Classic and installing said package.


* '''Can be reverted?''' Yes. You can right-click on the GCZ-compressed (in blue) ISOs in Dolphin and choose "Uncompress selected ISOs". Garbage data is still there but zeroed out, which has no effect since it's randomized anyways.
PBP is the official format used by Sony for the PS1 Classics on PSP and PS3. Audio tracks may be compressed in ATRAC3 or as raw PCM (unsupported on PS3's ps1_netemu, supported on PSP only by the earliest versions of POPS or the newest ones with the [http://wololo.net/talk/viewtopic.php?f=28&t=41330&start=60 cdda_enabler plugin])
 
It is possible to combine multiple disc .BIN files (not tracks, use [https://github.com/putnam/binmerge binmerge] for tracks) into one .PBP using PSX2PSP or POP-fe (Need to play enough to confirm)
 
===CHD===
* '''Archive-quality dump?''' [[#Before_we_begin|Probably no]], '''be sure to use a recent version, especially for CD-based titles (e.g.: get chdman from the last [https://github.com/mamedev/mame/actions MAME package])'''
* '''Gain:''' Immediate (better than PBP).
* '''Tools Used:'''  chdman
* '''Can be reverted?''' [[#Before_we_begin|Probably no]], use the same tool (chdman).
* '''Playable on Hardware?''' No.
* '''Playable on Emulators?''' libretro Beetle PSX, Avocado, DuckStation, PCSX2 (since March of 2021 and also because PCSX2 now has PSOne emulation functionality as well, so two-in-one), ares, PCSX ReARMed and NO$PSX.
 
==PlayStation 2==
{| class="wikitable sortable mw-collapsible"
|+PlayStation2/PS2 Disc-Saving Formats Overview
!
!Manual+GZip
!CSO/CISO
!ZSO/ZISO
!CHD
!Scrub+CHD
|-
|'''Archive Quality?'''
|No.
|Yes.
|Yes.
|Probably yes (for DVDs).<br>[[#Before_we_begin|Probably no]] (for CDs).
|No.
|-
|'''Gain?'''
|When compressed.
|Immediate.
|Immediate.
|Immediate.
|''Massive.''
|-
|'''Revertable?'''
|No.
|Lossless.
|Lossless.
|Probably yes (for DVDs).<br>[[#Before_we_begin|Probably no]] (for CDs).
|No.
|-
|'''Hardware Playable?'''
|Yes.*
|No.
|Yes.
|No.
|No.
|-
|'''Emulator Playable?'''
|PCSX2.*
|PCSX2.
|PCSX2.
|PCSX2.
|PCSX2.*
|}
 
===Manual Scrubbing + GZIP Compression===
Often times you can just open the ISO in UltraISO and find the dummy files. Sometimes they are obvious looking files, like DUMMY.BIN, DATA0.BIN (or .DAT), DUMMY.DAT, etc., or are folders with names like "PADDING" and such. You can look into the files (with a hex editor) to see if they're obviously padding data (usually the offsets will be 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.--><!--Wording is too weird to figure out what it's say, will fix when more information is obtained-->
 
* '''Archive-quality dump?''' No (missing data)
* '''Gain:''' Not Immediate (ISO dump size the same), however when used with compression the gain is really noticeable.
* '''Tools Used:'''  UltraISO, USBUtil, ExPERT/Xpert ([http://www.ps2-home.com/forum/viewtopic.php?t=3419 guides here])
* '''Can be reverted?''' Not really. Garbage data here is zeroed out, it's not important and you still have the same disk data structure.
* '''Playable on Hardware?''' Yes (after GZIP-decompression) (some games may break)
* '''Playable on Emulators?''' Yes - PCSX2 (some games may break)
 
You may forego the manual scrubbing part entirely. If you feel adventurous you might want to do it to enhance compression though. Let's get to the meaty part though...
 
The PCSX2 emulator supports opening compressed archives containing ISOs. The best format it supports would be '''GZIP'''.
 
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.
 
A simple method to mass convert a lot of PS2 ISO games to GZIP is this script when run in PowerShell.  However, it'll take many hours or days depending on the size of the collection.
<blockquote>dir *.iso | ForEach-Object { & "C:\Program Files\7-Zip\7z.exe" a -tgzip -mx9 -sdel ($_.Name+".gz") $_.Name }</blockquote>
 
===CSO (aka CISO)===
* '''Archive-quality dump?''' Yes
* '''Gain:''' Immediate (ISO dump size the same). Coupled with manual scrubbing, it can be bigger. Not as much of a gain as GZIP though.
* '''Tools Used:''' maxcso
* '''Can be reverted?''' Yes, using the same tool. No data loss.
* '''Playable on Hardware?''' NO
* '''Playable on Emulators?''' Yes - PCSX2.
 
===ZSO (aka ZISO)===
* '''Archive-quality dump?''' Yes
* '''Gain:''' Immediate (ISO dump size the same). Coupled with manual scrubbing, it can be bigger. Not as much of a gain as GZIP though.
* '''Tools Used:''' [https://github.com/Danixu/ziso_compressor ziso compressor], [https://github.com/unknownbrackets/maxcso#features maxcso], [https://github.com/ps2homebrew/Open-PS2-Loader/blob/master/pc/ziso.py ziso.py (requires python3 and pip install lz4)], [https://www.psx-place.com/resources/psxiso-compression-tool.1258/ PSXiSO (contains ziso CLI tool)]
* '''Can be reverted?''' Yes, using the same tool. No data loss.
* '''Playable on Hardware?''' Yes - Open PS2 Loader.
* '''Playable on Emulators?''' Yes - PCSX2 (since v1.7.5293)<ref>[https://github.com/PCSX2/pcsx2/releases/tag/v1.7.5293 v1.7.5293]</ref>
 
===CHD===
* '''Archive-quality dump?''' Probably yes (for DVDs), [[#Before_we_begin|Probably no]] (for CDs). '''Be sure to use a recent version (e.g.: get chdman from the last [https://github.com/mamedev/mame/actions MAME package])'''
* '''Gain:''' Immediate (better than GZIP).
* '''Tools Used:'''  chdman
* '''Can be reverted?''' Probably yes (for DVDs). [[#Before_we_begin|Probably no]] (for CDs). Use the same tool (chdman).
* '''Playable on Hardware?''' Yes, via UDPFS
* '''Playable on Emulators?''' Yes - PCSX2 (since v1.7.0-dev-1156)<ref>Added in 1150 but wasn't built. 1156 is the first release with CHD support. [https://web.archive.org/web/20210416020418/https://buildbot.orphis.net/pcsx2/index.php?m=fulllist Automated Pcsx2 builds]</ref>
* '''Note:''' List of titles that are [http://redump.org/discs/system/ps2/media/dvd/ DVD] and [http://redump.org/discs/system/ps2/media/cd CD] (or more up-to-date info, but no DVD/CD filter yet: https://redump.info/discs?system=PS2). Make sure to use ''createdvd'' command for DVD titles and ''createcd'' command for CD titles.[https://github.com/hrydgard/ppsspp/issues/18798#issuecomment-1919666370].
* '''Note:''' The latest android builds of AetherSX2 and NetherSX2 use an out-of-date chdman version which does [https://github.com/Trixarian/NetherSX2-patch/issues/37 not support CHD files built with createdvd]. For these android emulators, the ''createcd'' command will generate readable chd files. See also [https://github.com/dragoonDorise/EmuDeck/issues/1128 this thread] on the topic.
 
You can use the cmd script mentioned in CHD section in the beginning, just replace the extensions with .iso and add '''-hs 2048''' for slightly smaller filesize when using LZMA compression algorithm.
 
===Ultimate space-saving (Scrubbing + CHD)===
The smallest file size can be achieved by combining two methods of [[Save_disk_space_for_ISOs#Manual_Scrubbing_.2B_GZIP_Compression| Scrubbing]] and [[Save_disk_space_for_ISOs#CHD_2|CHD]].
 
* '''Archive-quality dump?''' No (missing data)
* '''Gain:''' ''Massive''
* '''Tools Used:''' USBUtil and chdman
* '''Can be reverted?''' No
* '''Playable on Hardware?''' No
* '''Playable on Emulators?''' Yes - PCSX2 (some games may break)
 
This only works on a few titles (2 out of 21 tested). Scrub using USBUtil, then convert scrubbed .iso to .chd.
 
Here's a file size comparison for God Of War:
 
{| class="wikitable" style="margin:left"
|-
! !!colspan=2| Unscrubbed !!colspan=2| Scrubbed
|-
| '''ISO''' || 7.46 GB || 100% || 3.62 GB || 100%
|-
| '''ISO→CHD''' || 5.73 GB || 76.81% || 2.92 GB || 80.67%
|-
| '''Total gained''' || 1.73 GB || -23.19% || 0.70 GB || -19.33%
|}
 
The ISO was reduced by '''4.54 GB''', a ''staggering 60.85% reduction.''
 
==PlayStation 3==
===Extracted files (aka JB format/GAMES)===
* '''Archive-quality dump?''' Not directly (BD filesystem metadata lost).
* '''Gain:''' Immediate (any padding between files is removed).
* '''Tools Used:''' [https://github.com/13xforever/ps3-disc-dumper ps3-disc-dumper], Most on-console file managers and *man homebrews, 7-Zip and other standard ISO extractors on PC.
* '''Can be reverted?''' Yes, using PS3 ISO Rebuilder and an [http://jonnysp.bplaced.net/ IRD file] representing the original file locations. Generic inaccurate JB to ISO conversions possible with makeps3iso (preferred) or genps3iso.
* '''Playable on Hardware?''' Yes - on CFW/HEN
* '''Playable on Emulators?''' Yes - RPCS3
 
For a long time (before the availability of Cobra and Mamba) the only playable format for PS3 backups (relying on little more than "peek and poke" CFW-provided syscalls to mount the game's folder over the currently inserted disc) but also the least accurate one, with significant compatibility issues (varying on whether the backup is stored on an internal or external drive, whether an original game disc is currently inserted, various optional hacks such as "BDMirror" moving the files to the root of the external drive on demand, ...)
 
==PlayStation Portable==
===CSO (aka CISO)===
* '''Archive-quality dump?''' Maybe: while the actual compression is inherently lossless, depending on the conversion software and/or its configuration, so-called ripping (deletion or zero-resizing of the system update, videos, or other files) may be performed on the fly.
* '''Gain:''' Immediate (ISO dump size lowers). Substantial, depending on game. Higher compression levels generally produce decreasing space gains while potentially increasing load times. Some tools allow for leaving audio/video content uncompressed.
* '''Tools Used:''' [https://romtools.io/ ROM Tools](web-based), CISO, CISO GUI, maxcso, UMDGen, PSP ISO Compressor, CISO Multi Compressor, CISO XP, ...
* '''Can be reverted?''' Yes, using the same tools and saving in ISO (uncompressed) format. No data loss.
* '''Playable on Hardware?''' Yes - most CFWs (Possibly longer load times though).
* '''Playable on Emulators?''' Yes - PPSSPP.
 
CISO GUI and CISO XP: Drag-and-drop ISO file on program, Select compression level (1 to 9 (Max)), "Compress", and choose directory for saving the new CSO file.
 
UMDGen is a PSP ISO editor. You can save to either the CSO format with this.
 
===DAX, JSO, ZSO===
Three different compressed-ISO formats. Significantly lower popularity/support than CSO.
 
===PBP===
* '''Archive-quality dump?''' ???
* '''Gain:''' Immediate (ISO dump size lowers).
* '''Tools Used:'''  ISO~PBP Converter, or Sign~Fake NP Expert
* '''Can be reverted?''' Yes
* '''Playable on Hardware?''' Yes - CFWs (and, if signed, OFWs too).
* '''Playable on Emulators?''' Yes - PPSSPP.
 
Official format for digitally distributed PSP/minis (partially related to the one used for PS1 games), containing a compressed disc image and optionally a custom boot logo.
 
To bulk convert ISOs to PBPs using ISO-PBP Converter, use this cmd script.
<blockquote>for %i in (*.iso) do IsoPbpConverter.exe "%~fi" -c -f "%~fi.PBP"</blockquote>
 
===CHD===
* '''Archive-quality dump?''' Probably yes.
* '''Gain:''' Immediate (Filesize is smaller than PBP in most cases).
* '''Tools Used:'''  chdman
* '''Can be reverted?''' Probably yes, using the same tool (chdman).
* '''Playable on Hardware?''' No.
* '''Playable on Emulators?''' Yes - PPSSPP.
* '''Note:''' Make sure to use ''createdvd'' command for UMD titles.[https://github.com/hrydgard/ppsspp/issues/18798#issuecomment-1919666370][https://github.com/hrydgard/ppsspp/pull/18803] You can use the cmd script mentioned in CHD compression section, just replace the extensions with .iso and add '''-hs 2048''' for slightly smaller filesize when using LZMA compression algorithm.
 
==Dreamcast==
===CHD Archive Format===
* '''Archive-quality dump?'''
** CHD v4: No (missing data due to lossy compression, no gameplay issues).
** CHD v5: Possibly Archive-quality.
* '''Gain:''' Immediate (ROM dump size lowers).
* '''Tools Used:''' chdman (with [https://wiki.recalbox.com/en/tutorials/utilities/rom-conversion/chdman GDI to CHD converter script]).
* '''Can be reverted?''' Yes with CHD v5.
* '''Playable on Hardware?''' No
* '''Playable on Emulators?''' Yes - DEmul, Reicast, Flycast, and Redream
 
==GameCube / Wii==
 
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.
 
However compressed formats incorporating the "padding zeroing" part were made since then, and Dolphin supports them! These are the WBFS and GCZ formats.
 
Dolphin can't play games directly from compressed archives (7zip/zip/gzip/rar...)<ref>https://forums.dolphin-emu.org/Thread-dolphin-s-support-of-archive-files?pid=513604#pid513604</ref>. Instead, it utilizes its own compression method.
 
===GCZ (Dolphin native archive format) - GC/Wii===
 
'''This format has been deprecated in favor of [[#RVZ (Modern Dolphin format) - GC/Wii|RVZ]].'''
 
* '''Archive-quality dump?''' Yes (Not directly if scrubbed; see reverting notes)
* '''Gain:''' Immediate. Depends on the game. It is very minimal if junk data is not removed (scrubbed).
* '''Tools Used:''' Dolphin (right-click the game(s) in the games list and select "Convert File..." (or "Convert Selected Files..." if more than one is selected), and select GCZ), or [https://wit.wiimm.de/ wit (Wiimms ISO Tools)], Nkit (for indirect recovery)
* '''Can be reverted?''' Yes (Directly for non-scrubbed files. For scrubbed files, first convert to ISO, then use Nkit tool's "Recover to ISO" option)
* '''Playable on Hardware?''' No
* '''Playable on Hardware?''' No
* '''Playable on Emulators?''' Only Dolphin.
* '''Playable on Emulators?''' Yes (Dolphin)
 
===RVZ (Modern Dolphin format) - GC/Wii===


====WBFS - Wii-only====
The Dolphin team developed a new compression format based on WIA called RVZ. Usage is very similar to GCZ in Dolphin itself, but it only works on newer Dolphin versions. It can efficiently compress both the actual data and junk data, without altering the file/directory structure.
* '''Gain:''' Immediate (ISO dump size lowers). Considerable, depending on game.
* '''Tools Used:''' Wii Backup Manager
</br>Under the "Files" section, choose "Add" then choose the ISO file you're converting.
</br>Tool is compatible with ISO, CSO (aka CISO) and WBFS disk dumps. When you're done, select the ISO files you added.
</br>Under "Transfer", use the destination format. So, in our case, WBFS. Choose the directory to save it.
</br>It saves a copy in the WFBS format. You might want to delete the original uncompressed ISO.


* '''Can be reverted?''' Yes. You "Add" the WBFS disk dump and "Transfer" it to the "ISO" format. Garbage data is still there but zeroed out, which has no effect since it's randomized anyways.
* '''Archive-quality dump?''' Yes
* '''Playable on Hardware?''' Yes!! WBFS dumps are playable on Wii.
* '''Gain:''' Immediate. Considerable, depending on the game.
* '''Playable on Emulators?''' Yes - Dolphin
* '''Tools Used:''' Dolphin 5.0-12188+ (right-click the game(s) in the game list and select "Convert File..." (or "Convert Selected Files..." if more than one is selected), and select RVZ)
* '''Can be reverted?''' Yes (In Dolphin, right-click the game, select "Convert File..." and select ISO)
* '''Playable on Hardware?''' No
* '''Playable on Emulators?''' Yes (Dolphin 5.0-12188+)


====CSO (aka CISO) - Wii-only====
[https://github.com/ElektroStudios/Dolphin_Emulator_RVZ_ISO_GameCube_Wii_Conversion_Scripts Dolphin RVZ/ISO Conversion Scripts]: A set of PowerShell and Batch scripts that automate bulk conversion between ISO and RVZ formats using DolphinTool.exe. Useful for converting large libraries without manually using the Dolphin GUI.
 
===Scrubbing and Trimming - GC/Wii===
* '''Archive-quality dump?''' Not directly, see note about reversing.
* '''Gain:''' Not Immediate for just scrubbing (ISO dump size the same); Immediate for trimming (ISO dump size lowers).
* '''Tools Used:''' GC-Tool ("wipe garbage data..." - Scrubbing for GameCube), GameCube ISO Trimmer (scrubbing and trimming for GameCube), WiiScrubber (scrubbing/trimming for Wii, although compressing with Dolphin will scrub it anyways).
* '''Can be reverted?''' Yes, with WiiScrubber's undo file or NKit.
* '''Playable on Hardware?''' Yes for scrubbed; some games won't work trimmed.
* '''Playable on Emulators?''' Yes for scrubbed; some games won't work trimmed.
 
Scrubbing games zeros out garbage/dummy data in the ISO file. The resulting file will be the same size, but it will be able to compress better than unmodified ISOs. The difference can be huge depending on the game. Animal Crossing, for instance, will compress to just a 26 MB .gcz file after being scrubbed!
 
Trimming (also known as "trucha scrubbing", and substantially different from the definition of "trimming" used in ROM-based systems) games will also defragment the files moving them towards the start of the disc image, resulting in a smaller ISO file. The trimmed file can be used immediately at a smaller size without compression, but the game's internal structure will be wholly modified. '''Games relying on direct sector access (as opposed to consulting the filesystem) will break if you trim them.'''
 
===WBFS - Wii only===
* '''Archive-quality dump?''' Not directly; see reverting notes.
* '''Gain:''' Immediate (ISO dump size lowers). Considerable, depending on the game.
* '''Tools Used:''' [http://www.wiibackupmanager.co.uk/downloads.html Wii Backup Manager] (after adding your game, go to "Transfer" and select "WBFS") or wit (Wiimms ISO Tools).
* '''Can be reverted?''' Maybe. WBFS files can always be converted back to ISO, but they will remain scrubbed (can be unscrubbed with NKitRestore) and, depending on settings at the time of conversion to WBFS, may be missing update/extras partitions (can be readded with wit or NKitRestore and a copy of the missing data).
* '''Playable on Hardware?''' Yes - Preferred format by most SD/USB loaders
* '''Playable on Emulators?''' Yes (Dolphin)
 
A scrubbed and sparse (gap-dropping) format directly derived from the one used in the obsolete WBFS file system.
 
Ideal space-saving option for Wii games to be played via an USB loader.
 
===CSO (aka CISO) - GC/Wii===
* '''Archive-quality dump?''' Not directly, see note about reversing.
* '''Gain:''' Immediate (ISO dump size lowers). Less than WBFS.
* '''Gain:''' Immediate (ISO dump size lowers). Less than WBFS.
* '''Tools Used:''' Wii Backup Manager. Same as above, but "Transfer" to "CISO".
* '''Tools Used:''' Wii Backup Manager (same as above, but select "CISO" - possibly Wii only), wit
* '''Can be reverted?''' Yes. You "Add" the CSO disk dump and "Transfer" it to the "ISO" format. Garbage data is still there but zeroed out, which has no effect since it's randomized anyways.
* '''Can be reverted?''' Maybe (same caveats as WBFS).
* '''Playable on Hardware?''' Yes (on Wii/Vwii only) - Nintendont for Gamecube games, uLoader for Wii games
* '''Playable on Emulators?''' Yes (Dolphin)
 
A scrubbed and sparse (gap-dropping) format. Unrelated to the PSP's CSO format.
 
Great space-saving option for Gamecube games to be played on Nintendont.
 
===FST (extracted File System) - GC/Wii===
 
* '''Archive-quality dump?''' No (Yes, if not scrubbed)
* '''Gain:''' Very low with GC ISOs, much better with Wii ones. Can also be combined with classic archives compression (ZIP/RAR/7z etc.) to match WIA and NKit compression ratios.
* '''Tools Used:''' [https://wit.wiimm.de/info/composing.html wit]
* '''Can be reverted?''' Partially via the align-files.txt created by wit when extracting.
* '''Playable on Hardware?''' GC games on Wii/Vwii: Yes ([https://github.com/FIX94/Nintendont/ Nintendont]) / Other combinations: No
* '''Playable on Emulators?''' Yes (Dolphin)
 
This has the advantage of easy experimenting with [[#Destructive Modification]]. Includes all disadvantages of trimming.
 
===WIA (Wii ISO Archive) - GC/Wii===
* '''Archive-quality dump?''' Not directly; see reverting notes (Yes, if not scrubbed)
* '''Gain:''' Immediate (ISO dump size lowers); more than WBFS. (No gain if not scrubbed and compression not used)
* '''Tools Used:''' wit, Dolphin 5.0-12188+, Nkit (for indirect recovery)
* '''Can be reverted?''' Yes (Directly, if not scrubbed. Not directly, if scrubbed, by converting it to ISO first, and then using Nkit tool's "Recover to ISO" option)
* '''Playable on Hardware?''' No
* '''Playable on Emulators?''' Yes (Dolphin 5.0-12188+)
 
A scrubbed and compressed format designed for maximum space savings without cutting corners on corruption detection, but it's not directly editable. Never really caught on and may be considered de-facto deprecated by NKit.
 
===NKit formats - GC/Wii===
'''This format has been deprecated in favor of [[#RVZ (Modern Dolphin format) - GC/Wii|RVZ]]. ([https://github.com/Nanook/NKit/wiki Developer's Wiki])'''
* '''Archive-quality dump?''' Yes (Not for Wii games, if the Wii update partition is removed and the recovery file not preserved)
* '''Gain:''' Immediate
* '''Tools Used:''' NKit
* '''Can be reverted?''' Yes (unless the Wii update partition was removed and the recovery file not preserved)
* '''Playable on Hardware?''' GC: Yes (ISO variant only) / Wii: No
* '''Playable on Emulators?''' Yes (Dolphin)
 
Apart from its previously mentioned unscrubbing/untrimming features mentioned in the above formats' descriptions, NKit is able to convert any ISO (clean dump or otherwise) to and from an [https://wiki.gbatemp.net/wiki/NKit/NKitFormat intermediate format applying various reversible changes] that optimize the image for lossless compression, including full decryption and optionally splitting the often non-unique update partitions to separate files.
 
NKit.GCZ is less space efficient than NKit.ISO compressed with a powerful general purpose archiver (7zip), however it is directly playable in Dolphin.
 
It has problems with emulation, such as slower emulated load times, breaking netplay if load times aren't the same, and crashing a few games.
 
Compressing NKit.ISO with a strong compression format gives the smallest size while being reversible.
 
==Wii U==
All uncompressed WUD dumps are 23.3GB, which makes compression needed de facto. Some examples:
* Super Mario World 3D: 23.3GB > 2.61GB (88% gain)
* New Super Mario Bros. U: 23.3GB > 1.8GB (92% gain)
* Donkey Kong Country Tropical Freeze: 23.3GB > 11.7GB (49% gain)
 
===WUX (Wii U Compressed Image Dump Archive)===
* '''Archive-quality dump?''' Yes (lossless, doesn't actually alter the data).
* '''Gain:''' Immediate (smaller file than WUD): Around 50% gain usually (depending on the game)
* '''Tools Used:''' [http://mega.nz/#!llQwyQQZ!58fErjqM7pyQZKFKe0Qlu1yLP5EbtmOmiDUN1ElW07c wud tool]. To use, drag-and-drop the ISO on the executable.
* '''Can be reverted?''' Yes. The wud tool includes a decompression utility, which recreates the original file.
* '''Playable on Hardware?''' No (can be converted to an installable format using [https://github.com/FIX94/wud2app wud2app])
* '''Playable on Emulators?''' Yes - Cemu (and potentially other [[Wii U emulators]])
 
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.
 
===APP (aka NUS/Installable Format)===
* '''Archive-quality dump?''' No in regard to discs; Partially in regard to CDN data.
* '''Gain:''' Immediate (Total size decreases, compared to disc image)
* '''Tools Used:''' wud2app (disc image to APP), disc2app (original disc to APP), NUSPacker (extracted format to APP), Teconmoon's WiiVC Injector (Wii/Gamecube disc image to Enhanced Vwii APP), ...
* '''Can be reverted?''' No
* '''Playable on Hardware?''' Yes (after installation)
* '''Playable on Emulators?''' Yes - Cemu recently implemented it with auto-scanning of DLC/Update
 
Consisting of a folder containing *.app, *.h3, title.cert, title.tik, and title.tmd files, this official Nintendo format is how tiles are stored on discs and some system titles are stored on the console and is very similar to how titles are stored on the CDN (on the CDN the files are named differently, .app files are encrypted with the title key and common keys and the tmd has a  certificate chain on the end that is same for every tmd). This is equivalent to the files contained within a 3DS CIA file; however unlike a 3DS title, converting a disc title to digital does not require modifying the title itself, thus leaving the title's signatures valid.
 
===RPX/RPL (aka Installed/Extracted/Loadiine Format)===
* '''Archive-quality dump?''' No (dump is extracted to individual files)
* '''Gain:''' Immediate (Total size decreases). Can be less than a WUX depending on the game.
* '''Tools Used:''' see below
* '''Can be reverted?''' No, any padding/file order/signature information is lost.
* '''Playable on Hardware?''' Yes, use [https://github.com/dimok789/loadiine_gx2/releases Loadiine GX2]
* '''Playable on Emulators?''' Yes
 
Titles installed to USB or MLC are stored in this format, comprised of three "code", "content", and "meta" folders.
 
Can be extracted from disc images with DiscU, UWizard ([http://digiex.net/guides-reviews/console-guides/nintendo-wii-u-guides/14680-wii-u-wud-loadiine-gx2-conversion-extract-wud-images-loadiine-use.html follow this guide for usage information]) or JWUDTool, and from the installable format using JNUSTool. Can be converted to installable format with NUSPacker.
 
Ideal format for game modding, less so for playing on console due to Loadiine's intrinsic modus operandi (appearing to the OS as the host title, with potentially different permissions) leading to poor compatibility.
 
===WUA (Wii U Archive)===
* '''Archive-quality dump?''' No (based on extracted format, see above)
* '''Gain:''' Immediate (Total size decreases, adds compression to the extracted format).
* '''Tools Used:''' Cemu (introduced in v1.27)
* '''Can be reverted?''' No (based on extracted format, see above)
* '''Playable on Hardware?''' No
* '''Playable on Hardware?''' No
* '''Playable on Emulators?''' Yes - Dolphin
* '''Playable on Emulators?''' Yes - Cemu (since v1.27)
 
Cemu (since 1.27) can convert installed titles to WUA, combining  the title itself, update (if available) and DLC (if available) into one file. The conversion tool is available via the Cemu title manager.
Based on a small testset of 44 titles with updates and dlc, WUA reduced the overall file size by roughly 16%. It also reduced the number of files per title from 3,500 on average to 1.
(archives compressed in the ZSTD format)
 
==Xbox==
Xbox emulation uses the [[Ripping_games|XISO]] format.
 
===Rebuilt XISO===
XISO extract (Manual Scrubbing), then repackaging to XISO again (a.k.a Ditching the VOB-side of things)
* '''Archive-quality dump?''' No (dump strips the DVD video portion or padding portion of the drive to focus on the game executables and assets.)
* '''Gain:''' Immediate (total file size decreases). Gains of 10-90% savings are not uncommon.
* '''Tools Used:''' [https://github.com/XboxDev/extract-xiso extract-xiso], [https://xiso.antangelo.com/ xiso.antangelo] and other known tools use some variation of [https://github.com/antangelo/xdvdfs XDVDFS].
* '''Can be reverted?''' No.
* '''Playable on Hardware?''' No.
* '''Playable on Emulators?''' Yes - [[xemu]].
 
===CHD===
* '''Archive-quality dump?''' Probably yes? '''Be sure to use a recent version of chdman (e.g.: get chdman from the last [https://github.com/mamedev/mame/actions MAME package])'''
* '''Gain:''' Immediate.
* '''Tools Used:'''  chdman
* '''Can be reverted?''' Probably yes? Use the same tool (chdman).
* '''Playable on Hardware?''' No.
* '''Playable on Emulators?''' [https://github.com/xemu-project/xemu/pull/2809 WIP]
* '''Note:''' Make sure to use ''createdvd'' command for Xbox XGD DVD titles. You can use the cmd script mentioned in CHD section in the beginning, just replace the extensions with .iso and add '''-hs 2048''' for slightly smaller filesize when using LZMA compression algorithm.
 
===CCI===
* '''Archive-quality dump?''' Not really, the format does not currently embed [[Ripping_games#Microsoft_Xbox|additional disc security]] or manufacturing-specific data, as this is generally unnecessary for standard playback. However, the architecture is designed for extensibility; it supports additional metadata payloads that can be integrated in the future without breaking compatibility with existing loaders. Aside from the core structural data, the format does not embed any other metadata at this time.
* '''Gain:''' Immediate.
* '''Tools Used:''' [https://github.com/Team-Resurgent/Repackinator/releases repackinator], [https://github.com/Team-Resurgent/XboxToolkit XboxToolkit], [https://github.com/astarivi/OGXRepacker OGXRepacker]
* '''Can be reverted?''' Yes, using the same tool (repackinator).
* '''Playable on Hardware?''' With [[homebrew]].
* '''Playable on Emulators?''' [https://github.com/xemu-project/xemu/pull/2808 WIP]
 
==Xbox 360==
Xbox 360 emulation typically utilizes the [[Ripping_games|XISO]] format. While using compression formats is highly preferred over keeping raw 8.5 GB images, the conversion processes are often too substantial and irreversible to be suitable for archival purposes, as they alter the underlying data structure tables.
 
===XEX (Xbox Executable) + Data Folder===
Often referred to as "spilling the ISO guts," this method extracts the raw assets and executable directly from the image.
 
* '''Archive-quality dump?''' No (the dump is collapsed into individual files and the original filesystem structure is lost).
* '''Gain:''' Immediate (total file size decreases significantly depending on the game).
* '''Tools Used:''' XBOX 360 ISO Extract, Exiso-GUI, or Exiso. (These are also highly useful for ROM hacking).
* '''Can be reverted?''' The ISO can be rebuilt, but not accurately to the original disc layout.
* '''Playable on Hardware?''' Yes, via a JTAG or RGH exploited console.
* '''Playable on Emulators?''' Yes (Xenia Canary and Xenia Edge).
 
===ZAR (ZArchive)===
A compressed archive format using ZSTD compression. '''It is created from previously decrypted and extracted XEX + Data folder dumps'''. Support for loading these directly was introduced via a [https://github.com/xenia-canary/xenia-canary/pull/165 pull request].
 
* '''Archive-quality dump?''' No (relies on an already extracted, un-archival data structure).
* '''Gain:''' High (combines the file-size reduction of extraction with ZSTD compression into a single neat file).
* '''Tools Used:''' [https://github.com/Exzap/ZArchive/releases ZArchive] tool or the built-in `xenia-canary -> create Zar package` option. For digital content/XBLA, "[https://digiex.net/threads/wxpirs-extract-content-from-xbox-360-demos-video-dlc-and-arcade-game-containers.9464/ wxPirs]" is required first to unpack containers.
* '''Can be reverted?''' No. While it can be unpacked back to loose XEX files, the original disc layout and padding data are already permanently lost.
* '''Playable on Hardware?''' No.
* '''Playable on Emulators?''' Yes (Xenia Canary and Xenia Edge).
 
===GoD (Games on Demand)===
GoD is the Xbox 360's hard drive installation format. GoD packages contain container metadata used by the Xbox 360 dashboard to identify and display installed titles. This metadata may also prove useful for future emulator dashboard implementations.
 
* '''Archive-quality dump?''' No (it is a proprietary digital container conversion and does not preserve the original optical disc layout).
* '''Gain:''' Moderate (removes system padding).
* '''Tools Used:''' ISO2GOD.
* '''Can be reverted?''' No.
* '''Playable on Hardware?''' Yes (native support as installed digital content).
* '''Playable on Emulators?''' No.
 
===Rebuilt XISO===
This method involves manually scrubbing an ISO and repackaging it back into an XISO format (effectively ditching the VOB/video side of the disc partition).
 
* '''Archive-quality dump?''' No (missing standard system data).
* '''Gain:''' Immediate (total file size decreases by removing empty padding).
* '''Tools Used:''' ISO2GOD (acting as an image rebuilder). Under settings, set the output and rebuild path to the same location, check "Always save rebuilt ISO", and set Padding to "Full (ISO Rebuild)". Add the ISO, click "Convert", keep the newly generated ISO, and delete the generated GoD folder.
* '''Can be reverted?''' No. The original padding quantity information and specific data structures are permanently lost.
* '''Playable on Hardware?''' Yes, provided the rebuilding process did not damage vital game files.
* '''Playable on Emulators?''' Yes (Xenia Canary and Xenia Edge).
 
===CCI (Compressed Compact ISO)===
* '''Archive-quality dump?''' Unknown.
* '''Gain:''' Immediate compression benefits.
* '''Tools Used:''' [https://github.com/Team-Resurgent/Simple360CCI Simple360CCI]
* '''Can be reverted?''' Likely yes, by using the same Simple360CCI utility to decompress it.
* '''Playable on Hardware?''' Yes, with [[homebrew]] software.
* '''Playable on Emulators?''' Support is currently a [https://github.com/xenia-canary/xenia-canary/pull/945 work-in-progress (WIP)].
 
=ROM images=
==PlayStation Vita==
===Trimming===
* '''Archive-quality dump?''' No, but trivially undoable.
* '''Gain:''' Immediate (ROM size lowers).
* '''Tools Used:''' None - [https://github.com/motoharu-gosuto/psvgamesd#trimming-zeroes manual process]
* '''Can be reverted?''' Yes (see above).
* '''Playable on Hardware?''' Yes - with psvgamesd.
* '''Playable on Emulators?''' ?
 
The psvgamesd gamecard backup creation and mounting tools supports mounting a trimmed backup (although no tools exist for dumping directly in trimmed format, or converting between full and trimmed.
 
Neither variant of the .psv format (unrelated to the Cobra Blackfin's .psv format) has caught on, despite being the most accurate options for physical game backups.
 
===Extracted files (NoNpDRM format)===
* '''Archive-quality dump?''' No for physical titles, close enough (and generally accepted as such) but no cigar for digital ones.
* '''Gain:''' Immediate (compared to ROM).
* '''Tools Used:''' NoNpDRM plugin + a file manager like VitaShell.
* '''Can be reverted?''' No.
* '''Playable on Hardware?''' Yes - with the NoNpDRM plugin.
* '''Playable on Emulators?''' Yes - Vita3K
 
NoNpDRM is a Vita plugin that generates decrypted licenses (valid for any console) when running an original Vita title, as well as allowing the system to accept those licenses, allowing for playing the encrypted files directly copied from a game card or memory card (by extension the name is therefore also used for such files, or the combination of the game's files and a decrypted license).
 
NoPsmDRM is the equivalent for PlayStation Mobile titles.
 
An hypothetical NoPspEmuDRM, allowing for PSP/PS1 eboots to be natively runnable and manageable from the LiveArea/Content Manager, is currently not known to exist nor believed to be in development.
 
==Switch==
===NSZ===
* '''Archive-quality dump?''' Yes
* '''Gain:''' Immediate (Total size decreases)
* '''Tools Used:''' [https://github.com/nicoboss/nsz nsz]
* '''Can be reverted?''' Only NCAs are fully reversible; compressed XCI and NSP files will be different when decompressed
* '''Playable on Hardware?''' Yes, after installation
* '''Playable on Emulators?''' No
 
It is possible to merge the game base, update and DLCs on a single NSP with the tool [https://github.com/julesontheroad/NSC_BUILDER NSC_Builder] and compress it to NSZ. Alternatively, [https://github.com/sinjunyoung/NSW.M2 NSW.M2] is a lightweight Windows GUI tool that can merge/split containers and decompress NSZ/XCZ on-the-fly.
 
==Game Boy Advance / Nintendo DS / Nintendo 3DS==
===Trimming===
* '''Archive-quality dump?''' No (data removed)
* '''Gain:''' Immediate (ROM dump size lowers).
* '''Tools Used:''' NDSTokyoTrim (GBA/DS/3DS), rom_tool (3DS), GodMode9 (can directly dump DS/3DS cards in trimmed format)<br />NDSTokyoTrim: Drag-and-drop roms, and press "Trim". The original file will be overwritten!
* '''Can be reverted?''' No. Some GBA/DS games may be broken by meaningful data at the end of the ROM being mistaken for padding.
* '''Playable on Hardware?''' Yes, same file format.
* '''Playable on Emulators?''' Yes
 
Trimming involves deleting bytes from the end of the ROM up to until the first different one.
 
However, with no mandatory allocation table, it's not intrinsically possible to identify the true end of the used area, and therefore some GBA/DS games can be broken by naive automated trimming (for example Golden Sun DS).
 
===Compressing (GB/GBA/GBC/NDS only)===
* '''Archive-quality dump?''' Yes.
* '''Gain:''' Immediate (ROM size lowers).
* '''Tools Used:''' 7-Zip
* '''Can be reverted?''' Yes, simply extract the compressed file.
* '''Playable on Hardware?''' Needs confirmation
* '''Playable on Emulators?''' [[mGBA]], [[VisualBoyAdvance-M]], [[melonDS]], [[Gearboy]] only supports .zip, no .7z as of now.
 
mGBA, VBA-M, and melonDS support playing the ROM file directly from a .zip or .7z file. GBA saw a reduction of ~58% in size (~3.7K ROMs, from 32.4GB to 13.5GB), while GB/GBC saw ~68% (~1.8K ROMs, from 1.06GB to 334MB).
 
Script for bulk .7z compression (with best settings):
for %i in (*.gba/gbc/gb/nds) do 7z a "%~ni.7z" "%i" -mmt8 -mx9 -md=256m -mfb=273 -m0=lzma2
 
The 8 in <code>-mmt8</code> parameter can be set to a minimum of 1, and a maximum of the total number of threads on your CPU.
 
===CIA (CTR Importable Archive, 3DS and DSiWare only)===
* '''Archive-quality dump?''' No in regard to gamecard dumps; Partially in regard to CDN data.
* '''Gain:''' Immediate (smaller than original ROM - not applicable to digital titles).
* '''Tools Used:''' GodMode9 (can directly dump 3DS cards or installed titles to CIA, as well as converting 3DS to CIA), 3dsconv or 3DS Simple CIA Converter 5.0+ (3DS rom to CIA); makerom (3DS to/from CIA, NCCHs/DSiWare/ELF+RSF to 3DS/CIA), make_cia (DSiWare to CIA)
* '''Can be reverted?''' No, if starting from a gamecard dump (update partitions removed, main content's ExHeader modified to change the media type from CARD/NAND to SD Application)
* '''Playable on Hardware?''' Yes, after installation.
* '''Playable on Emulators?''' Yes?
 
Official Nintendo format for developers to install digital titles, later became the most popular format for installable homebrew and game backups owing to the relatively low marketshare of flashcards and emulators (and, for the former, strong impopularity) in favor of CFW.
 
Equivalent of the Wii's WAD (for digital titles only) and the DSi's TAD (again for digital titles only, and with basically no popular support due to the lack of any homebrew title installers supporting the format - not to be confused with an homonymous unofficial format nor with the files produced by the official export-DSiWare-to-SD feature)
 
===NCCHs (CXIs and CFAs, 3DS only)===
* '''Archive-quality dump?''' No (partition table/ticket/signatures... removed), compared to CCI/3DS and CIA
* '''Gain:''' Immediate (smaller than original ROM - not applicable to digital titles).
* '''Tools Used:''' GodMode9, ctrtool, ...
* '''Can be reverted?''' No (result will be unsigned)
* '''Playable on Hardware?''' Not really, unless packaged back into a CIA or 3DS.
* '''Playable on Emulators?''' Yes
 
3DS and CIA files, as well as already installed digital titles, are comprised of one or more NCCHs (also called "partitions" or  "contents"): the main content (number 0) can either be an executable CXI for software, or a non-executable CFA for a data title. Additional CFAs may be present, [https://www.3dbrew.org/wiki/NCSD#Overview with conventional index numbers]. [[Citra]] can run CXIs directly.
 
===Z3DS (.zcia, .zcci, .z3dsx, .zcxi)===
* '''Archive-quality dump?''' Yes.
* '''Gain:''' Immediate (smaller than original ROM for decrypted titles; encrypted titles would be compressed terribly).<ref>https://azahar-emu.org/blog/compressed-backups/</ref>
* '''Tools Used:''' zstd (seekable zstd), Azahar (v2123-beta1+)<ref>https://github.com/azahar-emu/azahar/releases/tag/2123-beta1</ref>
* '''Can be reverted?''' Yes
* '''Playable on Hardware?''' Unknown
* '''Playable on Emulators?''' Azahar (v2123-beta1+)
 
=Other Tricks=
==Storage Tricks==
These methods have the advantage of being compatible with EVERY emulator, even those without proper support for compressed ISO/archive formats.
 
===NTFS Compression===
You can enable filesystem-level compression (like "NTFS Compression" in Windows) for the directory containing your ISOs/ROMs. This has a very noticeable space gain and doesn't affect the emulator's functionality. It's surprisingly effective.
 
* '''Archive-quality dump?''' Yes
 
===Decompression on Demand===
You can keep your ROMs/ISOs compressed in a 7zip archive and use RocketLauncher or any other [[Frontends]] to decompress 7zip archives and pass the contents onto the emulator.
 
* '''Archive-quality dump?''' Yes
 
===FileSystem Deduplication, alternative file systems===
If you use macOS, you can look up for fuse filesystems which support compression/deduplication. <br />
If you use windows, you can fire a VM/store your games on ,a pc with a transparent network file server running linux/bsd.(might be viable on low latency networks, and a fast file server) <br />
On linux and bsds one can use, filesystems with de-duplication(and possibly transparent file compression) like:
 
* '''Squashfs'''
* '''Note:''' you can mount the filesystem and use an overlay file system to add a new file, and then create a new squashfs against an overlay folder.
** '''ReadWriteable?''' No read-only.
** '''Deduplication?''' Yes, block level.
** '''Active Deduplication?''' No, Deduplication is triggered by the user, during filesystem creation.
** '''Available compressors:''' zstd, xz(lzma2), lzma, gzip, lz4, lzo.
** '''Compression level control:'''  Depends on the compression algorithm, xz dictionary size depends on filesystem block size.
** '''Transparent?''' On Linux and BSD via kernel. Squashfuse avaialble for macOS.
 
* '''Btrfs'''
** '''ReadWriteable?''' Yes.
** '''Deduplication?''' Yes, file and block level.
** '''Active Deduplication?''' No, Deduplication is triggered by the user.
** '''Available compressors:''' zstd, zlib, lzo.
** '''Transparent?''' On Linux via kernel.
 
* '''Zfs'''
** '''ReadWriteable?''' Yes.
** '''Deduplication?''' Yes, file and block level.
** '''Active Deduplication?''' Yes, deduplication happens during writes.(high memory requirements)
** '''Available compressors:''' zstd, zlib, lzo.
** '''Transparent?''' On Linux, BSD, via kernel. Openzfs on mac os(?).
 
* '''Xfs'''
* '''Note:''' Without de-duplication it is already quite efficient at storing files.
** '''ReadWriteable?''' Yes.
** '''Deduplication?''' Yes, file level via duperemove.
** '''Active Deduplication?''' No, deduplication is triggered by the user.
** '''Available compressors:''' None.
** '''Transparent?''' On Linux and BSD via kernel.
 
* '''LVDO - Linux Volume Duplication/Compression'''
** '''ReadWriteable?''' Yes.
** '''Deduplication?''' Yes, block. And whatever filesystem on-top
** '''Active Deduplication?''' Yes Transparent.
** '''Available compressors:''' LZ4.
** '''Transparent?''' Yes, On Linux and via kvdo module and lvm2 integration
** https://github.com/dm-vdo/kvdo
 
* '''Archive-quality dump?''' Yes
 
==Destructive Modification==
Sometimes, the most bloated part of the game is the game itself, either intentional or because of poor design choices.  For instance, many PSP JRPGs have a specific FMV movie duplicated a dozen times, and the Megaman Collection on GCN 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 the game's data.
 
Note, "deleting" often means replacing the file with a 1KB dummy file to prevent the ISO file structure from collapsing on itself, but sometimes such care isn't even put into ensuring it's still in a functional state. Some examples:
 
* delete all videos: this brings Super Smash Bros Brawl to 4.7GB (mainly due to Subspace Emissary).
* delete all voice acting and occasionally sound and music: this brings Xenoblade PAL to 4.2 GB with even only one of both dubs removed.
* delete unused content you could get with emulator cheats like rooms and stuff.
* delete "extra" languages other than the language you need.
* If a game has multiple quests, then you could try deleting characters/side-quest you don't like as much.
 
Tools used for this are modding tools for rebuilding file trees, like UMDGen (PSP), Tinke (DS) and also regular ISO tools (PS1, Saturn).
 
Since this results, in most cases, in very noticeable detrimental effects in gameplay (if the game doesn't crash outright), this is nothing short of mutilating the game image. Sadly enough, some of these dumps make it to sharing sites.
 
Avoid resorting to destructive modifications since it can lead to random crashes and unexpected behavior, especially in games with lots of shared assets. [[File hashes|Verify your dumps]] to make sure you don't have these, and if you still want to reduce size, prefer using other methods or uses decompression on demand. One reason to use a destructively modified dump is for burning your own Dreamcast games as GD-ROMs were over a gigabyte in size and CD-Rs top out at 850MB.
 
* '''Archive-quality dump?''' No (Removes data)
 
=See also=
*[[Ripping games]]
*[[List of filetypes]]
 
=External links=
*[https://github.com/86Box/86Box/issues?q=is%3Aissue+is%3Aopen+format+label%3Afeature+ Various image format feature requests for 86Box]
*[https://github.com/joncampbell123/dosbox-x/issues/1822 CHD feature request for DOSBox-X]
*[https://github.com/schellingb/dosbox-pure/issues/40 CHD feature request for DOSBox Pure]
*[http://web.archive.org/web/20231118032344/https://yuzu-emu.org/entry/yuzu-progress-report-aug-2023/#project-terra yuzu now supports sparse and compressed NCA games]. This means a long list of titles whose eShop releases couldn’t previously boot are now either running or perfectly playable, and their RomFS can be fully dumped.
 
=References=
 
[[Category:FAQs]]
Retrieved from "https://emulation.gametechwiki.com/index.php/Save_disk_space_for_ISOs"