AAC vs MP3 vs Opus: Quality per Bitrate, Latency, and Which Codec to Pick
Key takeaways
MP3 plays everywhere but spends more bits for the same quality, AAC is the default for video and Apple devices, and Opus wins at low bitrates and real-time voice but is weaker in legacy players. The post compares them by use case and shows FFmpeg migration commands.
Introduction
From voice calls to music streaming, gaming, and podcasts, audio codecs determine both bandwidth and perceived quality. MP3 is still widely used, AAC has become standard in Apple and broadcasting, and Opus excels in ultra-low latency and voice optimization. This guide compares all three on the same criteria.
All three are perceptual codecs: they split the signal into frequency bands and spend bits only where a psychoacoustic model predicts the ear will notice, discarding sounds masked by louder neighbors. The differences come from when they were designed and for what. MP3 (early 1990s) uses a hybrid filter bank with limited frequency resolution and fixed ~26 ms frames, which is why it smears sharp transients and struggles below about 128 kbps. AAC (late 1990s) replaced that with a cleaner MDCT, switchable window sizes for transients and more efficient entropy coding, so it reaches similar quality at noticeably lower bitrates. Opus (2012) was designed for interactive use from the start: very short frames, a speech-oriented mode, and bitrate that can change packet by packet as network conditions change.
When to Use AAC, MP3, or Opus?
| Aspect | AAC | MP3 | Opus |
|---|---|---|---|
| Performance (bandwidth) | Better efficiency than MP3 for same perceived quality | Best compatibility | Strong for low latency & voice |
| Usability | Good fit for Apple & broadcasting | Plays everywhere | WebRTC, game voice, etc. |
| Application Scenario | Streaming, mobile | Archive, legacy | Calls, live |
Quick Comparison
| Feature | MP3 | AAC (LC, etc.) | Opus |
|---|---|---|---|
| Release & Maturity | De facto standard since 1990s | Widely used (iOS, broadcast, streaming) | IETF RFC 6716 (2012~) |
| Quality at Same Bitrate (generally) | Lowest among peers | Often better than MP3 | Very efficient for voice & mixed |
| Bitrate Flexibility | 32–320 kbps; CBR, ABR and VBR (LAME) | Good VBR support | Wide range 6 kbps~510 kbps |
| Latency | Tens of ms plus encoder look-ahead; not suited to calls | AAC-LC too high for calls; AAC-LD/ELD variants exist for conferencing | Excellent for voice & real-time (about 26.5 ms by default, down to 5 ms) |
| Licensing | Patents expired (by 2017 in the US) | Licensing pool (Via LA); many early AAC-LC patents have expired | Royalty-free (BSD-like) |
| Typical Use | Compatibility, legacy | Music streaming, mobile | WebRTC, Discord-like, Ogg/WebM |
The latency row is the one that most often decides the choice. Latency here means the delay the codec itself adds — frame size plus look-ahead — before network and buffering. For a music stream a few hundred milliseconds of buffering is invisible, so AAC’s larger frames cost nothing. For a conversation, total mouth-to-ear delay above roughly 150 ms starts to make people talk over each other, and the codec’s share of that budget has to be small. That is why AAC-LC and MP3 are practically absent from voice chat, and why Opus is mandatory in WebRTC.
Codec Details
MP3 (MPEG-1 Audio Layer III)
Feature: One of the oldest popular codecs, with the huge advantage of playing everywhere. Pros
- Best player, car, and embedded compatibility
- High user recognition and broad editing tool support Cons
- Lower efficiency than AAC/Opus at same bitrate
- Inferior to modern formats in metadata and channel configuration (5.1, etc.) FFmpeg Example
ffmpeg -i input.wav -c:a libmp3lame -q:a 2 output.mp3
# Or CBR
ffmpeg -i input.wav -c:a libmp3lame -b:a 192k output.mp3-q:a 2 selects LAME’s VBR quality level 2 (the old -V 2 preset, averaging roughly 170–210 kbps for music), where lower numbers mean higher quality. VBR spends more bits on complex passages and fewer on silence, so for the same average size it usually sounds better than CBR. CBR is still worth choosing when a player or a streaming server needs a predictable bitrate, or when seeking accuracy matters: VBR MP3 files rely on a Xing/Info header for seeking, and players that ignore it show wrong durations or jump to the wrong position. Another MP3 detail that surprises people is gapless playback — the encoder adds padding at the start and end, so live albums or DJ mixes split into tracks get tiny gaps unless the player reads LAME’s gapless metadata.
AAC (Advanced Audio Coding)
Feature: LC-AAC is most common, with frequently reported quality gains over MP3 at low bitrates. Nearly default in Apple ecosystem, MPEG-DASH, and radio broadcasting. Pros
- Good quality per bitrate for music and general content
- Naturally combines with MP4 (M4A) Cons
- Not as specialized for ultra-low bitrate voice as Opus
- Real-time voice (ultra-low latency) has different requirements than Opus and dedicated codecs FFmpeg Example
ffmpeg -i input.wav -c:a aac -b:a 128k output.m4a“AAC” is a family, and the profile matters more than the name. AAC-LC is the workhorse for music at 96 kbps and above. HE-AAC (v1) adds Spectral Band Replication: it encodes only the lower frequencies and reconstructs the highs from a small amount of side data, which makes 48–64 kbps stereo usable for radio and streaming. HE-AAC v2 adds Parametric Stereo for even lower bitrates. The encoder also matters: FFmpeg’s built-in aac encoder only produces AAC-LC, and at low bitrates it is generally rated below Fraunhofer’s libfdk_aac, which supports HE-AAC (-profile:a aac_he) but has a license incompatible with the GPL, so most prebuilt FFmpeg binaries do not include it. On macOS, -c:a aac_at uses Apple’s AudioToolbox encoder, which is also well regarded.
Opus
Feature: Modern codec combining SILK (voice) + CELT (music), standard audio for WebRTC. Strong in variable bitrate and ultra-low latency settings. Pros
- Can cover voice (calls) to music with one codec
- Open, royalty-free, and good fit for real-time stacks Cons
- Legacy hardware (old car USB, etc.) often only supports MP3/AAC
- Some commercial DAWs and broadcast equipment have AAC/PCM-centric workflows FFmpeg Example
ffmpeg -i input.wav -c:a libopus -b:a 96k -vbr on output.opus
# With WebM
ffmpeg -i input.mp4 -c:v copy -c:a libopus -b:a 128k output.webmOpus switches internally between SILK, a linear-prediction speech coder originally from Skype, and CELT, a low-delay MDCT coder for music, or runs both together in hybrid mode. The encoder picks the mode from the content and bitrate; -application voip biases it toward speech intelligibility, while the default audio favors fidelity. Two practical details: Opus works internally at 48 kHz only (it also accepts 8/12/16/24 kHz input), so a 44.1 kHz source is resampled when encoded, which is harmless but means the decoded file will report 48 kHz. And Opus files carry a “pre-skip” value that tells the decoder how many initial samples to drop; tools that ignore it produce a few milliseconds of offset, which matters when syncing audio with video. Also note the WebM example copies the video stream with -c:v copy, which only works if the source video is VP8, VP9 or AV1 — WebM does not allow H.264, so for a typical MP4 input FFmpeg fails with an error about the codec not being supported in the container.
In live systems, the feature I would not skip is Opus’s in-band forward error correction (-fec 1 together with an expected -packet_loss percentage in FFmpeg, negotiated through SDP in WebRTC). It embeds a low-bitrate copy of the previous frame in each packet, so a single lost packet can be reconstructed instead of concealed. Without it, a voice stream over a lossy Wi-Fi link sounds choppy even though the bitrate is generous.
Performance Comparison
Below are frequently cited trends under general listening conditions. Varies by genre, listening environment, and encoder.
| Bitrate | MP3 | AAC | Opus |
|---|---|---|---|
| ≤64 kbps (voice-focused) | Easily becomes rough | Can improve | Often very good |
| 128 kbps (music streaming reference) | Practical | Generally preferred | Good for music, may be overkill for voice |
| 256 kbps+ | Near transparent | Near transparent | High bitrate music also possible |
Visualization: Priority by Use Case
flowchart LR
subgraph Voice_Realtime[Voice & Real-time]
O1[Opus]
end
subgraph Music_Compat[Music & Wide Compatibility]
A1[AAC]
M1[MP3]
end
Voice_Realtime --> O1
Music_Compat --> A1
Music_Compat --> M1
Testing Tip: ABX tests or encoding same source at multiple bitrates with opusenc/ffmpeg and listening comparison establishes team standards.
The table is deliberately qualitative. Published listening tests do consistently rank Opus and good AAC encoders above MP3 at 64–96 kbps, but results depend heavily on the encoder implementation and the test material — castanets, harpsichord and applause are classic “killer samples” that expose pre-echo and smearing that pop music hides. Objective metrics such as PSNR say little about perceived audio quality; perceptual models (ViSQOL, PEAQ) are better, but a blind ABX test on your own material with your own encoders is still the most reliable check. When comparing, match loudness first: listeners reliably prefer the louder of two otherwise identical clips, which can make a worse encode “win”.
Recommendations by Scenario
| Scenario | Recommendation | Reason |
|---|---|---|
| Maximum compatibility (USB, old devices) | MP3 or AAC | Decoder availability |
| Music streaming, podcasts | AAC 96~192 kbps or Opus | Efficiency & quality balance |
| Video call, game voice, WebRTC | Opus | Latency & voice quality |
| Archive master | PCM/FLAC (lossless) + AAC/Opus for distribution | Separate preservation and distribution |
| Low bandwidth mobile | Opus or HE-AAC variants | Bitrate efficiency |
The archive row deserves emphasis because it prevents the most common irreversible mistake. Every lossy encode throws information away, and a second lossy encode throws away different information on top of the first artifacts. If the only copy of a recording is a 128 kbps MP3, every future format change degrades it further. Keeping a lossless master (FLAC is typically around half to two-thirds the size of WAV, with identical audio) means distribution formats can be regenerated from the original whenever codec support or bitrate targets change.
Migration Guide
MP3 → AAC
- Verify target can play AAC (almost all smartphones and browsers OK).
- Test encode at one step lower bitrate targeting same listening quality.
- Migrate from ID3 to M4A metadata (tool-specific scripts).
AAC/MP3 → Opus
- WebRTC, Ogg, WebM pipelines make Opus natural.
- If hardware playback needed, distribute MP3/AAC in parallel.
- For voice-only, test from low bitrate (e.g., 24~64 kbps). Caution: Broadcasting and radio standards often have country/transmission system specific codec/bitrate requirements.
Migration only makes sense from lossless sources. Converting an MP3 library to AAC to “modernize” it produces files that are slightly worse than the MP3s and not much smaller, as the FAQ below explains; the migration steps above assume you are re-encoding from WAV, FLAC or the original production masters.
Deployment Notes
Mixed Usage (e.g., MP4 + H.264 + AAC)
- Web & mobile default: H.264 + AAC + MP4 is one of the most compatible combinations.
- Bandwidth reduction variant: Provide Opus (WebM) as separate rendition, fallback to MP4 for old browsers.
Fallback Strategy
<audio controls>
<source src="track.opus" type="audio/ogg; codecs=opus">
<source src="track.m4a" type="audio/mp4">
<source src="track.mp3" type="audio/mpeg">
</audio>- HLS/DASH: Often unify audio-only with single codec (e.g., AAC) to reduce client complexity.
The browser picks the first <source> whose type it believes it can play, so order is a preference list: most efficient first, most compatible last. The codecs parameter is important — without it, a browser may claim it “maybe” supports audio/ogg and then fail on the actual codec inside. Older Safari versions in particular did not play Ogg Opus, which is exactly the case the MP4 and MP3 fallbacks cover. Serving the right MIME types from the web server matters too: a .opus or .m4a file served as application/octet-stream may fail to play in some browsers even though the file is fine.
Encoding Best Practices
# AAC for music streaming
ffmpeg -i input.wav -c:a aac -b:a 128k -movflags +faststart output.m4a
# Opus for voice chat
ffmpeg -i input.wav -c:a libopus -b:a 48k -vbr on -application voip output.opus
# MP3 for maximum compatibility
ffmpeg -i input.wav -c:a libmp3lame -q:a 2 output.mp3-movflags +faststart moves the MP4 index (the moov box) to the front of the file so playback over HTTP can start before the whole file is downloaded; without it, some players wait for the full download or issue an extra range request to the end of the file. For voice at 48 kbps, mono is usually the better use of bits — add -ac 1 — since a stereo encode of a single microphone spends bits on two nearly identical channels.
Common Questions
Q1. Which is best for music only? Depends on listening conditions and bitrate. At same bitrate, AAC or Opus often outperform MP3 in reports. At high bitrate (256k+), perceived differences decrease.
Q2. Can Opus be used everywhere like MP3? Most software supports it, but old car stereos and appliances often only support MP3.
Q3. Are AAC and MP4 the same? No. AAC is an audio codec, MP4 is a container. AAC is usually distributed inside MP4 (M4A).
Q4. Can MP3 be used for real-time calls? Opus or dedicated voice codecs are more suitable due to latency and frame structure. MP3 is not designed for real-time. Q5. Is higher bitrate always better? If source (mic, mixing) quality is poor, increasing bitrate has limits. Mastering and noise reduction should come first.
Conclusion
- Legacy & maximum compatibility: MP3 or AAC
- Music & mobile default: AAC
- Voice, real-time, efficiency: Opus is the strong choice
- Services should first draw target device matrix, then choose codec. For compatibility use MP3/AAC, for voice & real-time default to Opus with MP3 fallback for legacy.
Related Articles
Frequently Asked Questions (FAQ)
Q. Will converting my MP3 library to AAC or Opus improve quality?
A. No. Transcoding from one lossy format to another cannot restore detail the first encoder threw away, and the second encoder adds its own artifacts, so quality usually gets slightly worse. Only re-encode from a lossless source such as WAV or FLAC; if you only have MP3 files, keep them as they are unless file size is the real problem.