FileForums

FileForums (https://fileforums.com/index.php)
-   Conversion Tutorials (https://fileforums.com/forumdisplay.php?f=55)
-   -   Fast Brute (test) (https://fileforums.com/showthread.php?t=97898)

felice2011 18-05-2016 11:27

Quote:

Originally Posted by Amsal (Post 449100)
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.:rolleyes:

Razor12911 18-05-2016 11:51

Good luck.

felice2011 18-05-2016 12:42

Quote:

Originally Posted by Razor12911 (Post 449105)
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 18-05-2016 14:57

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 18-05-2016 15:49

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..:D

Razor12911 19-05-2016 00:48

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

felice2011 19-05-2016 01:30

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 19-05-2016 01:35

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 19-05-2016 01:53

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.
Code:

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:rolleyes:

Razor12911 19-05-2016 03:49

Quote:

Originally Posted by felice2011 (Post 449116)
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 19-05-2016 05:47

Quote:

Originally Posted by Razor12911 (Post 449119)
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
P.S:Do not use the noun dude, it's unpleasant.;)

ChronoCross 19-05-2016 15:16

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 22-05-2016 09:24

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 22-05-2016 10:43

You can't unpack just yet man.

chum 29-05-2016 13:08

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.


All times are GMT -7. The time now is 12:13.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2026, vBulletin Solutions Inc.
FileForums @ https://fileforums.com