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

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. :)

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

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.

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:
See my "readme2.txt" file from few infos. Sourced from this site posts.

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