How Does Shazam Identify a Song? Fourier Analysis Explained

You hold your phone up in a loud bar. Someone's talking over the music, glasses are clinking, the speaker is tinny and too far away. Three seconds later: Shazam names the song, the artist, and the album.

That should be impossible. The audio your phone just captured is garbage compared to the studio recording sitting in Shazam's database. Different microphone, different room, background noise on top, maybe the song is even pitched slightly differently by the venue's sound system. And yet it works, against a database of tens of millions of tracks, in about a second.

The trick is not "compare the sound waves." That would never survive the noise. The trick is to throw almost everything away and keep only what noise can't touch.

Sound is one messy line. That's the problem.

A microphone recording is just a single number per instant: air pressure over time. Plot it and you get one jagged line. Somewhere in that line is the melody, the vocals, the bass. But also in that same line, mixed in inseparably, is the clinking glasses and the guy next to you laughing.

You can't point at a stretch of that line and say "this part is noise, this part is song." They're added together, sample by sample, into one signal. If Shazam tried to match your recording directly against a clean studio track, sample for sample, it would fail immediately. The two lines would barely agree, because a few feet of extra echo and a little static shift almost every sample.

So the first move is to stop thinking about the waveform entirely, and ask a completely different question: not "what does the signal look like," but "what frequencies is it made of, and when."

If you want the full mechanics of that question, how Fourier transforms work covers it end to end. Here's the short version, built specifically for what Shazam needs.

Turning sound into a picture

A single Fourier transform tells you which frequencies are present in a signal, but it throws away when they happened. A three-second clip with a rising melody and a three-second clip with a falling melody could produce a similar overall frequency list, even though they sound completely different.

Shazam needs both time and frequency. So instead of one transform over the whole clip, it slices the audio into short overlapping windows, maybe a tenth of a second each, and runs a separate Fourier transform on every slice. Line those results up side by side and you get a 2D picture: time along one axis, frequency along the other, and brightness showing how much of each frequency was present at each moment.

That picture is called a spectrogram.

Notice the trade-off as you drag the window length. A short window nails down exactly when a note starts, but it blurs which frequency it is, because a brief slice of a wave doesn't contain enough cycles to pin down its pitch precisely. A long window does the opposite: sharp on frequency, blurry on timing, because it's averaging together whatever happened over that whole stretch. This isn't a limitation of the code, it's a hard trade-off built into the math itself:

Shorter time window ($\Delta t$), worse frequency precision ($\Delta f$). Longer window, better frequency precision but blurrier timing. Shazam picks a window length that's a reasonable compromise, and lives with it.

Most of that picture doesn't matter

A real spectrogram is a huge grid of numbers, and most of them are nearly worthless. Background hiss, room echo, and ambient noise show up as a low, messy hum spread across every frequency and every moment. If you tried to match the entire spectrogram, all that noise would drown out the actual signal.

But here's the useful fact: noise is loud everywhere a little. A real note is loud somewhere a lot. So instead of keeping the whole grid, Shazam only keeps the local maxima, the points that are louder than every neighboring point in both time and frequency. These are called peaks, and the resulting sparse set of them is called a constellation map, because it genuinely looks like a scatter of stars against a dark sky.

Turn up the bar noise and watch what survives. Random noise is, by definition, unlikely to accidentally beat a real, strong peak at exactly the same time-frequency spot. The peaks that matter keep winning that local contest almost every time, even as everything around them gets buried. That's the entire noise-robustness trick: don't try to clean up the signal. Just find the points loud enough that noise can't fake them.

A typical song might get reduced from millions of spectrogram values down to a few thousand peaks. That's the whole fingerprint. Everything else gets deleted.

One peak isn't a fingerprint. A pair is.

Here's a problem with using single peaks directly: a "peak at 440 Hz" happens constantly, in thousands of different songs, at thousands of different moments. One peak alone doesn't identify anything. You'd get an overwhelming flood of false matches.

The fix is to combine peaks. For each peak, called an anchor, look at a handful of nearby peaks that come shortly after it, called targets. Every anchor-target pair gets bundled into one compact package:

the anchor's frequency $f_1$, the target's frequency $f_2$, and the time gap $\Delta t$ between them. This triple is the actual hash that gets stored and searched. It's vastly more specific than a single frequency, because now a match requires two particular notes to occur at two particular pitches with one particular timing gap between them. That combination is rare enough to be a genuine fingerprint.

Drag the anchor along the melody and watch which hashes it generates. Move the anchor, and every hash it produces changes with it, because each one is really describing a relationship between two peaks, not a property of one peak on its own.

A song ends up represented as tens of thousands of these small hashes, each one anchored to an exact moment in the track. Shazam's entire database is just a giant lookup table: hash value in, list of (song, exact timestamp) pairs out.

How the match actually gets found

Now the clever part. Your three-second clip gets the same treatment: spectrogram, peaks, hashes. Say it produces 200 hashes. Shazam looks each one up in the massive database table.

Most of those lookups will occasionally collide with an unrelated song by pure coincidence. That's expected and fine. But if your clip really is a piece of some track in the database, something distinctive happens: every hash from your clip that matches the real song will point to the same relative position within that song. If your clip started 47 seconds into the track, every one of those matching hashes will agree, almost exactly, that the offset is 47 seconds.

So Shazam computes, for every matching hash, the time offset $\delta$ between where that hash sits in the candidate song and where it sits in your clip, then builds a histogram of all those offsets, one song at a time.

Random false-positive matches scatter their offsets all over the place, because they have no real relationship to your clip. But true matches all vote for the same offset, so their votes pile up into one sharp spike. A spike means a match. And where the spike sits tells you exactly which second of the song your clip came from, which is how Shazam also knows where in the track to resume playback or show lyrics.

Press auto-scan and watch the spike track the true offset continuously as the clip slides through the song. Then turn noise on: with only a handful of surviving hashes, a few corrupted or dropped hashes can be enough to blur that spike below the detection threshold. That's exactly why real Shazam clips run a few seconds long instead of a fraction of a second: more hashes means the true spike stays tall even after noise knocks a chunk of them out.

Why this beats comparing sound directly

Step back and look at what actually happened. Shazam never compares your recording to a clean studio track. It converts everything into a small set of frequency peaks, turns those into combinatorial hashes, and searches for a consistent time-offset, all of which are things a hash table can look up in roughly constant time, regardless of how many millions of songs are in the database.

That's also why background noise, a bad microphone, and a tinny speaker barely matter. None of them touch the loudest peaks in a real song enough to move them off their time-frequency spot. The noise has to be genuinely overwhelming before it can bury a strong peak, and by then you'd probably struggle to hear the song yourself.

If you're curious how a closely related idea gets used to shrink files instead of identify them, the math behind MP3 compression uses the same frequency-domain thinking to decide which parts of a sound your ears will never miss.

The short version

Shazam doesn't listen to your clip the way you do. It slices the audio into short windows, Fourier-transforms each one into a spectrogram, and keeps only the loudest local peaks, the ones noise can't fake. Nearby peaks get paired up into compact hashes that encode two frequencies and a time gap. Your clip's hashes get looked up against a giant precomputed table, and if enough of them agree on one consistent time offset, that spike is the match, and its position tells you exactly where in the song you're standing.

It's less like reading a wave, and more like matching a small photo of the night sky against a star atlas: forget the faint background, find the bright points, and check whether their pattern lines up somewhere, at one consistent shift.