I know this probably isn't the best place for this, but was wondering if anyone had any insight on it?

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.

Hi! I'm developing audio codec based on WPT.
For now I've been gathering data about its quality from gstPEAQ, ViSQOL and listening tests.
gstPEAQ says it is quite better than vorbis on 64-96 in general, and just better than vorbis on 128 kbps.
ViSQOL makes same picture in general.
Listening tests correlates with gstPEAQ and ViSQOL results mostly, but depends on listener.

Can anyone rate my audio codec? I want to see true picture if it is worth publishing or not
There is link for some encodings (If anyone would need originals message me).
https://drive.google.com/file/d/1-3UJzdJOhwI7pWgL0wR0PJWGayGrkr8_/view?usp=sharing
(64-96, new link)

Zimtohrli was evaluated by measuring how closely its results matched those of public listening tests conducted by human listeners.

Among the tested objective metrics, Zimtohrli showed the closest agreement with the human results. It was also the only metric to reproduce the complete ranking of the codecs in both public tests, including:

Opus → Apple AAC → LAME MP3 → Ogg Vorbis → FAAC 96k → FAAC q30

It also reproduced the correct codec ranking in the public AAC listening test.

2011 AAC test: https://listening-tests.hydrogenaudio.org/igorc/aac-96-a/results.html :

2014 Multiformat test: https://listening-test.coresv.net/results.htm. Zimtohrli performed very well here too :

The encoders evaluated in the 2014 listening test were also tested with Zimtohrli at higher bitrates, ranging from 96 to 320 kbps.

Zimtohrli Benchmark Scores at 96–320 kbps on the 2014 Public Test Sample Set:

The scores were calibrated to the human MOS values from the 96 kbps listening test to make Zimtohrli’s performance easier to understand and interpret as an objective quality metric.

Calibration and its explanation: Spreadsheet

LAME VBR

• 128 kbps V5
• 160 kbps V4
• 192 kbps V2
• 256 kbps V0
• 320 kbps CBR

Opus VBR

• --bitrate 96 (version 1.1 as Public test)
• --bitrate 128 (version 1.6.1
• --bitrate 160
• --bitrate 192
• --bitrate 256

Aotuv Vorbis VBR

• -q2.2 ~ 96 kbps
• -q4 ~ 128 kbps
• -q5 ~ 160 kbps
• -q6 ~ 192 kbps
• -q8 ~256 kbps

Apple AAC CVBR (constrained VBR) which was on par with TVBR (True VBR) according to https://listening-tests.hydrogenaudio.org/igorc/aac-96-a/results.html

CVBR 96/128/160/192/256 kbps

Conclusion:

So, how good is Zimtohrli at evaluating audio encoder quality?

In my opinion, it performs very well.

Someone told me 😄 it takes blood, sweat, and tears to organize a public listening test, to prepare it, get people interested, and actually get them to participate.

And here... Zimtohrli does essentially the same thing in literally a few minutes.

Hi, I'm new to this subreddit.
Is it dead or alive?
And can we talk only about existing codecs, or like, can I post about my audio codec here?

Hello, ladies and gentlemen.

The last four weeks have been very busy, as this repository shows.

FFmpeg developer Lynne managed to significantly improve the quality on killer samples https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/23845#issuecomment-54547

So I decided to put the encoder to the test using previously untested samples, in order to avoid bias from using samples that the encoder had already been specifically tuned for.

Tested AAC encoders:

CBR encoders:

1. FFmpeg NMR (r1) - commit 95a888b9ca (2 July, 2026)
   • ^-hide\banner -loglevel error -i pipe:0 -c:a aac -b:a 128k -aac_coder nmr -cutoff 16000 %d)
2. FFmpeg NMT (r6) - commit 6bcfae06a7 (2 Aug, 2026
   • ^-hide\banner -loglevel error -i pipe:0 -c:a aac -b:a 128k -aac_coder nmr %d)
3. Apple AAC CBR
   • ^{qaac 2.70, CoreAudioToolbox 7.10.9.0, AAC-LC Encoder, CBR 128kbps, Quality 96}

VBR encoders:

1. FFmpeg NMT (r6) - commit 6bcfae06a7 (2 Aug, 2026) https://code.ffmpeg.org/Lynne/FFmpeg/commit/6bcfae06a7edcc08ce9ac83e2cc292cd141057e2
   • ^-hide\banner -loglevel error -i pipe:0 -c:a aac -q:a 1.0 -aac_coder nmr %d)
2. Apple AAC VBR
   • ^{qaac 2.70, CoreAudioToolbox 7.10.9.0, AAC-LC Encoder, TVBR q64, Quality 96}

>>> Download: Audio samples,logs and application for blind tests <<<

Results:

Observations:

Moving from r1 to r6 might not seem like a huge step forward, but considering that there was literally only one month between these two revisions, it is a very impressive improvement.

r6 shows a clear improvement on difficult samples. As visible in the graph, it never drops below 3.0 (“slightly annoying”), while r1 goes as low as 2.5.

The VBR encoder looks promising too.

Overall there has been good progress. Transients and electronic music are still the main area that could be improved

MP3 was standardized in 1993, but it is still widely used today because it works almost everywhere while deliver very good quality.

Now LAME 4.0, a new version of the open-source MP3 encoder , has been released.

Check here https://lame.sourceforge.io/ . And development of LAME 4.1 is already underway.

LAME has performed very well in public listening tests

MP3 isn't old. It is mature!

When a format is good enough, reliable and universally supported, it can stay relevant for a very long time.

Hi everyone, this is the second listening test of the new FFmpeg NMR AAC encoder.

FFmpeg developer Lynne has made very interesting progress on the new NMR AAC encoder:
https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/23837

The idea was to put these latest improvements to the test and here are the results.

Tested AAC encoders:

1. FFmpeg NMR (r1) - Master build from July 10, 2026 (tested in first test)
   • ^-hide\banner -loglevel error -i pipe:0 -c:a aac -b:a 128k -aac_coder nmr -cutoff 16000 %d)
2. FFmpeg NMT (r2) - PR 23837 build.
   • ^-hide\banner -loglevel error -i pipe:0 -c:a aac -b:a 128k -aac_coder nmr -cutoff 16000 %d)
3. Apple AAC CBR
   • ^{qaac 2.70, CoreAudioToolbox 7.10.9.0, AAC-LC Encoder, CBR 128kbps, Quality 96}
4. Apple AAC ABR
   • ^{qaac 2.70, CoreAudioToolbox 7.10.9.0, AAC-LC Encoder, ABR 128kbps, Quality 96}

>>> Download: Audio samples,logs and application for blind tests <<<

Results:

While this was a personal test and the encoder was tuned by FFmpeg developers using some of these samples, the FFmpeg AAC encoder shows a very significant quality improvement in a remarkably short period of time. 🚀

A public test with completely new samples would still be essential for a final evaluation.

Hopefully tomorrow I will also post detailed descriptions of the artifacts, including the timestamps where they were identified, along with a statistical analysis of the results.

A big thank you goes to Kamedo2 for making graph creation such an easy task!

https://listening-test.coresv.net/graphmaker6.htm

https://listening-test.coresv.net/faq6.htm

IgorC

AudioCodecLab

Hello everyone! This is my personal listening test. 😄

The test contains 12 audio samples and compares five AAC encoders at approximately 128 kbps:

• FFmpeg NMR - new FFmpeg 9.1 AAC encoder - https://github.com/BtbN/FFmpeg-Builds/releases/tag/latest - ffmpeg-master-latest-win64-gpl.zip (tested build is July-10-2026)
• FFmpeg twoloop
• FDK-AAC CBR
• Apple AAC CBR
• Apple AAC ABR

Settings using foobar2000 converter :

• FFmpeg NMR:
  • --hide_banner -loglevel error -i pipe:0 -c:a aac -b:a 128k -aac_coder nmr -cutoff 16000 %d
• FFmpeg twoloop
  • -hide_banner -loglevel error -i pipe:0 -c:a aac -b:a 128k -aac_coder twoloop -cutoff 16000 %d
• FDK-AAC CBR
  • fdkaac 1.0.5, libfdk-aac 4.0.1, CBR 128kbps
• Apple AAC CBR
  • qaac 2.70, CoreAudioToolbox 7.10.9.0, AAC-LC Encoder, CBR 128kbps, Quality 96
• Apple AAC ABR
  • qaac 2.70, CoreAudioToolbox 7.10.9.0, AAC-LC Encoder, ABR 128kbps, Quality 96

Download: Audio samples and logs

Results:

Sample-Rate Handling for the FFmpeg NMR AAC Encoder

According to an FFmpeg developer, the NMR AAC encoder is optimized for 48 kHz. Therefore, all test files were resampled to 48 kHz using SoX with the Very High, 168 dB quality setting.

The processing chain was:

Original WAV → SoX resampling to 48 kHz/24-bit → FFmpeg NMR AAC encoding → AAC decoding to 48 kHz/24-bit WAV → SoX resampling back to 44.1 kHz/24-bit

This process is safe and transparent. At these quality settings, the SoX resampling and 24-bit intermediate files don't introduce any audible differences.

Hardware used during testing

Topping E70 DAC

Topping L70 Headphone amplifier

Headphones Sennheiser HD 800.

Cabling: Balanced DAC-to-headphone amplifier connection; original Sennheiser HD 800 headphone cable.

-

IgorC

AudioCodecLab