New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Request] Support games compressed in .xz format #1964
Comments
I would love it. Some info for future implementer
|
Future/new version of xz (5.3) add a new API to parse block information: Then you can create an iterator You can directly go to the good block with Summary:
API is not clear for me. There are
With block and file info, you can directly use
|
So I read the xz file format specification. Information are duplicated for redundancy/corruption checking. So the full story is
NOTE: I checked a binary on my computer and size aren't present in block header. Conclusion we need first to decode index to get the various offset of the blocks. Iterator allow us to iterate on block records. |
@turtleli Edit: actually don't bother I pulled something in a local branch. It should be enough. |
While xz is definitely popular, if possible, I'd suggest to also examine/play with newer compression formats like zstd and brotly or maybe some of the LZ* family. In my experience with the gzip implementation, random access decompression speed is the key for avoiding lot of pitfalls, workarounds and caches. Also, it's best to avoid creating an index, and instead stick to formats/configurations which provide their own index as part of the standard - and require users to use these configurations only (I don't know how much this is true for the formats i mentioned). |
So I'm rather close of a working prototype (based on latest xz git). I manage to uncompress a couple of blocks. And cdvd format seem to be detected correctly. But it fails later. Maybe an issue with block boundary. I need to double check the logic.. |
Good news I manage to boot a game. The issue was on the blocksize/blockcount management. Honestly the logic should be moved into the base class. Anyway XZ stuff is done 👍 |
As a side note, xz could also be a neat replacement for save state too. I saved 30% with a repack of the savestate. |
Is this waiting on a new XZ release? |
Yeah a new XZ release would help. We would need to release 1.6 too. I don't want to requires an alpha release of XZ for our release. I'm also waiting to have free time to merge the code. |
Any news regarding it? |
Nope, everything you see in the pull requests section is what's currently being worked on. |
I hope that it gets added soon. |
I've just been checking for new XZ releases. This is the biggest gap between releases they've had in a long while, so hopefully it's soon. |
Looks like an alpha build of xz utils was published with the lzma_file_info_decoder() API https://git.tukaani.org/?p=xz.git;a=blob_plain;f=NEWS;hb=114cab97af766b21e0fc8620479202fb1e7a5e41 |
Whats happening/ed with this? I've just done a ton of tests to compress my PS2 library and out of gz, zip, 7z, rar, cso and xz, xz had the lowest filesize and did it suspiciously fast 10MB/s with the strongest compression. Gz was doing about 2MB/s (less cores used) Im using the one built into current 7z. Space savings roughly 8-15% over gz. Thats several hundred GB saved for larger collections. |
Nothing has really happened I'm afraid. xz got added to PCSX2 for making GS dumps, but no support for loading games yet, it's not really been much of a priority.
That's big brain right there, but I don't think that's how compression works. |
Btw, I found this codec recently. The promise is a similar lzma compression ratio, but a much faster decompression speed.
However, I don't know if we can chunk the bitstream for random access |
This is the most promising I've found. |
Closing as trivial and we support other formats. |
PCSX2 has a shiny new .xz module. Any chance of users being able to shrink down their game library because of it?
The text was updated successfully, but these errors were encountered: