BALZ v1.12 is here!

[encode]

OK, the brand new BALZ is here. New version features an improved mixer and some code optimizations. Enjoy!

http://encode.su/balz/index.htm

P.S.
Simon Berger, I'm sorry...

[Shelwien]

http://shelwien.googlepages.com/balz112.htm
Seems like compiler tweaking helped

[encode]

http://shelwien.googlepages.com/balz112.htm
Seems like compiler tweaking helped

Thank you!

[encode]

Testing results:

calgary.tar -> 836,654 bytes

sfc.7z -> 12,016,390 bytes

ENWIK8 -> 26,522,258 bytes
ENWIK9 -> 229,347,434 bytes

A10.jpg -> 836,359 bytes
acrord32.exe -> 1,377,909 bytes
english.dic -> 751,042 bytes
FlashMX.pdf -> 3,718,531 bytes
fp.log -> 554,250 bytes
mso97.dll -> 1,805,258 bytes
ohs.doc -> 805,189 bytes
rafale.bmp -> 981,574 bytes
vcfiu.hlp -> 638,674 bytes
world95.txt -> 556,146 bytes
Total -> 12,024,932 bytes

[LovePimple]

Thanks Ilia!

Mirror: Download

[encode]

LTCB updated:
http://cs.fit.edu/~mmahoney/compression/text.html#2293

[toffer]

I'm not that interested in such old algorithms (yyLZxx) but you keep making nice improvements. I can still remember lzpm Keep on going!

[Jahoui]

Hi, could you please include a small Changelog in the readme ?

[encode]

Just as you say! But for now the forum is the best changelog...

[encode]

Tested BALZ with SSE/APM. SSE/APM implemented in the PAQ9a manner - i.e. an additional mixer that mixes the final probability with p=0.5. Such thing works being fast - i.e. no huge speed penalty if at all, although it needs more experiments, mainly with SSE context...

[Shelwien]

Isn't that just a mixer? Somehow I expect SSE to split the probability range.

[encode]

Isn't that just a mixer? Somehow I expect SSE to split the probability range.

It's simply my mixer with a different configuration - i.e. initial weight plus different ranges for probability balancing. Well, with such thing BALZ compresses sf.7z down to 11,976,827 bytes - i.e. we go under 12,000,000...

[Shelwien]

Btw, check out my E8 (its in ST2.inc):

balz 1.12
wcc386.ex     287487
wcc386.e89.ex 268361

[encode]

Btw, check out my E8 (its in ST2.inc):

balz 1.12
wcc386.ex     287487
wcc386.e89.ex 268361

I know about wcc386... BALZ searches for valid PE-header in the buffer, and only after applies E8/E9 transformation. Somehow, wcc386.exe has no valid PE header inside... I really don't care because it's an old/outdated file, on ALL other files BALZ is OK.

[Shelwien]

Well, you're wrong about that, if you only apply E8 to the files with PE header.
First, there're "incorrect" files with PE header, like 64-bit or compressed ones.
And also there're non-PE executables, like linux ELF binaries... or wcc386.

Btw, I've checked with acrord32.exe and balz 1.12 ex made 1377909 straight
and 1380640 after I patched out MZ and PE signatures and applied my filter.
Does it mean that your E8 implementation works better?

[encode]

Well, you're wrong about that, if you only apply E8 to the files with PE header.
First, there're "incorrect" files with PE header, like 64-bit or compressed ones.
And also there're non-PE executables, like linux ELF binaries... or wcc386.

Btw, I've checked with acrord32.exe and balz 1.12 ex made 1377909 straight
and 1380640 after I patched out MZ and PE signatures and applied my filter.
Does it mean that your E8 implementation works better?

Yep, I use approach similar to CABARC. Also, I'm not sure about that my filter will work for 64-bit executables...

[Simon Berger]

OK, the brand new BALZ is here. New version features an improved mixer and some code optimizations. Enjoy!

http://encode.su/balz/index.htm

P.S.
Simon Berger, I'm sorry...

:-P. But i doubt I can catch up to LZMA and yours. We will see, it absolutly will be an implementation you never see in a comparable form in any other compression tool. Amazing or crap. Answer coming... :-D

Congratz to new version

[encode]

Just sitting on the toiled invented super-cool improvement... Finally new BALZ WILL beat LZPX(J) at SFC!

sfc.7z -> 11,951,908 bytes

[LovePimple]

Awesome!

[encode]

New version will be released within a week... Note that this is a very special release, it not only beats LZPX(J) at SFC but also LZPM at LTCB. I think new BALZ is close or even stronger than the PIMPLE in fast modes, being asymmetric! In other words it's totally aftercharts!
Having said, this version will be kind of a final, since I will do some serious break in development...

[encode]

I'm not finish yet:

sfc.7z -> 11,943,343 bytes

[joerg]

each version step by step increases the compress-ratio - good work

you wrote "some kind of final"

- what about to complete BALZ with a option
to compress a whole directory-tree
inclusive storing the path and the filenames

best regards

[encode]

Well, some plans regarding BALZ:

• Wait some time to collect more improvements and get new inspiration

• After I make sure that algorithm was finished or I will decided to leave the data compression scene - release it as an open source project - just like QUAD/LZPX... I'm not like Malcolm Taylor or other people, I prefer that my work will be open to the public - data compression is meant to be share!

• Before releasing it at SF.net, I might add a small file header to .BALZ files and other user-related features (a la GZIP)

[IsName]

- what about to complete BALZ with a option
to compress a whole directory-tree
inclusive storing the path and the filenames

Bulat is tired of advertizing freearc for this purpose