How do you turn a BPM into milliseconds for a delay, and how exact does the BPM have to be?

The formula and the note values

BPM counts beats per minute, and a minute is 60,000 milliseconds, so one beat is 60000 ÷ BPM milliseconds. In 4/4 the beat is a quarter note and a bar is four beats. Everything else is a multiple of the beat:

For an LFO or tremolo that asks for a rate in Hz instead of a time, divide 1000 by the milliseconds: a beat at 120 BPM is 2 Hz, a bar 0.5 Hz, an eighth 4 Hz.

BPM to ms table, 60 to 200 BPM

Every 5 BPM, with 128 and 174 added. For a tempo in between, use 60000 ÷ BPM for the beat and the multipliers above.

How exact does the BPM have to be?

A delay set from a slightly wrong tempo does not sound wrong on the first repeat; the error adds up across repeats and across bars. The table shows how far one step of BPM moves the beat. Faster tempos are more forgiving in ms, because the beat is shorter.

So a reading to 0.1 BPM, which is what this site's finder prints, pins a delay to within about half a millisecond per beat anywhere above 100 BPM. Whether the song itself holds its tempo that steadily is a separate question: a live recording that drifts by a few BPM moves the grid by far more than the reading's rounding.

How we tested

• Tool: this site's BPM finder, the real page run on a local copy in Chromium 153 through Playwright 1.63 (headless), on 2026-10-21.
• 15 drum tracks we made (30 s, 44.1 kHz, 16-bit mono WAV): a kick on every beat and a hi-hat every half beat, placed at exactly 60000 ÷ BPM ms, at 60, 72.5, 90, 100, 117.3, 120, 123.4, 127.5, 128, 133.3, 140, 150, 160, 174 and 200 BPM. We copied the main reading, the half or double reading and the "other tempos" line for each.
• Click spacing: before pressing Play with clicks we wrapped the browser's oscillator start call so our script saw the exact time the page scheduled each click, then compared the gaps with 60000 ÷ the printed BPM.
• Tap tempo: our script pressed the T key 17 times at a target spacing (1000 down to 300 ms) and recorded, inside the page, the moment each key arrived, so we could compare the page's reading with the spacing it really received rather than the one we asked for.

What the finder read, and what that does to the delay

Each row is one test track. "Beat from reading" is 60000 ÷ the printed BPM, the number you would type into a delay.

Eleven of the fifteen printed the tempo we built in, to the decimal, including 117.3, 123.4, 127.5 and 133.3. The four that did not were the half, double and two-thirds readings described in why the same song shows different BPMs, and in each case the true tempo was on the page too, as the second reading or in the "other tempos" line.

What matters for a delay is that none of those four gave a time that fights the song. Half or double the tempo gives a delay of twice or half the beat, which is still a note value: a half note or an eighth. The two-thirds reading (116.0 for 174) gives 517.24 ms, which is a dotted quarter at 174 BPM, a common delay choice in its own right. It only becomes a problem if you then pick an eighth or a triplet from the wrong row of the table, so check which reading you are on with Play with clicks before you multiply.

Play with clicks: does the page keep to the formula?

Yes. On all 15 tracks the clicks were scheduled at a constant spacing, and that spacing was within 0.043 ms of 60000 ÷ the printed BPM. The small differences come from the page keeping more decimals of the tempo than it prints: for the 120 BPM track the clicks were 499.968 ms apart, which is 60000 ÷ 120.0078, and the page printed 120.0. If the clicks sit on your song's beat, the printed number is the one to use.

Tap tempo: from a spacing in ms to a BPM

Tap tempo is the formula run backwards: the page divides the time from the first tap to the last by the number of gaps. Our script could not press a key at exactly the moment it meant to, and the page recorded when each press really arrived, so the fair comparison is the reading against the spacing it got.

In every run the printed BPM was within 0.052 of the BPM worked out from the taps the page actually received, which is the 0.1 rounding of the display. Single taps that landed up to 27 ms early or late did not move the result, because the page only uses the first and last tap and the count. The one run that missed its target, 128.3 for 128, missed because our presses arrived 1.26 ms too close on average, not because of the page; even so, the delay from 128.3 is 467.65 ms against 468.75, 1.1 ms per beat and 4.4 ms per bar.

Steps

1. Open the BPM finder and drop in the song, or press Tap and tap along, or Start listening with the song playing out loud.
2. Press Play with clicks. If the clicks fall on every other beat or twice per beat, switch to the second reading. Keep the one that matches how you count the song.
3. Divide 60000 by that BPM for the beat in ms, or read the row from the table above, and multiply by the note value you want: ½ for an eighth, ¾ for a dotted eighth, ⅓ for an eighth triplet.
4. For a rate in Hz, divide 1000 by the milliseconds.

Questions

The finder shows two readings. Which one do I use for the delay?

Either keeps you on the grid, because one is exactly twice the other: an eighth note at the lower reading is the same time as a quarter at the higher one. Use the reading whose clicks match how you count the song, so that the note names in the table mean what you expect.

My delay drifts out of time after a few bars. Is the reading wrong?

Possibly, but check the song first. A reading to 0.1 BPM is worth under half a millisecond per beat above 100 BPM, which takes many bars to hear. A song that was not recorded to a click can move by a few BPM between sections; the finder says "The tempo seems to change" when its sections disagree, and then no single delay time will stay locked.

Does the formula change in 3/4 or 6/8?

60000 ÷ BPM always gives the length of whatever the BPM counts. If the tempo marking counts quarter notes, the table applies as is and a bar of 3/4 is three beats, not four. If it counts dotted quarters, as 6/8 is often written, the "beat" column is the dotted quarter and an eighth is a third of it.