hi guys I have a quisition
does the order of the External compressor matters?
I mean for example in the arc.ini file:

[External compressor:srep]
[External compressor:precomp]
[External compressor:pzlib]
[External compressor:lzma64]

If I changed the order would it matter with compresion?

order in arc.ini doesn't affect anything

I have made an observation, which appeared very strange to me.

If your compression method looks something like this:

You've to rename cls-srep.dll to cls-srep64.dll in order for it to decompress, or else, it'll get stuck after decompressing a few files every time. This is applicable to WPI, btw. I don't know how to work with any other scripts so I can't speak for the others.

cls-XXX.dl decompress method XXX, so just look into compressed data. may be method is encoded as "srep64" - in this case cls-srep.dll isn't used at all and you probably stuck with arc.ini-specified srep.exe in stdin-to-stdout mode, which isn't very reliable in freearc

Is this always the case or stdio isn't properly implemented in FA?

yes, stdio-to-stdout mode in freearc has bugs and i don't know how to implement it correct

@Bulat..Why not open a new thread with the beta version 0.20 of FANext compiled.
So you can discuss, test it, and test pros and cons.
Honestly I tested the 0.11 release, but I have had various difficulties in its operation, continuing to love only FreeArc.:)

i will do that when it will be released

here i answered on the question about old arc.exe

Oh Yepp the context I had understood of the old FA ....:), more or less when is estimated the FANext release with a new update?

Stupid question: What`s the difference between 32 and 64bit version?

Conversion speed, x64 is more faster.

Thanks for this razor.

First i was dumb, i got everytime errors in compression, then - after some hours of try&error - i checked arc.ini... there was no packcmd for pzlib... Now i got it :D

I think my first conversion using pzlib is just behind the mountain.

PS: Is there any pzlib checker? Can't find it on INDEX.

zlib checker
http://fileforums.com/showthread.php?t=97657
http://fileforums.com/showthread.php?t=98198

Razor, what would you recommended settings be for a PC equipped with 16 GBs of RAM and four cores/four threads processor when using pZlibV3?

I am getting CRC error during decompression while compressing Witcher 3, BTW.

My current settings:

I had CRCs too. Define number of threads like this : -t75p and it will be fine (in pack/unpack section)

Thank you!

More time for games with the big size pZLib comes problem for extracting

But these settings will fix the problem.

[External compressor:pZLib]
header = 0
packcmd = pZLib e -m2 -t125p - -o - <stdin> <stdout>
unpackcmd = pZLib d -t100p - -o - <stdin> <stdout>

What games and errors like what?

BERSERK And The Band Of The Hawk
crc error

Hello, I'm trying to compress the bf3 multiplayer.
But I'm having problems when it comes to unpacking it.
One of the most common problems is CRC error
Could you say that I am doing wrong?

https://k60.kn3.net/F/8/E/7/6/C/177.jpg
https://k60.kn3.net/F/5/1/6/6/7/7FB.jpg
https://k61.kn3.net/0/F/E/1/6/8/D24.jpg
https://k61.kn3.net/2/1/9/1/8/C/392.jpg

ARC.INI
[External compressor:msc]
header = 0
packcmd = msc c -v -f -wav=1 -raw=1 -bmp=1 -ddsraw=1 -ddsdxt=1 -mp3=1 -bmf=9s -tak=9+ -dxt=1 -lzma=hc4,lc8,lp2,pb2,fb273,mc1000000 $$arcdatafile$$.tmp $$arcpackedfile$$.tmp

[External compressor:pzlib]
header = 0
packcmd = pzlib e -m2 -st75p -t4 -ct8 -c32m -b512k $$arcdatafile$$.tmp -o $$arcpackedfile$$.tmp
unpackcmd = pzlib d -t4 - -o - <stdin> <stdout>


[External compressor:srep64]
header = 0
packcmd = srep64 -m5f -d1g -a2 $$arcdatafile$$.tmp $$arcpackedfile$$.tmp
unpackcmd = srep64 -d -s -- <stdin> <stdout>

[External compressor:xz,lz77]
header = 0
packcmd = 7z a -txz -an -mcrc=0 -m1=lzma2:d120m:fb=273:mf=bt4:mc=1000000:lc=4:lp=0 -mmt=4 -mx9 -si -so <stdin> <stdout>
unpackcmd = dec x -txz -an -y -si -so <stdin> <stdout>

Repack.bat
Arc a -ma9 -ds -lc1024 -ld1024 -ep1 -di -i2 -ed -r -s; -w"D:\TMP" "E:\BF4 repack\Setup-1a.bin" -mpzlib+msc+srep64+delta+exe2+lz77 "E:\Program Files (x86)\Split_Kompress_v1.3d\Temp Folders\Battlefield 3_1\*"

I am using this version of arc.exe and unarc.dll

http://fileforums.com/attachment.php...6&d=1488018486

pzlib is not perfect, it does have bugs.

But I do every time I use the single-core (t25p), there is no problem and error:D

Sample
Just Cause 3 pZLib e -t100p Crc Error | -t25p No Crc Error
BERSERK And The Band Of The Hawk pZLib e -t100p Crc Error | -t25p No Crc Error
Final Fantasy X X-2 HD Remaster pZLib e -t100p Crc Error | -t25p No Crc Error

Someone on the previous pages telling not to use <stdin> - <stdout>. Then you should use all settings without crc error. But honestly, i don't know how to use this.

single thread has a different code in pzlib, no point in using multi threading technique for 1 thread, result will just be slower.

I wonder the same thing
However, for me this is it.

I've tested many games with large file

For example
BERSERK And The Band Of The Hawk
Just Cause 3
pzlib:m2:x:s:r9:t100p:st100p:ct100p Crc Error
pzlib:m1:x:s:r9:t100p:st100p:ct100p Crc Error
pzlib:m2:t100p:st100p:ct100p Crc Error
pzlib:m2:c250m:t100p Crc Error
pzlib:m2:t100p Crc Error
pzlib:m2:t75p Crc Error
pzlib:m2:t50p Crc Error

pzlib:m2:t25p No Crc Error

Use External compressor

[External compressor:PZLib]
header = 0
;packcmd = pZLib e -m2 - -o - $$arcdatafile$$.tmp -o - <stdout>
;packcmd = pzlib e {options} - -o - <stdin> <stdout>
packcmd = pZLib e -m2 -t25p - -o - <stdin> <stdout>
unpackcmd = pzlib d -t100p - -o - <stdin> <stdout>

CLS uploaded

Cls decodes only, might fix bugs.

@Simorq

-t#, automatically sets -st# and -ct# to be the same value.
Try,
pzlib:m2:t100p:st1

CLS can decompress without pzlib.exe or not ?
btw, thanks still update for PZLIB.

update :
got some error in cls, always close....

It just closes?

yes, always close. i try in other archive and same, still closing while extracting.
Always close in 54% - 57%...


Before, i compress use pzlib.exe for 64-bit but in extacting i use pzlib.exe 32-bit and working fine.

The CLS works wonderfully, thank you Razor!

Does not require pzlib executable (I assume that's the purpose of cls to begin with?)

Tip: If you used pzlib64 to compress your game, rename the cls-pzlib.dll to cls-pzlib64.dll and it'll work just fine.

Thank you very much
But the problem is not solved.

Styx Shards of Darkness
Mad Max
I think it is a bug in -t.

With most games i get ok decompression with CLS+Freearc GUI, but with one game specifically i get errors during decompression like others.

Apparently CLS-pzllib.dll is not respecting the argument -t#p or -t# for decompression, even if i set -t50p it always using total of 7 threads (-t75p). I have 8 threads CPU.


Edit: Ok i find the cause of decompression errors. If i compress that specific game with -t75p then decompression will cause error. But compressing with -t50p give correct decompression without any error. Anyway decompression always using -t75p for cls-pzlib.dll.

Like I said before, -t# sets -st# and -ct# to be the same value, so if st1 gives errors, you might wanna try -st2

Try to set t75p @comp/decomp.
It worked for me flawless!
Previously i had many CRCs,too.
Let me know the results.
And before i forget,do not use pzlib's stdin/out !!!
Specify output/temp files,like in precomp ! :)

Thank
I'm testing and I'm Report
But it it does not matter
It is important for decompression using t100p:D there is no problem

Razor, thanks for cls, great update! One question: is it locked to 50p or 75p of available cores? And can it be adjusted like you did it in config for cls-precomp?

Mad Max

That's not surprising.

Mad Mad is compressed using level 1, by default pzlib is level 6, or rather reflate, the moment you place raw2hif_dll.dll, you are disabling internal recompression, so this is what you will get.

ZLibv3:c256m+srep+Lzma2 6.4 GB
because level 6 was used, you didn't set reflating level, which is the -r# option.
Secondly, the option -x, enables both internal recompression to work with reflate. which is why 4.26GB is the best size because unlike reflate, internal recompression works like precomp, trial and error, it will try all levels and pick one that is best.

@Everyone
pzlib does work without raw2hif_dll.dll, only place the library if you know what it does, or how it works or how it is used else you'll just end up with negative ratios.

CLS updated

-Added confirguration
-There a few noobs out there, so hif2raw_dll.dll is embedded in cls, it's loaded automatically, no need to place near it near the CLS, at least this could rule out a few errors.

Tested new updated CLS - it works good, but the bug from pzlib.exe still exists - it's impossible to cancel unpacking. Before it was possible to kill pzlib.exe process, now the whole setup must be shut down.