FileForums - x86 compatible compression equivalent

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

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

- - x86 compatible compression equivalent (https://fileforums.com/showthread.php?t=99124)

x86 compatible compression equivalent

I am very much novice in all this and I was wondering if there's an x86 equivalent of Fazip? The reason I ask for this is that I am trying to compress some older games like Mass Effect Trilogy, and I would like to maintain x86 OS compatibility if possible.

I am at my wit's end and I can't seem to get the 32Bit xz to work. It keeps saying Disk Full and refuses to compress regardless of the parameters used.

Quote:

Originally Posted by romulus_ut3 (Post 458028)

I am at my wit's end and I can't seem to get the 32Bit xz to work. It keeps saying Disk Full and refuses to compress regardless of the parameters used.

You can just compress with 64-bit tools and extract them using 32-bit ones.

I wasn't aware of that. Is that possible? The de-compressors that are included to unpack the archives are 64 Bit. Hence the question.

here you will find everything
http://fileforums.com/showthread.php?t=98819

64 bit and 32-bit compressed version are 100% compatible

Quote:

Originally Posted by PrinceGupta2000 (Post 458042)

here you will find everything
http://fileforums.com/showthread.php?t=98819

64 bit and 32-bit compressed version are 100% compatible

Thank you, I have seen those, however, there are some 32Bit variants of known compressors like xz and lz77 that aren't included there, and I am having difficulties getting them to work.

Since we are on the subject of maintaining compatibility, maybe some of the more talented people like Razor, yourself and Panker, Felice, JRD! can do something about maintaining x86 and older OS compatibility? It'd greatly serve the purpose of preserving historical accuracy.

1. all compressors i ever seen, had 32-bit and 64-bit versions compatible by the compression data, i.e. ypu can compress with x64 and decompress with x86 and vice versa - as far as it fits into memory available for program

2. i'm sure that you can google for official XZ site and download 32-bit version here

3. my FAZIP includes only algorithms internal to freearc itself, it's just external implementation of internal compressors. so, 32-bit and 64-bit fazip versions are compatible with each other as well as with internal freearc implementation of algorithms with the same names

Thank you for your response, Bulat. :) It's great to see the initiator himself is present among us.

I have obtained the xz and lz77 32Bit variants through googling.

However, the problems I have are the following.

Code:

[External compressor:xz]

header = 0

packcmd   = xz a -txz -an -mcrc=0 -m1=lzma2:d25:fb=273:mf=bt4:mc=1000000:lc=4:lp=0 -mmt=2 -mx9 -si -so <stdin> <stdout>

unpackcmd = dec x -txz -an -y -si -so <stdin> <stdout>

This is what my arc.ini looks like. And it always results in the compression process stopping whenever I am using the x86 variant of xz with the error hard disk is full. I, by no means understand the parameters used in the compression and I'd very much appreciate it if someone could point out what I am doing wrong?

^Just change d25 to d64m or d128m etc... I still don't get why you want to compress with x86 variant. Just compress with x64 variant as it supports higher dictionaries or memory usage and use x86 variant only for decompression.

Just to update on the situation, I took FD_RLT's advice and compressed everything with X64 Binaries, and used X86 Binaries for decompression, and there's visibly no changes in decompression speed whatsoever between the two, and everything worked out like a charm.

I thank each and everyone of you for your input, and also Felice2011 and RamiroCruzo, whom I have pestered via PM! :D

I have one last question though, what's the difference in Srep m3f and m5f? Is there an advantage in using Srep m3f over m5f?

Quote:

Originally Posted by romulus_ut3 (Post 458140)

I have one last question though, what's the difference in Srep m3f and m5f? Is there an advantage in using Srep m3f over m5f?

Select the help-info from the command line or the Viper and you will get all the information.

Quote:

Originally Posted by felice2011 (Post 458145)

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.

m5 is always best, but maybe only by a small margin. using m5 may trash your hdd, while m3 works entirely from RAM. m4 is between them in both terms - it rereads data from HDD like m5 but less amount

Thanks a million. :) Yes, I've noticed that m5f brings everything down to a crawl, specially when handling a large file. I don't own a SSD so I guess m5f isn't going to be as taxing when longevity is concerned.