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:

▪︎ Core rewrite — the C++/setjmp-coroutine wrapper was replaced with a portable C89 state-machine design: smaller, allocation-free on the hot path, and far easier to audit and maintain.
▪︎ Reliable DLL handling — MpzSlimmer.dll is loaded by absolute path from the executable's own directory, with PE bounds/signature validation of the patch site and hardened search-path handling (no DLL-hijack surface).
▪︎ Crash-safe codec execution — codec faults and unexpected failures are trapped and reported as clean errors instead of hanging or dying silently.
▪︎ Robust Win32 I/O — rewritten buffering, seeking and partial read/write handling, with uniform support for regular files and stdin/stdout pipes.
▪︎ Large-file (2 GB) protection — streams exceeding the codec's signed 32-bit limit are detected and rejected before any output is written.
▪︎ Configurable I/O buffer — buffer size is now selectable on the command line (clamped to a safe range) to trade throughput against memory use.
▪︎ Progress reporting — file-to-file operations display live progress; suppressed automatically for pipes.
▪︎ Improved CLI — explicit c / d modes, "-" for stdin/stdout, optional buffer size, and -h / --help.
▪︎ Security & build hardening — ASLR/DEP enforced, no RWX/self-modifying memory, and an embedded version resource + application manifest; together these cut antivirus false positives.
▪︎ Dual-toolchain build — compiles warning-clean under both MSVC (cl) and MinGW GCC/Clang from a single Makefile.
▪︎ General robustness — EOF, empty input, same-file in/out, and failure cleanup (incomplete output is removed) are now handled explicitly rather than relying on old coroutine side effects.

In short: v2 is a substantial rewrite focused on reliability, safe error handling, better I/O, and a cleaner, more portable codebase.
Compiled with: clang-14.2.0-mingw-w64msvcrt-12.0.0

Full credit to Eugene Shelwein for the original MPZ wrapper

[kj911]

Nitro NG 1.05 [FAST ZLIB PRECOMPRESOR] [OPEN SOURCE]

Very shorted descriptions:

================================================================================
          NITRO ENGINE - ARCHITECTURAL CHANGELOG: v1.03 -> v1.05 HP
================================================================================

[SUMMARY]
* v1.03 Baseline: Single-pass linear engine. Isolated from Preflate bugs.
                  Used precise 1-to-1 scanning but lacked memory recycling.
* v1.05 HP:       Hardware-aware system featuring Zlib stream memorization,
                  lock-free lookups, real-time pipeline streaming, thread
                  memory pools, and purist native Win32/POSIX E/S interfaces.

Longer descriptions and x64 Win/Linux binaries here.

My test, detects huge memory footprints, larger than previously posted "precomp_zlib" iterations. Original precomp 0.4.8 still have 24-40MB RAM usage during compress/recompress from testing 124MB ARC archive. Precomp_zlib around ~200MB, NitroNG memory spikes avg. 500MB RAM!

Bad memory mapping code?

My 32bit (XP-compatible) EXE's patched in 4GB RAM limit, avg. 2720-2725MB's memory allocated in 64bit host, before crashing. Speed comparable to Precomp_Zlib iterations. Multithreaded.

[wrathma]

^^ this might be the most certain ai slop posted in this forum.
this project is also from the same dev i think. both of them suffer
from the same problem, the devs dont understand their tools.
they dont know what their tool is supposed to do. probably built
with 2-3 prompts in a single day. dont even get me started on
the issues i see only from the first 100 lines of the code.

edit: even the readme is ai generated and doesnt fully
resemble the tool/code

[kj911]

^^ To be honest, I find it quite strange myself that someone known as a member of the "PC/RIP" scene—especially amidst the current AI craze—would turn to and utilize such tools, given that he was already writing simpler programs even before the advent of AI.

Is it worth pursuing these projects—now or in the future? Obviously, if someone makes use of them and fixes them up, something truly useful could still come of it, couldn't it?

[wrathma]

Originally Posted by kj911

^^ To be honest, I find it quite strange myself that someone known as a member of the "PC/RIP" scene—especially amidst the current AI craze—would turn to and utilize such tools, given that he was already writing simpler programs even before the advent of AI.

who exactly ?
when someone is making a tool atleast he should go and properly
battle test it first before releasing v33.1 or v1.03 in the first day.
also theres a huge difference between ai assisted code and ai slop.
theres alot to fix in this tool. and a lot more to learn. i would say take
reference from xtool source code. compare with xtool, use it as a
benchmark. and actually understand your code instead of accepting
what ai writes for you. of course you will not make it in one day.

i reported a issue and gave a fix on his last tool Oodleforge.
Oodleforge was fixed but the issue persists on this new tool

[Lord.Freddy]

Originally Posted by Lord.Freddy

Changelog:

▪︎ Core rewrite — the C++/setjmp-coroutine wrapper was replaced with a portable C89 state-machine design: smaller, allocation-free on the hot path, and far easier to audit and maintain.
▪︎ Reliable DLL handling — MpzSlimmer.dll is loaded by absolute path from the executable's own directory, with PE bounds/signature validation of the patch site and hardened search-path handling (no DLL-hijack surface).
▪︎ Crash-safe codec execution — codec faults and unexpected failures are trapped and reported as clean errors instead of hanging or dying silently.
▪︎ Robust Win32 I/O — rewritten buffering, seeking and partial read/write handling, with uniform support for regular files and stdin/stdout pipes.
▪︎ Large-file (2 GB) protection — streams exceeding the codec's signed 32-bit limit are detected and rejected before any output is written.
▪︎ Configurable I/O buffer — buffer size is now selectable on the command line (clamped to a safe range) to trade throughput against memory use.
▪︎ Progress reporting — file-to-file operations display live progress; suppressed automatically for pipes.
▪︎ Improved CLI — explicit c / d modes, "-" for stdin/stdout, optional buffer size, and -h / --help.
▪︎ Security & build hardening — ASLR/DEP enforced, no RWX/self-modifying memory, and an embedded version resource + application manifest; together these cut antivirus false positives.
▪︎ Dual-toolchain build — compiles warning-clean under both MSVC (cl) and MinGW GCC/Clang from a single Makefile.
▪︎ General robustness — EOF, empty input, same-file in/out, and failure cleanup (incomplete output is removed) are now handled explicitly rather than relying on old coroutine side effects.

In short: v2 is a substantial rewrite focused on reliability, safe error handling, better I/O, and a cleaner, more portable codebase.
Compiled with: clang-14.2.0-mingw-w64msvcrt-12.0.0

Full credit to Eugene Shelwein for the original MPZ wrapper

Source code + final compiled executable file added.

[kj911]

wrathma: It is KPS—alias KaPiTaLSiN—who writes this software... (there are so many rare PC/RIP tools from the 1990s and 2000s that remain unpublished to this day.)*

You are right that he could test them more thoroughly, identifying and fixing potential bugs in a timely manner. Xtool turned out incredibly fast compared to the original Precomp; anyone needing only ZLIB recompression would choose it over the classic Precomp. True STDIO support is only partial (with the exception of the custom v0.4.8 fork from one of the members here, plus ProFrager’s v0.4.3 package—though the latter is decompression-only). Both Precomp_Zlib and Nitro_NG do have one advantage: they support multithreading. I wonder if the original Precomp’s single-threaded codecs for MP3, SWF, JPG, PDF, GZIP, PNG, Base64, MJPEG, and BZIP2 could somehow be made to run on multiple threads? (Excluding LZMA.) So far, no one has solved this; we’ve only relied on hacks using auxiliary tools like MTX, PMT, and the like.

Nitro_NG Github repo page.

*ex: mp3pack tools, lossily compress many WAV files to single mp3unpack executable.

Lord.Freddy: Many thanks from new MPZ Wrapper.