The Drop · August 24, 2026

Beat sync video maker: what synced actually means

Every beat sync video maker promises cuts that land on the beat. None of them land on the beat, because the beat is an instant and a video is a stack of frames. Here is where the milliseconds actually go, and how much slop you get before anyone notices.

Photo via Unsplash

Synced is a window, not a moment

The useful number here is old and it comes from broadcast, not from music. ITU-R Recommendation BT.1359-1 collects subjective tests run in Japan, Switzerland and Australia on how far sound and picture can slide apart before a viewer clocks it. The finding, in its own words, is that "the thresholds of detectability are about + 45 ms to -125 ms and thresholds of acceptability are about +90 ms to -185 ms on the average", where a positive value means sound is advanced with respect to vision.

The range between those just detectable limits is about 170 milliseconds wide, and the document calls the middle of it an undetectability plateau. There is no single correct instant in there. Anything inside the plateau reads as together.

The two sides are not the same size, and that is what matters for a visualizer. Sound arriving 100 ms late is unremarkable. Sound arriving 50 ms early is already detectable. In the world, light reaches you before sound does, so a picture running slightly behind its audio is the arrangement your ears have never once complained about.

The bad news is which side we are on

A beat detector is reactive. It cannot flash on a kick drum it has not heard yet. Every millisecond of processing pushes the picture later, which is sound advanced with respect to vision, which is the strict side. So the working budget is not 170 milliseconds. It is roughly the 45, and the whole job is fitting inside it.

Where the milliseconds go

Two sources, both measurable, both unavoidable in a browser.

The analysis window. Frequency data comes from an analyser node, and MDN defines its fftSize as "the window size in samples that is used when performing a Fast Fourier Transform (FFT) to get frequency domain data". This app sets that to 512. At a 44.1 kHz file, 512 samples is 11.6 milliseconds of audio. The reading describes a slice that has already happened. Smoothing sits on top of that, kept low here at 0.3 rather than the usual 0.8 to keep onsets sharp.

The frame boundary. Nothing gets drawn between frames. At 60fps a frame is 16.67 milliseconds, so a flash detected anywhere inside that gap lands in the same place: the start of the next frame. That is the floor under every browser visualizer.

Add the two and a typical flash lands under 30 milliseconds behind the transient that caused it. Inside the 45, with real but not generous headroom, which is why the honest answer to "how tight is it" is a range rather than a number. The beat detection post covers what the detector is doing inside that window.

One more limit, not an error but it shapes the result: a hard 90 millisecond floor between flashes. About eleven a second, maximum, whatever the drummer does.

The flash does not drift. The content grid does.

This is the distinction that decides how a long render holds up.

The flash is retriggered by the audio every single time. Each one is independently late by its own small amount, and those amounts never add up, because the next flash starts fresh from the next transient. Ninety seconds in, the flashes are as tight as they were at the top.

The images, text lines and shapes swap on a clock instead, and the clock is the detected tempo: 60000 divided by the BPM, times the change rate you picked. That target interval then gets rounded up to the next frame, because frames are the only moments that exist.

Do the arithmetic on a normal case. At 128 BPM the default Every 1/4 beat asks for a change every 117.19 milliseconds. At 60fps, seven frames is 116.67 and eight frames is 133.33. Seven is a hair too early, so you get eight, and eight is 14 percent long. The content is now swapping at a rate that belongs to 112.5 BPM. Unlike the flash, that error repeats every interval and accumulates, so by the end of a three minute track the picture rhythm and the music have parted company completely.

Two useful things follow:

• Slower change rates are proportionally tighter. The rounding is always the same fraction of a frame, so it costs less over a longer interval. At 128 BPM the default 1/4 beat is 14 percent out and Every 1 beat is about 3 percent out, which is the same setting doing four times better.
• Some tempos land clean. 150 BPM at Every 1/4 beat is exactly 100 milliseconds, exactly six frames, no rounding at all. 112.5 BPM is exactly eight.

A drummer versus a bounced loop

Tempo detection happens once, offline, when the file loads. The app scans the first minute, builds an energy envelope, and correlates it against every candidate from 60 to 180 BPM in half BPM steps. What comes out is one number for the whole track.

Bounced from a DAW at a fixed tempo, one number is the truth for the full length. For a band playing live it is an average: the drummer pushes into the chorus and pulls in the verse, the grid does not follow, and the swaps wander in and out of phase even though the reading was right. The flash does not care either way, because it never consulted the grid. So on live material, set the content rate slow, or switch to the legacy every N flashes mode, which advances on detected beats instead of on the clock.

What actually breaks it

All of the above assumes frames are arriving. Two ways they stop.

The recording is real time. The canvas is captured as a stream at 60 frames a second, and per MDN that frame rate argument "indicates the rate of capture of each frame". If the page cannot render 60 a second, the capture takes what is there, and every dropped frame is a flash that lands late or not at all. Heavy overlay settings on a slow machine are the usual cause.

The bigger one: the animation loop is throttled to nothing when the tab is not visible. Audio keeps playing, so you get a full length audio track over a frozen picture. Not a sync problem, a no-picture problem. Keep the tab in front for the length of the song.

After that the timing is baked into the file. The export guide covers getting that WebM into whatever format a platform wants, which is a container change and does not touch the sync.

The short version

1. There is no exact instant. Published broadcast testing puts the detectable window at roughly 45 milliseconds on one side and 125 on the other.
2. A reactive detector always lands on the strict side, so budget against the 45.
3. An 11.6 millisecond analysis window plus a 16.67 millisecond frame boundary is the real cost, and it fits.
4. Flashes do not accumulate error. Clock driven content swaps do.
5. Slower change rates round better. Every 1 beat is roughly four times tighter than Every 1/4 beat.
6. Bounced-at-a-fixed-tempo audio holds the grid. Live playing does not.
7. Keep the tab focused while it renders, or the picture stops and the audio does not.

No timeline, no plugin, no account. Load a track in the browser, read the tempo it prints, and let the arithmetic do the dragging.