Syncitol resolves each clip's record-start time from the best available source — the media's embedded creation time / timecode, read directly by the bundled FFmpeg decoder. If a file carries none, it falls back to the file modification date minus the clip's duration. Every clip is then placed on a new timeline so the gaps between recordings match real clock time, and the audio is fine-aligned by waveform.

Tracks that were recording at the same time corroborate each other’s clocks, so they are laid out at their real offsets from one another rather than every track starting at 0:00 — which leaves the audio pass with a fine-tune instead of a minute-scale hunt. A track nothing corroborates (its recordings sit apart from everyone else’s, or its times come from the mtime fallback) keeps its own anchor and starts at 0:00 as before; one camera with a dead clock battery no longer costs the others their layout. The log names which tracks went which way.

Consistent timestamps are not automatically real ones. A bulk download from Google Drive or Dropbox rewrites every file’s date to the moment it arrived; a batch transcode or proxy render writes a fresh creation time into every file it makes; a camera with no clock set stamps them all identically. Each looks perfectly self-consistent. So Syncitol checks something none of them can fake: one device cannot record two files at once. If a track’s own clips claim to overlap each other in time, those timestamps are when something processed the files, not when they were shot — that track is excluded from the clock layout and flagged in the log. The check is per-device on purpose: genuine multicam really does have every camera starting within seconds of the others, and any test based on “these all start too close together” would throw exactly that away.

No external install required — the FFmpeg audio decoder ships inside the plugin. The Detected Clips table tags each row meta (embedded metadata) or mtime (file date). On the mtime fallback, preserve file dates when copying media — if the OS updates mtime on copy the sync will be off.

Audio envelopes are cached on disk, so re-running a sync on unchanged media is much faster. When Premiere's own waveform cache (.pek peak files) covers the media, the coarse alignment reads it directly — milliseconds instead of minutes, no audio decoding.

One click runs the whole pipeline hands-off: scan → build sync sequence → align (coarse whole-track + fine per-clip). Make your original sequence active first (not an already-built -SYNC — Auto Sync refuses those), then click Auto Sync. It stops with a clear message if a step can't proceed, and a ✕ Cancel button next to the spinner stops long audio scans at any time. When it finishes, the Sync Results table shows each track and clip's shift, the signal it matched on, and a confidence score.

Auto Sync aligns audio in two automatic phases. The coarse pass shifts each whole track to correct minute-scale clock offsets between devices. The fine pass then polishes every clip's position within ±5s via audio waveform cross-correlation, using a reference track — by default the one with the most recorded coverage, on any track. Only corrections larger than 20 ms are applied.

A coarse offset is a claim about a whole track made from a single clip, so it has to earn it. Any clip over 90s is probed at points spread across its whole length — not just its liveliest stretch — and the offset must hold at more than one of them. It is then re-tested against the other clips on the same track: if they agree with each other on a different offset, theirs is used instead; if they contradict it with no consensus between them, the track is left to the fine pass rather than moved somewhere confidently wrong. In the fine pass, any overlap longer than 120s is matched at both ends and the two must tell the same story — a music bed or a stretch of room tone can score beautifully at a position that is minutes out.

Afterwards the fine pass’s own results are read back as an audit of the coarse one. If most of a track failed to match, the log says so plainly — that is what a wrong coarse offset looks like. If several clips on a track all needed the same correction, that correction is also given to the clips on that track the fine pass could not match: they are one device carrying one clock error, and their track-mates are better evidence than leaving them behind.

The Audio reference dropdown in the Active Sequence card overrides that pick: choose any populated audio track (your field recorder, the main camera’s sound) and every other clip is aligned to the recordings on it. Auto is the default. A forced track that holds every clip in the sequence would leave nothing to align, so the panel falls back to Auto and says so in the log.

The list shows audio tracks only. Forcing a track really selects the files on it, and a camera clip’s picture and sound are one file — so V1 and A1 would pick exactly the same recordings. Auto still considers every clip whatever track it sits on.

Every clip of one source file moves as a single piece, so a camera’s picture and its own sound never come apart. Audio linked from a different file — merged clips, Synchronize, a manual Clip > Link — is detected by the span it shares with the picture and moved with it rather than synced separately; unlink it first if you want Syncitol to align it on its own. After every move the timeline is read back: anything that landed unevenly is nudged into line, and if that won’t take, put back exactly where it started — unsynced, but never torn. The log names whatever happened.

After Auto Sync, ↩ Revert (in Sync Results) undoes exactly the shifts the fine pass applied. On overlaps longer than 10 minutes the panel also checks for clock drift — devices whose clocks run at different rates — and warns with the measured drift (a single offset can't fix both ends; split long clips before syncing if flagged).

The Log at the bottom of the panel is the full record of a run. ⬇ Export .txt writes the whole thing to a file — send that with a bug report and the sync can be replayed from it.

Syncitol asks GitHub once a day whether a newer release exists and shows a banner at the top of the panel if so — dismissing it hides that version, not the next one. Clicking the version number in the footer checks immediately and reports either way; if the check can’t reach GitHub it just opens the releases page. Nothing else is ever sent or received.