"97 or 142? What one instructor's email changed in RideComposer"

A few days ago, an instructor testing RideComposer wrote to us. His message was short, precise, and it triggered one of the biggest fixes we've shipped in months.

"Take this track: Astrix – Artcore. RideComposer analyses it at 97 BPM. MixMeister analyses it at 142. A BPM measuring app gives 141.9. And that changes everything: 97 is flat road, 142 is a climb. We're not talking about the same ride at all."

He was entirely right. On both counts.

Why a wrong BPM is not a detail

For an instructor, tempo isn't decorative data — it determines pedalling cadence, and therefore the very nature of the effort. A track at 142 BPM is ridden at 71 revolutions per minute: a heavy cadence, standing or under strong resistance. That same track labelled 97 BPM calls for a fast, light cadence on flat road.

In other words: one wrong number in the BPM column, and the meaning of your whole block changes. You plan a climb, the software hands you a sprint.

What we found: three problems, not one

Digging in, we expected one flaw. We found three, tangled together.

The first was invisible and insidious. In certain situations, RideComposer stored not the track's tempo but half of it. The direct consequence for users coming from MixMeister: an imported ride proudly announcing 142 BPM was saved as 71. That was exactly the concern our tester raised when he asked "what about importing an MM ride?" He was spot on.

The second was the heart of the matter. Our tempo analyser, inherited from the earliest versions, had three design weaknesses: it only listened to the first thirty seconds of a track — often the intro, before the beat has settled; its filter, meant to isolate the kick drum, didn't really isolate anything; and it measured gaps between consecutive beats without ever cross-checking the whole. The result: on our test bench, it answered 97 for four completely unrelated tracks. That wasn't an error, it was noise.

The third one surprised us. The analysis depended on the computer's sound card. The same file could yield a different tempo from one machine to another. That flaw was invisible to everyone, ourselves included.

How you fix something without guessing

The most important part of this work wasn't writing code — it was building a way to verify.

A tempo detector that "seems to work better" is worthless: you need numbers. So we built a test bench from a professional fitness music library, where every track carries a BPM certified by its supplier — 1,954 verified reference tempos. Every change to the engine is now measured against that reference, on a sample drawn at random across all genres.

The bench proved its worth immediately. Two ideas that looked excellent on paper were abandoned within minutes because the numbers contradicted them: one degraded overall accuracy, the other dropped salsa from 60% to 40%. Without measurement, both would have shipped looking perfectly sensible.

The new engine, in plain terms

The principle comes down to a few simple ideas.

The engine now listens to three different passages of a track — never just the beginning — and only to the low frequencies, where the kick drum lives. It then looks for the pulse that repeats not only from beat to beat, but also from bar to bar: that's what separates a genuine tempo from a syncopated rhythmic figure, such as a salsa clave.

Finally, it settles an ambiguity as old as music itself: a steady rhythm can always be counted at two speeds. 71 or 142 is the same music counted differently. To choose, the engine now relies on what class music actually is — a range of 60 to 240 BPM, heavily concentrated between 120 and 130.

The results

On a representative sample of 123 tracks across all genres:

| | Before | After |

|---|---|---|

| Usable tempos | 80.5% | 87.8% |

| Exact tempos | 68.3% | 72.4% |

| "Half / double" errors | 7 | 0 |

That last figure matters most to you: the errors that turned a climb into flat road are gone — across all seven genres we tested, from moombahton to pop, house to flamenco.

And our tester's track? It reads 142.

What changes for you

• Your MixMeister imports keep their original tempo. An .mmp announcing 142 is stored as 142.
• The BPM and RPM columns finally say two different things: the music's tempo on one side, your pedalling cadence on the other.
• A "Re-analyze BPM" button recalculates tempos across your existing library. It works on whatever you're displaying — select a folder to start small — stops whenever you want and resumes exactly where it left off. BPMs you entered by hand are never overwritten.
• When the engine isn't sure, it says so, showing "—" rather than inventing a number. You then enter the value yourself.

What isn't perfect yet

We'd rather say it plainly. One known weakness remains: on music with ternary metre — salsa, and flamenco rumba with its twelve-beat compás — the engine still gets it wrong about one time in three. It sometimes counts in threes where the beat counts in fours.

We know exactly where the problem lies, we have two approaches to try, and above all: we can now measure each attempt in two minutes. That's the next piece of work.

Thank you

This fix wouldn't exist without an email from a user who took the time to cross-check with two tools, write down the numbers, and tell us. If something looks wrong in RideComposer, write to us: that is precisely how software gets better.

The fix is available in the latest version of RideComposer.