The Radio Engineer’s Dilemma: Opus Is Ready. Radio Infrastructure Isn’t.

If you’ve run an internet radio station for any length of time, you probably have one URL in your stack that nobody wants to touch.

The stream URL.

Maybe it’s 128 kbps AAC-LC. Maybe it’s 192 kbps MP3. It sits in directories, smart-speaker integrations, mobile apps, car dashboards, old widgets, and bookmarks you forgot existed. It is boring infrastructure, and boring infrastructure is valuable because it works.

Then you listen to a properly encoded Opus stream at 64, 80, or 96 kbps and get a little annoyed.

Because it sounds far better than a stream using that little bandwidth has any right to sound.

That is where the argument usually goes off the rails. Someone hears a good 64 kbps Opus encode, declares MP3 dead, says AAC is obsolete, and decides the whole station should switch tomorrow.

I wouldn’t do that.

Opus is ready. The radio distribution ecosystem is only partly ready.

That distinction matters.

First, Get the Vocabulary Right

Opus is a codec. WebM and Ogg are containers. Icecast, HLS, WebRTC, plain HTTP streaming, and the rest are delivery mechanisms or protocols.

Those things get mashed together constantly, even by people who should know better.

For internet radio, one of the most practical combinations today is Opus carried in Ogg and served by Icecast. Liquidsoap can generate that directly. WebM/Opus is also common on the modern web. Current browsers handle Opus very well.

The difficult part is no longer producing an Opus stream.

The difficult part is deciding where you can safely send it.

Opus Is Extremely Efficient. It Is Not Magic.

The Opus specification gives a broad sweet spot of roughly 64–128 kbps for full-band stereo music. That is a wide range for a reason.

A clean 64 kbps Opus stream can sound excellent. On some material it can embarrass much higher-bitrate MP3. But I would not write “64 kbps Opus equals 128 kbps AAC” on a spec sheet and pretend it is a law of physics.

Audio does not work that way.

Codec performance depends on the encoder, the source, stereo complexity, processing, transient density, and the kind of artifacts you personally find objectionable. A sparse acoustic track and a smashed modern master with bright cymbals are not the same test.

For a music-heavy station, I consider 80–96 kbps Opus stereo a much more comfortable target for a primary web stream. 64 kbps is aggressive but absolutely usable when bandwidth matters. For talk-heavy programming, Opus can go lower very gracefully.

And there is another point that gets lost in codec tribalism: AAC is a family. Modern HE-AAC and xHE-AAC are also very efficient. Any chart claiming Opus simply “destroys AAC” at every bitrate is marketing, not engineering.

For the kind of conventional internet-radio feeds most operators are running today, this is a more useful way to think about it:

The exact number still deserves a listening test. Your processing chain gets a vote.

The Bandwidth Math Is Where Opus Becomes Hard to Ignore

Suppose you have 1,000 concurrent listeners.

At 128 kbps, the raw audio payload is about 57.6 GB per hour.

At 64 kbps, it is about 28.8 GB per hour.

That is roughly 28.8 GB saved every hour while those 1,000 listeners are connected. Hold that audience continuously for a 30-day month and the difference is about 20.7 TB of transfer, before protocol overhead.

At that point, codec choice is no longer an audiophile argument. It is an infrastructure bill.

And the listener benefits too. A 64–80 kbps stream is simply easier to keep alive on a congested mobile connection than a 128–192 kbps stream. That matters in the real world, where people listen in cars, on commuter trains, in crowded venues, and in places where “5G” on the status bar does not necessarily mean 5G performance.

About That “Under 20 ms Latency” Claim

This one needs to die.

Opus has very low algorithmic codec delay. Depending on mode and frame size, the codec itself can operate with delay measured in only a few milliseconds.

That does not mean your internet radio station suddenly has 20 ms glass-to-glass latency.

Your encoder buffer, Icecast queue, TCP behavior, player buffer, network path, and browser all add latency. A conventional web-radio stream can still be seconds behind the studio.

Opus’s low-delay design is a major reason it is excellent for WebRTC, voice chat, live communications, and interactive audio. For ordinary internet radio, the more immediate win is usually quality per bit, not magically instantaneous playback.

That difference may sound pedantic. It isn’t. Engineers should describe the system they actually built.

The Apple Problem Is Becoming an Old Story

For years, “but iPhone” was a perfectly reasonable objection to Opus on the web.

It is much less convincing now.

Modern Safari supports Opus in WebM, and Safari 18.4 added Opus support in Ogg on current Apple operating systems. Chrome, Firefox, Edge, and modern Android browsers have been comfortable with Opus for years.

So if somebody says, “Safari can’t play Opus,” the next question should be: which Safari, on which OS, in which container?

That does not mean compatibility is solved. Older iPhones, old WebViews, embedded SDKs, smart speakers, and hardware radios do not magically upgrade because Safari did.

The browser is no longer the scariest part of the compatibility matrix.

The rest of radio is.

Where Opus Still Hits the Wall

This is the part codec enthusiasts tend to hand-wave away.

SHOUTcast remains centered on MP3 and AAC/AAC+. If that is part of your distribution stack, Opus is not a drop-in replacement.

TuneIn explicitly documents MP3 and AAC as accepted audio formats and recommends keeping an MP3 alternative for maximum compatibility.

And that illustrates a larger problem with radio aggregation: a lot of the infrastructure broadcasters depend on is still designed around assumptions that were reasonable fifteen or twenty years ago.

Then there is the enormous category nobody can inventory perfectly: older Wi-Fi radios, in-dash systems, smart-speaker middleware, cheap embedded decoders, forgotten mobile apps, and third-party aggregators that were written around a world where “internet radio” meant MP3 or AAC over HTTP.

If one of those endpoints rejects your stream, your listener does not care that Opus is technically superior.

They hear silence.

That is why I would not make an Opus URL the only public stream for a station that cares about broad distribution.

OndaCast Is Not Going to Hold Broadcasters Back

This is also where I should be clear about OndaCast’s position.

OndaCast fully supports Opus streams in all of the variants we encounter, alongside AAC and MP3.

We are not interested in forcing broadcasters to keep encoding inefficient streams simply because that is what radio directories have historically expected.

AAC and MP3 are not going anywhere on OndaCast. They remain enormously important for compatibility, and we will continue supporting them.

But compatibility should be a safety net, not an excuse to freeze the industry in place.

If a station engineer can reduce bandwidth consumption, improve delivery over constrained mobile connections, or simplify their infrastructure by deploying Opus, we want that stream to work.

Full stop.

Broadcasters already spend enough time worrying about automation systems, encoders, processing, metadata, licensing, distribution, server bills, and everything else required to keep a station running. An aggregator should not be another piece of infrastructure telling them, “Sorry, we only understand what radio looked like in 2010.”

Our job is to discover and play radio.

If the broadcaster sends us a modern, standards-based stream, we should make every reasonable effort to support it.

That philosophy is part of why OndaCast exists in the first place. We will keep compatibility with the old world while refusing to resist changes that make broadcasting easier, more efficient, and less expensive.

Those two ideas are not mutually exclusive.

Licensing: Opus Wins, but AAC Is Often Misrepresented

Opus is open and royalty-free. That is one of its best properties.

AAC is more complicated, but there is a common myth worth correcting: you do not pay a patent royalty every time someone streams an AAC bitstream. The AAC licensing program applies to encoder and decoder products; distribution of AAC-encoded bitstreams is not charged a per-stream patent fee.

So yes, Opus has the cleaner open-technology story.

No, your monthly bandwidth bill is not secretly full of AAC patent tolls.

Accuracy matters more than codec cheerleading.

The Architecture I Would Deploy Today

I would run two outputs from the same clean source.

The reach stream: AAC-LC around 96–128 kbps, or MP3 at 128–192 kbps when maximum directory and hardware compatibility matters.

The smart web stream: Opus at 64–96 kbps, with the exact bitrate chosen after listening tests. For a music-first station, I would probably start at 96 kbps, test 80, then test 64 rather than starting low and talking myself into it.

A capable web player can prefer Opus when the browser supports the combination you are serving and fall back to AAC or MP3 when it does not.

That gives you the efficiency where you control playback without gambling the station’s entire distribution footprint on every old device being modern.

This is not theoretical infrastructure. Icecast officially supports Opus, and current Liquidsoap can output an Opus stream directly. The encoder side is easy enough now that the distribution matrix is the real engineering problem.

And if OndaCast is one of your distribution points, there is no reason to hide the Opus stream from us.

Give it to us.

One Non-Negotiable: Do Not Transcode Your Old Stream

If your current public feed is 128 kbps AAC, do not decode that feed and use it as the source for your shiny new 64 kbps Opus stream.

That is how good codecs get blamed for bad audio.

Feed both encoders from the cleanest source you control: PCM from the automation system, a lossless internal feed, or the same pre-encoding program bus.

Lossy-to-lossy transcoding stacks artifacts. The damage from the first codec does not disappear when the second codec is more efficient.

When you test Opus, use ugly material too. Bright cymbals. Dense modern masters. Sibilant speech. Stereo imaging. Station sweepers. Applause. Crowd noise. Anything your processing chain already makes difficult.

A codec demo built around one polite acoustic guitar track tells you almost nothing about how your station will sound on a Friday night.

So, Should You Switch to Opus?

Yes.

Just not in the dramatic way people usually mean when they ask that question.

Do not rip out the compatibility stream that already reaches radios, directories, dashboards, and old apps. Keep it.

Add Opus beside it.

Use Opus where you control the player and wherever your distribution partners properly support it. Let web and mobile listeners get the smaller stream. Measure startup time, buffering, listening duration, and egress. Run blind listening tests on your own processed audio instead of trusting codec folklore.

Then move more traffic toward Opus as your real audience proves it works.

That is the part I find exciting.

For years, internet radio solved reliability by throwing more bitrate at the problem. Opus gives us another option: spend the bits more intelligently.

MP3 is not dead. AAC is not obsolete. Opus does not need either of them to disappear in order to be useful.

It only needs a place in the rack.

And in 2026, it has earned one.