Oodle precompressor (Side project)

[panker1992]

Originally Posted by Masquerade

I went back today and did some digging, it turns out you are correct in saying that core 4 works, because I removed the core 6 from oodle rec and replaced with core + ext 4 from poodle and I got better results than poodle:



Here they are side by side. "kraken" is oo2reck while poodle is poodle.

Tested on Data4.bdt (516mb).

Update: Precompression has worked, here is result:

"That" Game you talk about is my favorite game

I have made it 7.1GB in total patch 1.04

use my way if you want and here are the blocks if you want to go sfk style.

offset (hex)

Block 1
17f332aa to 1b898ca9

Block 2
28c02dba to 53ae4699

Block 3
55e2a35a to 59987939

Block 4
5d37301a to 622e4cf9

Block 5
647e7c6a to 66b999a9

Block 6
6acdb9ba to 754c22d9

Block 7
79eb250a to 7c00e649

Remember to pack sounds together except the language ones

[Masquerade]

Hello panker1992, I hope my mess of oodlerec hasn't offended you or your favourite game

I do not know what you mean by "go sfk style" - I saw in your Resident Evil 3 Remake conversion that is some kind of patching tool. I hope you don't mind if I ask which files contain which blocks?

Will this result in a CRC perfect installation (when compared with retail build)?

Thank you.

[panker1992]

Originally Posted by Masquerade

Hello panker1992, I hope my mess of oodlerec hasn't offended you or your favourite game

I do not know what you mean by "go sfk style" - I saw in your Resident Evil 3 Remake conversion that is some kind of patching tool. I hope you don't mind if I ask which files contain which blocks?

Will this result in a CRC perfect installation (when compared with retail build)?

Thank you.

Let me answer your questions one by one.

Fitgirl went sfk style first and she manages to keep crc the same.
it Separates data in large archives and it makes lolz ridiculously fast and efficient. in some options it completely removes data... foreign languages you dont need.


the above blocks i removed result in all languages being removed and you get to keep what you want from folder "sound" of the game.

Data1.bdh has the entire folder named sound compressed in it, by removing the data you wont miss anything but a bad crc. you can even repatch it after to get it perfect crc match.

another example: DMC5 has a 32GB file which contains 10GB of movies and sounds.

if you sfk remove the 10GB of high entropy low compressability of stuff you will feed lolzi with pure textures and get high compressed file and very good speed.



In order to remove the data from the blocks above you need hex editor or convert them in decimal and use sfk, then zero them out and patch them back into position as shown in re3.
its only 7 blocks so use hex editor it will fast

Using a xdelta or zstd patch or bsdiff is a bad idea since you know what blocks to remove/inject.

[Masquerade]

Thank you for the explanation.

I'm following slightly, here's what I understand:

Data1.bdh contains the sound folder, so you can use sfk to remove it (effectively removing the duplicated data) then after installing you can patch the sound folder back in by using sfk again.

In order to remove the data from the blocks above you need hex editor or convert them in decimal and use sfk, then zero them out and patch them back into position as shown in re3.

So from this I gather that in the hex editor, it will show address "17f332aa" and then you go to address "1b898ca9" and replace all of the data between these 2 addresses with 0s so that it essentially becomes empty - leading to a deduplicated file with more efficient compression - yes?

its only 7 blocks so use hex editor it will fast

Are all of these blocks in Data1.bdh or are they scattered over the 5 data files?

Using a xdelta or zstd patch or bsdiff is a bad idea since you know what blocks to remove/inject.

So If you didn't know what parts of a file to remove and reinject, how would xdelta help? I thought xdelta can only create a patch based on an old file and a new file (by creating a patch with changed data betweeen the 2) - this part confuses me, because how will you be able to know which part of the file to remove?

I see the method would be create an xdelta patch using the modified, smaller file, and the original file then apply it after installing.