cso1 format compresses worse than compact /c /s /a /i /exe:lzx even with all compression options

This is expected. CSO files use zlib/DEFLATE compression, and they're seekable. The latter especially comes with a ratio cost.

You can read a bit more about lzx here if you're interested. It is similar to DEFLATE: https://wimlib.net/compression.html

maxcso is designed to generate CSO files. If it used a different algorithm or made files that weren't seekable, even if we called them "CSO files" they wouldn't be readable by software that accepts CSO files. And they could be problematic to support for some software too (i.e. PSP CFW, phones running PPSSPP, phones running Play!, etc.)

Moreover, lzx requires sequential decompression to my understanding. To use an analogy, it's like a book that you can only read starting from the beginning. The trouble is that PSP game ISOs are more like reference books, and the game is constantly looking up things on different pages, in a somewhat random order. If it's forced to read every page starting at page 1, it's much slower.

Most compression formats are not seekable, such as zip or 7z files. This is also true of lzx. The benefits of lzx are that it's transparent (no need to manually decompress the file), and it's supposed to be multithreaded (may decompress faster than zip or 7z.) But it'll have an increased startup cost when accessing a file you haven't accessed for a while.

If you're just after the smallest file possible, compressing the iso using 7-zip is likely even better than lzx, as far as file size. If you don't want to have to deal with decompressing it manually, but also don't mind the reduction in startup performance, lzx is a good choice for its convenience.

This isn't a bug, so closing.

-[Unknown]

unknownbrackets / maxcso

cso1 format compresses worse than compact /c /s /a /i /exe:lzx even with all compression options #62