Tools for Repacking

[wrathma]

Originally Posted by newfolder

OodleForge v33 - OodleLZ Exact-Match Precompressor (open source), read the readme's

instead of -ssd -hddslow -hddfast you could add a in memory buffer. a set size of memory will be allocated at start (ex: 64mb). you first write processed output to this memory buffer and when its full you flush it directly to storage (1 write operation, works on a separate thread) and in the meantime allocate another memory buffer to start again. so instead of a 1gb file doing 4k+ write operations (with -hdd*) it will do only 16-17 write operations.

[newfolder]

Originally Posted by wrathma

instead of -ssd -hddslow -hddfast you could add a in memory buffer. a set size of memory will be allocated at start (ex: 64mb). you first write processed output to this memory buffer and when its full you flush it directly to storage (1 write operation, works on a separate thread) and in the meantime allocate another memory buffer to start again. so instead of a 1gb file doing 4k+ write operations (with -hdd*) it will do only 16-17 write operations.

You right, this changed the code 100%, amazing

[Razor12911]

Originally Posted by newfolder

OodleForge v33.1 The Memory Beast Edition - OodleLZ Exact-Match Precompressor (open source), read the readme's

It's good to see an alternative project in the works and given that it is open source, I would assume it is active development? If so, then I'd like to report a few issues I've discovered from the few tests I've conducted.

Issues

- A significant number of streams are left behind (not detected), scanner needs some improvements
- Even though there's only one game known to use of internal crc checks sendQuantumCRCs (The Crew 2), such data cannot be processed by this project
- spaceSpeedTradeoffBytes cannot be set by user and/or program does not check input for this change meaning games that this program cannot work on games that use the frostbite engine
- this project suffers from the same problem as xtool with leviathan and some hydra streams where they can be detected but not processed at all


The streams that are left behind can be however seen by this tool which can be found here, it's good that it is also open source as well, should help with development.

[newfolder]

Originally Posted by Razor12911

It's good to see an alternative project in the works and given that it is open source, I would assume it is active development? If so, then I'd like to report a few issues I've discovered from the few tests I've conducted.

Thanks a lot for checking it out and for the detailed feedback — really appreciate it coming from the XTool author!
The public repo is only ~2 days old (still v33.1), but I'm actively developing the Trinity Engine branch (Oodle + Unity LZ4 + Zlib + Preflate) with perfect AES roundtrips.
Scanner improvements are my top priority right now. Would love to hear more details about the missed streams or any test files you can share.
Open to collaboration!

https://github.com/johna124/Oodleforge

[kj911]

Could someone make a 64-bit version of this "t5lzma.exe" (source code) program? (While maintaining compatibility.) The 32-bit version only supports dictionary sizes up to "-d27", it no longer supports "-d28", although it is a good question whether it could handle higher ones. It is noticeably slower than the classic 7z/LZMA, but perhaps it could be minimally better.

[kj911]

An interesting precomp-fork, 32bit test package. (Only suitable for zlib-streams.)

Its compression speed, thread-dependent, can be up to 50+ MB/s. The decompression speed is slightly minimally faster. (Unfortunately, it also has quite strong limitations.)

Original author's description:

__________ __________.__ ._____.
\______ \_______ ____ ____ ____ _____ ______ \____ /| | |__\_ |__
| ___/\_ __ \_/ __ \_/ ___\/ _ \ / \\____ \ / / | | | || __ \
| | | | \/\ ___/\ \__( <_> ) Y Y \ |_> > / /_ | |_| || \_\ \
|____| |__| \___ >\___ >____/|__|_| / __/ /_______ \|____/__||___ /
\/ \/ \/|__| \/ \/
===========================================
Precomp Zlib is a program that uses the ideas of Precomp Classic and Xtool with its optimized zlib library. The result is a lighter binary and much smaller code. In this case, we haven't modified the zlib library itself, but rather adjusted the compression level values.

Remember to test the restored file with MD5 and CRC. While it's suitable for general use, the program (who knows?) might perform a poor restoration.

Manual
=======
To expand the file, use: `precomp_zlib.exe e filename.zlib filename.pre -j 2` (two threads) for example.

To recover the file, use: `precomp_zlib.exe d filename.pre filename.zlib -j 2` (two threads) for example.

This program is NOT designed for PNG or ZIP or PDF files. It's for files with zlib compression, such as Unreal Engine .pak files or GOG setup files. It performs wonderfully with these files.

LICENCE:
I DON’T CARE HOW EACH PERSON USES IT

See my "readme2.txt" file from few infos. Sourced from this site posts.

[panker1992]

Archiver, Demo,

Archiver has in-built a patch engine which allows you to create a patch from 2 folders, and then make it into a proprietary format,

The format itself is designed to be streaming, compressed and deduplicated, precompression failed for this as the patches themselves fail to give proper data which precompression can understand.

the reason is because the patch itself isnt aligned data which each algo is designed to work with.


What this streaming, delivers is a seamless performance which will decompress, edit each file verify it and delete the old one, you can use the folder to patch as well in case the you dont like the idea of having a prebaked archive format,

The API itself in Inno has the ability to take in such a format and applying it, and still maintaining the progress in a progressbar.

Added Edit:
Archiver IO Massive, exec2 in the works


@echo off

archiver i -exec2 -c0="D:\Epica" -c1="ffmpeg.exe" -c2="-i" -c4="-vn -b:a 256k -y" -c5="mp3" -c6=".ogg"

pause

[Razor12911]

LZ4 dll collection

You can obtain more from here

[Lord.Freddy]

Changelog:

▪︎ Complete rewrite of the wrapper core — replaced the old C++/coroutine-based implementation with a cleaner C89-compatible state-machine design.
▪︎ More reliable DLL handling — MpzSlimmer.dll is now loaded from the executable directory with validation and safer dependency/search-path handling.
▪︎ Safer codec execution — codec crashes and unexpected failures are caught and reported instead of leaving the process hanging or terminating silently.
▪︎ Robust input/output handling — improved Win32 I/O, buffering, seeking, partial reads/writes and support for both regular files and stdin/stdout.
▪︎ Configurable I/O buffer size — buffer size can now be specified from the command line for better control over performance and memory usage.
▪︎ Progress reporting — file-to-file operations now show processing progress.
▪︎ 2 GB stream protection — inputs and outputs exceeding the codec's supported 32-bit limit are detected and rejected safely.
▪︎ Same-file protection — prevents accidentally using the same file as both input and output.
▪︎ Automatic cleanup on failure — incomplete output files are removed when processing fails, avoiding misleading/corrupted results.
▪︎ Better command-line interface — explicit c / d modes, - for stdin/stdout, optional buffer size, and -h / --help.
▪︎ Overall stability improvements — numerous edge cases around EOF, pipes, large files, errors and cleanup were handled explicitly instead of relying on the old coroutine behavior.

In short: v2 is not just a small update; it is a substantial rewrite focused on reliability, safer error handling, better I/O, easier usage and a much cleaner codebase.
Compiled with: gcc-14.2.0-mingw-w64msvcrt-12.0.0

The source code will be added to the post shortly, once I’ve finished a few final cleanups and adjustments.