How to Fix Remotion Audio Muting Early When Using playbackRate
A specific, reproducible bug pattern: audio plays correctly at normal speed but goes silent before the video ends when playbackRate is applied.
This is a known, specific failure pattern: an <Audio> component plays fine at playbackRate={1}, but the moment you speed it up or slow it down, the audio cuts out silently before the visual content finishes — no error, no warning, just missing sound for the last portion of the render.
Why it happens
Remotion calculates how much of the audio source needs to be decoded based on the sequence's duration in frames. When you apply a playbackRate, the actual real-time duration of audio played changes, but the calculation of how much source audio to fetch doesn't automatically follow — it can end up requesting less audio than the sped-up (or slowed-down) playback actually consumes, so the source runs out early.
The fix
Explicitly adjust the Sequence duration to account for the playback rate, rather than relying on the default calculation:
<Sequence durationInFrames={Math.ceil(originalDurationInFrames / playbackRate)}>
<Audio src={staticFile("voice.wav")} playbackRate={playbackRate} />
</Sequence>Dividing the original duration by the playback rate gives you the correct number of frames the sped-up (or slowed-down) audio will actually occupy, so Remotion knows to keep decoding for the full real length instead of stopping early.
How to verify it's actually fixed
Don't just listen at normal volume near the end — render the full composition and check the waveform in an audio editor, or listen specifically to the last 10-15% of the clip at the speed you applied. This bug is easy to miss in a quick preview because the cutoff point moves depending on the exact playback rate used.
This is exactly the kind of narrow, easy-to-miss bug that a locked, pre-tested template only has to fix once. NULLFRAME's templates have already hit this class of issue and closed it — you're not the one debugging it.
See the templates