Archiver, 7z Alternative and FreeArc Replacement
 

This is a project i have been designing for the past year,

this is practically a brand new archiver, it has custom everything,

Brand new Header, like Freearc which with its utility has taken this forum for the past decade and more
this project's plan is to practically replace it.

I have added a ton of stuff, including the ability to use external algorithms and tools, and i have also included xtool 7.9 from Razor Github page into it as an internal means to precompress.

it comes with 2 modes,

Solid Block, and Blocked compression

you can rely on solid block to pack your games while a block compression can be used to maintain archives.

I plan to expand this with GUI and a DLL for Inno.

Unsolveable:
1) zstd, cannot use window > 1GB in 32 bit, hence :w30 is max for 32 bit systems. it cannot even decompress it.
2) filtering has been suspended because its slow.
3) packjpg,packmp3 are single threaded due to init sequence they are having build in and their buffers automatically clear each other out.
4) Precomp Codec will never be able to work in succession, you can only have one instance per chain, but you can use whatever you want in it as many cases and whatever depth (max:10)

Known Cases Future Fix maybe:
32bit executable uses 64bit placeholders, originally a 32 bit wasn't in the plans. this is a future fix.
New code for delphi lzma2/lzma/xz/7z is added via sdk 26.01. Possibility of adding it.

Bugs - To Do list:
Bug: Brunsli Codec in Precomp, out of bound bugs, best replacement is jojpeg because packjpg is single threaded.
Bugs: New patching Engine, release 0.1, which will be replacing zstd one that is actually present.
Masked Compression placeholders are added.


Changes - WIP 7.4:
SOS!!!
1) a critical bug in header creation was fixed
2) a critical bug was fixed that didnt verify files on decoding, on some occasions that led to corruption
3) a memory leak that occured rarely in compression succession.

Bug report (too old cpu or compilation issues?):

Running the "Archiver.exe" get error message: Xtool.exe instantly crashing. (orig 0.7.9 hotfix release 32bit exe still works.)

What is your system specs ? what OS you use?? what CPU ?

Archiver is 64 Bit application only

The old laptop specs, see image:

Tested another Xeon PC: works! (OS is same, Win7 SP1 x64, Xeon E5-2665 CPU)

Quick test from internal zstd compression, found two bugs:

1. The program's exception handling when the syntax is incorrect... /Red lines. Good preserved in green coloured text./
2. There is no feedback on the success of testing the archive. /Blue lines./

let me see what i can do, you probably lack heavy instruction set. also try to use block compression to test

Is that what you mean?? --> archiver a pack pack.arch -mzstd:l18 -b128 -t6

On the old laptop, the same error occurs as above. On the Xeon PC, there is no error!

UPD: Meanwhile, it turned out that testing small archives (<1-10MB) runs so quickly that there is no indication of the current status of the process. When testing larger archives (1+ GB), there is already a progress indicator. However, there is still no "Archive/All OK" feedback about the success of the testing (or about any errors?).

Are all the classic FreeArc algorithms supported?

What about the incompatibility of tta + solid mode combinations or other rare cases?

Could the "Archiver" program itself be backported to WinXP x86, from source? True, this would be useful mostly for unpacking (like: lolz!), if someone were to use it on XP, with many restrictions. (avoiding large dictionary sizes, Xtool FLAC codec not available in 32bit version, limited support for oodle codecs, etc...)

The precomp, is it version 0.4.7/0.4.8 or older?

UPD2: Found another bug/issues...

Bink compressions not workings, in get 0% ratio reduction via "-mxtool:bink/bpk" or another xtool-related iterations or wrong archive via "-mbink" compression mode, get ~32-36MB size bad archive and testing decompression, will generate blank and weird "chinese-text" named file. (Picture) Compress via -mdedup or -msrep only its works. (~10% size reduction.)

2nd issues, its probably 99% "dedup" external compressors only, stream conflicts/imcompatibility issue via xtool.

Bad: -mprecomp:cflac+dedup+zstd:l22:w31:s9:f1 -b32m -t8
Working: -mprecomp:cflac+srep+zstd:l22:w31:s9:f1 -b256m -t8
with or without "-b256m ..." switches.

More infos from attached TXT file.

Hello and thank you for your contribution to this new tool it needs attention.

that said, the issues you have, you cant use solid mode only stuff into blocked compression,

Blocked Compression and Solid Compression are 2 different things in my tool.

-mprecomp:cflac:cbink+rep+zstd:l22:w31:s9:f1
or
-mprecomp:cbink:b512mb:t90p

use this

Issue2:
This tool cant be ported to WinXP, i loved WinXp too back in the day but dedicating another year just to make it work on that old prehistoric OS is a solid Nope for me,

My plan was to make this futuristic tool with great utilities inside, most of which cant work on that OS for very good reasons.

however i plan to add a dedicated DLL for unpacking in x86 at some point.

Issue3:
TTA and other stuff can be added externally, they arent present in my code, use fazip.exe it works and also lolz works great

one point, would it be possible to keep your external compressor ini compatible with FreeArc's one, this one will allow freearc users to easily use this "replacement".

My external Compression is working similarly to FA, there are however some differencies in the API which of course is different since my project is written in Delphi,

And the was written in C++.

When i designed the way it works, i was making sure that intercompatibility will be a thing

i will of course explain how it works at some point with many details

and of course you should notice that this is a WIP aka work in progress, this isn;t the final product therefore you should TEST ONLY

Updated the project to WIP 3, and liblzma to 1.0.1

the plans are for me to create a repacking GUI, so you can use the archiver.
Also provide a DLL for Inno usecase

liblzma: i plan to add more utilities in that project as its becoming larger and larger and plays a significant roll in archiver, while keeping archiver as a tool that can help itself.

liblzma brings the following APIs to archiver, XZ,lzma,Preflate,Brunsli,packjpg,Lzham,Oodle, Gritibazli, Lizard,Lzav,Brotli, Kanzi.

i plan to add code from precomp and flac

Updated to WIP4

Changes - WIP 4, 25/9/2025

1) Changed Lizard to use the streaming functionality instead of using blocks. it is no longer comaptible with old version
2) Added lzham Compression to the blocked compression, and solid compression
3) Fixed lzma2, it is no longer comaptible with old version
4) Fixed Parsing when --pass= is used changed it to --password=, when you use password encryption
5) Changed Header, Params, Added Sections for spanning and more, this broke the compatibility with WIP completely
6) Fixed Zlib, compression and decompression, had issues

Changes - WIP 5, 21/10/2025 (Complete Overhault)

At this point, i decided to make this tool, from scratch, everything has been created from the beginning
so i fixed countless bugs ,added a plethora of new Features.

New: Filters, in Low API, when the archive is taking the data in, aka source gathering , with tolerance , aka filter configuration
New: Span, Spanning can be activated but with some limitations, spanned archives cant contain updated streams inside for now.
New: CLS-host, with partial compatibility from Bulat's Freearc, NOTE: not all filters work and i haven't tested every single one that exists.
New: 4x4, works similarly to FA with the ability to use internal and external codecs, but not CLS-Filters for now. Note: creates temps for external. but its very fast and efficient

All around fixes and optimizations:
1) Fixed: Stability, optimized several functions which in decompression in particular has to read and reread the archive several times before unpacking.
2) Created Unarc.DLL.
3) Reduced size of the executable with 1 mb.
4) Removed depedencies from the code to work barebone
5) LZAV,Lizard, FastLzma2 have been removed from the DLL and are now Native to the executable.
6) ZSTD has been updated to 1.5.7
7) XXhash has been updated to 8.3
8) LZ4 has been updated to 1.9.4
9) Fixed internal zlib which was creating depedencies and errors , it was seeking
10) fixed lzma which had bugs, was creating buffers and it was bufferign the entire stream to ram, removed lzma2, you can use lzma2 via 4x4:b512:t4:mlzma:d256:l9.

ArchiveManager is now an advanced way to unpack your Data easily and view them in real time. provided a starting point in the future to come.

Generic IO fixes has been made as well.


There is a known issue, liblzma.dll in 32 bit doesn't work and it will give a runtime error no matter what. if this continues the 32 bit's functionality will be severely decrease

Changes - WIP 6

1) Micro optimizations, Pipes now have a little more headroom and a bigger buffer thus they operate smoother.
2) fixed an issue where in Decompression you had to give .\ param to a local folder, it can now detect folder|drive or \\ network
3) added a hash generator which can scan a folder and create a list, where it stores their hashes, xxh32 , xxh64, crc32,crc64 are supported for now because they are stored as Uint64,
MD5 expecting a string or an array of chars so i stirred clear.
4) that hashlist can also be stored and compared to another folder
5) Oodle has been removed from 32 bit Executable. i plan to make a separate 64 bit help application that will intervene and extract but in native 32 bit systems oodle can't work. period.
Silent fixes: XZ, was seeking and its now fixed, Lizard in 32bit was missing malloc, was giving EA , fixed

Didn't imagine we have a freearc alternative in the future:D

I cannot wait to replace FA fully with this.

i updated this tool, this is not only a massive archiver, but the capabilities it coems with far exceed my expectations.

Next update this will expose the patch engine as in DLL, and you will be able to use it if you want it.

you can replace FA with this.

Is it fully compatible with inno yet ? Would be great if you could upload a sample inno script with full integration and as well as how to replace freearc with archiver in existing inno scripts :D

I am working on it, rest assured, i have however provided a Setup.exe in Delphi

which i use myself. unarc.dll both 32 bit and 64 are working but i havent tested them in Inno yet.

Added this tool which is a reflection of the internal precomp archiver uses but in external way,
This is an Xtool 7.9 Fork, which i created and maintain for my archiver.

Several fixes that have happened on top of Razor's Xtool work:
gdeflate original is kept as it was.
gdeflate2 is now present and also libgdeflate is also there, Razor provided those
as a courtesy because i helped him with libgdeflate. thanks Brother.
packmp3 is new addition which is now able to detect mp3 streams. and process them.
packjpg bug fixes
zstd codec patched to work.
zlib patched to work without zlibwapi.dll
All external DLLs are now in liblzma.dll
Including brunsli,packmp3,packjpg and many others.

Usage: precomp.exe c/d [params]
Release Version: 1.0.0

Main Options:
h Print Help

c <input> <output> Compress

:c - Codec(s) for precompression, multiple allowed:
preflate, reflate,zlib,lz4,zstd,kraken,lzo,png,brunsli,flac, packjpg,packmp3,gdeflate,gdeflate2,libgdeflate
Example: :czlib:creflate:czstd
:b - Block Size in MB [Min: 4, Default: 32]
:t - Thread count, e.g. :t50p = 50% of system cores [Default: :t50p]
:d - Depth (1 or 2) [Default: 1]
PNG requires :d2 and Preflate to function properly
:dd - Enables block deduplication on the current job
:db - Enables internal deduplication database

d <input> <output> Decompress

Precomp 1.0.1
Fixed liblzma.dll by removing everything it didn't need.
fixed a case where instead of using oo2core_x_dll it used liblmza.dll
it now uses internal patch engine instead of zstd

Complete refactoring.

Known Cases Future Fix maybe:
32bit executable uses 64bit placeholders, originally a 32 bit wasn't in the plans. this is a future fix.
New code for delphi lzma2/lzma/xz/7z is added via sdk 26.01. Possibility of adding it.

Bugs - To Do list:
Bug: Brunsli Codec in Precomp, out of bound bugs, best replacement is jojpeg because packjpg is single threaded.
Bugs: New patching Engine, release 0.1, which will be replacing zstd one that is actually present.

Changes - WIP 7.3:
1) Introduced Packmp3 API, in a streaming precompressor codec, not a filtering technique previously used, usage: precomp:cpackmp3
2) Introduced jojpeg API, brunsli - packjpg replacement. usage: precomp:cjojpeg
3) Unarc.dll, precomp use external executables, to speed up the process and use dedicated RAM
4) liblzham is using now a streaming compressor <> hence this will break the compression compatibility if you used it before (!)
5) Fixed a bug that used internal liblzma.dll to precompress using oodle specific codecs. it will now look for an oo2core_x_win64.dll
6) ExecArray, works and testing seems promising.
7) Rework on parsing, multiple 4x4 and 4x1 is now able to be used, it now uses array of params instead of global params.
8) Rework on TDirInput, allows for multiple inputs, instead of one input it now uses array of Inputs
9) Refactoring, the entire Project is refactored to the point of rewriting major aspects,
Analysis: Rewrote the way it handles Inputs, collect entries, removed single file and added array of inputs, separated public variables.
added placeholders for future usage including 32bit, cleared complex funcions. Broke Compatibility badly!
10) New handler added "e" stands for external decompression via Unarc.dll, added for debugging, tired to use a small program to load unarc.dll all the time :P
11) The project is updated to use Rad Studio 13.1
12) ZSTD 1.5.7 added with multithreading capabilities, check encoders

SOS Upgrade if you use 7.3, critical bugs have been found and fixed

Changes - WIP 7.4:
SOS!!!
1) a critical bug in header creation was fixed
2) a critical bug was fixed that didnt verify files on decoding, on some occasions that led to corruption
3) a memory leak that occured rarely in compression succession.

--span=<size> option does not work it seems.