Audio and Video Out of Sync After Converting? How to Fix It
Sound drifts after conversion? Learn to tell a constant offset from progressive drift, then fix audio video desync in your MP4 the right way.
You converted the file, pressed play, and knew within seconds: voices land a beat after lips move, or the music arrives before the action. Audio and video out of sync after converting is uniquely frustrating because the source was fine — the conversion broke the timing. Before re-exporting anything, spend two minutes on the diagnosis below.
Step one: constant offset or progressive drift?
Watch the first thirty seconds, note the gap, then check again at the ten-minute mark. That second data point identifies the problem:
| What you see | What it means | Typical cause | | --- | --- | --- | | Same gap at the start and at ten minutes | Constant offset | Wrong timestamps, or one stream delayed as a block | | Starts aligned, gap grows over time | Progressive drift | Streams of different lengths — usually variable frame rate mishandled |
A constant offset is one number: shift one stream by that amount and everything lines up. Progressive drift can't be fixed by any shift — the streams have different lengths. Different diseases, different medicine.
Why conversion causes desync
| Suspect | What happens | | --- | --- | | Container timestamps rewritten incorrectly | The converter wrote wrong start times, so both streams play correctly but begin at the wrong moment. | | Variable frame rate (VFR) treated as constant | Phone and screen-recording footage often stores variable frame rates. A converter assuming constant frame rate stretches frames while audio runs on real time — the gap widens as the video plays. | | The tool delayed the wrong stream | An offset meant for video was applied to audio (or vice versa), shifting one stream as a block. |
That VFR-to-constant case is the most common source of audio lag after conversion — phone and screen recordings drift; camera originals play fine.
Fix audio video desync in your MP4: two methods
Constant offset → shift one stream. If the sound runs half a second ahead of the picture, delay the audio by half a second. ffmpeg does it with -itsoffset:
ffmpeg -itsoffset 0.5 -i input.mp4 -i input.mp4 -map 0:v -map 1:a -c copy output.mp4
Video comes from the first input, audio from the second, delayed 0.5 seconds — both copied without re-encoding. A negative value shifts audio earlier instead; adjust in small steps until lips and voices meet.
Progressive drift → re-convert at a true constant frame rate. No shift fixes this; the streams need matching durations. Re-encode, forcing a frame rate close to the source's average:
ffmpeg -i input.mp4 -r 30 -c:v libx264 -crf 18 -c:a copy output.mp4
-r 30 writes a constant 30 fps timeline — pick the value nearest your source's average, commonly 30, 25, or 24. The video re-encodes once; audio copies through.
What conversion can and can't fix — honestly
Timestamps and container-level offsets — the constant-offset family — are usually fixable, often by remuxing with corrected timings alone. Frame-rate drift is fixable too, by re-converting onto a constant timeline. But drift baked into the source — the camera dropped frames while recording — can't be repaired: those frames never existed, and no converter restores timing that was never captured. Straight talk about our tooling: VideoFix has no dedicated desync-repair feature; the practical fix is redoing the conversion with the timing handled correctly.
Redo the conversion locally with VideoFix
The video converter runs ffmpeg entirely inside your browser, so the file never leaves your device. It accepts MP4, MOV, MKV, and M4V and outputs MP4 or WEBM, remuxing whenever the original codecs can be kept and transcoding only where they can't. Conversion costs 0.1 credits per minute; new accounts get a one-time 5 credits with no credit card, and packs run $4.99 for 50, $9.99 for 120, and $19.99 for 300 — one-time purchases that never expire, no subscription, no watermark. For a fuller walkthrough see convert video to mp4 online; if the problem is silence rather than timing, read video has no audio after converting.
Frequently asked questions
Why is the original file fine but the converted one out of sync?
Because timing lives in the container, not just the streams. The original's container holds timestamps both streams agree on, so players align them correctly. Conversion rewrites that container, and if the rewrite mishandles start times or frame-rate mode, synchronized streams end up misaligned. The content didn't change; the metadata did.
In my editing software the sync looks perfect, but the exported file drifts. Why?
Two different systems are at work. Inside the editor, playback is interpreted in real time by the editing engine, forgiving about imperfect timestamps. Export bakes the timeline into a file with its own timestamps — and if that pipeline mishandles a variable-frame-rate source or the timeline's audio latency, the file drifts even though the preview didn't. Fix it on the export or conversion side: force a constant frame rate and rebuild the audio as a standard codec.
Get the picture and the sound back in step
Diagnose first, then apply the matching fix. Rather than hand-crafting ffmpeg commands, re-run the conversion from the original source: open the video converter, drop in the file, and let a clean conversion rebuild the container's timing locally, at 0.1 credits a minute.