The Glitch You Almost Didn't Hear
You're halfway through a quiet album track, headphones on, when something almost happens. A faint shimmer on the vocal. A texture that was there and then slightly wasn't. Your Wi-Fi hiccupped, the stream recovered, and you've already moved on before you could fully form the thought. Most people assume the platform just "caught up" somehow, like rewinding a garden hose after you pinch it. The reality is considerably stranger.
Streaming platforms don't reconstruct audio by magic. They do it through a layered system of buffers, adaptive bitrate switching, and codec-level error concealment, each one a fallback when the one above it fails. That stack explains why a two-second dropout on a good connection sounds like nothing, while the same dropout on a shaky one sounds like a robot gargling.
The Buffer Is Buying You Time
Before a single note reaches your ears, the app has already downloaded several seconds of audio it hasn't played yet. This is the pre-roll buffer. Its whole job is to make network hiccups invisible.
Spotify has historically used a buffer of around 10 to 30 seconds depending on connection quality and device state. Apple Music and Tidal behave similarly. A dropout lasting under five seconds can often pass entirely unnoticed: the app keeps playing from its stored reserve while the connection quietly restores itself in the background, refilling as packets start flowing again.
Think of it less like a hose and more like a toilet cistern. The flush happens from the tank, not directly from the pipe. If the pipe slows for a moment, you don't notice until the tank runs dry. And when it does run dry, which requires either a sustained dropout or a very thin buffer to begin with, the platform reaches for the next tool.
Adaptive Bitrate Switching: Trading Quality for Continuity
Most streaming services encode the same track at multiple quality levels simultaneously. A song might exist as a 320 kbps AAC file, a 128 kbps version, and a 64 kbps fallback, all sitting on the server, all ready to serve. The client constantly measures available bandwidth and switches between these rungs without asking your permission.
Say your connection drops from 5 Mbps to 0.4 Mbps for eight seconds. The app detects the collapse mid-buffer-drain, requests the lower-quality stream, and continues playback with reduced fidelity rather than stopping entirely. When bandwidth recovers, it steps back up.
This is why audio sometimes sounds slightly flat or compressed during a rough patch even when the stream never fully breaks. You didn't lose the music. You lost the top floor of the frequency range while the elevator descended a few floors and came back up.
The transition is stitched at a packet boundary, typically at a chunk boundary in the HTTP audio segment, so the switch happens between small blocks of audio data rather than mid-waveform. Done well, it's inaudible. Done under duress, with the connection collapsing faster than the client can react, it produces that characteristic warble.
What the Codec Does When Packets Actually Go Missing
Here's where things get genuinely clever. Even after the buffer and the bitrate ladder, some packets will simply not arrive. Lost in transit, not delayed. The codec has to fill that gap with something, because silence or a click would be far more jarring than a plausible approximation.
This is Packet Loss Concealment, or PLC. Modern codecs handle it in ways that are, honestly, underappreciated.
Opus, which Spotify and Discord both use for certain streams, analyses the waveform that arrived just before the gap. It then synthesises a short continuation of that audio, extrapolating pitch, amplitude envelope, and spectral shape forward in time for the duration of the missing packet (typically 20 milliseconds per packet). It's not guessing randomly. It's pattern-matching against what it just heard and projecting forward, the way you can hum the next bar of a song you know well before you've consciously decided to.
For music, PLC works best on sustained tones: strings, pads, held vocals. It struggles with transients. A snare hit, a piano attack, a consonant in a word. Those events are too sudden and unpredictable to synthesise convincingly. So a missing packet during a guitar solo sounds more forgivable than one at the precise moment a kick drum lands.
AAC, used by Apple Music and YouTube Music, has its own error resilience tools baked into the format, including bitstream error detection and the ability to re-use the previous audio frame's decoded output as a substitute. Less sophisticated than Opus PLC in some respects, but fast and computationally cheap, which matters on older hardware.
Consider two people streaming the same album on a patchy home network. One is using a phone from four years ago running a basic AAC stream at 256 kbps. The other has a newer device running an Opus-based stream at a similar bitrate. During an identical 60-millisecond dropout, the first listener hears a faint pop where the codec ran out of good substitution data. The second hears almost nothing, because Opus extrapolated a plausible continuation and faded it out gracefully. Same dropout, different experience. The codec was the difference, not the connection.
The Part That Operates Below Your Awareness
All of this happens on timescales that sit beneath conscious perception. The human ear starts to notice audio gaps at around 20 to 30 milliseconds. A single lost Opus packet is 20 milliseconds. The concealment algorithm fires before your brain has finished processing the previous sound.
This is why a brief dropout feels less like a cut and more like a vague wrongness. Your auditory system detected something, but by the time you could form the thought, three layers of error correction had already filed a report and moved on.
Deeper dropouts, lasting 200 milliseconds or more, are where the system starts to show its seams. PLC degrades quickly beyond two or three consecutive missing packets because extrapolation compounds its errors. A synthesised continuation of a synthesised continuation of real audio becomes something like a watercolour painted over a photocopy of a watercolour. The buffer may have drained. The bitrate ladder may have hit its lowest rung. At that point, the app either plays degraded audio or briefly stalls and rebuffers, which most platforms now prefer because a half-second pause is less disorienting than several seconds of audio that sounds like it was processed through a melting synthesiser.
What Your Settings Actually Change
Most streaming apps let you cap quality manually, and people often set this to "low" on mobile data to save bandwidth. Worth knowing: that setting affects which rung of the bitrate ladder you start on, not how the error concealment works. PLC and buffering operate regardless of your quality setting. You're just deciding how far the ladder extends upward.
The "download for offline" option, on the other hand, removes the dropout problem entirely for that track. No live stream, no packets to lose. The codec still runs, but it's reading from local storage, which doesn't hiccup the way a network connection does.
And if you're on Wi-Fi with your app set to anything below its maximum quality, ask yourself what you're actually saving. Nothing, is the answer. You're leaving fidelity on the table for no practical reason.
The Seams Are Designed to Disappear
The remarkable thing about this whole system is that it's optimised not for accuracy but for perceptual smoothness. The goal is never to perfectly reconstruct what was lost. It's to produce something your ears will accept as plausible in the 20 milliseconds before you notice anything is wrong.
That's a genuinely different engineering target than most people assume, and I'd argue it's more interesting than simple fidelity. Streaming platforms aren't trying to recover the truth of the missing audio. They're trying to convince your auditory cortex that nothing happened. The dropped packet you never heard was a small act of technical deception, performed entirely for your benefit, in less time than it takes to blink.