How to sync external audio to video without a clapper

Why the clapper disappeared (and what replaced it)

A clap does two jobs: it gives every recording device one sharp, simultaneous transient, and it labels the take. On small crews — one shooter, a sound bag, three interviews before lunch — nobody slates. Fortunately the clap’s technical job can be done better by metadata and mathematics. Three mechanisms, in descending order of robustness:

1. File timecode — every file carries a matching clock stamp in its metadata.
2. LTC on an audio track — the clock rides inside one of the camera’s audio channels.
3. Waveform matching — the camera’s scratch audio is mathematically matched against the recorder’s audio.

A serious sync workflow uses them in that order: trust timecode where it exists, decode LTC where it is hiding, and fall back to (or refine with) waveform analysis everywhere else.

Route 1: file timecode — the BWF/iXML way

If cameras and recorder were jammed to a common clock, every file already knows when it started. The details differ per format, and knowing where the stamp lives helps you debug mismatches:

• Sound rolls are almost always Broadcast Wave (BWF). The start time lives in the bext chunk as a time reference: the number of samples elapsed since midnight. At 48 kHz, a stamp of 1,728,000,000 means the file started at 10:00:00 exactly. Alongside it, an iXML chunk usually carries scene, take, tape/sound-roll name, frame rate, track names and the sample rate the timestamp assumes. For a field-by-field tour of both chunks, see BWF and iXML metadata explained.
• Camera files carry start timecode in container metadata — a tmcd track in QuickTime/MP4, sidecar XML on some professional cameras, MXF metadata on others.

Matching is then arithmetic: a camera clip starting at 14:32:07:18 overlaps a sound roll starting at 14:31:50:00, so the sound file is placed 17 seconds and 18 frames into its duration, and the overlap becomes a synced pair. Three things to respect:

• Frame rate context. The same wall-clock instant produces different frame numbers at 25 and 29.97 fps, and drop-frame counting changes the mapping again. A TC match must convert both sides through their declared rates — naive string comparison of HH:MM:SS:FF fails quietly.
• Sample-count vs frame-count truth. The BWF time reference is sample-precise; camera TC is frame-precise. The recorder knows its start to 1/48,000 s, the camera only to 1/25 s. The residual half-frame belongs to the camera side.
• Overlap is the test, not equality. Files never start at the same moment. Any camera clip whose time range intersects a sound file’s time range on the same day is a candidate pair; duplicated time-of-day across multiple shoot days is why files must first be bucketed by recording date.

Where it fails: devices that were never jammed (or re-jammed after a battery swap), one device set to the wrong frame rate or DF/NDF mode, cameras whose internal clock quietly resets, and time-of-day rollover at midnight. Timecode is also only frame-accurate — expect up to half a frame of residual offset even on a perfect match.

Route 2: LTC on an audio track

Cameras without timecode inputs — mirrorless bodies, action cameras, many drones — can still carry the clock: feed LTC from a sync box into one audio channel and decode it in post. The picture file’s metadata TC stays meaningless, but the audio channel contains a sample-accurate record of the master clock. This route is robust enough that whole productions run on it; its failure modes (low level, AGC, lossy codecs, bleed) and the decoding process are covered in depth in our guide to how LTC timecode actually works.

Once decoded, an LTC-stamped clip behaves exactly like a file-timecode clip in Route 1 — with the bonus that the decoded stamp is anchored to an audio sample, not just a frame boundary.

Route 3: waveform matching

No timecode anywhere? If the camera recorded any audio of the scene — even a poor on-board scratch mic — the camera track and the recorder track contain the same acoustic events. Cross-correlation finds the offset at which the two waveforms agree best: conceptually, slide one recording against the other and score the overlap at every possible offset; the true sync offset produces a sharp, unambiguous peak.

Practical realities that decide whether the peak is sharp or mush:

• The scratch mic matters. It can be noisy and tinny, but it must actually hear the scene. A camera 30 metres from the subject records mostly its own surroundings plus room reverb, and the correlation broadens or locks onto an echo.
• Speech and transients are ideal. Consonants, door slams and footsteps produce distinctive patterns. Continuous broadband noise (traffic, wind, air conditioning) correlates weakly everywhere.
• Repetitive audio is a trap. Music playback on set, a metronome, looped announcements — anything periodic produces multiple near-equal peaks, and an automatic matcher can confidently pick the wrong one. These clips need human eyes.
• No camera audio, no match. Drones and cameras with audio disabled simply cannot be waveform-synced. They need Route 1, Route 2, or manual placement against action.

Done well, waveform sync is sample-accurate — tighter than timecode — which is why the strongest workflows use timecode to find the coarse pairing and the waveform to refine the final alignment.

Multicam: same problem, more devices

With several cameras plus a recorder, sync becomes a grouping problem: which clips belong to the same real-world moment? Timecode answers this directly — overlapping time ranges define the group. Without timecode, each camera’s scratch track is matched to the recorder’s audio, and the recorder becomes the hub that transitively aligns cameras that never heard each other clearly. The output your NLE wants is a multicam group (a multicam clip in Premiere or Final Cut terms): all angles plus the sound roll, aligned on a common timeline, with angles named consistently (A-cam, B-cam, drone) so the editor can cut between them immediately. How groups travel inside FCPXML and Premiere XML is covered in the editor package guide, and building the group in Resolve specifically is covered in multicam sync in DaVinci Resolve.

Drift: the failure that arrives late

Getting the start of a clip in sync is half the job; staying in sync to the end is the other half. Two clocks are involved in every device — the timecode clock and the audio sample clock — and on cheap hardware neither is exact.

Numbers worth knowing:

• A sample clock off by 10 ppm drifts 0.6 ms per minute — inaudible on a 3-minute take, a visible lip-sync error (>40 ms) after about an hour.
• A consumer camera off by 50–100 ppm drifts 3–6 ms per minute: a one-hour ceremony recorded in a single take ends 180–360 ms out of sync even though it started perfectly.
• The classic 48,000 vs 48,048 Hz mismatch (0.1%, from pull-down workflows) drifts 60 ms per minute — unmistakable within two minutes.

Diagnosis is straightforward: align the head of the clip, then check the tail. If the tail is out by a consistent amount proportional to duration, it is clock drift, and the fix is a tiny speed adjustment (resampling the audio by the measured ratio), not a re-sync. If the offset jumps at some point mid-clip instead, look for a dropped-frames event or a file-spanning boundary, not drift.

Which route when: a field guide

Verify before you deliver

Whatever made the match — metadata or mathematics — verification is the same, and it is not optional on paid work:

1. Spot-check heads and tails. Play the first and last 10 seconds of the longest clip in each group with both tracks audible. Phasing/flanging between scratch and recorder audio means you are within a few milliseconds; a distinct echo means you are not.
2. Watch one plosive. Find a “p” or “b” in close-up. Lips closed on the consonant, audio hit on the release — the eye catches a one-frame error faster than the ear.
3. Distrust unanimous silence. A sync pass that reports zero problems across a full shoot day deserves suspicion. Real days contain a camera that was never jammed or a clip with no usable scratch audio; a tool (or an assistant) should tell you which clips were matched by which method, at what confidence, and which remain unmatched — that document is the sync report, and it belongs in the editor handover.

Where Launchr Post fits

Launchr Post runs exactly this hierarchy on your machine: it pairs by file timecode first (BWF time reference, iXML, camera metadata, all converted through their declared frame rates), decodes LTC where a camera carries it in an audio track, refines every match to sample accuracy against the waveforms, groups multicam angles, and measures drift on long takes. The output is a synced, sorted, transcribed shoot day plus a per-clip sync report stating how each match was made — so the verification step above takes minutes, not the afternoon.