Memory Full

Forum / Development

Best crunchers in 2020

BSC * 10 Feb 2020 17:28:16

Salut und tach auch,

I was wondering which crunchers give the best results both in crunch rate and decrunch speed. I don't care if the crunching is slow. And the decrunch does not have to be blazing fast, either. But the compression ratio should be excellent. I am also interested in articles covering how to improve compression ratio based on how the input file might be organized - if that's feasible.

Thanks in advance!

Beb * 10 Feb 2020 19:33:20

Maybe Aplib or LZSA2.

Hicks * 15 Feb 2020 13:40:00

Hardcore crunching & sloooow decrunching: Shrinkler for 4k (7 seconds of decrunch for The Third Kind), or Exomizer for bigger files (2 times slower than Aplib).

BSC * 04 Mar 2020 20:59:35

Shrinkler yields impressive results. But I will still try Exomizer, too. Any other suggestions?

ast * 17 Mar 2020 12:57:57

My personnal choice will be PuCrunch. I especially love this one.

BSC * 17 Mar 2020 17:04:39

Wow, never heard of that! Thanks, will give it a shot.

ast * 17 Mar 2020 21:15:26 * Modified at 21:15:39

you're welcome Bsc.

Targhan * 27 Mar 2020 20:43:20

Is there a "definitive" cruncher for short data (from let's say, 50 bytes to 2kb)? Or is it "try them all and test"? Thanks.

Hicks * 28 Mar 2020 14:34:02

Try them all!
If datas = 2k, I think that Shrinkler will be the best in all cases.
If datas = 50 bytes, don't crunch them, since every decruncher will be bigger than them.
If datas = 1k, then try a cruncher with a very short decruncher like ZX7 (the smallest one?), it could be better than Shrinkler...

Targhan * 28 Mar 2020 16:34:14 * Modified at 16:34:57

Thanks. But something I didn't say is that there would be many data to decrunch, at various point, so there would be one decrunch code, and many tiny-to-small chunks of data. As for Shrinkler, no way, it is too slow (it's for a game).

Hicks * 29 Mar 2020 09:30:19

Take a look here:
I suppose that LZSA2, MegaLZ, or ZX7 will do the job well... easy to try on a batch of files.

BSC * Today 01:03:19 * Modified at 01:06:26

I have some data that has a lot of inherent/repetitive patterns and thus probably compresses quite good, regardless of the cruncher used (at least that's what I guess). I was wondering, mainly when considering shrinkler, if it was any good if I pre-compressed (more generally re-arrange to decrease redundancies) that data somehow so that my code will expand/create it at runtime, making the uncompressed binary become smaller, even though I'd have to add the code for blowing up that data. I figure the entropy in that version would be higher compared to the untreated one. Do you think that's worth trying? I am sure you guys have already dealt with similar problems.