The Stream Test

The Full Story

Mastering for Streaming

Everyone's got opinions on True Peak headroom, loudness targets, and how much you should worry about inter-sample peaks (ISP). It kind of boils down to the same recommendation: keep your True Peak below -1 dBTP, maybe -2 dBTP, and don't ask questions.

WHAT? WHY?

So I ran a codec conversion test on a master I did of a Hardstyle track in Mid 2025 — roughly 4dB - 5dB of overall limiting, lots of low end energy, Roughly -5.5 LUFS @0dB TP. I wanted to mimic a SRC (sample rate conversion) the way the more popular streaming services do. I certainly made a very solid attempt at duplicating a scenario of multiple codec changes the way the "Big Name" streaming services do (Spotify, Apple Music mostly), and how much ISP they introduce, how severe they could be, and whether the standard headroom recommendations hold up under scrutiny.

Methodology

The Test

I started with a 96 kHz / 24-bit WAV master — a hard-hitting EDM track pushed to 0 dBTP, representative of what we deliver for clients in EDM and hip-hop. From there, we ran a series of conversions and analyzed every output in iZotope RX 10 using Waveform Statistics and visual waveform inspection.

The signal chain looked like this:

Signal Chain

→96 kHz / 24-bit WAV → Sample rate conversion to 44.1 kHz / 24-bit WAV

→44.1 kHz WAV → AAC 256 kbps (via ffmpeg — simulating Apple Music)

→44.1 kHz WAV → AAC 128 kbps (via ffmpeg — simulating worst-case streaming)

→44.1 kHz WAV → Ogg Vorbis 320 kbps (via RX — simulating Spotify Premium)

→44.1 kHz WAV → Ogg Vorbis 160 kbps (via RX — simulating Spotify Free)

Every output was loaded back into RX for True Peak analysis.

Findings

The Results

Stage 1

Sample Rate Conversion (96k → 44.1k)

No inter-sample peaks introduced. The SRC stage — whether performed in Ableton or in RX — handled the conversion cleanly. RX's SRC introduced zero ISPs even with post-limiting unchecked. Ableton's renderer appeared to apply its own internal limiting during the bounce, but the result was equally clean.

Verdict

SRC is not a risk factor for this material.

Figure 1: Original 96 kHz / 24-bit WAV master in RX — the starting point.

Figure 2: After SRC to 44.1 kHz / 24-bit via RX. No ISPs introduced. Waveform remains clean.

Stage 2

AAC Encoding (256 kbps and 128 kbps)

Neither AAC bitrate introduced inter-sample peaks. The 256 kbps encode was essentially transparent from a peak perspective. Even at 128 kbps — a bitrate low enough to introduce audible compression artifacts — the True Peak remained at or below the original ceiling. The AAC codec handled the dense, limited material without generating overshoots.

Verdict

AAC is not introducing ISPs on this material, even at low bitrates.

Figure 3: 44.1 kHz WAV converted to AAC 128 kbps. No ISPs. Peak levels remain controlled.

Figure 4: 44.1 kHz WAV converted to AAC 256 kbps. Clean conversion, no overshoots.

Stage 3

Ogg Vorbis Encoding — Where Things Break

This is where the results got interesting.

Ogg Vorbis 320 kbps (Spotify Premium): ISPs present throughout the entire track. The highest peak overshoot measured +0.56 dB above the original ceiling. Not catastrophic, but clearly presents itself across the full duration of the track.

Ogg Vorbis 160 kbps (Spotify Free): ISPs significantly worse. The highest peak overshoot measured +1.4 dB above the original ceiling. The waveform showed overshoots distributed across virtually the entire track, with the densest sections (drops, heavy bass passages) producing the most severe peaks.

Verdict

Ogg Vorbis is the only codec in this test that introduces ISPs — and the severity scales dramatically with lower bitrates.

Figure 5: 44.1 kHz WAV converted to Ogg 320 kbps. ISPs visible across the full track, peaking at +0.56 dB.

Figure 6: 44.1 kHz WAV converted to Ogg 160 kbps. ISPs significantly worse, peaking at +1.4 dB. The red-boxed region shows the scale of the problem.

What This Means

Ogg Vorbis is Spotify's primary playback codec for the vast majority of its listeners. The desktop and mobile apps both use Ogg — at 320 kbps for Premium subscribers and 160 kbps for free-tier users. The web player uses AAC, but that represents a small fraction of total Spotify traffic.

This means the codec most likely to introduce clipping on your master is the one being used by the largest music streaming platform in the world, serving it to its largest audience segment (free-tier listeners) at the bitrate that produces the worst overshoots.

Meanwhile, platforms that rely on AAC — Apple Music, YouTube, Tidal's lower tiers — handled the same master cleanly at 0 dBTP.

One Important Caveat...

Our AAC testing used ffmpeg's built-in encoder, which is not identical to the proprietary encoders used by Apple Music, YouTube, or other platforms. It's possible that a platform's specific AAC implementation could behave differently. We tested what we could control — and the results were clear — but we can't guarantee that every AAC encoder in every platform's pipeline will produce the same clean result. The headroom recommendation accounts for this uncertainty.

What about downloads?

Ah of course! It's definitely worth noting that masters intended for DJ download platforms like Beatport, Juno Download, or Traxsource are a different story entirely. These platforms deliver lossless files directly to the buyer — no lossy transcoding, no Ogg Vorbis, no AAC conversion in the pipeline. The listener gets exactly what we deliver. For these releases, we master at full range with no headroom compromise, preserving every bit of impact and loudness the track is designed to carry. The codec safety margin is a streaming concern, not a universal one, and we treat each delivery path accordingly.

And, Conclusion..

Based on this testing, we recommend 1.0 to 1.5 dB of True Peak headroom for masters destined for streaming platforms. This range covers the Ogg 320 kbps overshoot comfortably (+0.56 dB) and gets close to covering the worst-case 160 kbps scenario (+1.4 dB). It's a delicate dance with each master depending on the program material.

It's worth noting that this applies specifically to streaming distribution. If you're submitting to download-only marketplaces like Beatport or Juno Download — where the buyer receives a lossless file that won't be transcoded — the Ogg concern doesn't apply, and you can deliver with less headroom.

Every track is different. A less aggressively limited master, or one with different frequency content, may produce different results. But for the kind of loud, bass-heavy, hard-limited material that defines modern EDM and hip-hop, Ogg Vorbis at lower bitrates is where the risk lives — and it's a risk worth managing.

I promise, last thought..

After even uploading these test files to the internet, my question is this... Will most people notice?

No, absolutely not. Unless they have dog ears or can hear grass grow. You could spot a difference in some of the finest of acoustically conditioned rooms.

But ultimately, it's a game of balance. Some tracks, the headroom does help as long as Dynamic/Loudness management is well tendered to during the mastering process.

Mastering for Streaming

The Test

The Results

Sample Rate Conversion (96k → 44.1k)

AAC Encoding (256 kbps and 128 kbps)

Ogg Vorbis Encoding — Where Things Break

What Happens to a -8 LUFS Master on Each Platform

What This Means

One Important Caveat...

What about downloads?

And, Conclusion..