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

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