The LAME 3.100 encoder which Audacity uses has a horrible bug that deteriorates CBR encoding quality.
Listen to this file encoded using Audacity 3.7.5 using its stereo option which is joint stereo, at 32kbps CBR.
And compare it with this file encoded using LAME from terminal using simple stereo mode which is more inefficient as it divides the two channels completely 16kbps each side, with the difference of it using -q 9 value which differs from the -q 3 that is the default that Audacity probably uses, it still sounds better than the default Audacity export.
(I tried to upload it here but I can’t upload more than one file as new user, download qval9.mp3 from the link below for comparison).
But basically, every -q value from 0 to 3 is bugged, and values 4 and above are ok.
This bug has two ways to solve, one is to use -q 4 flag on CBR exports which removes the source of the bug on the encoding when using default LAME 3.100. The other way to solve it is explained in the forum which is to patch LAME and modify some values from a file to 0 in two lines of code from each switch case in cases 0 to 3, and that way the best possible quality obtainable will be -q 0 which is the slowest encoding, and without the bug.
For a quick fix I guess you could just use default LAME 3.100 and just enable the flag -q4 for CBR exports, but the ideal solution would be to deliver Audacity with the patched version of LAME 3.100 and use -q 0 flag on CBR exports which is the slowest but highest quality encoding.
I would upload the audio sample of the patched -q 0 export for comparison along with the other two from default LAME but I am not on Linux at the moment so I don’t have the tools to compile LAME from source easily but I have tried it before and it is definitely the best quality possible.
Even at 128kbps you can hear the effects of the poor encoding of default LAME settings, I might install Linux later to make test files and show the difference, you may also read the forum from the Hydrogen Audio link I put there to understand the problem better.
I assume Audacity is using the defaults, which should be the best settings for most files at higher bitrates. Audacity has never given access to all of the LAME options and the defaults may not be best at low bitrates.
I have the impression that the LAME developers are focused on transparency, which you’ll never get at 32kbps. I don’t believe they’ve put much effort into low bitrates. There are other CODECs that try to get the best speech quality at low bitrates and they aren’t optimized for higher bitrates or music.
If you want to use low bitrates and you want to tweak the settings, maybe export as WAV or FLAC and use the command line or a different LAME front end. Assuming you are on Windows the Pazera Front End has an Expert Mode, which I believe gives you access to everything,
Or you may be able to use Audacity with an External LAME Encoder and you can use your preferred command line settings.
Picky or paranoid audiophiles use FLAC or WAV, or other lossless formats.
The defaults are far from the best settings, even the devs intended -q 0 to be the best setting, not the default -q 3, you can check this in their documentation, and both options even when intended to be among the best, are actually the worst, this is a LAME bug the developers clearly did not test at all.
This could be the reason this guy complained here and no one could solve his problem:
This is a vert well documented bug by now, here is another guy who noticed it:
The default LAME settings are the worst at any bitrate, tested on as low as 8kbps all the way through to 320kbps, the only thing that changes is the cutoff point where the artifacts can be noticed, they eat up this frequencies at the top and surpress them making a muddy mess MP3 has always been know for, which does not have to be like that because with the patch the result is far better, even if not with the patch, setting exports to -q 4 already makes a very big improvement which disables the frequency eating algorithm.
This might not be noticed at 320kbps but MP3 is not intended to be a 320kbps only audio format, if lower kbps is required the change would make lower bitrate exports sound better, and 320kbps exports would be of higher fidelity as they would not be affected at all by this upper frequencies surpressing algorithm that muddies and makes noise artifacts at the upper frequency content of the file.
Also I would use WAV or FLAC for highest fidelity but it is not as supported as MP3 which is guaranteed to be supported on any speaker or stereo system that lets you connect a USB drive, the songs are not always recognized on FLAC or WAV but always recognized if they are MP3, MP3 is just neccesary for compatibility purposes.
If (you think that) the MP3 quality of Audacity is not good enough for your purpose, you can always export the file as .aiff, .wav, etc. - and then use an external converter to produce your MP3-file. Mac and Windows users can use iTunes (Win and MacOS before 10.15 “Catalina”) and Music.app (Mac versions 10.15 “Catalina” and later) to do the conversion - but there are many other utilities around.
It is not that I think that, it is that the MP3 quality of Audacity can exponentially improve if the changes I suggested are made, all I want is to help improve Audacity so it delivers higher quality on MP3 CBR exports, the solution is as simple as changing one value on two lines of code to 0, and using the flag -q 0 on CBR exports. Why would you not want to implement this good change fixing that bug?
I am on my way to installing Debian to make sample tests for comparison if you are still not convinced on the impact of this bug and how better the patched LAME makes the exported MP3 files sound.
It is not my decision whether Audacity introduces something you suggest. I am just an Audacity user.
You do not need to convince me, for the above reason. I just gave you a suggestion on how to come around your problem as long as Audacity does not meet your expectations.
Just now doing some tests I realized that the patched MP3 CBR is better than VBR even at lower bitrate, on the Hydrogen Audio forum I confirmed that, and also discovered that MP3 CBR can sound as good as AAC for the same bitrate, here’s the encoded MP3 file with the patched version and -q 0 at 32kbps CBR with lowpass 12.5kHz that AAC had at 32kbps:
and the Audacity 32kbps CBR:
The AAC file for comparison is on the Hydrogen Audio forum.
Right but not as compatible, I mean I would just use WAV because I don’t care about the file sizes I just want the highest quality possible, but even WAV is not as supported as MP3 on every speaker or stereo system to just connect a usb stick and play the music, an aux cable is an alternative but it depends on another device to send the lossless data so it’s a little less practical, that is why I care about MP3.
but if you are using very low bit rates, you clearly don’t care much about the quality
It looks like LAME will be improving the quality of low bit-rate MP3 soon, at which time I agree that it would be nice if Audacity updates its LAME library. Until then, I’d recommend either using a slightly higher bit-rate, or a format that is better suited for extreme compression.
From a developer perspective, it can be tempting to patch a library for better performance, but the cost is more than just applying the patch. The patch makes the library non-standard, so the dev team then become responsible for it.
If you patch the library locally, you’re now carrying a fork that you have to test and maintain. Even a tiny change can have unintended side effects, such as subtle performance regressions, memory issues, or different behaviour on edge cases.
Also, dependency management tools are built around the assumption you’re pulling official releases. In the case of Audacity, forking LAME would require modifying the “Conan” dependency recipe and hosting the patched version of the library.
I just did a test and patched -q 0 seems to still not be the best option, the old bug is gone but after reencoding generations it seems that -q 4 is safer as there was an artifac generated through the generations in -q 0 that is quite noticeable compared to -q 4 which did not have it, now I will discard -q 0 and see the other options to see if they’re also bugged or if one is better than -q 4, if -q 4 ends up being best, it will not be neccesary to patch lame or at least not the way it was thought.
I already tested this more thoroughly, and patched -q 0 is better for mono encoding than -q 7, but -q 7 is better than -q 4 and patched -q 0 on simple stereo and joint stereo modes.
I basically discovered lossless MP3, not true lossless of course but the sample remain untouched after 1000
MP3 transcodings using the patch and -q 0 for a mono file using 320kbps, the results are incredible.
Yeah just tested this LAME 100 320kbps with -q4 switch and you can hear a difference even at such at high bit rate especially with electronic music
How the hell as this been discovered for over a year and no update or fix it’s a major critical bug no wonder mp3 has had such a bad rep over the years
Also I use LAME 3.97 on windows on my old sound forge pro is this version affected also?
I think I may just to stick to Logic Pro or helix for mp3 CBR lame is a mess
I filed a bug of this with Launchpad for Ubuntu and Debian as neither uses the patched 3.101 Beta 3 version.
At this point, LAME will never have an official release. We need this q switch for CBR and ABR modes.
Precedent exists. Every distribution in the Linux world uses a patched version of EasyTag because that will never have another official release, and that last official release messes up Ogg files upon writing Vorbis comments.
I also sent separate emails to the listed maintainers: Debian Multimedia Maintainers, and the LAME-specific Fabian Greffrath and Reinhard Tartler.
Fabian Greffrath kindly responded to me and changed the Debian in unstable (which I hope will trickle into sid then testing and to Ubuntu / Linux Mint and also show an example to others in the *nix space) and the in-depth discussion on the SourceForge page for LAME: https://sourceforge.net/p/lame/bugs/516/
All of this stems from the optimizations for -q3–-q0 for an older psycho-acoustic model that is no longer in use. As a result, -q4 seems to work as the best. We seem to be in a position where the best version is a patched version in common usage but no official release, akin to the status of EasyTag for *nix.
