Quad 1.04a has been released! [!]

[encode]

This is a rebirth of Quad! This version has MUCH higher compression ratio and at the same time higher compression speed at the cost of decompression speed. Note that this program in terms of compression ratio vs. compression time is my best creation! Also note that Quad 1.04a requires about 160 MB of free RAM, so you must have at least 256 MB RAM installed.

Anyway, enjoy!

Link:
quad104a.zip (38 KB)

[LovePimple]

Awesome! The power is amazing.

[LovePimple]

First results...

A10.jpg > 830,494
AcroRd32.exe > 1,305,394
english.dic > 819,389
FlashMX.pdf > 3,692,336
FP.log > 578,101
MSO97.dll > 1,715,654
ohs.doc > 784,955
rafale.bmp > 1,003,503
vcfiu.hlp > 603,346
world95.txt > 577,764

Total = 11,910,936 bytes

Very quick compression/decompression time!

[LovePimple]

ENWIK8 > 27,712,832 bytes

This test also returned VERY QUICK compression/decompression time.

[LovePimple]

PHT.psd (6,755,163 Bytes) compresses to 1,014,035 Bytes

Compression time: 14.453 seconds

Decompression time: 6.296 seconds

Awesome speed!

[Nania Francesco]

Very fast and good compression! Good Work!

[LovePimple]

Quad now has an excellent balance of good compression and amazing speed.

What next for Quad?

[encode]

What next for Quad?

First of all, Ill wait for testing results (MFC, Squeeze Chart 2007, ...).

After that, who knows, probably Ill write some GUI or 7-Zip/Total Commander Plugin based on new compression...

Or this engine will be added to PeaZip...

However, this engine must be carefully tested for both performance and reliability.

[Black_Fox1]

Thanks!

12,565,938 bytes
Compression ~700kB/s, decompression ~800kB/s - that's incredible!

[LovePimple]

Or this engine will be added to PeaZip...

This is a great little engine but I would much prefer the TC engine added to PeaZip.

[Nania Francesco]

As I had already said would be fantastic to see also all and two form to you in Peazip why they have high velocity and great jam! If you succeed to little improve the TC speed this it is sure the best one!

[encode]

Good news! I invent a new modeling trick of LZ output. With Quad, this trick gives some compression improvement with no speed loss! The compression improvement is depends on data, but in average, this gives nice compression gain. Now I am experimenting with this idea, but even at this stage, this thing shows nice results, for example, improvement on english.dic is over 15 KB!

[Black_Fox1]

Good news! I invent a new modeling trick of LZ output.

Good work encode

[LovePimple]

Good news! I invent a new modeling trick of LZ output. With Quad, this trick gives some compression improvement with no speed loss! The compression improvement is depends on data, but in average, this gives nice compression gain. Now I am experimenting with this idea, but even at this stage, this thing shows nice results, for example, improvement on english.dic is over 15 KB!

Thats quite an impressive gain! Hopefully this will improve ENWIK8/9 results.

[encode]

While Im experimenting and thinking about better implementation, look at some testing results:

Quad 1.05a

SFC

A10.jpg: 830,494 bytes
acrord32.exe: 1,302,718 bytes
english.dic: 802,917 bytes
FlashMX.pdf: 3,691,294 bytes
fp.log: 571,848 bytes
mso97.dll: 1,713,249 bytes
ohs.doc: 783,423 bytes
rafale.bmp: 1,001,231 bytes
vcfiu.hlp: 600,482 bytes
world95.txt: 573,489 bytes

Total: 11,871,145 bytes

Large Text Benchmark

ENWIK8: 27,606,392 bytes
ENWIK9: 238,523,840 bytes

pht.psd

pht.psd: 1,012,807 bytes

I hope this version will be released within 1...3 weeks.

[thometal]

coool

I hope you will release in 1 week.

[LovePimple]

Its looking good, but is it possible to improve the ENWIK8/9 compression?

[encode]

Its looking good, but is it possible to improve the ENWIK8/9 compression?

To achieve higher compression on text files I must use a higher order model. In this case speed will be significantly affected. Also I can improve compression with a larger dictionary and hash table, but since Im making something usable I will not do that.

I hope you will release in 1 week.

Im just also experimenting with some other things like improved EXE-filter. In addition, Im very pedantic with my programs...

[Christian]

Hi!
Congratulations for QUAD compressor. Its really fast and compresses very good.

Good news! I invent a new modeling trick of LZ output. With Quad, this trick gives some compression improvement with no speed loss!

This is really impressive!

Im just also experimenting with some other things like improved EXE-filter. In addition, Im very pedantic with my programs...

What exactly does this exe-filter do? Does it "jmp & call" or do you do additional things like "jxx", tables? But I do understand if you dont want to tell.

Keep up your amazing work!

Regards, Chris

[encode]

What exactly does this exe-filter do? Does it "jmp & call" or do you do additional things like "jxx", tables?

Currently, Quad uses an EXE filter similar to CABARC:

E8/E9 + it checks for valid reference. So, bad commands just ignored. This gives excellent results with single executables, but it works not so well on TAR files with lots of exe and other files.

Previously, I use in my programs a BCJ like filter:

E8/E9 + 0/255 checking + reverse bytes. This approach shows better results on TAR files. Probably, Ill use this filter.

By the way, what kind of filter used in your CCM?

[Christian]

Previously, I use in my programs a BCJ like filter:

E8/E9 + 0/255 checking + reverse bytes. This approach shows better results on TAR files. Probably, Ill use this filter.

By the way, what kind of filter used in your CCM?

I use this method but without the reverse part. I think I should try this out as it might possibly create longer matches.

Do you gain much by reversing the bytes?

[encode]

Do you gain much by reversing the bytes?

This gives some nice gain, especially on EXE files. Note that in some cases this can even hurt compression. However, Ive found better use this trick.

[encode]

By the point, do you use any kind of auto-detection or fiter is always enabled?

[Christian]

No. The filter is always enabled. I don't know if detection is a good/bad thing speed-wise. But since I found that the filter doesn't really hurt compression on non-EXE files I didn't feel like doing any detection.

[encode]

No. The filter is always enabled. I dont know if detection is a good/bad thing speed-wise. But since I found that the filter doesnt really hurt compression on non-EXE files I didnt feel like doing any detection.

Thank you for information!

[encode]

Well, Quad's code was significantly changed. I completely rewritten many parts of code, made many speed improvements. Probably, I'll keep some speed improvements at the cost of compression. However, performance at SFC must be 11,8xx,xxx bytes.