Freqblog

Posted on Jul 14 • Originally published at freqblog.com

Mixed In Key vs Rekordbox vs Serato: Why DJ Platforms Disagree on Key 60% of the Time

#music #dj #api

Take a track. Run it through Mixed In Key, then Pioneer Rekordbox, then Serato. Compare the keys.

If they all agree, congratulations — you've picked a track that's harmonically unambiguous. If you spent an afternoon picking 20 tracks and ran the experiment, you'd find that all three platforms agree on the key for only about 39% of them. Mixed In Key disagrees with Serato on 45%. Mixed In Key disagrees with Rekordbox on 38%.

That isn't a typo. Three professional, paid DJ platforms produce three different answers for nearly two in three tracks. This article unpicks why — and what it means if you're building software that depends on key detection.

The numbers

The 39 / 45 / 38 percentages come from independent comparisons run by harmonic-mixing communities and reproduced multiple times since 2019. The methodology is straightforward: take a corpus of commercial music, run each platform's analyser on the same files, and tabulate exact-match agreement.

Pair	Agreement	Disagreement
All three platforms agree	~39%	61%
Mixed In Key vs Serato	~55%	45%
Mixed In Key vs Rekordbox	~62%	38%

"Disagreement" here means the platforms returned different keys (e.g. F# minor vs A major) — not minor numerical differences. The disagreement is categorical.

Why three pro tools produce three different answers

1. Different algorithms

Each platform implements key detection differently. Mixed In Key uses a proprietary algorithm trained on commercial music, often with manual curation in the training set. Rekordbox uses Pioneer's in-house engine that prioritises speed (analysis runs in the player). Serato uses a third approach optimised for live performance.

Most modern key detectors are chromagram-based: split the audio into short frames, compute a 12-bin pitch-class histogram, then correlate against a reference template (Krumhansl-Schmuckler is the classic). The differences come from how:

Frame size and hop — longer frames smooth out percussion, shorter frames pick up rapid modulations.
Harmonic peak detection vs. raw spectral energy — harmonic peak detection is more accurate but slower.
Low-pass filtering before chromagram — cuts cymbal hash, but can over-suppress melody.
Reference template choice — Krumhansl, Temperley, Bellman, or a neural-network alternative each give different priors.
Modal handling — relative major and minor share the same notes; algorithms decide differently between e.g. A minor and C major.

2. The relative-key flip

The single biggest source of disagreement: relative major and minor have identical pitch content. A minor uses the same seven notes as C major. Algorithms decide between them via priors that look at melody contour, downbeat emphasis, and chord voicing — signals that are easy to get wrong.

On the Camelot wheel, this flip means the same track gets tagged 8A or 8B by different platforms. Either is musically defensible; only one matches the producer's intent.

Practical effect: when two platforms disagree on a track, ~70% of the time it's a relative-key flip (same Camelot number, different letter). The other 30% is genuine pitch-class disagreement.

3. Different definitions of "in key"

Many tracks change key. A pop song might verse in A minor and chorus in C major. Some platforms report the dominant key by duration; others report the chorus key; others bias toward the more "harmonically rich" section. Each is a defensible choice.

4. Tuning frequency drift

Pre-1980 recordings, jazz, and a lot of indie / experimental music aren't tuned to A4 = 440 Hz. They might be at 432, 435, 442, or anywhere in between. A chromagram tuned to 440 will smear pitch-class energy across two adjacent bins for a track at 432 — and the algorithm picks whichever bin happens to win.

This is the dirty secret of key detection: the further you get from "modern recording, tuned to 440, clear melody", the more the algorithms diverge.

What to do about it

If you're a DJ

Pick one tool and trust its analysis end-to-end. Mixing across platforms produces inconsistent results because of the disagreement above. The Camelot wheel was designed to be tolerant — adjacent moves (±1 number, same letter) work even when the underlying key tag is slightly wrong — so consistency matters more than which platform you chose.

If you're building an app

You need a single source of truth that's API-accessible. The DJ tools above don't expose their analysis as an HTTP endpoint, so you're either:

Building your own detector with Essentia / Librosa / Madmom (weeks of tuning, then you have your own opinion to defend)
Paying Spotify (deprecated audio_features as of November 2024) or AcousticBrainz (frozen July 2022)
Using a managed API that handles the tuning, modal disambiguation and Camelot conversion for you

Try FreqBlog — free tier, no card: https://freqblog.com/

Confidence scores beat opinions

Every detector should expose a confidence score alongside the key. Mixed In Key colour-codes its output (green = confident, red = best-guess). Rekordbox does too internally but doesn't expose it. Serato hides it from users entirely.

This matters because for ~60% of tracks the algorithm knows it's not certain. Surfacing that lets your application:

Treat low-confidence detections as advisory rather than authoritative
Fall back to user override or alternative algorithms
Flag tracks that are likely to clash on a harmonic playlist regardless of platform agreement

Our own API returns a key_confidence field on every /lookup response. Below 0.4 means the track is likely atonal, modal, or harmonically ambiguous — treat that as "play it solo, don't try to mix it".

Camelot is robust to all of this

Here's the bright side. The Camelot wheel was specifically designed for the case where two algorithms disagree on the relative-key flip. 8A and 8B mix harmonically with each other — you can play the relative even when the algorithm got the modal wrong.

If you build playlists using Camelot adjacency rules (same number, ±1 number, same-or-opposite letter), you get a tolerant matcher that works with any of the three platforms above. The key detection accuracy stops mattering as much when the downstream consumer is robust to off-by-one errors.

The takeaway: stop chasing perfect key detection. Build robustness into your harmonic-mixing logic and accept that any single algorithm is a probability distribution, not an oracle.

DEV Community