Compressed ISO Formats
Compressed ISO is an ISO image compressed in some way to reduce the space usage. There are a few competing formats, each with different tradeoffs. The formats are specified below.
Technical Overview
| Format | Author | Supported Algorithm | Supported Block Size | Compression Ratio vs Decompression Speed | Comments |
|---|---|---|---|---|---|
| CSO | by Booster | DEFLATE | Any (2K is Standard) | Great compression size, Slow decompression speed | Uses the same de/compression algorithm as DAX, but a lighter structure. While it supported any block size, the standard was 2K (it was also the only size allowed by compression tools, including the official one), in contrast to DAX’s 8K. Traditionally, this meant DAX was faster as it had to process fewer blocks than CSO, but this is no longer true with the new reader; thus, they both perform the same regardless of block size. However, this also means that standard 2K CSO is bigger than DAX, but CSO compressed using the same 8K block size as DAX actually produces a smaller image. Meaning that an 8K CSO is superior to DAX in every way (this could be the reason DAX himself dropped support for DAX in favor of CSO, though the M33 driver never supported anything other than 2K CSO). |
| DAX | by Dark_AleX | DEFLATE | 8K Only | Great compression size, Slow decompression speed | A competing format of CSO, it uses a slightly different structure, though the compression algorithm is the same. The original version did not allow for Non-Compressed sectors, a feature added in Version 1, though in a complicated and inefficient way. Though the format used to be faster than CSO, this was merely due to unoptimized IO access in the older drivers. Eventually, support for the format was dropped with the M33 CFW. |
| JSO | by Uncle Jam | LZO or DEFLATE | Any | Average compression size, Fast decompression speed | This format was created long ago as a response to the slow nature of unoptimized CSO/DAX readers of the time, and combined technical aspects of both CSO and DAX while also adding its own unique features. It attempted to improve speed by adding support for LZO (de)compression format; however, this had relatively bad results since the main issue with speed on those old drivers was the heavily unoptimized IO calls. It supported either LZO or DEFLATE, but both couldn’t be used at the same time on a single file. |
| ZSO | by Codestation | LZ4 | Any (2K is Standard) | Worst compression size, Fastest decompression speed | This format was created as another late attempt at improving compressed ISO speeds, this time using the incredibly fast LZ4 de/compression algorithm. It was soon discovered that it wasn’t just the compression algorithm that affected the speed of CSO, but the main bottleneck was in the incredibly huge amount of IO calls being done for every single data request by the game (as opposed to a single IO call per data request on ISO). This meant that now standard CSO performs well enough for most cases. |
| CSOv2 | by UnknownBrackets | LZ4 and DEFLATE | Any (8K is Standard) | Good compression size, Good decompression speed | An attempt at combining the good compression ratio of CSO with the great decompression speed of ZSO, it also has some technical aspects from JSO (such as multiple algorithm support and detection of non-compressed blocks). In this format, each block is compressed with either algorithm, meaning that both algorithms are used at the same time throughout the file. |
tldr
Which algorithm to use nowadays largely depends on the use case.
If speed is your priority, then ZSO and JSO are good options, while for space saving, you can use CSO or DAX.
The format can also depend on the game, with more intensive games benefiting more from faster decompression (such as ZSO with GTA games), while with other games the slower decompression only results in a bit more loading times but no difference in gameplay and thus CSO/DAX works fine (such as the case of Minis).
History: Format Wars
Format wars aren’t a thing exclusive to the movie industry, and Sony is certainly no stranger to them, though they had nothing to do with this one (at least initially, they did end up making their own PBP format for PSN releases).
Back when the first ISO drivers showed up on the console, memory sticks weren’t bigger than 2GB, which necessitated the implementation of a space-saving mechanism in the form of a compression format for ISO files.
Compressing an ISO into a ZIP file would not be enough, as you can’t do random-access on ZIP files; you have to decompress the entire file before you can use it. This works for classic retro console roms as they are small enough that the entire file can be loaded into RAM, but for a UMD that can reach up to 1.8GB, this was not going to cut it.
It was then that two formats appeared: Booster’s CSO and Dark_AleX’s DAX formats. On these formats, compression is done on a per-sector (or per-block) basis, rather than the entire file, allowing for random access directly on the compressed file. The only downside is that compressing small chunks instead of the whole file will always be detrimental to the compression ratio; in this case, even though CSO and DAX use the same compression algorithm as ZIP, an ISO compressed into a ZIP file will have slightly better compression. Though this wasn’t too bad and the compression ratio was pretty good anyway, especially with games that used lots of uncompressed data and dummy files (pretty common in optical media).
Each format had its own benefit, with DAX considered to be overall faster and having better compression, but CSO being much simpler and more powerful (in a great moment of “forward thinking”, CSO could actually work on DVD and Blu-ray ISOs, while DAX was limited to UMD and Mini-DVD). Also, while the CSO format was standardized to having 2K blocks, it was meant to use any block size, meaning if they had gone with 8K blocks as DAX had done, then CSO would have been as fast as DAX while being even more compressed (due to being an overall more space-efficient format).
A little bit after the creation of CSO and DAX, a third competitor named JSO entered the scene. Developed by Uncle Jam, the format aimed at using a faster decompression algorithm, LZO in this case, to improve the speed of the format. This never took off, however, and the format never gained much popularity, even though many PC apps at the time would fully support converting to and from this format. The reason for its failure has mainly been related to the unoptimized usage of I/O present in drivers of the era, rendering the speedup gained with the faster decompression function relatively unnoticeable. Though the format has seen a resurrection with ARK-4’s Inferno 2 driver, as it offers the best tradeoff between speed and compression ratio.
Most ISO Drivers (i.e. SE and OE) for a while would implement support for both formats, though eventually Dark_AleX (the most famous PSP CFW developer of all time) would drop support for his own DAX format when the M33 CFW was created.
Because DAX offered faster speeds and better compression than standard CSO files, even though it went unsupported, the format went on to gain a sort of niche following and an aura of being the “superior even if not popular format”, pretty similar to what happened to Betamax.
Interestingly enough, the speed differences between DAX and CSO related to the block size all go away with a properly I/O optimized driver, and a CSO file created using 8K blocks will provide a better compression ratio than DAX.
Fast forward to the end of the PRO era, and a new fourth format arrives on the scene. Created by Codestation, the ZSO format uses the same exact binary structure as a CSO, with the difference of using the much faster LZ4 algorithm to handle compression. The LZ4 algorithm is the fastest algorithm available, though the speed is traded off for compression ratio, having the worst among the different formats. The format, however, reached the same dead end that JSO had found in the day: the bottleneck and main issue that slows down CSO is not the compression algorithm, but the huge amount of I/O calls being issued when reading any compressed format. Once this bottleneck was eliminated, the original CSO format became much faster to use and therefore most people decided to stick with it instead of migrating to ZSO. Where ZSO did find more success was in the PSP’s sister console, the PS2.
Which algorithm to use nowadays largely depends on the use case. If speed is your priority, then ZSO and JSO are good options, while for space saving, you can use CSO or DAX. The format can also depend on the game, with more intensive games benefiting more from faster decompression (such as ZSO with GTA games), while with other games, the slower decompression only results in a bit more loading times but no difference in gameplay and thus CSO/DAX works fine (such as the case of Minis).