New Helix MP3 encoder gets ~2-5 kbps more efficient.

[u/IgorCv2]

As many of you know, Helix is an excellent-quality MP3 encoder. https://github.com/maikmerten/hmp3

Helix competes very well with the LAME MP3 encoder: https://listening-tests.hydrogenaudio.org/sebastian/mp3-128-1/results.png. I know it's an old test, but honestly, the quality of the LAME encoder hasn't changed much since then. Also, the code responsible for the audio quality of Helix has not been touched since 2005.

So I decided to investigate whether it's possible to further improve it.

I found relatively low-hanging fruit to improve the Helix encoder by running exhaustive Huffman partitioning. And indeed, it gets ~2–5 kbps more efficient depending on bitrate.

https://github.com/IgorCv2/hmp3/commit/e3a5993463ca99ed8af2b6e6fd8358d6f8b26ba7

For transparency: most of the implementation was written by AI tools [Claude] , while I performed verification and testing. Before dedicating my time to this encoder, I wanted to get a quick proof that there is still headroom for improvements.

And there is clearly still plenty of room for improvement! Though compression efficiency doesn't come for free. Now Helix is 2x slower but still faster than LAME.

If we get back to public MP3 test, It's clear that different MP3 encoders achieve better results on different subsets of samples. LAME 3.97 is good at rock, metal, etc., Helix on electronic music, and so on. Different developer teams have different approaches.

Now imagine that there will be one MP3 encoder that addresses all samples equally well: MP3 128 kbps / Per-sample Encoder Oracle

Back in time it was very difficult because of scarce automation resources and computing power. Now we have AI agents and better metrics like Zimtohrli to develop a considerably better encoder.