PDA

View Full Version : Archiver, 7z Alternative and FreeArc Replacement


panker1992
26-08-2025, 12:53
Archiver, a new archiving project

Changes - 0.0.2: Beta

Bug Fixes & Stability


Fixed Visual Bugs in Precomp - Resolved display and rendering issues within the Precomp interface
Fixed packmp3 in LibGUI - Addressed MP3 packing functionality within the GUI library
Fixed foxshellDLL crashes - Resolved critical stability issues in the shell extension DLL


New Features & Enhancements


Native Alternative to Srep - Created ADDeX as a native external tool alternative
WAVPACK Method Added - New compression method for WAV audio files
Silent Addition for API - Enabled archiver_api usage for compression via executable (debug purposes)
Inno Example Created - Added Inno Setup example for installer reference


Native Delphi Ports


Brunsli - Now implemented as native Delphi port
PackJPG - Now implemented as native Delphi port
PackMP3 - Now implemented as native Delphi port
Preflate - Now implemented as native Delphi port


Optimizations & Quality of Life


Several QOL changes and micro optimizations - Various user experience improvements and performance tweaks
Further Precompression changes - Ongoing improvements for game engine enforcement compatibility

kj911
28-08-2025, 05:02
Bug report (too old cpu or compilation issues?):

Running the "Archiver.exe" get error message: Runtime error 217 at 000007FEE6DAA3BD

Xtool.exe instantly crashing. (orig 0.7.9 hotfix release 32bit exe still works.)

panker1992
28-08-2025, 05:39
Bug report (too old cpu or compilation issues?):

Running the "Archiver.exe" get error message: Runtime error 217 at 000007FEE6DAA3BD

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

kj911
28-08-2025, 08:03
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./

C:\Users\Joci\Desktop\Arch>Archiver.exe a "C:\totalcmd" pack0.arch -mzstd:l22:w31:s9:f1

Original Total Data: 22226432, Actual data size: 22231292

Processing codec 1/1: zstd
Input file: chain_1.tmp (22231292 bytes)
Output file: chain_2.tmp
Progress: 100,00% | Compression Ratio: 31,16 zstd: 22231292 -> 6928193 (31,16%)


Final compressed size: 6928193
Overall compression ratio: 31,16%
Compression vs original estimate: 31,17%

C:\Users\Joci\Desktop\Arch>Archiver.exe d pack0.arch zzz
EAccessViolation: Access violation at address 000000000040DC55 in module 'Archiv
er.exe' (offset DC55). Read of address FFFFFFFFFFFFFFFF

C:\Users\Joci\Desktop\Arch>Archiver.exe d pack0.arch null

C:\Users\Joci\Desktop\Arch>Archiver.exe d pack0.arch .\zzz
Writing: wincmd.key - File: 100,0% - Total: 100,0% - Speed: 0,06 MB/s

panker1992
28-08-2025, 08:12
let me see what i can do, you probably lack heavy instruction set. also try to use block compression to test

kj911
28-08-2025, 08:26
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 (https://i.kek.sh/v8kMPaSzyZf.png)) 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.

panker1992
29-08-2025, 05:53
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 (https://i.kek.sh/v8kMPaSzyZf.png)) 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

futureking
06-09-2025, 00:01
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".

panker1992
06-09-2025, 14:24
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

panker1992
11-09-2025, 05:43
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

panker1992
25-09-2025, 11:45
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

panker1992
21-10-2025, 09:59
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

panker1992
23-10-2025, 00:04
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

KaktoR
23-10-2025, 07:02
Didn't imagine we have a freearc alternative in the future:D

I cannot wait to replace FA fully with this.

panker1992
19-04-2026, 14:11
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.

Dunnowho69
24-04-2026, 08:30
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

panker1992
25-04-2026, 07:31
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

panker1992
29-04-2026, 12:57
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

panker1992
06-05-2026, 11:57
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

panker1992
11-05-2026, 11:25
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.

KaktoR
03-06-2026, 09:53
--span=<size> option does not work it seems.

panker1992
08-06-2026, 11:06
--span=<size> option does not work it seems.

As i told you in discord, at that time --span=10mb wasn't parsed, at this time it works with mb or gb prefixes

Important Note:
After 2 years of development, this project is reaching the END of adding new stuff, manipulating the Engine and optimizing the way it works.
As it's finilizing itself, i will begin to make a new GUI to make everyones life a bit easier.
The Next release will probably be the first Public Release making it to 0.0.1.
Also to make use of the previous release i plan to keep the WIP - Work in Progress Releases public for people that used it.

panker1992
05-08-2026, 12:18
inno + archiver are fianlly married

thanks to Razor we got ourselves a testing kit :)

Also the archiver.exe inside the example can support srep natively

-msrep:m1 = m3f
-msrep:m2 = m4f
-msrep:m3 = m5f

panker1992
07-08-2026, 15:21
Alpha version is out.
Changelog:

1) Fixed Visual Bugs in Precomp
2) Fixed packmp3, in LibGUI
3) Native Srep, algorithm has been added.
4) Several QOL changes and micro optimizations.
5) Silent Addition to enable usage of archiver_api to be used to compress via executable for debug purposes.
6) Inno Example has been created.

panker1992
28-08-2026, 09:56
Archiver, a new archiving project

Changes - 0.0.2: Beta

Bug Fixes & Stability


Fixed Visual Bugs in Precomp - Resolved display and rendering issues within the Precomp interface
Fixed packmp3 in LibGUI - Addressed MP3 packing functionality within the GUI library
Fixed foxshellDLL crashes - Resolved critical stability issues in the shell extension DLL


New Features & Enhancements


Native Alternative to Srep - Created ADDeX as a native external tool alternative
WAVPACK Method Added - New compression method for WAV audio files
Silent Addition for API - Enabled archiver_api usage for compression via executable (debug purposes)
Inno Example Created - Added Inno Setup example for installer reference


Native Delphi Ports


Brunsli - Now implemented as native Delphi port
PackJPG - Now implemented as native Delphi port
PackMP3 - Now implemented as native Delphi port
Preflate - Now implemented as native Delphi port


Optimizations & Quality of Life


Several QOL changes and micro optimizations - Various user experience improvements and performance tweaks
Further Precompression changes - Ongoing improvements for game engine enforcement compatibility


Inno Exampel has been added, i will be providing a LibGUI inno from Razor pretty soon

KaktoR
28-08-2026, 16:38
This is a really good freearc replacement.

You people should give it a try.

Dunnowho69
28-08-2026, 22:13
Can I use cls.ini like freearc for installation or is there a different way for this ?

panker1992
29-08-2026, 01:55
The Cls.ini is a file that is loaded in CLS runtime, by the CLS itself, if the CLS supports it then yes you can use it,

for example lolz and lolzi supports it and you can use it,

CLS.ini isn't loaded in archiver, as archiver cannot know in advance what params each cls will use.

Dunnowho69
29-08-2026, 03:13
The Cls.ini is a file that is loaded in CLS runtime, by the CLS itself, if the CLS supports it then yes you can use it,

for example lolz and lolzi supports it and you can use it,

CLS.ini isn't loaded in archiver, as archiver cannot know in advance what params each cls will use.
Thanks for clarifying, also is there a way to exclude the parent folder since
Archiver.exe a test.arc "C:\test\*" -msrep -o+
doesn't work ?
Edit: found it my bad

panker1992
29-08-2026, 07:44
To exclude the parent folder you need to use -rr=1 command this is very similar to what FA does as well,

the archiver project is primarily created to be used in windows, and as 7z alternative,
this is why i had to use this to avoid several naming collision on special folders

Registered55
17-09-2026, 07:41
Hi everyone,

I've been experimenting with archiver.exe and testing out various multi-codec chains (combining precomp sub-codecs, srep, and zstd), but I'm finding it a bit tricky to dial in the optimal syntax without official example scripts.

Since documentation on command-line configurations is sparse, would any of the experts or the developer be willing to share a few working example command lines?

Specifically, I'm looking for two or three profiles:

Normal / Balanced Profile: A clean, reasonably fast command for everyday folder archiving.

High-Compression / Max Profile: A heavy archival command (using precomp/rep/zstd or alternative internal codecs) pushed to its limits for maximum size reduction.

Extraction Command: The matching clean extraction syntax for those specific profiles.

Having a small cheat sheet of tested examples on the forum would be immensely helpful.

for context, i'm currently testing on PS3 ISO's Decrypted.

panker1992
19-09-2026, 11:07
Generally i am trying to understand what is it that you are trying to do ??

if you want to max compression why would you use ZSTD?

precompression is there to help you pack better, so if you precompress kraken and leviathan streams you need equivalent or better to go for more

therefore ZSTD for max compression is a no go,

you can use rep or addex in my archiver both are good deduplications engines self made.

rep is a sliding window, symmetric deduplication engine which uses the same ram to compress/decompress and its very very fast and efficient.

Addex will be better to gather reps that are scattered i used logic that came from Srep to make this happen.

of you want to compress max

xz:l9:d256mb:t10 will give you the best lz77 family can get you

if you want to go oodle, then you can do

oodle:l9:a13:v1:t10:d256mb,
this will make leviathan scoop the input because v1 uses previous block as a dictionary for the next. using :v0 will half the ram

zstd:l22:w31:f1:s9 will give you the best ratio zstd can offer, remember zstd is using Entropy + tANS so it will take 2 hours to compress and will give you worse ratio than xz

if you are interested in details give me a PM and i will help you more

Joe Forster/STA
19-09-2026, 11:11
if you are interested in details give me a PM and i will help you more

I think everyone is interested in the details; that's what this forum is for. :)

panker1992
19-09-2026, 11:44
Details vary per request,

What details do you require??

Do you want to maximize ratio? or get the best possible speed??

Do you have compress once decompress many model ?? like repackers where compressing once takes multiple hours but the unpack will happen to millions of PCs?

Do you want RAM oriented performance ??

how am i supposed to provide detailed guidance in any case.


There is something else as well.

Archiver has Build-in Compressors you are highly familiar with for example lzma2,xz,zstd and more. i didnt change their params to something else so if you know how to use zstd in FA then you can use it on my tool as well in the same way.


Details for my own algorithms is a welcoming question


I have forked xtool 7.9 and i have added native code for packmp3,packjpg,wavpack, and my own algo for OGG, called oggpre.

the same goes for addex, and rep.

So the request for details must at least include a topic.

Registered55
20-09-2026, 02:21
Thanks for the guidance! To give you the exact context of what I'm aiming for:

My use case is "compress once, store forever" (archiving game ISOs like PlayStation 3 dumps and heavy media libraries onto a home NAS). Compression time and CPU/RAM load don't matter at all—I have a 32GB system and I want to squeeze out the absolute maximum space savings.

Once I lock down the ideal settings, my ultimate goal is to wrap this into a PowerShell batch script so the whole pipeline runs completely hands-off. I've experimented with MiniCompressor and DiskSpan 2 in the past, but getting them to cooperate reliably in unattended batch modes proved difficult. Because your archiver.exe is built from the ground up as a standalone entity, it opens up fantastic automation options.

Before I write the wrapper script, I'd love to clarify a couple of quick technical details on how your native algorithms behave:

addex vs. rep: Are both addex and rep fully baked natively inside archiver.exe, or do they rely on external binaries? Furthermore, is addex essentially the advanced evolution of rep for scattered matches (using SREP-inspired logic, as you mentioned)?

Parameter Syntax / .ini behavior: When I tried passing -mrep:m3 directly via the command line, the -m3 parameter seemed to be ignored, and I had to manually edit the .ini file to force it from level 1 to level 3. Is there a specific syntax I should be using in the command string to pass parameters directly to rep or addex without touching the .ini file?

More than anything, seeing a couple of working example command lines (e.g., a standard balanced profile and a max-compression profile using XZ or Oodle combined with your native dedup) would be immensely helpful. It's less about copy-pasting the strings directly, and more about seeing the exact syntax grammar, parameter formatting, and delimiter rules for how your tool's parser expects everything to be structured.

If you can share a couple of reference examples along those lines, I'd love to test them out and start building the PowerShell automation script!

so far i have been building something like this archiver.exe a "R:\PS3\TEST\bejeweled_3_archive.arc" "R:\PS3\TEST\bejeweled 3 [BLUS30865]" -mprecomp:creflate:czlib:cpng:clz4:czstd:cflac:cbru nsli:cpackjpg:cpackmp3:ckraken:b1024:t50p:d2:dd+sr ep+xz:l9:d512:t8 -b4096m --tempdir="C:\Archiver\temp"

but to be clear, i'm learning as i go and no idea if i'm on thr right track, but so far this is the latest string i have cobbled together lol.

another issue i have been having, i'm finding it difficult to get archiver to go above 35% of cpu usage, when it starts it jump to around 50-60% great, but as it gets to stage 2 and 3, the cpu goes down to 35% leaving a lot of CPU performance on the floor.

i have tried playing around with threads, but knowing where to put the -t options where and what number has so far alluded me.

one more thing is, let's say i wanted to run lolz (i have found this in your external archive) where would this be placed in the command string?

panker1992
20-09-2026, 13:54
Addex = a rich matchfinder with ultra long range matching technique.
REP = a minimal matchfinder that uses a sliding window to do the dirty work.

addex:m1 is equivalent to srep:m3f
addex:m2 is equivalent to srep:m4f
addex:m3 is equivalent to srep:m5f

rep doesn't use this at all, rep:a128, a: param is the grater and 128 is the sand, the lower the number the smallest possible match will be found.

if you use :a128 it will find almost all matches within the window
to increase the window you can use :w1g, this will provide a sliding window of 1GB, you can go lower :w512mb and so on.

Addex and rep are build-in you dont need external depedencies and other libraries to enable them.

if you want to maximize the ratio without using external stuff and only what i offer you can use oodle:a13:l9:v1:t8:d512mb
:t is the number of threads and this uses much ram, 512mb * number of threads * 3 to be precise

if you want to use lolz you can do it, i use it too.

it may come as a complete shock but my rep is trully capable, dont think that because it is a rep and not srep that it does bad job.
Test it and compare it, and then you will see, unlike addex rep offers decode speeds multiple gb/sec.

Archiver was created to offer trully next gen experience.
i offer precompression, xtool external libraries if you use them are supported and can be used.

i also offer IO, you can make your own patches for games down the line.

Next update will bring 2 new compressors, that are my own design.

One is tANS, and one will be lz77 family. Enjoy


Quick Fix



archiver.exe a "R:\PS3\TEST\bejeweled_3_archive.arc" "R:\PS3\TEST\bejeweled 3 [BLUS30865]" -mprecomp:cpreflate:czlib:cpng:cflac:cbrunsli:cpack jpg:cpackmp3:t90p:d2:dd+addex+xz:l9:d512:t8 -rr=1 --tempdir="C:\Archiver\temp"