Yeah I have one what youre saying and cls from razor but the problem is it's extracting data more than original size and only in one file I got 8 Files but it's extracting only in 1 file and size is bigger than original. Why???

i truly try to help you man
try use srep witout cls in compression and with decompression use cls by profargo 0.33

@PrinceGupta I tried razor cls decompression failed because it's decompressing data more than actual but when I use cls which is 86 on deck pressing successfull with speed of 20 Mb/s

@doofoo24 OK now I had compressed the whole game with srep without cls if I use cls profeg one will it decompress successfully???

But why razor cls extracting more data than actual

ImmortalArc what the method you using

-m3f

not srep but in the batch file what srep + ?

default pzlib arc.bat
Method is -mpzlib+srep+lzma

But I don't know why cls makes decompress slower

ok now
are you using external lzma or fastzip ....
it do not matter
i use file in the folder
srep.exe
pzlib.exe
arc.ini
.bat file
arc.exe
and the folder you want to compress that all i don't use fastzip or other dll
if you have problem in decompression try it
only this file are necessary
try in bat file
arc a -lc4096 -ed -ep1 -r -ma -md -mx -s; -w.\temp -mpzlib+srep+lzma:a1:mfbt4:d185m:fb273:mc10000:lc8 31.arc "file\*"
and make sure their is no fastzip or other lzma in arc.ini only

[External compressor:pzlib]
header = 0
packcmd = pZLib e -m2 -c16m -b256k -t8 - -o - <stdin> <stdout>

[External compressor:srep]
header = 0
packcmd = srep -m3f -a2 $$arcdatafile$$.tmp $$arcpackedfile$$.tmp

no. lzma is really that slow. lzma2 will be faster, since it just copies incomperssible data instead of trying to compress them

if you have problem, try to solve it in small steps: remove evrything else from your compression method and try with srep.exe, then with vaioyus dlls that you trust

bulat but in lzbench on github lzma or xz speed around 60 mb/ s,
so shouldn't lzma in freearc be the same ?

1. computers are different
2. speed depends on the data
3. we usually measure speed of decompressed stream i.e. if in 1 second 20 mb are decompressed into 60 mb, we say that the speed is 60 mb/s

try to compare with 7-zip/xz speed and you will find that arc is pretty close

I Would say it is an Internal Bug , i already reported it earlier
http://fileforums.com/showthread.php...684#post452684

yes i think its strange because cls by Profager is always manages to deliver correct data,
i think it is because the ClS-Srep by Profrager is kinda old and probably written using older sources of srep which doesn't have that bug, may be it can be possible
on the other hand CLS by Razor doesn't work on the ground level, It is simply like using arc.ini but with some more settings like use of x64 srep
I don't know how razor's CLS actually works its a conjecture nothing more

Bulat you right using 7z
[External compressor:lzma2]
header = 0
packcmd = 7z a -txz -an -mcrc=0 -m1=lzma2:d128m:fb=273:mf=bt4:mc=10000:lc=4:lp=0 -mmt=8 -mx9 -si -so <stdin> <stdout>
unpackcmd = 7z x -txz -an -y -si -so <stdin> <stdout>

with freearc is almost the same as using lzma in freearc and the built-in lzma give better ratio 0.5% to 1%.
but i have other question why ZSTD IS WORST THAN 4X4:LZMA in decompression speed i have I7 6700K 4.7GH OVERCLOCK WITH SSD NVME
4x4:lzma decompress around 1gb/ sec but use more memory and cpu to the full while zstd only use 128mb of memory but limit to 400 to 500 mb /sec.
i find it odd ?