MLow: Meta's Low Bitrate Audio Codec
How Meta built a new audio codec from scratch that delivers twice the perceptual quality of Opus at 6 kbps, while keeping computational complexity 10% lower — targeting the billions of calls on low-end devices that existing codecs leave behind.
The standard assumption in codec design is that better quality requires more compute. ML-based audio codecs like Encodec proved this isn’t always true — but they shifted the bottleneck to processing power rather than network bandwidth, which means the gains only reach users who can afford flagship hardware. MLow is a direct challenge to that tradeoff: the claim is that you can double perceptual quality at the lowest bitrates without raising the complexity bar at all.
Source
MLow: Meta’s low bitrate audio codec
By: Meta
Published: Jun 13 2024
Type: Engineering article
Worth keeping because it’s a clear account of building a codec for the actual distribution of devices and network conditions, not the idealized case — and because the POLQA score comparison at 6 kbps is a genuinely striking result (MOS 1.89 for Opus versus 3.9 for MLow).
Designing a codec for the tail of the network
The problem MLow targets is specific: what happens to call audio when bandwidth estimation drops the operating bitrate to 6 kbps. At that floor, Opus switches to NarrowBand mode, which samples only up to 4kHz. Human speech contains frequencies above that range — consonants, fricatives, the cues that distinguish “s” from “f” — so calls at Opus’s lowest mode sound muffled and unnatural regardless of packet conditions. This isn’t a bug in Opus; it’s a deliberate floor that made sense in 2012. The problem is that Meta’s call volume has grown large enough that “a significant chunk of calls” routinely hit poor network conditions, and the floor now affects hundreds of millions of calls a day.
The naive path is to replace Opus with a modern ML-based codec. Encodec, released by Meta in October 2022, achieves impressive clarity at very low bitrates. But Encodec’s computational cost is prohibitive on anything below a high-end processor. More than 20 percent of Meta’s calls happen on ARMv7 devices. Tens of millions of daily WhatsApp calls run on hardware that is ten or more years old. Shipping Encodec to those users isn’t possible. The result is that the quality gains from ML codecs compound toward users who already have the best conditions, while the people on slow connections and old devices stay on a degraded Opus fallback.
MLow’s design starts from the opposite direction: fix the worst-case first, without raising the compute floor. The codec builds on CELP (Code Excited Linear Prediction) — the same architectural family as Opus — but with significant improvements to excitation generation, parameter quantization, and coding schemes. The most consequential structural choice is split-band processing: the encoder divides the audio signal into low and high frequency bands, processes them separately while sharing information between them, then runs the combined output through a range encoder for further compression. The decoder reverses this exactly. This architecture lets MLow deliver SuperWideBand audio (32kHz sampling) at bitrates that would force Opus into NarrowBand mode — a direct win for the tail case.
The quality result at 6 kbps is stark. POLQA MOS (a perceptual quality measure on a 1-5 scale) scores 1.89 for Opus versus 3.9 for MLow at the same bitrate and Wideband mode. MLow’s complexity is 10 percent lower than Opus despite the quality jump, which means it can run on the same hardware that currently runs Opus at minimum settings. That combination — better quality, lower complexity — is what makes the deployment story possible rather than aspirational.
The codec’s efficiency at low bitrates also changes what’s feasible for Forward Error Correction. FEC packs redundant audio information into packets so the receiver can reconstruct audio even when packets are dropped. Opus needs a minimum of 19 kbps before it can afford any inband FEC at 10 percent packet loss. MLow can pack FEC at much lower bitrates, which matters significantly in the conditions where poor audio is most common: congested networks where both bandwidth and packet loss are problems simultaneously. At 14 kbps with 30 percent receiver-side packet loss, the difference in recovered audio quality is audible and substantial.
Meta shipped MLow to all Instagram and Messenger calls before the article was published, and was actively rolling it out to WhatsApp. The team reports “incredible improvement in user engagement driven by better audio quality” — which is a metric framing for what users would describe as calls that don’t cut out. The feedback loop between codec quality and call duration is real: if audio breaks up at low bitrates, people hang up faster, which shows as a measurable engagement signal.
The broader point is about where you set your optimization target. ML codecs optimize for peak quality on capable hardware. MLow optimizes for minimum acceptable quality on constrained hardware. Those are different problems, and on a platform where the median device is not a flagship, the second problem affects more users. Building a codec that runs comfortably on a 10-year-old phone while delivering twice the perceptual quality of the previous incumbent is a different kind of engineering achievement than pushing MOS scores on benchmark hardware.
My take
The codec taxonomy implied here — CELP-family codecs for compute-constrained environments, ML codecs for quality-first environments — suggests the real question for any audio pipeline is what your device distribution looks like, not what the best codec is in the abstract. MLow’s result also suggests that the CELP architecture has more headroom than Opus’s 2012 design extracted, specifically in split-band encoding and quantization. The gap wasn’t inevitable; it reflects the fact that no one had strong incentives to push the architecture further until Meta’s scale made the tail case worth solving.
Where this is useful
- Audio encoding pipelines where the device population includes low-end or older hardware
- RTC products where call quality at 6–14 kbps is a real operating range, not an edge case
- Any codec selection decision where complexity and FEC efficiency are constraints, not just peak quality metrics
- When NOT applicable: offline or broadcast audio transcoding where latency and compute cost are not limiting factors
Apply this: When evaluating audio codecs, run your quality comparison at the lowest bitrate your BWE module can actually hit in production — not at comfortable operating ranges.
What I want to remember
Remember: Split-band encoding lets MLow deliver SuperWideBand audio at bitrates that force Opus into NarrowBand — the architecture constraint on quality was not fundamental, just unaddressed.