![]() |
Quote:
Beyond to infinity of time which is putting, I'm curious to know the compression ratio.:rolleyes: |
Good luck.
|
Quote:
☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢ ☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢ 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. ٩(๏̯͡๏)۶ |
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.
|
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
|
Haha, level setting is not needed for this, it's not based on raw2hif or reflate for that matter.
|
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.
|
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.
|
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 |
Quote:
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. |
Quote:
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.;) |
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.
|
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 |
You can't unpack just yet man.
|
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