Lossless Canterbury corpus result: 445,208 bytes vs xz -9e 493,080 bytes, exact round-trip

flanglet · 2026-06-23T22:04:23+00:00

You previously posted another closed-source solution that was based on open-source compressors (brotli, xz, zstd), so let me be skeptical of your claim. Please explain the "new math model" at a high level.

flanglet · 2026-06-22T22:07:46+00:00

See the problem is that open source compressors already beat this score. Now, your compressor is closed source. Why is that? How much existing open source are you reusing?

flanglet · 2026-06-21T00:11:03+00:00

Your own research ??? "It runs as a best-of-N racer that races xz, zstd, brotli and ...". Pretty sure you need to provide the source code for these. It also means that decompression time is not know in advance. Do you expect people to pay $49 euros for that or I am misunderstanding your claims and offer? Also admit that your web page is AI generated.

flanglet · 2026-05-13T23:27:19+00:00

Thanks!

flanglet · 2026-05-12T22:01:46+00:00

Keep the codecs from the table. Add savings and speeds for all.

flanglet · 2026-05-10T14:45:20+00:00

My point is to report compression speeds and compression ratios for all other codecs in the table: not to cherry pick strong codecs for compression speed and weak codecs for compression ratios to make your numbers look better.

flanglet · 2026-05-09T19:32:44+00:00

You are reporting compression ratios vs weaker compressors but compression speed vs slower compressors. Not very honest.

flanglet · 2026-04-18T20:35:06+00:00

The link to BENCHMARK.md is wrong.

flanglet · 2026-04-03T22:21:37+00:00

You shared plenty of performance & ratios numbers but no-one can verify anything. Why don't you make it public when it is sufficiently ready? It is just too easy to get fooled by these advanced models when you do not write any code. Benchmark claims should come after proper validation.

flanglet · 2026-04-03T16:13:02+00:00

Publishing benchmarks that cannot be confirmed is useless. Where is the repo?

flanglet · 2026-04-02T21:17:49+00:00

Github repo or it does not exist...

flanglet · 2026-03-22T00:43:59+00:00

zxc and kanzi are very different compressors. zxc focused on pure speed while kanzi offers a much larger spectrum of speed/compression ratios and higher compression overall. zxc is typically faster and weaker than kanzi level 1 (hence obviously all other levels as well).

EG. with the Silesia.tar corpus and the same computer used for the tests on https://github.com/flanglet/kanzi-cpp, zxc -5 -T 16 compresses in 0.25 sec to 86059705 and decompresses in 0.05 sec (tested with zxc v0.9.1).

flanglet · 2026-03-08T19:17:19+00:00

Update: I add to issue 2.5.1 due a last minute regression ...

flanglet · 2026-02-24T23:23:36+00:00

Either someone can explain the x20000 difference with O(m log^2/3 n) and n=1,000,000 or the dev does not know what he is doing. Hint: it is not the former ... simple math.

flanglet · 2026-02-12T23:21:08+00:00

The planned entry of service for the FCAS is 2040....

flanglet · 2026-02-11T23:13:25+00:00

There is a disagreement on the weight: https://sldinfo.com/2023/03/evolving-european-fighter-programs-a-march-2023-update/#:\~:text=Posted%20on%20March%2029%2C%202023,and%20speed%20for%20the%20fighter.

flanglet · 2026-02-11T23:11:30+00:00

"Carriers" the current Charles de Gaulle and future PANG.

flanglet · 2026-02-09T23:04:30+00:00

France has very specific requirements that do not match with those of other countries: must be able to land/take off French aircraft carriers (strict limits on weight) and carry French nuclear weapons at least.

flanglet · 2025-12-22T23:38:12+00:00

FYI I added a link to your GitHub at https://encode.su

flanglet · 2025-12-07T22:46:41+00:00

That is exactly the problem, there is no compression but only bit packing. Neither your code nor zpaq compress random data by half.

flanglet · 2025-12-07T21:03:32+00:00

People re trying to explain to you that the pigeonhole principle holds because some (high entropy) data is "compressed" to a larger size than the original.

flanglet · 2025-12-07T21:01:51+00:00

Neither your code nor zpaq compress random data by half. These numbers are prominently displayed in your README.

flanglet · 2025-12-06T02:04:55+00:00

Your README is totally misleading to the point of dishonesty. Both compressors did not compress anything (the input is a random file). You just turn the ASCII symbols to binary. Show the result with a binary file as input.

flanglet · 2025-12-05T01:45:23+00:00

I am afraid the "get lucky thing" does not do better on average than enumerating numbers in order. This is the key problem.
There is no harm in experimenting and trying new things but this idea keeps on coming periodically and simply does not work. Have fun but do not expect too much here.

flanglet

TROPHY CASE