Advanced Compressor (Nanozip)
 

Intro Nanozip

Nanozip is by the far the program that i still try to figure out,
the reason follows in the diagram below.
as you can see it features many switches that manipulate different algos



Options Alg
--------- ----
-cf LZP = fast comp/decomp
-cF LZP = fast comp/decomp improved
-cd lz77 = pretty tight comp very close to lzma if not identical
-cD lz77 = pretty tight comp very close to lzma improved
-cdP lz77 = parallel comp identical to xz method i originally posted in the forum
-cDP lz77 = parallel comp identical to xz method improved
-co BWT = best compression with fastest decom
-cO BWT = best compression with fastest decom imporved
-cc CM = *Ultimate Compression* extremely slow



Positives:
1) It has better ratio over lzma
example: i compressed MGS V into 11.7G without reflate and with precomp set to intense overall it took 5~6 hours to compress and 1 and a half hours to decompress
2) It can be used atop of lzma algo YES you can do lzma and then nz on top :P
3) It takes less ram to Compress you can get better ratio than lzma with 2G dictionary
4) Supports multicore systems in both comp/decomp
5) Can be used with masked compression for greater results

Negatives:
1) It takes the same amount of ram to decomp as it takes to compress
2) its decomp speed is around 10m/sec in -cc and arund 50m/sec in -cO
you will lose some ratio but its worth with that speed
3) it's progress cannot be seen in Inno though it works flawlessly
4) it lucks stdin and stdout

Oh look, panker discover nanozip congrats panker. Ccm algo have better compression ratio than lzma with speed cost. The creator of nanozip take ccm algo and he make the best optimization for the algo but nanozip is close source. He take the source to the grave.

in ASC, I somehow made it possible to show decompression progress of nanozip and other compressors like bcm. For now it is not perfected.

well i didnt discover anything, this post isnt about discovery at all.

its an addition to my original Masked Compression project that i indeed discover along with xz.

Nanozip may be a closed source and slow along the way but if you mask it you may get
pretty nice results



@razor i use Kurutsu's source are they different from yours in progressbar?? how can i implement it ?

Kurutsu's source?

kurutsu blackbox Inno setup 1.8

how come you havent seen that before ?? :/

Oh that, I have seen it but I haven't used it in a while, maybe last used it 2-3 years ago. I just forgot about it, I don't know if compatible but asc isn't built using inno setup like the bb script is. So far it works with bcm compressor, will just have to post pic to show you what I mean.

Razor as you can see my GUI-coding skills are novice,

i am trying to bring my projects to Bilawal's RG script and your ASC project but

i cannot make them work without archive.ini file

have problems making your program to read my data.bin file :/

hello panker 1992
thank you for your work
we do not see in advance progress bar of zpaq in inno also with kurutsu blackbox Inno setup 1.8
thank you for your tools

Kenzo yes this is right, you dont get to see zpaq but usually text files that zpaq compresses, decompress in an instance you only feel a moment of freeze nothing else



Here we are talking about an entire 20 maybe 30 gigs of game :P the amount of time that it need in cm algo is freaky

Nanozip is the best compressor #1 in the world of compression. Cmix0.6 use ccm and is a little faster than nz but you know compression ratio cost.btw nice info about nanozip panker. Pd: LOL is kurutucu

and the funny thing is that i have used his script for 2+ years :)

i like nanozip because it has many algorithms inside it, took me a long nighter to optimize the thing :P

with masks you can use it in different styles example
a)
[External compressor:nzf]
;nzf = stands for fast
packcmd = nz a -r -v -cO -m4g -t0 -br128m -bw128m -p2 $$arcpackedfile$$.tmp.nz $$arcdatafile$$.tmp
unpackcmd = nz x -m1400m -t0 -p0 $$arcpackedfile$$.tmp.nz $$arcdatafile$$.tmp
datafile = $$arcdatafile$$.tmp
packedfile = $$arcpackedfile$$.tmp.nz


b)

[External compressor:nzs]
;nzs = stands for slow
packcmd = nz a -r -v -cc -m6g -t0 -br128m -bw128m -p2 $$arcpackedfile$$.tmp.nz $$arcdatafile$$.tmp
unpackcmd = nz x -m1400m -t0 -p0 $$arcpackedfile$$.tmp.nz $$arcdatafile$$.tmp
datafile = $$arcdatafile$$.tmp
packedfile = $$arcpackedfile$$.tmp.nz


and then use mask to compress text with nzs for ultimate compression and
nzf for fast data :)


PS: but i wonder how long till they find out themselves :)

I don't get what up with the masks word???

Ramiro i havent had the time to give a full scale tutorial about it yet :/ i was really busy to make a inno setup for it :)

send me an inbox and i will tell you about it in a few words

Hi all, just stumbled across nanozip after seeing it used in various repacks, how does it compare to "lolz"? Are there general advantages/disadvantages or are the benefits/downsides situational? I mostly use "lolz", but sometimes use "lzma" (when beneficial) as a final compressor, but I haven't the foggiest idea what nanozip actually is or how it works.

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!

NanoZip 0.09 alpha x64 BUG!
 

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!!!) :eek:

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:
https://i.kek.sh/i5q5LNIcYdc.png
https://i.kek.sh/k8qAx2qQRjy.png
https://i.kek.sh/si0yrbUaTiP.png

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!

https://i.kek.sh/yai7Al9RMSc.png
https://i.kek.sh/9Geh5tLebBW.png