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!
