Fast Brute (test)

[felice2011]

Originally Posted by Amsal

Actually I was asking for brute, that command I know with precomp 038, but I want to know with brute

Now I'm testing the result of "brute" with Mad Max.
Beyond to infinity of time which is putting, I'm curious to know the compression ratio.

[Razor12911]

Good luck.

[felice2011]

Originally Posted by Razor12911

Good luck.

With the hope that has all the fallen teeth ...

☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢ ☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢

Test executed of the game "Mad Max" File "game38.arc", Tool used in compression "M&S Kompressor".

Input File = 554MB

T1 = precomp0.38+msc+srep64+dispack070+nz / Output = 419.154MB / RC = 75.68% / T°= ~ 00h.03m.50s

T2 = pzlib+msc+srep64+dispack070+nz / Output = 419.728MB / RC = 75.79% / T°= ~ 00h.02m.30s

T3 = brute+msc+srep64+dispack070+nz / Output = 282.384MB / RC = 50.99% / T°= ~ 01h.54m.16s

Truly amazing the compression ratio with the new brute compressor, but time seems exaggerated with just 554MB of tests.

Razor & Panker are doing a great job, are having my admiration. ٩(๏̯͡๏)۶

[Razor12911]

2 hours mate?! I get 0.2mb/s on data without zlibs, always like that. 554 / 0.2 / 60 = 46.167 minutes, but there is room for improvement.

[felice2011]

I forgot to read the speed of the closing of the compression with brute, but the result is to, it would be good thing to be able to refine adding a compression level to be chosen, for example from L1 to L9, actually also the compression seems excessive we speak of 50% Mad Max is 32GB would become 16GB, I guess to install it and decompress the archive it will take two days..

[Razor12911]

Haha, level setting is not needed for this, it's not based on raw2hif or reflate for that matter.

[felice2011]

A real disadvantage is compiled in this way, the compression time is too high, and certainly also the decompression time, you have to find the right balance for all, and give the user the ability to choose its own level of compression, in this way "brute" will not make a long way, I'm sorry mate.

[Razor12911]

Haha, compression time high, have you tried precomp brute? How does it compare to this with speed? BTW, it doesn't mean if compression took long, decompression will take long as well.

[felice2011]

My interest is the new brute, I have no interest to compare the precomp with brute, personally think that the only precomp compression worthy is the "0.38" all other versions continue to generate errors on most files at the end of data compression, I tested the last 0.45 by schnaader, and personally I still do not see any substantial difference.

it doesn't mean if compression took long, decompression will take long as well

Ha ha...I hope it is as you say, but I doubt it

[Razor12911]

Originally Posted by felice2011

A real disadvantage is compiled in this way, the compression time is too high, and certainly also the decompression time, you have to find the right balance for all, and give the user the ability to choose its own level of compression, in this way "brute" will not make a long way, I'm sorry mate.

Dude. "give the user the ability to choose its own level of compression"
This doesn't make sense, how can you add level for decompression? Brute is not reflate or made based on raw2hif, level setting is something that reflate does itself, brute on the other hand is search every byte then decompress.imagine a 794mb file, it has 832 618 624 bytes, brute must use trial and error for every single of those bytes starting from 1 to file size, brute checks about 200000 bytes per second on my cpu, I dont think that is slow.

[felice2011]

Originally Posted by Razor12911

Dude. "give the user the ability to choose its own level of compression"
This doesn't make sense, how can you add level for decompression? Brute is not reflate or made based on raw2hif, level setting is something that reflate does itself, brute on the other hand is search every byte then decompress.imagine a 794mb file, it has 832 618 624 bytes, brute must use trial and error for every single of those bytes starting from 1 to file size, brute checks about 200000 bytes per second on my cpu, I dont think that is slow.

Mine was only a hypothesis and a request on a product that I do not know, I can not know with what structure and concept compresses a file, we are talking about "Fast Brute" and therefore hypothesized the possibility to make it even more faster.
I like to be informed about things, especially on issues that interest me, sorry for the chatter.
P.So not use the noun dude, it's unpleasant.

[ChronoCross]

Is impossible not compare brute with precomp or reflate. But each of this tools are very diferent and unic. The concept to brute in applications always is very power and slow. I was spend 17hs to test folder in brute mode on my own compiled version of precomp. But in fastbrute only spend 1.30hs and the results are very close. The test was made it without any pipe chain with compressors.

[ramazan19833]

arc.exe a -ep1 -r -ed -s; -w.\temp -mbrute+msc+pzlib+srep+delta+lzma:a1:mfbt4:d512m:fb 273:mc1000:lc8 -ld4096mb data.arc

unpacked HELP

[Razor12911]

You can't unpack just yet man.

[chum]

Good job bro, i want to congrat you for keep helping community for long time.

My test with GTAV x64w.rpf 893MB.

Bilawal reflate+srep+lzma -> 498MB in 451 seconds.
FastBrute+rep+delta+exe+lzma -> 558MB in 1426 seconds.
fastbrute+srep+lzma => 526MB in 758 seconds.


Precomp with brute mode is too slow for GTA 5 file.