Open jberq opened 8 months ago
Technically, maxcso (and the pre-existing CSO format) does not currently require the contents actually be ISO9660.
The behavior would ideally be different on PSP (uses Joliet) and PS2 (uses old-style ;1
suffixes afaik.) That's probably the main complexity, not sure if there are other platforms to think about. PS1 would be different, although is not currently supported entirely because files are required to be a multiple of 2048 bytes (although this is just really an optimization, since no one uses CSO for PS1 anyway.)
I'd probably accept a pull request but probably won't have time to do anything on this for a while. It does seem like it could be useful and not that hard, although there's also an argument for other tools to simply support CSO files as inputs directly. Then they can do whatever.
-[Unknown]
@unknownbrackets Would there be any benefit to using CSO for PS1 games rather than CUE/BIN? Are there reasons it hasn't been done other than that no one tried?
There's a nice little utility called sfo which works very well in concert with 7z— one can quickly verify whether an ISO contains PSP_GAME\PARAM.SFO, extract it, query/modify it, and then update the image.
None of that is possible with a .CSO image without first decompressing the entire thing, often times from an HDD. It would be super useful to at least be able list the files within an image before deciding whether to decompress.
I have no idea how tall of an order this is in terms of complexity, and if Stdin/Stdout would be easier to implement, that would be an equally useful feature.