AAC vs MP3 for internet radio: choose the listener path, not the fashionable codec

AAC and MP3 can both deliver an internet radio station. AAC is often selected for better quality at constrained bitrates. MP3 remains valuable because it is understood by a very broad range of players, devices and directories.

The wrong question is “Which codec wins?” The useful question is “Which listener path works reliably for this station’s audience?”

Start with the whole delivery chain

A codec decision affects more than the encoder.

The complete path includes:

1. the live encoder or AutoDJ output;
2. the streaming server;
3. any proxy or edge-delivery layer;
4. the station’s web player;
5. embedded players on other sites;
6. radio directories and aggregators;
7. in-car, smart-speaker and mobile clients;
8. metadata and artwork behaviour;
9. fallback handling when a preferred format is unavailable.

A stream that sounds excellent in one desktop browser but fails in a common directory is not a successful default.

What MP3 offers

MP3’s main advantage is operational familiarity.

• Many older hardware and software players accept it.
• Stream URLs are commonly understood by directories.
• Broad browser and operating-system support reduces surprises.
• Operators and support teams are familiar with its failure modes.

At lower bitrates, MP3 may need more bandwidth than AAC to reach a similar subjective result. The exact difference depends on encoder implementation, material and audience expectations, so a universal percentage is not useful.

For spoken-word programming, a well-chosen MP3 bitrate can still be entirely adequate. For complex music at very constrained bandwidth, its limitations may become more audible.

What AAC offers

AAC is designed as a newer compression family and can perform well at lower bitrates. That can reduce listener bandwidth or provide more perceived detail at the same nominal rate.

The label “AAC” is not a complete configuration. Profiles and containers matter. A client that accepts one AAC delivery format may not accept another. Browser support can also depend on the operating system and the way the audio is presented.

That is why the decision belongs in a compatibility matrix rather than a codec slogan.

A practical comparison

Decision factor	MP3	AAC
Legacy player reach	Usually the safer choice	Must be verified against target clients
Efficiency at constrained bitrates	Serviceable, but may need more bitrate	Often the stronger candidate
Directory familiarity	Very common	Common, but support varies by directory and profile
Browser testing	Still required	Required across browser and operating-system combinations
Operational simplicity	Familiar default for many stations	Configuration needs more precision
Best use	Universal fallback or primary stream where reach dominates	Preferred stream where tested clients support it

This table is a planning aid, not a substitute for testing the station’s actual path.

Do not estimate bandwidth from bitrate alone

A nominal audio bitrate is the starting point for delivery planning. Real usage also includes container and transport overhead, reconnects and any parallel renditions.

A simple listener-hours estimate is:

bitrate in kilobits per second × 0.45 ≈ megabytes per listener-hour

That shortcut gives an approximate audio payload:

• 64 kbps ≈ 28.8 MB per listener-hour;
• 96 kbps ≈ 43.2 MB per listener-hour;
• 128 kbps ≈ 57.6 MB per listener-hour.

Actual transfer will be somewhat higher. Use observed delivery metrics for capacity and cost decisions.

If a station serves both AAC and MP3, total bandwidth depends on which rendition listeners select. Producing two renditions also changes origin processing and monitoring requirements.

Use capability detection, not wishful thinking

A web player can prefer AAC when the browser reports support and fall back to MP3 otherwise. The fallback must be tested as a first-class route.

Important behaviours include:

• the player chooses a playable source before starting;
• an AAC failure can move to MP3 without trapping the listener;
• play and pause controls remain accurate after a fallback;
• reconnect logic does not create overlapping audio;
• current-track metadata continues to refresh;
• analytics identify the rendition actually used.

The universal MP3 link should remain easy to find if it is the recovery path for external players.

Test representative material

Codec evaluation should use the station’s programming, not a single favourite track.

Include:

• dense contemporary music;
• quiet acoustic material;
• spoken voice;
• sibilant presenters;
• applause or crowd sound;
• older recordings with noise;
• station imaging and hard transitions;
• live-source audio from the real encoder.

Listen for high-frequency smearing, unstable ambience, watery artefacts, harsh transients and voice intelligibility. Compare at matched loudness; a louder sample can appear “better” even when the codec is not the reason.

Test representative clients

At minimum, verify:

• current Chrome, Safari and Firefox on desktop;
• iOS and Android browsers;
• the station’s embedded player;
• direct stream URLs;
• any priority directory;
• the live encoder handover;
• a constrained mobile connection;
• reconnect after temporarily losing the network.

Record the client, operating-system version, stream format and outcome. “Works on my laptop” is not a release criterion.

A resilient default pattern

For many independent stations, a sensible approach is:

1. Offer the efficient rendition to clients known to support it.
2. Maintain a broadly compatible MP3 rendition.
3. Make the player’s selection and fallback behaviour deterministic.
4. Monitor both public endpoints.
5. Measure actual rendition usage.
6. Revisit the decision using listener evidence rather than assumption.

This costs more operational attention than publishing one stream. It can be worthwhile when the audience genuinely benefits.

The decision

Choose MP3 when maximum reach and operational simplicity are the strongest requirements. Choose AAC as a preferred path when lower-bitrate efficiency matters and the target clients have been tested. Offer both when the station can operate and monitor both properly.

The codec is only one part of reliability. Listeners experience the player, connection, fallback, metadata and recovery behaviour as one product.

Primary references

• MDN: Media formats supported by HTML audio and video
• Apple: HTTP Live Streaming
• SGNL Desk internet radio player
• SGNL Desk internet radio hosting