Audio sync calculator
Which signal to move, which way, and by how much.
Say whether the sound arrives before or after the picture, and by how much: in frames, milliseconds, samples or a timecode duration. Or enter where a flash and its blip land on your timeline, two measurements to tell a fixed offset from drift, or the delays along a signal chain. You get the correction as an instruction, the same offset in every unit, a check against the EBU R37 tolerances, and the steps in FFmpeg, OBS, Premiere Pro or Resolve. Everything runs in your browser, and a result can be shared as a link.
What you see and hear
Enter the size of the offset. Direction is set above.
The fix
Audio is 3 frames early.
Delay audio by 120 ms (5,760 samples).
Or move picture earlier by 3 frames (120 ms).
The settings travel in the link itself; nothing is stored.
The same offset in every unit
| Frames | 3 | at 25 fps |
|---|---|---|
| Milliseconds | 120 | |
| Seconds | 0.12 | |
| Samples, exact | 5,760 | at 48 kHz |
| Samples, nearest whole | 5,760 | no rounding |
| Frames, nearest whole | 3 | no rounding |
| Timecode duration | 00:00:00:03 |
≈ marks a rounded display; the maths behind it is exact. A sample delay can only be set in whole samples, so the nearest whole value is what a delay line will actually apply.
Against a tolerance
Allows audio up to 40 ms early and 60 ms late.
Outside tolerance 120 ms early is 80 ms past the 40 ms limit for early audio.
Reference guidance from EBU R37-2007, Table 1. The specification you were commissioned against takes precedence.
Do it in your app
- Delay the audio. Either re-encode it through adelay, which is sample-exact:
- or keep both streams untouched and offset a second reading of the file. A positive -itsoffset delays every stream of the input it precedes, so map only the audio from that one:
ffmpeg -i in.mov -c:v copy -af "adelay=delays=5760S:all=1" -c:a pcm_s24le out.movffmpeg -i in.mov -itsoffset 0.12 -i in.mov -map 0:v -map 1:a -c copy out.mov- Pick the audio codec your delivery needs in place of pcm_s24le; adelay output has to be encoded.
Checked against: FFmpeg documentation: -itsoffset · FFmpeg filters: adelay.
Flash-and-blip test clip
A 10-second clip at 25 fps with 48 kHz sound: a one-frame white flash and a one-frame 1 kHz tone at −18 dBFS together, about once a second, as EBU R37 describes. Play it through the chain you’re checking, record the result, and read the flash and blip positions into Flash and blip above.
Opens in QuickTime Player, VLC, FFmpeg and editing applications; web browsers can’t play it. Every frame rate and sample rate here is checked with FFmpeg: each blip starts on its flash frame, within one sample of the frame’s start.
Why the answer is a sentence, not a number
A sync offset written as “−3” means opposite things in different places. ITU-R BT.1359 counts sound before picture as positive; many editing applications show a clip slipped later as positive. A naked sign is how a 3-frame error becomes a 6-frame one. So this tool asks which way the sound is off, in words, and answers in words: delay audio, or advance it.
Exact rates at 23.976, 29.97 and 59.94
These rates are exactly 24000/1001, 30000/1001 and 60000/1001 frames per second. One frame at 29.97 lasts 1001/30000 s, which is 33.3666… ms, and at 48 kHz exactly 1,601.6 samples. The calculator keeps every value as an exact fraction, so a long offset doesn’t drift the way it would with 33.37 ms per frame. Where a result falls between samples it shows the exact value, the nearest whole sample a delay line can actually apply, and the difference.
Drop-frame doesn’t change the maths
Drop-frame timecode at 29.97 and 59.94 skips frame labels (two, or four at 59.94, at the start of most minutes) so the timecode keeps pace with the clock. No frames are dropped, and every frame lasts exactly as long as in non-drop. For an offset of a few frames the two labellings agree; they only differ for durations that cross a minute boundary, which is why the drop-frame box is there for timecode input.
EBU R37 tolerances
EBU R37-2007 sets two limits. Each stage of production should keep sync within 5 ms early to 15 ms late. At any output intended for emission, the end-to-end offset should be no more than 40 ms early or 60 ms late. Both are lopsided because early sound is the more noticeable: in life, sound never reaches you before the light. Note that one frame at 25 fps is already 40 ms, so the per-stage limit can only be met by correcting in milliseconds or samples, not whole frames.
R37 also recommends measuring with flash-and-blip markers: a one-frame white flash with a one-frame 1 kHz tone at alignment level. The test clip above is exactly that, made in your browser at your frame and sample rate. The leader & clock builder can add a sync plop to a programme leader for the same job. Keep audio and video coincident in the file, rather than offsetting them to suit a later stage. See also ITU-R BT.1359 on relative timing of sound and vision for broadcasting.
A fixed offset, or drift?
A fixed offset is the same all the way through, and one slip fixes it. Drift grows: sound and picture ran on clocks at slightly different speeds, so a slip that fixes the start breaks the end. Measure near the start and near the end. A change of more than a frame is drift, and the rate usually names the cause: about 1,000 ppm (3.6 s an hour) is a 0.1% pull-down mismatch, such as 23.976 against 24 or 48 kHz audio treated as 48.048 kHz; a few tens of ppm is two devices that never shared a clock. The fix is a speed change, which the calculator gives exactly.
Related: timecode calculator · frame rate & runtime · audio track layouts · leader & clock builder.