Every sample browser that shows a BPM column has to get the number from somewhere. Sometimes it is in the filename (drum_loop_120_Am.wav), sometimes it is stored in the file, and often it is estimated from the audio. This article covers the estimating: what a tempo detector listens for, why it makes the mistakes it makes, and how to check a reading quickly.
SampleStack detects the tempo of loops automatically. The BPM and pitch detection page covers how that works in the app. The ideas here apply to any tool that shows a detected BPM.
Step one: find the onsets
A tempo detector does not hear beats. It hears changes. The first stage, onset detection, scans the audio in short frames, typically 10 to 20 ms each, and measures how much each frame differs from the one before.
The simplest measure is energy: a kick drum makes a frame much louder than the silence before it. Energy alone misses hi-hats over a sustained bass note, though, so most detectors use spectral flux instead. Spectral flux splits each frame into frequency bands and adds up how much each band got louder. A hi-hat raises the top bands sharply even when the overall level barely moves, so it registers as an onset.
The output is an onset strength curve: a line that spikes at every hit. On a clean drum loop it looks like a comb. On a pad it looks like gentle hills.
Step two: find the spacing
With an onset curve in hand, the detector looks for the spacing that repeats. The standard tool is autocorrelation: compare the curve with a copy of itself shifted by some delay, and score how well the spikes line up. Try every delay in a sensible range and the best scores mark the spacings that recur.
A drum loop at 120 BPM has a beat every 500 ms. Shift the curve by 500 ms and the kicks land on kicks and the snares land on snares, so the score is high. Shift by 250 ms and the hats line up with hats, so that score is high too. Shift by 1,000 ms and every other beat lines up, also high.
Converting a winning delay to BPM is one division: 60 divided by the delay in seconds. 0.5 seconds gives 120 BPM.
Step three: pick one
The autocorrelation step returns several good candidates, and they are almost always related by factors of two. For the 120 BPM loop, delays of 250, 500, and 1,000 ms all score well, which corresponds to 240, 120, and 60 BPM. The audio fits all three. Choosing between them is a judgement about what a person would tap along to.
Detectors make that judgement with a prior: a weighting that favours the range most music sits in, roughly 80 to 160 BPM. Inside that range the prior picks correctly most of the time. Outside it, the prior pulls the answer toward the middle:
- Drum and bass at 172 BPM often reads as 86.
- Half-time trap at 70 BPM, with hats running at 140, often reads as 140.
- Slow ambient material at 60 BPM can read as 120.
These are called octave errors, and they are the most common way BPM detection goes wrong. The detector found the right pulse and reported the wrong multiple of it. Fixing one is a matter of doubling or halving the number.
Using the file’s length
Sample-pack loops have an advantage that a full song does not: they are usually cut to an exact number of bars. That makes the length of the file a second source of tempo, independent of the audio.
In 4/4, a loop of b bars at tempo T lasts b × 4 × 60 / T seconds. Turn it around and a 2-second loop could be one bar at 120 BPM, two bars at 240, or half a bar at 60. A 3.2-second loop could be one bar at 75 BPM or two bars at 150.
On its own, the length cannot choose between those readings. Combined with the onset analysis, it settles most cases: if the audio suggests something near 150 and the length says 75 or 150 exactly, 150.00 is a far better answer than the 149.6 the onset curve produced. Tools that use the length can report clean whole-number tempos for well-cut loops, and they can flag loops that are not cut cleanly, because the length and the audio disagree.
The length method breaks down when a loop has a tail. A crash cymbal left ringing past the bar line, or a reverb tail rendered into the file, adds time that is not part of the musical loop, and the arithmetic stops working.
Material that defeats detectors
Some loops have no clear answer, and a detector that reports one anyway is guessing.
- Pads, drones, and textures have no onsets to speak of. The onset curve is smooth hills, and whatever tempo comes out is noise.
- Rubato and live playing drift. A tempo detector assumes one tempo for the whole file, and a performance that speeds up into the chorus does not have one.
- Heavy swing moves every second sixteenth late. The beat-level tempo usually survives, but detectors that lean on fast subdivisions can be pulled off.
- Polyrhythms and odd meters give several strong, unrelated spacings. A loop in 7/8 can fool the bar-length arithmetic, which usually assumes 4/4.
- One-shots have a single onset and no spacing at all. A kick drum has no tempo. A detector should leave the field empty.
Field recordings, foley, and the sort of long source material that goes on a Morphagene reel fall into the first two groups. A BPM shown for them is not meaningful.
Checking a reading in ten seconds
You do not need to trust a detected tempo. Two quick checks catch nearly every error:
- Play the loop and tap. If your taps land on every other beat the detector counted, it reported double. If the loop’s beats fall between your taps, it reported half. Fix it by halving or doubling.
- Check the length. Multiply the duration in seconds by the BPM and divide by 240. A well-cut 4/4 loop comes out at a whole number of bars, or very close. If it comes out at 2.5 bars, either the tempo or the cut is wrong.
For loops that carry a tempo in the filename, compare the two. Pack makers label tempo by hand and they are rarely wrong, but files get renamed, re-exported, and time-stretched over the years.
Why the number matters on hardware
In a DAW, a wrong BPM costs you a few seconds: the loop plays at the wrong speed against the grid, you notice, you fix it. On hardware it can cost more.
Samplers that time-stretch, like the Octatrack, need to know a loop’s original tempo to play it at the project tempo. If that number is off by a factor of two, the loop stretches to twice or half its proper length. Slicing a loop into equal parts for a sample chain depends on the bar count being right, which depends on the tempo. Getting the tempo right in the library, before the files go to the card, saves working it out at the machine.
What about key?
Key detection is a different problem. Instead of onsets, a key detector builds a chroma profile, a measure of how much of each of the twelve pitch classes is present, and compares it against templates for major and minor keys. It is less reliable than tempo detection on short loops, which may not contain enough notes to separate a key from its relative minor.
SampleStack does not detect key. The key field is there to fill in by hand, and for sample-pack loops the filename usually tells you. For tonal one-shots that you want to play across a keyboard, root note detection is the more useful measure, and How sample pitch detection works covers that.
In SampleStack
SampleStack runs tempo detection on loops as it analyses them and writes the result to the BPM field. You can overwrite any value, and REX files bring their own tempo with them. With a tempo set, the editor shows a beat grid you can snap selections to, which makes cropping a loop to an exact bar a single drag. The sample editor page covers slicing and cropping in more detail.