# Why we play short voice clips differently from long background tracks A five-second voice take and a ninety-minute soundtrack are both audio files. We don't ask the browser to hold them the same way. By Ibiang Emmanuel · Published 2026-11-08 Source: https://reedapt.com/blog/why-we-play-short-voice-clips-differently-from-long-background-tracks You change a sentence in the editor, listen to the new take, then play it again. Maybe you move the playhead back a little to hear how it joins the previous line. That take might be five seconds long. The background underneath it might run for ninety minutes. Both are audio files, but giving them the same playback path would make one of those jobs unnecessarily expensive. For the take, we want a small piece of sound ready to reuse. For the background, we don't want to hold an entire film's decoded samples in an application-held audio buffer just to play the next few seconds. The difference starts with what happens after the download. ## The file size isn't the sample storage A compressed audio file is a compact way to carry sound. Once decoded into an `AudioBuffer`, the sound is available as samples, channel by channel. Web Audio exposes those samples as 32-bit floating-point values: four bytes per sample. The basic calculation is small enough to keep in your head: ``` sample bytes = seconds × samples per second × channels × 4 ``` At 48 kHz, a five-second stereo take needs about 1.83 MiB for those samples. Ninety minutes in the same format comes to about 1.93 GiB. We haven't changed the sample format. We've just asked it to represent much more time. **Small take, long track, same sample format** *Float32 sample payload only. No media is allocated by this calculator. No browser memory, decoding-speed or product-limit claim.* Synthetic English speech and a generated four-note music pattern. Compare aligned reference audio with adjustable voice delay, rate drift, music level and energy-based ducking. Resampling also changes pitch. Transcript: A small delay can change how a conversation feels. Keep the voice clear, and let the music sit behind it. This is not Reedapt output. [Interactive example](https://reedapt.com/blog/why-we-play-short-voice-clips-differently-from-long-background-tracks) Those are sample-storage calculations, not measurements of Reedapt or a browser's total memory. The download, decode work, audio objects, video, editor state and any extra copies all add costs of their own. Nor does this equation tell us how long decoding will take. The sample rate here is the rate of the decoded buffer. It needn't match the file's original rate: `decodeAudioData` resamples for the audio context. The calculator lets you change it, rather than treating 48 kHz stereo as a fact about every take. ## A replay shouldn't have to start the download again Short takes are useful to decode ahead of time. Once a take is ready, the editor can start it at an offset, stop it at the end of a line, and reuse it when the playhead returns. Our earlier element-based path could cancel an unfinished download when a take left the playback pool. Returning to it meant starting that work again. That is especially unhelpful when someone is moving around a long timeline, checking one line and then another. The current voice pool separates stopping a voice from releasing its decoded audio. Stopping leaves the buffer available. Removing a take from the patch list can release it. A take that is still loading isn't cancelled merely because the playhead has moved away, so its decoded result can still become useful. There is still a cache policy. We can't turn "keep it for replay" into "keep every take forever." **Follow a tiny decoded-take cache** *Three-entry target, fictional equal-length takes, immediate successful loads. No real cache, downloads or elapsed-time benchmark. Warmest retained entry first.* Synthetic English speech and a generated four-note music pattern. Compare aligned reference audio with adjustable voice delay, rate drift, music level and energy-based ducking. Resampling also changes pitch. Transcript: A small delay can change how a conversation feels. Keep the voice clear, and let the music sit behind it. This is not Reedapt output. [Interactive example](https://reedapt.com/blog/why-we-play-short-voice-clips-differently-from-long-background-tracks) The small cache above has a target of three entries so you can follow it. The reviewed implementation defaults to a target of 48 decoded take buffers. That is a count, not a byte budget: one long take can cost more than several short ones. It is also a soft target. A voice that is still sounding is protected from eviction, even if retaining it takes the cache over the target. Cutting off an active voice to make a counter look tidy would be the wrong trade. Protected cold entries don't justify evicting a warmer entry that would otherwise be retained, either. Changing a take's speech speed can introduce another allocation: the player can keep a pitch-preserving, time-stretched copy alongside the original. The cache count alone is not a complete memory accounting system. ## The long background takes another path The background stem uses an audio element. The editor does not first turn the whole long track into one application-held `AudioBuffer`. That is a narrower claim than "streaming uses almost no memory." The browser still downloads, buffers and decodes sound. Our background element uses `preload="auto"`, which allows the browser to fetch ahead; it is not a promise to download only the few seconds currently on screen. The useful distinction is who holds the complete decoded asset. The short-take player deliberately keeps samples it expects to reuse. The long-track path leaves media loading and playback to the browser, without asking our voice cache to own the whole soundtrack as PCM. You shouldn't expect a successful version of either path to sound different just because its storage is different. The next example plays the same short source through both mechanisms. It is a way to inspect the paths, not a listening test for memory usage or a latency benchmark. **One short source, two playback paths** *The same synthetic English mono WAV in both paths. Not Reedapt output, not a long-track streaming test, and not a performance comparison. No autoplay.* Synthetic English speech and a generated four-note music pattern. Compare aligned reference audio with adjustable voice delay, rate drift, music level and energy-based ducking. Resampling also changes pitch. Transcript: A small delay can change how a conversation feels. Keep the voice clear, and let the music sit behind it. This is not Reedapt output. [Interactive example](https://reedapt.com/blog/why-we-play-short-voice-clips-differently-from-long-background-tracks) The source is a synthetic English voice in a short mono WAV, not a customer recording, a compressed-file demonstration or Reedapt dubbing output. The decoded sample count comes from the buffer actually created for this example. It says nothing about the browser's hidden media buffers or a ninety-minute track. ## The right buffer can still be the wrong voice Having a take ready doesn't mean it should play over everything else. Suppose the loaded mix already contains a line, and you generate a replacement. In the incremental preview path, the editor needs the new take to replace the voice in that window, not join it. The existing mix is lowered there while the new take plays. Once that take is included in a newer rendered mix, leaving the overlay active would play the voice twice. The editor uses the take's mix-version stamp to work out whether the take is newer than the loaded mix and still needs that overlay. **Does this voice still need an overlay?** *Twelve-second fictional incremental-preview timeline. The replacement occupies seconds 4–7. Gain ramps are 25 ms; no audio is played by this diagram. Not a stems-mode model.* Synthetic English speech and a generated four-note music pattern. Compare aligned reference audio with adjustable voice delay, rate drift, music level and energy-based ducking. Resampling also changes pitch. Transcript: A small delay can change how a conversation feels. Keep the voice clear, and let the music sit behind it. This is not Reedapt output. [Interactive example](https://reedapt.com/blog/why-we-play-short-voice-clips-differently-from-long-background-tracks) That example shows the incremental mix path only. Stems mode has a different arrangement: it schedules individual takes with the background, including takes that are already baked into the rendered mix. It isn't accurate to describe every mode as playing only changed lines. There is a fallback to think about, too. A line without a separate active take may still have speech in the rendered mix. A missing take must not automatically become a silent line. ## One player would hide the decision We could put both paths behind something called an audio player. We would still have to decide what it loads, what it retains, what it releases, and whether the loaded mix already contains the voice we're about to play. For a short take, keeping decoded samples buys us useful control and cheaper re-entry while the buffer is retained. For a long background, asking for that same representation up front can mean a very different allocation. The file extension doesn't make those decisions for us. The amount of sound, and the way someone needs to edit it, does. ## Reference [The Web Audio specification's AudioBuffer definition](https://www.w3.org/TR/2021/REC-webaudio-20210617/#AudioBuffer) describes the sample representation and distinguishes short, memory-resident sounds from longer media playback. Reedapt-specific behavior above was checked against the voice pool, preview scheduler and timeline reconciliation code; the review notes record the revision and test scope.