A few weeks ago, a power user sent us a message: "The app is crashing." It wasn't, technically. The servers were healthy, the endpoints were returning 200s, and analyses were completing without errors. But he was right that something was very wrong. A mix he had run a month earlier had given him 54 tracks. The same URL now gave him zero, five times in a row.
Fixing that — and being honest with everyone it affected — is the story of this post. But first, it's worth explaining why DJ track identification is so much harder than the world thinks it is, and why Shazam, despite being the household name for "identify any song," breaks down almost completely the moment a real DJ starts mixing.
Why Shazam Fails on DJ Sets
Shazam was built for a very specific problem: you're at a café, a song you don't recognise is playing on the speakers, you hold your phone up, and within 10 seconds it tells you what it is. That works because the audio you're capturing is essentially clean — one track, one waveform, no other music in the background. Shazam's fingerprint algorithm is built around that assumption.
DJ sets violate every part of that assumption.
A DJ is rarely playing just one track at a time. There's usually two running in parallel during transitions, sometimes three when stem decks and acapellas are layered. The tempo is constantly being nudged up or down to beat-match. EQ filters are sweeping through the frequency range. Effects send slices of one track out into reverbs and delays while another track plays underneath. From a fingerprinter's perspective, what you're hearing isn't a song — it's a fast-moving composite of fragments, and there are very few stable moments where a single track is playing alone for the 5–10 seconds Shazam-style algorithms need to lock onto a match.
The result is predictable: on a typical 2-hour techno set, a Shazam-only approach will identify a handful of tracks at best, and will often surface the same recurring false positives. Anyone who has tried to ID tracks from a Boiler Room recording knows the pattern. The same three or four ghost-tracks keep showing up across completely different mixes — songs that aren't actually in any of them — because the algorithm latches onto whichever pattern in its database matches most closely, even when nothing in the database really matches at all.
What "Doing Better" Actually Looks Like
The temptation, when you set out to build something better than Shazam for DJ mixes, is to think the answer is just "a better fingerprinting algorithm." It isn't. Every fingerprinting service in the world is essentially solving the same problem with the same kinds of methods, and they all share the same fundamental limitation: they need a stable moment of clean audio to work with.
What actually moves the needle is layering. Multiple independent identification systems looking at the same audio from different angles, cross-checked against each other, supplemented by every other signal you can scrape from the mix itself — the SoundCloud comments where listeners have called out track IDs, the description the DJ wrote, any image-based clues if there's a tracklist photo. None of these sources is reliable on its own. Together they're an order of magnitude more accurate than any single tool.
That's the architecture we landed on for TrackRadar. We don't ask any one tool to solve the problem; we ask several to weigh in, and we trust the consensus more than any individual answer. The details of how that consensus is calibrated is where most of our engineering time has gone over the past year.
What Happens When You Stop Paying Attention
Here's the uncomfortable part of the story. You can build a careful, layered, multi-source identification pipeline — and still ship a change that breaks it without realising. We did.
Across two weeks in May we shipped a small handful of changes that each looked reasonable in isolation. One was framed as a cost optimisation, another as a quality improvement, a third was a routine infrastructure tweak. Read individually, they all made sense. Read together, they cut our SoundCloud track yield by around 80%. The kind of mix that should give a user 50 tracks was suddenly giving them 10. Worse mixes were giving them zero.
The painful thing is how invisible it was. Our error logs were quiet. Our health checks were green. Our analyses completed successfully. The change in track quality was statistical — it happened across the population, not on any single request that screamed for attention. If that one power user hadn't been frustrated enough to message us about it, we might have gone weeks longer before noticing.
Once we did notice, we found three separate things contributing to the regression, all of them in code we had written ourselves, all of them shipped under names like "fix" or "optimisation." That was a humbling few days. We rolled the changes back, re-tested everything end-to-end against mixes we had historical numbers for, and only then — when we had real evidence that the pipeline was returning to its previous quality — did we tell anyone it was fixed.
What We Did About the Users Who Got the Bad Version
About fourteen people had run SoundCloud analyses during the bad window. Some of them were existing users who would have noticed the drop. Most of them were new users who had tried TrackRadar for the first time during exactly the wrong two weeks, gotten 1–8 tracks back from a 2-hour mix, and concluded — completely reasonably — that the product didn't work.
We wrote to all fourteen of them personally. Not a templated mailshot — actual emails referencing the specific mix each person had run, the number of tracks they had gotten, and an honest acknowledgement that the result they had seen wasn't representative of the product. We told them what had gone wrong, what we had done to fix it, and invited them to try the same URL again.
The power user who first flagged it got a longer message back, and we asked if we could spend half an hour watching how he actually uses the tool. He's the kind of user who notices things weeks before our dashboards do.
What We Learned About Trust
DJ track identification is harder than it looks, but the technical difficulty isn't the part most people get wrong. The part most people get wrong is treating "the pipeline finished" as evidence that "the pipeline worked." A successful HTTP response tells you nothing about whether the result was good. Useful quality monitoring for this kind of system has to look at what comes out, not just whether anything came out at all.
We now have a daily check that runs known reference mixes through the live system and compares the results against a baseline. If the numbers drift, we hear about it before the next user does. It's the simplest possible version of regression detection, and we should have built it a year earlier.
The other thing we learned — and this matters more than the engineering — is that users notice quality changes long before analytics do. Power users especially. They are not just a source of revenue; they are a free, high-fidelity sensor for whether your product is doing what it claims to do. Listening to them is not optional.
If you tried TrackRadar in late May and it didn't quite work the way you expected, give it another try. You'll see a different product than you saw last month — and if you don't, we want to hear about it directly.
Want to test a mix? Try the DJ set analyzer with any SoundCloud URL — the first analysis needs no account, and a free account includes 3 every month.