Quote:
Originally Posted by felice2011
Select the help-info from the command line or the Viper and you will get all the information.
|
I did that before I posted the question.
The answer looked greek to me.
I could use the explanation in Layman's terms.
Code:
-m0: only in-memory compression (REP algorithm)
-m1: fixed-window content-defined chunking with matches checked by VMAC
-m2: order-1 content-defined chunking with matches checked by VMAC
-m3: check matches by VMAC digest (compression memory = 7-8% of filesize)
-m4: check matches by rereading old data (compression memory = 3-4% of filesize)
-m5/-mx: rereading with byte-accurate matches (compression memory = 7-9% of filesize)
-l: minimum LZ match length, default 0
-c: size of hash chunk, by default as small as required to find all these LZ matches
-aX[/Y]: alloc X bytes of those Y bits will be set per L input bytes for compression accelerator
Y=0/1/2/4/8/16/32/64, -a0 is slowest but requires least memory
-ia-: disable I/O acceleration to reduce memory usage (-m5* only)
-tN: use N compression threads (only for -m1/-m2)
-dBYTES: dictionary size for in-memory compression (REP algorithm), default 512mb
-dhBYTES/-dcN/-dlN: size of hash / size of hash chunk / minimum match length for in-memory compression
-m1..-m5: index-LZ - list of matches saved at the end of compressed file
-m1f..-m5f: future-LZ - decompression dictionary will hold only future matches
I could've sworn I saw a post where someone said that using m3f gives compressors like lzma2 to achieve better ratios, though I am not a 100% certain. Pardon me if I have mistaken, as I can't really recall this correctly.