▣ shipped · re-measured · 3,267,201 samples, 8 kb shipped
The peak
Three cameras. Nobody clapped, nobody ran timecode, and each operator hit record when they felt like it. The only thing all three recorded in common was the room's sound — so the sound is what puts them back on one timeline. This page is the instrument: drag one camera against the anchor and watch the answer form under it.
00 — where these numbers come from
the arrays were never saved, so they were measured again
The sync run computed a GCC-PHAT cross-correlation for every clip and then threw the curve away. For each clip it kept two scalars: the lag of the maximum, and a peak-to-median confidence ratio. There is no correlation array anywhere in that project, so drawing one and calling it the pipeline's output would be a fabrication.
What you can drag below was instead re-measured from the original source
audio, with a script that ships alongside the data
(recompute_gccphat_peak.py — mono at 8 kHz,
PHAT-whitened cross-power, inverse FFT, deterministic). It is a fresh, independent pass
over the same sound the pipeline heard. And it agrees:
- stored by the pipeline
- +13.708 s
- re-measured, independently
- +13.7263 s
- they disagree by
- 0.0183 s
0.018 s is under one frame at 24 fps. the lock is real twice over.
One consequence to state before you touch anything: the curves below are normalized so the true peak is exactly 1.0. That is a choice of axis, not a measurement — the raw GCC-PHAT peak is 0.014567, because PHAT peaks are numerically tiny. The pipeline's own quality number is a ratio, not a height: peak over median, 46.6 on this pair.
01 — the instrument
slide one camera until the room agrees with itself
The top lane is the anchor's sound — the Centre camera, C0008. The bottom lane is Camera A, C0281,
and it starts wherever you put it. Underneath, the correlation: for every candidate
offset, how much the two recordings of the same room look like each other. You are not
computing it — it was computed once, over every offset at once. You are reading it.
the whole search · ±204 s · max-pooled envelope, 800 of 1,600 bins · normalized, peak = 1.0
the same curve, ±3 s around the answer · full resolution · same normalization
The nearest rivals on this pair are real and unimpressive: −45.37 s at 0.26, +14.74 s at 0.25, +22.87 s at 0.24, +4.58 s at 0.24. Across the 64 clips that locked in this performance the peak-to-median confidence ran from 25.8 to 352.6, median 105, against a threshold of 25. Those are the measured numbers, and they are the ones on the page.
02 — the wrong answers
confidence is not correctness
This pair locked cleanly. Others did not, and they did not fail quietly — they failed with high confidence, because the song under the whole evening repeats, and a repeating signal correlates beautifully with itself one loop away. Every row below is a real lock from the run, all of them well over the threshold, all of them landing before the anchor even started recording:
| clip | camera | offset | confidence |
|---|---|---|---|
| C0509.MP4 | Camera B | -185.746 s | 140.1 |
| C0494.MP4 | Camera B | -164.840 s | 132.8 |
| C0496.MP4 | Camera B | -127.357 s | 124.6 |
| C0493.MP4 | Camera B | -188.677 s | 117.8 |
And this is where the number people remember comes from. It is not a peak. Nothing sits at 141 seconds on any curve. It is the distance between two answers — how far wrong a confident lock can be:
+13.708 s − (-127.357 s) = 141.065 s
the true lock, minus a real wrong one (C0496.MP4, confidence 124.6) — 141 seconds of error carried by a number that looked fine. the fix was not a better correlator; it was refusing any lock that lands outside the window the anchor was actually recording. the long version.
03 — what the peak buys
three cameras, one instant
These three files are uncorrected. Each was cut from its own camera's native start and nothing was applied — which is why they disagree. Put them on one real-world playhead G and the whole act is one subtraction: file time = G − offset. Switch between the two states and watch the room stop being three rooms.
offset 0.000 s · file time —
offset +13.708 s · file time —
offset +32.658 s · file time —
g is constrained to [32.658, 53.258] — the 20.6 seconds where all three cameras have footage at once. camera b is the short clip and it is what sets that window. in as recorded each file plays from its own zero, which is what a folder of camera cards gives you.
The offsets on those captions are the ones in
angle-offsets.json, and GCC-PHAT re-run on
these exact encoded files returns +13.726 s and +32.659 s — non-zero, i.e. the media really is out of sync, and the build asserts the page's
numbers against that file so the two can never drift apart.