Editors: Fix Frame Rate Mismatch Audio Drift With ffprobe and ffmpeg
Last Edited: Oct 13, 2026

If your dialogue lines up at the start of a clip and slides out of sync by the end, you’re almost certainly looking at progressive drift from a variable frame rate or a clock mismatch, not a simple offset. Run an ffprobe check first to confirm it. If the numbers show variable timing, transcode to a constant frame rate before you touch anything else. If the gap stays the same throughout the clip, shift the audio.
TL;DR:
- Variable frame rate files from phones or screen recorders are the main cause of progressive drift and must be transcoded to a constant frame rate before editing.
- Differences between r_frame_rate and avg_frame_rate in ffprobe indicate a VFR file, which will drift over time and require conversion.
- Constant offset issues, often caused by start-point mis-marking, can be fixed by shifting the audio track or applying an offset in the container without transcoding.
- Ensuring project and device settings match, such as frame rate and sample rate, and always verifying sync at the start, middle, and end avoids future drift issues.
- Building a routine check with ffprobe during ingest, along with proper set-up like jam-syncing devices, significantly reduces post-production sync problems.
How to Tell Constant Offset From Progressive Drift
Every sync problem falls into one of two camps, and knowing which one you’re facing decides your entire repair path. A constant offset means the audio and video are shifted by the same amount everywhere: dialogue starts a beat late, but the gap never grows or shrinks. That usually comes from a bad in point, a slate mis-mark, or a device that started recording a fraction of a second before the other. A progressive drift means the gap widens (or narrows) as the clip plays, and that points to a timebase problem: a variable frame rate file, a clock running fast or slow, or a sample-rate mismatch that compounds over minutes.
The check is simple and doesn’t require any software beyond your player and a stopwatch mentality.
- Compare a hard consonant or clap at the very start of the clip against the video.
- Jump to the middle and the last thirty seconds and check the same sync point again.
- If the gap is identical in both spots, you have a constant offset. If it grew, you have drift.
Waveform matching backs this up visually: when a spike in your audio track lines up with the video at the head of the clip but drifts later, that’s a clock or frame-rate issue rather than a static offset. Editors sometimes assume small frame-rate differences will sort themselves out in the edit, but 23.976 and 24 fps are genuinely different timebases, and that mismatch shows up exactly as this kind of growing gap over long footage.
Pro Tip: Never trust a sync check done only on the slate. Drift from VFR or clock mismatch is often invisible in the first ten seconds and obvious by minute twenty.
If your test shows progressive drift, treat it as a VFR or timebase problem and re-encode to a constant frame rate before you do any further cutting. Editing on top of a drifting file means redoing the sync work twice.
Common Causes of Audio Drift Tied to Frame Rate and Timebase
Most drift traces back to one of four sources, and each leaves a slightly different fingerprint.
Variable frame-rate footage is the most common culprit, especially from phones and screen recorders that adjust frame rate on the fly to reduce file size. Editors and non-linear editing systems generally assume that every file runs at a constant frame rate, so when a file’s actual frame timing wobbles, the audio track (which plays back on a steady clock) and the video track (which plays frames at inconsistent intervals) slowly drift apart. Phones and screen recorders frequently rely on VFR, and if the dialogue in that footage matters, it needs to be transcoded to a constant frame rate before it goes anywhere near a timeline.
Frame-rate mismatches between what a camera recorded and what your project expects cause a related but distinct problem. 23.976 fps and 24 fps look almost identical on paper, but across an hour of footage that tiny difference in timebase accumulates into a drift of multiple seconds. Drop-frame and non-drop-frame timecode add another layer of confusion here: drop-frame timecode skips certain frame numbers to stay aligned with real time at 29.97 fps, and mixing drop-frame and non-drop-frame sources in one project is a reliable way to introduce sync errors that look like drift but are actually timecode math.
Device clock drift is quieter but just as damaging on multicam or dual-system shoots. Every device that records audio or video runs its own quartz oscillator, and no two oscillators run at exactly the same rate. Over a short clip, that variance is invisible. Over thirty or sixty minutes, two devices with slightly different clock speeds will drift apart by a noticeable amount, even if both were started at the same instant.
Sample-rate mismatches and mis-muxed timestamps round out the list. A file recorded at 44.1kHz played back against a 48kHz project timeline, or a recording where the audio and video streams were packaged with inconsistent start times, will drift or offset in ways that look identical to a frame-rate problem but need a different fix.
- Variable frame rate files create cumulative error because NLEs assume constant timing.
- Frame-rate mismatches like 23.976 versus 24 fps compound over long footage.
- Device clock variance causes two recordings to slowly separate over time.
- Sample-rate mismatches or broken timestamps produce drift that looks timebase-related but isn’t.
Tools and Commands: FFprobe, What to Read, and NLE Checks
The fastest way to confirm which of those causes you’re dealing with is to ask the file directly. Run this command against your clip:
ffprobe -v error -select_streams v:0 -show_entries stream=r_frame_rate,avg_frame_rate,start_time -of default=noprint_wrappers=1 clip.mov
Two fields matter here. r_frame_rate is the frame rate the container declares, and avg_frame_rate is what ffprobe actually measured across the file. When those two numbers match, you’re looking at a genuine constant frame rate file. When they differ, that mismatch is the signature of variable frame rate, and it’s the single most reliable diagnostic signal you’ll get from a command line. This distinction is exactly what DaVinci Resolve’s interpret footage settings are built to expose and correct once you know which frame rate the file should actually be treated as.

A file where r_frame_rate reads “30000/1001” and avg_frame_rate reads “29970001/1000000” or something similarly inconsistent is a VFR file wearing a CFR label, and it will drift the longer it plays.
The start_time field is worth checking too. If your audio and video streams report different start times, you’re looking at a mis-muxed file rather than a clock or frame-rate problem, and the fix is different (more on that in the next section).
Inside your NLE, a few settings deserve a second look before you start cutting:
- Check the clip’s “interpret footage” or media properties panel against what ffprobe actually reported.
- Confirm your project frame rate matches your primary camera’s native frame rate, not a rounded assumption.
- Verify the project’s audio sample rate matches what your recorder actually captured.
- Watch for drop-frame versus non-drop-frame timecode flags on any 29.97 fps sources.
Once you’ve made a fix, run the long-play lip-sync test again: check the sync at the head, middle, and tail of the clip. A waveform spike that aligns across all three spots confirms the drift is gone. If it still creeps at the tail, the file wasn’t fully conformed and needs another pass.
Concrete Remediation Steps: Transcode, Resample, Realign
The right fix depends entirely on what your diagnostics turned up, so work through these in order rather than guessing.
- If ffprobe showed VFR (r_frame_rate and avg_frame_rate disagree), transcode to a constant frame rate using the declared fps from your probe output:
ffmpeg -i input.mov -fps_mode cfr -vf fps=30 -c:v libx264 -c:a aac output.mov. This forces every frame onto a fixed timing grid, which is what your NLE actually expects. - If the offset was constant everywhere in the clip, don’t transcode at all. Either slide the audio clip manually in your timeline to match the video, or apply an offset at the container level with
ffmpeg -itsoffset 0.5 -i audio.wav -i video.mov -c copy output.movadjusting the value to match the measured gap. - If sample rates don’t match your project standard, resample the audio rather than the video. A DAW generally handles this with higher-quality dialogue than a quick command-line pass, since dedicated resampling algorithms preserve more clarity than a default conversion. Command-line resampling
ffmpeg -i input.wav -ar 48000 output.wavworks fine for a rough pass, but it’s worth a second look in your audio tool of choice if the dialogue is going to a final mix. - If start_time values didn’t match between streams, try a remux before you commit to a full transcode:
ffmpeg -i input.mov -c copy -map 0 output.movis quick and lossless. If that doesn’t resolve it, a small nudge with-async 1during transcode can stretch or compress the audio slightly to match, though this should be a last resort since it alters playback speed by a small margin.
After any of these fixes, re-run the ffprobe check. Converted files should show matching r_frame_rate and avg_frame_rate values, both reading the same fraction. Follow that with one more long-play lip-sync test before you export anything downstream.
One caution worth flagging here: changing a clip’s frame rate inside your editor rather than through a proper transcode can generate new timecode and break externally synced audio, particularly on multicam projects where other clips are locked to the original timecode. Transcoding outside the project, or using frame interpolation deliberately, is safer than adjusting clip attributes inside the timeline and hoping sync holds.
| Symptom | Likely cause | Fix |
|---|---|---|
| Gap grows over the clip | Variable frame rate | Transcode to CFR with -fps_mode cfr |
| Gap stays constant throughout | Slate or start-point offset | Shift audio track or use -itsoffset |
| Dialogue sounds thin or pitched oddly | Sample-rate mismatch | Resample to project standard, ideally in a DAW |
| Streams report different start times | Mis-muxed file | Remux first; use -async 1 only if needed |
On-Set and Ingest Checklist to Prevent Future Drift
Every hour spent fixing drift in post is an hour that clock discipline on set would have saved. Jam-syncing timecode across all your recording devices before a shoot, or using genlock on multi-camera setups, keeps every device counting time from the same reference instead of its own drifting oscillator. Set every recorder and camera to 48kHz audio, note the frame rate on your shoot log for each camera body, and if you know dialogue matters, request constant frame rate capture rather than whatever power-saving default your camera or phone ships with.
Anything captured on a phone or with screen-recording software should be transcoded to CFR at ingest before it reaches your editing timeline. Build this into your ingest routine rather than treating it as a fix you apply later.
- Jam-sync or genlock your cameras and recorders before rolling.
- Standardize every audio device to 48kHz and log each camera’s frame rate.
- Transcode phone and screen-capture footage to CFR immediately at ingest.
- Run one quick ffprobe check and one long-play lip-sync test per source before editing begins.
Most drift traces back to mismatched clocks and sloppy conversions, and a five-minute ingest check catches nearly all of it before it costs you an afternoon later.
Pro Tip: Build the ffprobe check into your ingest script if you’re on a recurring production. Catching a VFR file before the editor ever opens it saves everyone downstream a repeat conversation.
When to Transcode Versus When to Work Around It
Transcoding every file to CFR the moment it lands on your drive is the safe default, and for long-form dialogue or anything heading to a paying client, it’s worth the render time. A drifting file that slips through review costs far more time to fix after the cut is locked than it does to transcode up front.
For quick turnarounds, like short-form cuts or heavy multicam sequences where you’re pulling three-second bites from dozens of angles, a full transcode pass on every source can be overkill. In that case, checking sync per excerpt as you cut is often faster than converting hours of footage you’ll never fully use.
Either way, the real fix isn’t a clever workaround. It’s adding one ingest step to your pipeline so the same file doesn’t cost you twice.
— Wake
How SoundBridge Handles Resampling and Final Sync Verification
Once your video is conformed to a constant frame rate, the audio side of the fix still needs attention, and that’s where a dedicated audio workstation earns its place in the pipeline. Native video support in some digital audio workstations lets you bring a picture directly into the session, so you can audition your resample or time-stretch against the actual locked footage rather than guessing.

If you’re resampling dialogue to match a project’s sample rate, high-quality time-stretching algorithms that preserve tone can yield better results than a quick command-line pass, with support for high sample rates when the source requires it. Export the corrected track and drop it back into your NLE for the final conform. Our guide to editing audio tracks walks through the resampling workflow step by step, and the Free Version is a solid place to start auditioning fixes before you commit to a paid tier.
FAQ
How to fix audio drift?
First, confirm whether the gap is constant or growing: run ffprobe to check if r_frame_rate and avg_frame_rate match. If they don’t, transcode the file to a constant frame rate; if the gap is constant everywhere, shift the audio track or apply an offset instead of transcoding.
Is 75ms audio delay noticeable?
A delay in that range sits close to what many editors and viewers can perceive as slightly off, though tolerance varies by person and content type. Rather than relying on a fixed threshold, run the diagnostic checks in this guide to determine whether the gap is constant or growing, since the fix differs in each case.
Does frame rate affect audio?
Frame rate itself doesn’t change audio, but a variable-frame-rate video file causes the video and audio tracks to drift apart because the video plays at inconsistent intervals while the audio runs on a steady clock. Small frame-rate mismatches, such as 23.976 fps versus 24 fps, can also accumulate into several seconds of drift over an hour of footage.
How to correct audio-video mismatch?
Diagnose the type first: a constant offset needs a simple audio shift, while progressive drift needs a transcode to a constant frame rate using a command like ffmpeg -fps_mode cfr -vf fps=30. After either fix, re-check with ffprobe and run a long-play lip-sync test at the head, middle, and tail of the clip to confirm the fix held.
Recommended
MASTER MUSIC PRODUCTION
Expert-led courses designed to take you from fundamentals to finished tracks.


