Why are my dax-compressed games a few mbs smaller in size?

[VGkav]

Example, I open Disgaea.iso in UMDGEN and delete the UPDATE folder and save a new iso, it is 884mb. Now, with UMDGEN I compress it to dax without enabling any of the NC options, it becomes 413mb and compression is fast. Normal maxcso usage cannot reach this size.

I tried setting block size to 8192 with the -n=8192 option and the size reached lower than 413mb ... but the game doesn't show up on my PSP (6.61 ME 2.3). Then I copied the dax file and it shows up.

So my question is, dax uses DEFLATE, correct? What are the equivalent maxcso options for equivalent compression ratio and speed? (And a working file?)

EDIT: With block size 4096 the file is bigger than dax: 421mb

[unknownbrackets]

DAX and CSO are different formats. Specifically:

• DAX is hardcoded to using 8192 block size. CSO can use a dynamic block size.
• DAX uses DEFLATE using a ZLIB wrapper. CSO uses raw DEFLATE without the wrapper.

maxcso can create DAX files, but you have to tell it to using --format=dax. This won't allow you to use --block=4096 or similar, because such sizes are not supported by DAX.

PSP CFW generally only support CSO files with a block size of 2048. The reason the file didn't show up is likely because it couldn't read it for this reason.

To get an equivalent compression you should use --format=dax --block=8192 --fast. This will bypass compressing with alternative deflate algorithms and compares to -9 (maximum compression) in other tools. maxcso doesn't not have any options to compress at lower levels than "maximum compression" in other tools.

-[Unknown]

[VGkav]

Thank you, this was exactly what I was looking for, I got a 410mb dax file very quickly, which appears fine on the PSP, I will launch the game later but I don't expect any problems!

Congratulations on your program. Googling around there is a lot of talk about this deflate library:

https://github.com/ebiggers/libdeflate

Do you think it is worth your time to add it? It supports raw deflate.

[unknownbrackets]

Great. Yeah, I should probably add libdeflate to maxcso at some point soon. Its API limitations are no problem for CSO compression.

Even if you don't use --fast, it should still be compatible as well. It'll just take a longer to compress because it tries multiple algorithms. At best might be a few more MB smaller.

The main reason for maxcso's speed advantage using --fast is how effectively it uses multiple CPU cores. It's ultimately doing roughly the same work.

-[Unknown]

[VGkav]

With --fast the result was the same as UMDGen doing dax. Without --fast it was 3mbs smaller :D

I don't care about compression time too much. Sadly Zipflo takes waaaayyyy too long for minimal benefit. I will be following this project for new releases, thanks again!

Oh, a final suggestion, you show compression ratio and other info during processing ... but then you hide it at the end! Can you show final stats like:

908.6mb --> 410.1mb Compression ratio: 36.2% Threads used: 2 Time elapsed: 0:59.201

[unknownbrackets]

I've added libdeflate in bb7a94b, but don't get your hopes up - 7-zip's deflate is very competitive and libdeflate level 12 only shaved less than 0.01% more off the original size in addition. It slows down trials enabled by default, but this is maxcso after all. It's nowhere near as slow as zopfli.

For now I've left --fast at zlib level 9, but you can use --only-libdeflate instead to get libdeflate level 12.

I also went ahead and replaced "Complete" with size and percentage, although I didn't do a complete status readout (it lists a line for each file you give it, so I want to keep it mostly terse.)

-[Unknown]

[VGkav]

Oh, nice, so when the new version comes out my batch file command will be

maxcso --format=dax --only-libdeflate %1

For maximum compression without the ultra-slow zipflo. Because I doubt doing trials makes much sense. Or maybe you should disable zlib trials by default and leave the two big boys?

[unknownbrackets]

Well, sometimes 7-zip's deflate is better, or sometimes zlib gets it better by a few bytes. It just depends on how much you want to wait and how much you want to save.

For comparison, on a reference ISO:

Mode	Time	Ratio	Diff
--fast	0.4s	16.1691%	+281596
--only-libdeflate	1.0s	15.9742%	0
--only-7zdeflate	3.0s	15.9284%	-66110
Old Default	5.2s	15.928%	-66623
--no-zlib	4.7s	15.9251%	-70859
Default	7.4s	15.9249%	-71177
--use-zopfli	168.9s	15.8236%	-217547

So it's definitely much better than fast, and close to the same speed. You're losing about 0.05% (based on this example) from excluding 7-zip.

-[Unknown]

[unknownbrackets]

Version v1.13.0 has been released with libdeflate support.

-[Unknown]