The audio matches the video perfectly at the start of the clip, but by the end it’s noticeably off — and the further you scrub, the worse it gets. This is audio drift, and it’s a fundamentally different problem from a fixed delay. A constant offset is the same amount of lead or lag from beginning to end, and you fix it with a single timestamp shift. Drift accumulates: it grows because the audio clock and the video clock are running at slightly different speeds, so the gap between them widens frame after frame. Fixing drift means correcting the rate, not adding a one-time offset. This article explains the cause and gives you runnable fixes.
Tested with: FFmpeg 8.1
What You’ll Learn
- The difference between drift (gets worse over time) and a constant offset (same amount throughout)
- Why drift comes from an audio sample-clock vs video-clock mismatch, or a VFR source
- Why constant-offset tools like
-itsoffsetdo not fix drift - Three runnable fixes:
aresampleasync (stretch / squeeze / fill / trim), resampling to a fixed rate for compatibility, and forcing constant frame rate
If your audio is off by a fixed amount from the very start, this is the wrong article — you need a single offset, covered in Fix Audio Delay Manually. For the general sync toolbox, see Fix Audio Sync.
Drift vs Constant Offset: Why It Matters
The fix you need depends entirely on which pattern you have. Confirm the symptom first.
| Pattern | Symptom | Cause | Fix type |
|---|---|---|---|
| Constant offset | Audio is off by the same amount from start to end | A fixed delay in recording/muxing | One-time shift (-itsoffset, adelay) |
| Drift | In sync at the start, increasingly off by the end | Two clocks running at different rates, or VFR | Rate correction (resample / CFR) |
The key tell for drift: if you nudge the audio to line up at the start, the end is now even more wrong — and vice versa. No single offset value can satisfy both ends at once, because the error grows over the duration of the clip.
Why -itsoffset Cannot Fix Drift
-itsoffset shifts an entire stream’s timestamps by a fixed number of seconds. That’s exactly right for a constant offset — the whole stream moves together. But drift isn’t a uniform shift: at the 1-minute mark the audio might be 100 ms off, and at the 10-minute mark it’s 1 second off. A single offset would line up one point in the clip and leave every other point wrong.
Think of it this way: -itsoffset slides the audio left or right as a rigid block. Drift needs the block to be stretched or compressed so its playback rate matches the video. That’s a resampling operation, not a shift — which is why the fixes below all act on the audio’s rate or the frame rate, never on a fixed offset.
Fix 1: aresample async — Stretch, Squeeze, Fill, and Trim to Track the Clock
The aresample filter with an async value tells FFmpeg to actively keep the audio aligned to its timestamps. With a value greater than 1 it can stretch or squeeze (resample) the audio as well as fill or trim samples to close the gap. The number sets how many samples per second FFmpeg is allowed to add or remove — a larger value lets it correct more aggressive drift.
ffmpeg -i input.mp4 -af aresample=async=1000 -c:v copy output.mp4-af aresample=async=1000— allow up to 1000 samples/sec of stretch / squeeze / fill / trim to track the timestamps-c:v copy— copy the video untouched (fast, lossless)- The audio is re-encoded because the filter rewrites samples
async=1000 is a sensible starting point for audible drift. If drift remains, raise the value; if you hear artifacts, lower it. This is usually the first thing to try because it keeps the video stream copied.
Fix 2: Standardize the Sample Rate (Compatibility)
-ar 48000 sets the output sample rate and resamples the audio to it (48000 Hz is the video-friendly standard). Be clear about what this does and doesn’t do: it standardizes the rate so the output is clean and broadly compatible, but it does not, by itself, correct cumulative drift caused by a wrong real clock or bad timestamps. The actual drift correction is the async resampling in Fix 1; if the file has a known wrong declared sample rate (it was tagged at the wrong value), asetrate is the tool that reinterprets it. Treat -ar as a standardization step you pair with the real fix, not as a drift cure on its own.
ffmpeg -i input.mp4 -ar 48000 -c:v copy output.mp4-ar 48000— set/resample the output audio to a standard 48 kHz-c:v copy— keep the video as-is
Use this when you want a clean, predictable output rate, and combine it with Fix 1 to actually close the drift — -af aresample=async=1000 -ar 48000 -c:v copy output.mp4 standardizes the rate and tracks the timestamps at once.
Fix 3: Force Constant Frame Rate (When the Source Is VFR)
If the video side is the culprit — a variable-frame-rate (VFR) source whose frame intervals wander — then the audio is fine and it’s the picture clock that’s unsteady. Forcing the video to constant frame rate (CFR) gives every frame a predictable interval that the audio can stay locked to.
ffmpeg -i input.mp4 -fps_mode cfr -r 30 -c:v libx264 -c:a aac output.mp4-fps_mode cfr— force constant frame rate output (FFmpeg 8.x option)-r 30— target frame rate; set it to your source’s nominal rate-c:v libx264 -c:a aac— re-encode both streams onto a steady timeline
Note: In FFmpeg 8.x use
-fps_mode cfr. The legacy-vsync cfrstill works but is deprecated.
VFR is such a common root cause of drift that it has its own dedicated guide with ffprobe detection steps: Convert Variable Frame Rate to Constant. If your drift appeared specifically after a conversion step, also see Audio Out of Sync After Converting.
Which Fix Should I Use?
| Situation | Recommended fix |
|---|---|
| Drift you can hear, want to keep video copied | -af aresample=async=1000 -c:v copy |
| Want a clean, standard output rate (pair with async) | -ar 48000 -c:v copy |
| Source is a screen/phone/game capture (VFR) | -fps_mode cfr -r 30 (re-encode) |
| Audio is off by a fixed amount, not growing | Not drift — see Fix Audio Delay |
Start with aresample=async, since it keeps the video copied and handles most audible drift — it’s the part that actually corrects the rate. Add -ar 48000 to standardize the output, or switch to CFR if the root cause is a VFR source.
FAQ
How do I tell drift apart from a constant delay?
Line up the audio at the start of the clip. If the end is now even more out of sync, it’s drift (the error grows over time). If the whole clip shifts together and stays uniformly aligned, it’s a constant offset — fix that with Fix Audio Delay Manually.
Why doesn’t -itsoffset fix my drift?
-itsoffset slides the entire audio stream by a fixed amount, like moving a rigid block. Drift means the error grows over the duration, so any single offset only lines up one point and leaves the rest wrong. Drift needs a rate correction (resampling or CFR), not a shift.
What does the number in aresample=async=1000 mean?
It’s the maximum number of samples per second FFmpeg may insert or drop to keep the audio aligned to its timestamps. Higher values correct more aggressive drift but risk audible artifacts; lower values are gentler. 1000 is a reasonable starting point.
My drift is caused by a variable frame rate — what then?
Force constant frame rate with -fps_mode cfr -r 30 while re-encoding. The detection and full walkthrough is in Convert Variable Frame Rate to Constant.
Can I combine the resample fixes?
Yes. ffmpeg -i input.mp4 -af aresample=async=1000 -ar 48000 -c:v copy output.mp4 applies async tracking and forces a fixed 48 kHz rate at the same time, while still copying the video.
Related Articles
- Fix Audio Delay Manually
- Fix Audio Sync
- Audio Out of Sync After Converting
- Convert Variable Frame Rate to Constant
- How to Fix No Sound Issues in FFmpeg
Tested with FFmpeg 8.1 — verified with our command-check script
Primary sources: ffmpeg.org/ffmpeg-filters.html#aresample / ffmpeg.org/ffmpeg.html