FileForums - Shelwien's Reflate compatible with Freearc

FileForums (https://fileforums.com/index.php)

- Conversion Tutorials (https://fileforums.com/forumdisplay.php?f=55)

- - Shelwien's Reflate compatible with Freearc (https://fileforums.com/showthread.php?t=98317)

actually you will never get the error in PZLIb V3H if you use reflate dll and smaller value with -s
looks like the error is in razor methods(m1,m2) but not with reflate itself
try using something like pzlib:m2:x:s16:c96m:t100p
arc.ini

Code:

[External compressor:pzlib]

header = 0

packcmd   = pzlib64 e {options} - -o - <stdin> <stdout> 

unpackcmd = pZLib64 d -t100p - -o - <stdin> <stdout>

What exatly -s parameter does? I not even added this but using reflate.dll worked, now pzlib detect streams and can decompress it without error. Thanks for simorq and princegupta2000.

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

without error

I just noticed than if i use one sollid block with this command -s; it cause error in decompression with Pzlib+reflate.dll in this specific game i trying. If i set manual solid block size with -s8192m it decompress without error.

Simorq -t#p only dictate the number of your CPU threads in percentage, does the thread numbers used affect reliability for compression to avoid errors? When i decompress i use higher amount of threads because decompression speed with pzlib is very sensitive with number of CPU threads used.

Code:

Compressed 12,723 files, 8,971,439,002 => 3,806,018,872 bytes. Ratio 42.42%

Compression time: cpu 17.97 sec/real 2054.92 sec = 1%. Speed 4.37 mB/s

All OK

Decompression using -t6:

Code:

Extracted 12,723 files, 3,806,018,872 => 8,971,439,002 bytes. Ratio 42.42%

Extraction time: cpu 20.91 sec/real 271.14 sec = 8%. Speed 33.09 mB/s

All OK

What's the difference between k and l in archive?