Decompression?

[i30817]

I haven't seen a cmd line switch for decompression to file? Is it not supported? I want to update some xdelta patches in isos. Considering i used the option for larger block sizes i'm uneasy about using other decompressors (unless you say it's ok ofc).

[unknownbrackets]

Well, if another decompressor doesn't support it, it'll just fail. Also, you can use --crc.

I suppose I could add a decompression option. Another possibility would be applying or unapplying xdelta patches to an iso/cso (and outputting a cso.) Though, I'm not sure xdelta is the ideal patch format for block based files.

-[Unknown]

[i30817]

A problem with xdelta support idea is that it needs to be 'softpatch'

What i'm currently doing is to apply the xdelta hacker provided patch, then creating my own xdelta from the hacked iso to the original so i can reset and not need to keep the original. You can use this idea if softpatching is impractical. It would still ballon file sizes though - but less (besides not really being part of the CSO file format ofc, unless it allows adding arbitrary subheaders).

Then you could update the xdelta 'easily': Convert compressed iso to uncompressed. Apply reset xdelta patch if any (in a header) Apply new xdelta patch (user provided) Create new reset xdelta patch (new patched iso to original iso) Compress new patched iso Add a header containing the new xdelta reset patch Delete all the crap that is no longer needed.

Just be careful when uncompressing to warn the user about the difference between uncompressing the original iso vs the patched iso... maybe different switches for both or just the 'original'. Or just not allow uncompressing in this tool and just add switch for updating the xdelta... although that would be kinda lockin (because other uncompressors would only uncompress the patched iso, if they can).

I'm partial to a switch for only decompressing the original and another for updating the xdelta. The rest is secondary and may cause confusion.

[unknownbrackets]

Well, I think you need to keep around any xdelta patch if you want to unapply it.

I was thinking it would just automate decompress/recompress steps around applying (or reversing) an xdelta patch, in other words hardpatching. CSO doesn't have any direct mechanism to add extra data.

-[Unknown]

[i30817]

you need to keep around any xdelta patch if you want to unapply it

I've been using this reset method for quite a while, i didn't see anything in the original xdelta command line tool indicating that the patches themselves contain reset data.

CSO doesn't have any direct mechanism to add extra data.

Ugh what a pity. I'd seriously would start using and evangelizing CSO2 if emulators supported it and it had support for 'hardpatch' with resets and updates inbuilt. Can't you just add something at the end and assume every decompressor is well coded and doesn't uncompress beyond original iso size? -_-;

[unknownbrackets]

Oh, for some reason I misremembered that xdelta supports reversing patches. I think I mistake it in my memory for ninja2 or something.

I think we've had this discussion on best patch format before. Somehow I'm not sure vcdiff/xdelta is ideal for isos. Not sure.

It seems like if the patcher used xor, the only thing that would be tricky to reverse would be deletions. Maybe those could be optionally represented as an xor of another portion of the source data. In that way, patch file instructions could be presented without any risk of containing any portion of the original data...

-[Unknown]

[i30817]

Ehhh, i'm using xdelta not because it's the 'best' (i really have no idea) but because it's what the PSP hacking scene uses. If 9 out of 10 patches are distributed as xdelta (modulo things like the Final Fantasy Type 0 patch, which needed to decompress/recompress every thing from inside the iso therefore making binary patching impractical due to everything being different) then that is what i'd like to see used.

Ciphered and compressed filesystems only make this worse ofc. The glory days of binary unintelligent patching may be over.

[i30817]

Another option is creating a new file-format, say: .deltacso (or something) that wraps the cso with a header containing the needed stuff for reset the hardpatch and teach emulators and loaders to use it. Seems kinda troublesome.

The guy that did the CSO specification should really have thought about optional data headers...

[unknownbrackets]

Okay, well, patching format discussion aside, I've implemented decompression in v1.5.0.

Just use maxcso --decompress compressed.cso -o result.iso. It supports all input formats, including ZSO, CSOv2, DAX, and any block sizes.

-[Unknown]