Audio Out of Sync After Recovery — How to Fix It

You've recovered a corrupted file. The video plays. The audio plays. They just don't line up. Either the audio is offset from the picture by a fixed amount (often around half a second), or it starts in sync and drifts over the course of the recording.

This page explains both patterns and how to fix them.

Pattern 1: fixed audio offset (~0.5 s)

This is the single most common audio sync problem in recovered MP4 / MOV files. The audio starts about half a second before or after the picture and stays that way for the whole recording.

The cause is almost always audio chunk placement during the rebuild. In MOV / MP4 interleaving, audio chunks sit alongside video chunks inside mdat. Where the audio chunk lands relative to the video chunk in each group matters: placed after the video chunk in its group, audio drifts ~0.5 seconds late; placed at the start of the group, sync is correct.

This bites Atomos / Ninja / Shogun files in particular — those units write a specific chunk-placement pattern that some recovery tools mis-handle. We learned this on a Ninja V firmware, ran a regression test, and now place audio chunks at the start of their video group by default.

Quick fix in your editor: nudge the audio track 0.5 s earlier (or later, depending on direction of offset) and the sync usually snaps. Premiere: select audio track, alt-drag. Resolve: timeline shift. The offset is constant across the whole file, so a single nudge fixes it.

Better fix: regenerate the recovery with corrected chunk placement. If you used our service, escalate the case and ask — it's a single parameter and the rerun is free.

Pattern 2: audio drifts over time

Audio starts in sync and progressively drifts. By minute 10 of a 30-minute take, it's a couple of seconds off; by minute 30 it's an obvious mismatch.

This is a sample rate mismatch. The audio's actual sample rate (e.g. 48,000 Hz) doesn't match the rate declared in the rebuilt container (e.g. 44,100 Hz). The player decodes the audio at the wrong speed, so each second of audio takes slightly less or more time than it should, and the offset grows.

Cause: during recovery, the audio header was missing or damaged. The recovery tool guessed a rate and got it wrong.

Fix: re-import the file specifying the correct sample rate. In FFmpeg:

ffmpeg -i recovered.mp4 -c:v copy -c:a pcm_s24le -ar 48000 corrected.mov

(Replace 48000 with the actual rate. Check your camera's audio menu to confirm — most modern cameras default to 48 kHz; some older ones use 44.1 kHz.)

If you used our service, escalate the case and provide the correct sample rate; we'll regenerate.

Pattern 3: audio is in sync at the cut points but not in between

Less common but recognisable: audio is sync at the start, sync at the end, sync at every visible cut, but drifts within each shot. Usually means the recording was variable-frame-rate (VFR) — the camera shot at a notional frame rate but actually wrote frames at slightly varying intervals — and the recovery converted to constant-frame-rate (CFR) without re-timing the audio.

Most camera footage is CFR. Phone footage is the common exception: iPhones and Android phones often record VFR. If you're recovering phone footage and seeing this drift, that's why.

Fix: re-export the recovered file with VFR preserved:

ffmpeg -i recovered.mov -c copy -vsync passthrough corrected.mov

If that's still wrong, the underlying timestamps in the codec stream have been damaged and the only reliable fix is re-timing per-shot in your editor.

Pattern 4: audio sounds like static

Distinct from sync: audio plays at the right time but sounds like white noise. This is usually endianness — most commonly with Atomos and other external recorders that write little-endian 24-bit PCM. Generic recovery tools that swap bytes unconditionally produce static; correct recovery detects endianness from the data.

See /fix/atomos-ninja-recording-stopped for the Atomos-specific version.

How to figure out which pattern you have

Play the file and watch the lips:

How our recovery handles these

The audio probe pass detects:

• Endianness by sampling the data and checking which interpretation has plausible distribution. We don't swap unless the data tells us to.
• Sample rate from chunk-size dominance — most chunks have a size driven by the actual rate; outliers are filtered.
• Channel layout from correlation analysis (mono / stereo / 5.1).
• Chunk placement based on the camera's writing pattern.

For the cases where we get one of these wrong on the first pass, the escalation flow lets you tell us the symptom and we rerun with the right parameter. No charge for reruns.

What you do

If your recovery is from us:

1. Escalate the case from your job page. Tell us which pattern you're seeing.
2. We rerun with corrected parameters. No charge.

If your recovery is from elsewhere:

1. Upload the original broken file. We'll redo the recovery with correct audio handling. Free preview before any payment.

FAQ

Why didn't the original recovery get audio sync right? For a clean file, audio sync is unambiguous. For a recovered file, the metadata that tells the player how to interpret the audio is partly missing — the recovery has to infer it. Smarter inference is the difference between tools.

My audio is fine in some players and out of sync in others. Most likely a metadata flag a strict player (Premiere) interprets but a permissive player (VLC) ignores. Re-mux with FFmpeg to clean up the metadata.

Can you re-export just the audio, not the video? Yes — escalate the case and ask. We can return audio-only as a WAV / AAC if that's more useful for you.

Is my footage safe? Server in France, auto-deleted after 48 hours, never used to train anything or shared. Privacy policy.

Related

• Atomos Ninja recording stopped
• Video plays but no audio
• How our recovery engine works

Upload your file →