Advanced Compressor (Nanozip)

[panker1992]

Dear L33THAK0R, and others of course

nanozip cm algo is highly symmetrical, that means that if you need 5 hours of compress time then you need 5 hours to decompress as well.

That said there are some advantages high ratio of course and etc on executables which razor can do better due to internal instructions

lolz is highly Assymetrical compression tool designed to search and compress DDS files 1 to 5 and other type of CM stuff from various textures.

so all in all Nanozip = good against sound executables
Lolz = good against Textures other media files except sound and TXT files

[L33THAK0R]

Originally Posted by panker1992

Dear L33THAK0R, and others of course

nanozip cm algo is highly symmetrical, that means that if you need 5 hours of compress time then you need 5 hours to decompress as well.

That said there are some advantages high ratio of course and etc on executables which razor can do better due to internal instructions

lolz is highly Assymetrical compression tool designed to search and compress DDS files 1 to 5 and other type of CM stuff from various textures.

so all in all Nanozip = good against sound executables
Lolz = good against Textures other media files except sound and TXT files

Thank you for the detailed response! I'll be sure to test out NanoZip on sound executables!

[kj911]

Found very rare case, bug from NanoZip 0.09alpha x64 version!! (OS: Win7 SP1 Ultimate x64)

Default file compressions schema: Any compressors use any X MB's Dictionary Size or Comnpression memory from during compression.
Higher values = Better compression. Usually it is.
Found worse variant from use NZ x64 version, compare to x86 versions.

Source: MSTS game, 159 372 files, 19 007 954 401 byte.

NanoZip 0.09alpha x64:
-co -m3g (opt1): 7 074 556kB = 6908.746MB = 6.747GB*
-co -m6g (opt1): 10 718 627kB = 10467.41MB = 10.222GB* (WTF!!!)

NanoZip 0.09alpha x86 GUI:
-co -m512m (opt1): 7 322 122kB* = 7150.509MB = 6.983GB (Hmmm!)
-co -m3072m (opt2): 6 922 587kB* = 6760.339MB = 6.602GB (Best!)

Yes! Use 6GB memory from x64 version during the compression and very worse results than 3GB memory and x86 version results!

Note: x86 version not handle 3600/3840MB's memory allocation from compression process. Max. memory usage 3072MB+few MB's use from compress.

Note2: *The complete MSTS game (and WAV files separately) compresssed in via 10+ times repeated again, use various compression algos and programs. Results it coming soon. The NZ version results not containn two RAR-archives (2*9580264byte), deleted from before during compression. (Crunch Two RAR's with FreeArc -mx switches: 5572kB) All unnecesseray temp or not fully removed the game. (10+ file, ~20-21MB's useless data.)

Images:




Memory allocation or any bug, error?? Don't use x64 versions?

And found bug from x86 version lzpf algos! (OS: WinXP SP3)
Compress 2.09GB's WAV files (5001 file) and not handling the properly from during compression! Compression percentage stuck at 6-7%, archive size 100/107MB's and exited now! (Don't killed/breaked!) Not finishing the compression process and make wrong archive!