Best Compression Methods for 'Specific' Games. Q&A

[L33THAK0R]

Has anyone else experienced some issues with Oggre when processing a large amount of streams? I'm currently working on "Nioh 2", whose audio can be extracted into a readable Vorbis Ogg format. I individually packed every file (~9000) and compared the original file checksums to determine which files were incompatible and removed them accordingly. In the past this process has never failed me and has always without fail resulted in a successful decompression of those particular assets, however this time around it seems I'm left with a bit of a confusing result. Attempting to pack all the streams together results in the installer, presumably due to the CLS Oggre plugin, crashing.

Investigating the issue by creating a large stored archive of all files in their packable format shows a much clearer image:

Original Input, Stored Archive (7.79 GB) -> Processed with Oggre (5.29 GB) -> Unpacked with Oggre (4.67 GB)

My current solution I'll be employing for my conversion is simply post-install, unpacking the stored archive with the "temp" packable files, then using a patch made between the temp files and a stored archive of the original files.

I'll be then putting these 2 files alongside each other into one large archive, whilst praying I can squeeze some small gains but I'm under no illusion it'll almost certainly be a satisfactory result. Definitely not happy about the amount of additional R/W operations that'll be performed on the end-users drive, but its the best solution I can come up with.

I should mention I was able to process the audio from the original "Nioh" without any trouble, which follows the same structure as "Nioh 2", with a pretty decent final result of 20.3 GB for v1.21.04 of the Complete Edition release for "Nioh".

UPDATE: I ran an additional test with the original unmodified audio archives packed with a generic srep + lolz configuration, when alls said and done, srep actually works well with the duplicated data, resulting in an inflated final result of only 390MB. Given the negligible gains compared to the amount of data that would would need to be written (~16gb) for the original patching approach to work, I think for the time being, and in the interests of the end-user, I'll sacrifice this 390MB.