BALZ v1.13 [FINAL] is here!

[encode]

OK, a new version is here, kind of a FINAL this time. New BALZ features not only CM-related improvements but some ROLZ-improvements as well. Concluding, what can I say about BALZ? Nice compression tool featuring a hybrid of (RO)LZ+CM algorithm. Here we have an option for regular compression - "e" and for max/benchmarking compression - "ex". All in all algorithm has some weak parts but also has some very strong parts. If compare BALZ to RZM - RZM is stronger at compression, but BALZ has two modes - with regular/default mode BALZ is much faster than RZM. In addition, BALZ eats slightly less memory at compression, and, of course, BALZ supports HUGE files, AFAIK, RZM still not... The author of RZM claimed that the most compression came from Optimal Parsing, and with simpler parsing RZM achieves ~12,000,000 bytes at SFC. Well, BALZ has no Optimal Parsing and gets below 12,000,000 at SFC...

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

[encode]

BALZ v1.13 at SFC:
A10.jpg -> 835,668 bytes
acrord32.exe -> 1,367,426 bytes
english.dic -> 739,207 bytes
FlashMX.pdf -> 3,699,894 bytes
fp.log -> 551,055 bytes
mso97.dll -> 1,793,522 bytes
ohs.doc -> 805,127 bytes
rafale.bmp -> 976,468 bytes
vcfiu.hlp -> 635,626 bytes
world95.txt -> 553,986 bytes
Total -> 11,957,979 bytes

[osmanturan]

Here is the results on my laptop (Core2 Duo 2.2GHz, 2GB RAM)

Valley.cmb (19.776.230 bytes)
BALZ 1.13 (ex) -> 8.790.115 bytes (32,854 seconds)
RZM 0.7h -> 7.564.143 bytes (17,681 seconds)

enwik8 (100.000.000 bytes)
BALZ 1.13 (ex) -> 26.421.416 bytes (224,486 seconds)
RZM 0.7h -> 24.361.070 bytes (154,457 seconds)

Design2.tif (My own design on a newspaper advertisement for a company, 25x35cm @ 300 dpi -> 2953x4134 pixels printable CMYK; uncompressed, interleaved (RGBRGB...), little endian TIFF)
49.413.716 bytes

BALZ 1.13 (ex) -> 12.953.526 bytes (75,716 seconds)
RZM 0.7h -> 10.065.599 bytes (73,354 seconds)

I think, your comparasion is not a good idea (RZM vs BALZ). As you see, RZM gets better result in less time. Maybe I'm walking around BALZ's weak points I'm not sure. As said before, I didn't expect such that behaviour when we consider CM back-end

I think, on SFC result, E8E9 transform makes the difference.

[encode]

I talked about "e" option...

[osmanturan]

If "e" option makes better result in less time, I can test it

[encode]

I think, osmanturan, you're not carefully reading. Please read what I'm posting carefully, using English dictionary if necessary. I'm not claimed that BALZ has a higher compression that RZM, I said only that with "e" mode BALZ is OK, and BALZ has some additional bonuses...

[osmanturan]

> I think, osmanturan, you're not carefully reading. Please read what I'm
> posting carefully, using English dictionary if necessary. I'm not claimed that
> BALZ has a higher compression that RZM, I said only that with "e" mode
> BALZ is OK, and BALZ has some additional bonuses...
Ok ilia. Don't angry with me. Just kidding you

[LovePimple]

OK, a new version is here, kind of a FINAL this time. New BALZ features not only CM-related improvements but some ROLZ-improvements as well. Concluding, what can I say about BALZ? Nice compression tool featuring a hybrid of (RO)LZ+CM algorithm. Here we have an option for regular compression - "e" and for max/benchmarking compression - "ex". All in all algorithm has some weak parts but also has some very strong parts. If compare BALZ to RZM - RZM is stronger at compression, but BALZ has two modes - with regular/default mode BALZ is much faster than RZM. In addition, BALZ eats slightly less memory at compression, and, of course, BALZ supports HUGE files, AFAIK, RZM still not... The author of RZM claimed that the most compression came from Optimal Parsing, and with simpler parsing RZM achieves ~12,000,000 bytes at SFC. Well, BALZ has no Optimal Parsing and gets below 12,000,000 at SFC...

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

Thanks Ilia!

Mirror: Download

[encode]

[encode]

Thanks LovePimple!

[encode]

LTCB has been updated:
http://cs.fit.edu/~mmahoney/compression/text.html#2282

[Shelwien]

Well, I replaced the cpu and was experimenting with overclocking.
Still am not sure whether its final, but here's what I currently have.

Q9450 8x450=3.6Ghz, DDR2 5-5-5-18 at 2x450=900
http://shelwien.googlepages.com/balz113.htm

This version didn't improve both speed and compression, so its hard to say if its better.
Well, the metric says it is.
But rar still looks like better choice.

[encode]

Thank you!

[kaitz]

timer balz113.exe e enwik8 enwik8.out
Kernel Time = 0.765 = 00:00:00.765 = 0%
User Time = 113.406 = 00:01:53.406 = 96%
Process Time = 114.171 = 00:01:54.171 = 97%
Global Time = 117.250 = 00:01:57.250 = 100%

Size 27 405 650


timer balz113.exe ex enwik8 enwik8.outex
Kernel Time = 0.593 = 00:00:00.593 = 0%
User Time = 232.453 = 00:03:52.453 = 99%
Process Time = 233.046 = 00:03:53.046 = 99%
Global Time = 234.703 = 00:03:54.703 = 100%

Size 26 421 416



timer balz113.exe d enwik8.out enwik8.out1
Kernel Time = 0.281 = 00:00:00.281 = 1%
User Time = 17.234 = 00:00:17.234 = 89%
Process Time = 17.515 = 00:00:17.515 = 90%
Global Time = 19.265 = 00:00:19.265 = 100%

timer balz113.exe d enwik8.outex enwik8.outex1
Kernel Time = 0.453 = 00:00:00.453 = 1%
User Time = 17.140 = 00:00:17.140 = 69%
Process Time = 17.593 = 00:00:17.593 = 71%
Global Time = 24.672 = 00:00:24.672 = 100%

[encode]

Thanks for testing!

[encode]

Just recalled that initially BALZ was LZ77-based... Well, I have ideas about further LZ77 experiments, with some improvements I made in my recent CM:
+ Improved arith. coding
+ Improved counter
etc.