Tools for Repacking

[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.

[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

[Masquerade]

I've updated KaktoR's Oodle library collection to add a few more Oodle libraries I have stored on my hard drive.

Original post here.

Please note that the v numbers in the dll names do not indicate the "version" of Oodle used. neither do the core numbers since these can be easily renamed. Ofc to use these dlls with oo2rec or XTool you will need to remove the _v* after win64.