After Nine Years Frozen, LAME Is Moving Again - What Is in 4.1

The MP3 encoder that quietly sits inside Audacity, foobar2000 and almost every CD ripper shipped two releases in three days this July - and the one worth caring about still has not arrived.

The LAME logo set into a slab of cracking ice with green bubbles rising from the break

LAME 4.0 landed on 11 July 2026, its first major version since 2017.

It was a housekeeping release, and the version number was the most exciting thing in it.

LAME 4.1 is the one worth paying attention to, and it is being written right now.

You cannot download 4.1 yet.

It exists only as source code in the project's development tree. There is no installer, no tarball, and the release manager said plainly in August that there is no estimated date. The current LAME 4.0 download is still what you should be running today.

Why 4.0 Was the Boring One

Version 4.0 fixed two security problems and tidied up some build machinery, and that was genuinely all.

The more serious of the two was a buffer overflow in the old Blade-compatible library that legacy Windows applications still load, where a settings structure handed in by the calling program was accepted without checking its size. The second could hang the encoder in an endless loop on a deliberately malformed AIFF file.

Neither changes how anything sounds. Nothing in your music library needs re-encoding because of 4.0, and nothing in it will need re-encoding because of 4.1 either.

Even the jump from 3.101 to 4.0 was housekeeping. Every MP3 that LAME writes carries a small tag naming the encoder, that tag has a fixed nine-byte slot for the version string, and three-digit minor versions had been quietly overflowing it since 3.100.

The Quality Bug That Has Been Wrong for Years

Here is the change most people will actually feel.

Quality slider settings shown backwards before the fix and in correct order after it

LAME has a quality dial separate from bitrate, running from -q0 at the slowest and supposedly best, down to -q9 at the fastest. For years, on fixed and average bitrate encodes, the slow settings have produced worse results than the faster ones.

That is not a rumour and it is not placebo. It is a real effect, caused by a noise-shaping routine left over from a psychoacoustic model the encoder no longer uses, and the advice everyone eventually arrives at is to ignore -q0 through -q3 and use -q4 instead.

In 4.1 that routine is switched off for fixed and average bitrate. The dial stops working backwards, and -q3 and -q4 simply become the same thing, as do -q1 and -q2.

Variable bitrate was never affected.

If you encode music with -V 2 or -V 0, which is what most people should be doing anyway, none of this ever applied to you and nothing about your output changes. Our best LAME settings guide walks through which mode suits music, podcasts and audiobooks.

Faster Encoding, and Not Only on Windows

The bulk of the work in 4.1 is speed, and one detail in it is quietly embarrassing.

Four processor instruction sets compared by encoding speed gain, AVX2 fastest

Modern processors can work on several numbers at once, and LAME has had hand-written code to exploit that for a long time. On Linux, macOS, the BSDs and 32-bit Windows, though, that code has silently not been running since 3.100 - those builds have been grinding through plain, unaccelerated C for nine years.

4.1 turns it back on everywhere, rewrites it, and adds two new tiers on top. The project's own changelog puts fixed-bitrate encoding somewhere between a sixth and a fifth faster than before on a recent Intel desktop, with a further gain on machines new enough for the wider AVX2 instructions.

There is a third tier for AVX-512 on newer server-class chips, and a set for ARM, which matters more every year as ARM laptops and Apple Silicon Macs become normal. LAME also no longer needs a separate assembler program to build, which has been a persistent nuisance for anyone compiling it themselves.

Two things are not in 4.1, and both come up constantly. It is still single-threaded, so it still uses one core no matter how many you have - the request for multithreading has been open since 2007. And there are no changes to the psychoacoustic model, so the encoder's fundamental judgement about what to throw away is the same one it has had for years.

You Will Probably Get It Without Noticing

Almost nobody runs LAME directly.

It reaches most people as a component inside something else, which is why a release nobody announced still ends up on millions of machines. Audacity has bundled it internally since version 3.2, so its MP3 export just works with no library to install. LameXP wraps it in a normal window alongside Opus and FLAC encoders and takes drag-and-drop batches.

When 4.1 ships, those applications will pick it up on their own schedule and you will get it in a routine update. That is also why the security fixes in 4.0 mattered more than their modest headline suggested - the code is embedded in a very large number of programs whose users have never heard of it.

Is LAME Actually Being Maintained Again?

On the evidence, yes, though thinly.

The mailing list that mirrors every code change carried nothing at all through 2024 and 2025. Across July and August 2026 it carried close to 270 messages, and the most recent change landed two days before this article was written.

Nearly all of it is one person. LAME's own developers page still lists three primary developers, but that page has not been edited since 2017, and the 2026 commit record is essentially the work of a single maintainer with patches from a handful of contributors. The project has also gone back through its bug tracker and closed things properly rather than just adding features.

There is a public call for testers open on the developer mailing list for the AVX-512 work, which is a healthy sign. It is also a reminder of the scale here: this is a small volunteer project that happens to sit underneath a very large amount of software.

What to Do Today

Nothing dramatic, which is the honest answer.

If you encode your own music from your own discs, keep doing what you are doing and use variable bitrate. If you have been using the slow quality settings with a fixed bitrate, drop to -q4 now and stop worrying about it until 4.1 arrives.

If you are running something older that loads LAME's library and you feed it audio from elsewhere, updating to 4.0 is worth doing for the overflow fix. The install guide for Windows covers pointing an application at the library if yours still asks for it.

Quick questions

When will LAME 4.1 be released?

There is no date. The release manager said in August 2026 that there is no estimated time of arrival and that he wants to finish and polish several things first, then ask for testing. Treat any site claiming a release date as guessing.

Can I download LAME 4.1 now?

Not as a finished build. It exists only as source code in the project's development tree, so using it means compiling it yourself. Everyone else should stay on 4.0.

Will 4.1 make my existing MP3s sound better?

No. Nothing changes files you have already encoded, and there is never a reason to re-encode an MP3 you already have. Re-encoding a lossy file only loses more.

Does the quality fix affect variable bitrate encoding?

No. The change applies to fixed and average bitrate only. If you encode with the -V presets, which is the usual advice for music, your output is unchanged.

Will LAME ever use more than one CPU core?

Not in 4.1. Multithreading has been an open request on the project's tracker since 2007 and no work on it appears in the current development tree. Encoding a large batch faster still means running several files at once rather than one file across several cores.

Is LAME still free for commercial use?

Yes. It is open source under the LGPL, and the MP3 patent licensing program ended in 2017, so there is no fee for encoding MP3s in personal or commercial work.