AAC vs MP3 for radio streaming

AAC is a newer, better codec than MP3. At the same bitrate it sounds closer to the original; at the same quality it costs fewer bits. On the engineering merits it wins, and it has won for twenty years.

Most online radio stations should still stream MP3.

That is not nostalgia. It is what happens when you optimise for the listener's device instead of the encoder's benchmark, and radio's device list is longer and stranger than almost any other kind of streaming.

The efficiency gap

The rule of thumb that holds up in practice: AAC-LC at about 96 kbps is comparable to MP3 at 128 kbps, and AAC-LC at 128 is comparable to MP3 at around 160–192. The advantage is largest at low bitrates and shrinks as both formats approach transparency — by 256 kbps the argument is academic.

There is also HE-AAC (AAC+), which adds spectral band replication and is genuinely impressive below 64 kbps, where MP3 falls apart. A listenable 48 kbps stream is possible with HE-AAC and is not possible with MP3. If you need a very low-bandwidth stream, this is the only real answer.

So on paper: switch to AAC, cut a quarter to a third of your bandwidth, keep the same quality.

Why radio does not

Because "the listener's player" is not a browser. It is:

• A car head unit from 2016 running someone's firmware.
• A kitchen internet radio bought in a supermarket.
• A smart speaker, via a skill or an aggregator.
• An aggregator directory — TuneIn, Radio Garden, myTuner, Online Radio Box — each of which normalises your stream for its own apps.
• A website player in a browser, which handles both fine.
• A phone app, which handles both fine.

MP3 plays on all of them. AAC plays on most of them. The failures are not spread evenly across your audience — they cluster in exactly the group a station cares about most, the people with a dedicated radio in the kitchen who listen for four hours a day.

And the failure mode is bad. It is not degraded audio; it is a player that connects and produces nothing, or refuses the mount, with no message explaining why. Those listeners do not file a bug report. They stop listening.

The container problem

There is a second, more technical reason AAC causes support tickets in radio: how the stream is packaged.

AAC over Icecast is usually shipped as ADTS, a raw framed stream a player can join mid-flight — which is exactly what a radio listener does. That is the right choice, and it works widely.

AAC inside an MP4/M4A container does not work for live radio at all, because the container's index sits at the end of a file that never ends. Software that encodes AAC perfectly well for files will happily produce a stream no radio player can open, and the resulting bug report says "AAC doesn't work" when the codec was never the problem.

MP3 has no equivalent trap. A frame is a frame, and any decoder can start on any of them.

When AAC is the right call

Three situations make it worth the compatibility cost:

A very low-bitrate stream. Below 64 kbps, HE-AAC is listenable and MP3 is not. If you need a mobile-data fallback that costs almost nothing, this is how it is built.

A closed listening surface. If your audience reaches you through your own app and your own website and nothing else — in-store audio, internal communications, a members' service — then you control every decoder and the compatibility argument evaporates. Take the bandwidth saving.

A second stream, not a replacement. MP3 stays as the published, directory-listed, everyone-can-play-it stream, and AAC exists alongside it for the app. This is what larger broadcasters do, and it is the only version of "switch to AAC" that carries no risk.

Do not stack encodes

Whichever you choose, encode the stream from the highest-quality source you have.

Every lossy encode throws away detail based on assumptions about what the ear will miss. Encoding a 128 kbps MP3 stream from a 128 kbps MP3 file applies those assumptions twice to audio that has already had them applied once, and the artefacts compound audibly — a smeared, watery quality on cymbals and sibilants that no bitrate increase downstream will repair.

Convert between formats even once and it is worse again. MP3 to AAC is not a translation; it is a second-generation lossy encode of a first-generation lossy file.

Keep the library as good as you can afford to store, and let the stream be the only encode a listener hears.

What we do

RadioHost Studio streams MP3 up to 192 kbps, for the reasons above: the station has to play in the kitchen radio and the car, and a codec choice that quietly loses those listeners is not a saving.

Frequently asked questions

Is AAC better quality than MP3?

At the same bitrate, yes — noticeably below about 128 kbps, marginally above it, and not at all once both are near transparency. The question for a radio station is whether that gain is worth the players it loses.

Does AAC use less bandwidth than MP3?

At matched quality, roughly 25–30% less. AAC-LC at 96 kbps is broadly comparable to MP3 at 128, so the saving is real — it is the compatibility, not the efficiency, that decides it.

Will my station appear on TuneIn if I stream AAC?

Aggregator directories generally accept both, but their handling differs by platform and their own apps re-serve the stream in ways you do not control. MP3 is the format that never needs checking.

What about Opus or Ogg Vorbis?

Both are technically excellent and both are worse choices for public radio streaming than AAC, because browser and hardware support is narrower still. Opus is the right answer inside systems where you own both ends, and the wrong answer for a stream a stranger's car will try to open.

Should I re-encode my MP3 library to AAC?

No. That is a second-generation lossy encode of every file you own, in exchange for storage you probably have. If you want a better library, replace files from a better source.