One tenth of a BPM, and your climb became a flat

On 18 August we told you here how one instructor's email set off a complete rebuild of our tempo detection. We closed that article with a promise: the next job would be ternary-metre music, the kind our engine still counts in threes instead of fours about one time in three.

Here is what happened next. It contains a fix we are not proud of, a failure we are owning, and one measurement that changed the way we read our own numbers.

A threshold sitting on top of the noise

Start with the defect, because it reached the bike directly.

RideComposer turns a track's tempo into a pedalling cadence. The rule is simple: above 120 BPM you pedal on every other beat — 140 BPM gives 70 revolutions per minute. Below it, you pedal on every beat — 110 BPM gives 110 RPM. The line has to be drawn somewhere, and it is drawn at 120.

The trouble was that the software compared 120 against the raw value returned by the analysis, decimal included. Around 120 BPM, our measurement resolves to roughly 0.15 BPM. So a track its publisher labels 120 very often comes out at 119.9. One tenth of a BPM below the line.

The result: that track was not announced at 60 RPM but at 120 RPM. A factor of two on your riders' legs, decided by a tenth of a BPM.

This was not a measurement error — 119.9 for 120 is accurate to a tenth. It was the threshold cutting through noise. And it is not some rare edge case: 32.6% of our reference library is labelled between 114 and 126 BPM, which is to say, pressed right up against that line.

The fix is one line. The comparison now uses the rounded BPM. 119.9 and 120.0 give the same cadence, the way your ear hears them.

Measured on our reference corpus — 1,242 tracks whose BPM is certified by their publisher, run through the application's real engine: the share of tracks whose cadence matches the label goes from 81.8% to 83.5%. Twenty-one tracks repaired, none lost.

We announced it before we had done it

Now the uncomfortable part.

Version 1.3.0, released overnight, already claimed "120 BPM = 60 RPM". Two tracks had been reported to us, we made the threshold inclusive — an exact 120 now counts as a climb — and we considered the matter closed.

Except that most of the affected tracks do not come out at exactly 120, they come out at 119.9. So the promise was only half kept in the binary our customers received. The measurement across 1,242 tracks, run afterwards, is what exposed it. Version 1.3.1 contains nothing but that fix.

The lesson for us is the same one August taught: an unmeasured fix is not a fix, it is an intention.

August's promise: attempted, and failed

The ternary work announced on 18 August was carried out. It did not work. We would rather tell you than let the promise quietly expire.

The idea looked good on paper. When a track can be counted at two speeds in a three-to-four ratio, instead of looking at how regular the beats are — which had already failed in August — you ask each candidate tempo to land squarely on the bar (four beats) and on the phrase (eight beats). A tempo that misses the phrase is not the right one.

The test bench answered in minutes, on the same 1,242 tracks:

	Exact BPM	Same cadence
Current engine	78.3%	82.5%
Criterion on, low threshold	70.5%	17 repaired / 114 broken
Criterion on, high threshold	75.0%	13 repaired / 54 broken

Tightening the criterion improves the ratio without ever crossing into profit. The signal is real: the same tracks get repaired at both settings — the reggaeton and afrobeats family, in three-three-two, where a track announced at 137 comes back to 103. But that same criterion shouts "ternary" at perfectly binary dance music, and breaks four tracks for every one it repairs.

So we dropped it, and wrote down in the code, next to August's report, exactly why. So that nobody rediscovers the same idea in six months and mistakes it for a new one.

What the campaign actually taught us

This is the week's most useful result, and it has nothing to do with ternary metre.

Until now we quoted a single overall accuracy figure — 78% of tempos exact. That number means nothing, because it averages repertoires that have nothing in common. On the same corpus, split apart:

	Exact BPM	Same cadence
Club music (721 tracks)	91.4%	93.6%
Professional fitness mixes (195)	88.2%	90.3%
Albums, pop, live (465)	56.6%	64.7%
The Beatles (121)	22.3%	35.5%

The reading is unambiguous. On the music actually used in indoor cycling classes — club tracks and fitness mixes — the engine finds the right cadence more than nine times out of ten. On a Beatles recording, acoustic drums played by a human being, it is wrong two times in three. These are two different worlds, and averaging them tells you nothing about either.

That does not mean the poor numbers do not count. If you build your classes out of sixties rock, you are correcting BPMs by hand, and we owe you better. But it tells us where to dig, and it tells you what to expect from the software given your own library.

One last point, which pleased us: out of those 1,242 tracks, the engine refused to give a tempo for fifteen. Eleven of them are sound design — sirens, countdowns, pads — tracks that genuinely have no pulse. On real music the engine never gives up, and when it does give up, it is right.

What to take away

• If your library holds a lot of tracks around 120 BPM, move to 1.3.1: their cadences were wrong by a factor of two.
• Tracks you have already analysed keep the tempo computed back then; it is the conversion to cadence that is fixed, and it applies straight away.
• Ternary metre remains a known defect. We have no lead left to announce, and we will not announce one until the test bench has confirmed it.

As always: if a tempo looks wrong to you, write to us with the title and the figure you expected. That is precisely the email that, back in August, set all of this in motion.