Every audio professional has used Shazam. Few know what it's actually doing. The assumption is usually something like "it listens for the melody" or "it matches the waveform." Neither is true. The algorithm ignores melody entirely. It doesn't even store audio. What it does instead is elegant enough that Avery Li-Chun Wang published it at ISMIR 2003 under the title An Industrial-Strength Audio Search Algorithm, and it became one of the most-cited papers in music information retrieval.
The Problem That Needs Solving
Fingerprinting audio is harder than it sounds. The same song played in a loud bar and captured on a phone microphone looks completely different at the waveform level. There's background noise, room reverb, microphone coloring, low bitrate encoding, and potentially a few seconds sampled from the middle of the track rather than the beginning. A naive approach, cross-correlating the raw waveform against a reference library, would fail immediately. The match rate would be close to zero.
The solution requires finding features that survive all of that degradation while still being specific enough to identify one song out of tens of millions.
Step One: The Spectrogram
Shazam starts by running a Short-Time Fourier Transform (STFT) on the incoming audio. The audio is typically sampled at 44,100 Hz, and the FFT window is around 4096 samples, giving a frequency resolution of roughly 10.77 Hz per bin. The window slides forward in 10-30ms hops, producing a two-dimensional map where the horizontal axis is time, the vertical axis is frequency, and pixel brightness represents energy.
This is a standard spectrogram. At this point, nothing unusual has happened. The spectrogram of the noisy bar recording and the clean studio reference still look quite different, because ambient noise smears energy across many frequency bins simultaneously.
Step Two: Peak Detection and the Constellation Map
Here is where the algorithm diverges from how most people would solve this problem. Instead of trying to work with the full spectrogram, Shazam discards roughly 90% of it.
The algorithm scans the spectrogram looking only for local maxima: frequency bins where the energy is significantly higher than neighboring bins in both time and frequency. These are the peaks that dominate their region of the spectrogram. The result is called a constellation map, a sparse scatter of bright dots in time-frequency space, like stars on a black background.
The key insight is that background noise is diffuse. It adds low-level energy broadly across the spectrogram but rarely creates the single loudest point in any given region. The peaks that survive the filter are the frequencies dominant enough to punch through. A guitar note, a drum hit, a vocal harmonic: these create sharp energy concentrations that appear as peaks in both the noisy recording and the clean studio version. They match.
A typical four-second recording might generate a few hundred constellation points from thousands of time-frequency cells. The map is sparse but robust.
Step Three: Combinatorial Hashing
A single constellation point is not enough to identify a song. Many songs have a loud kick drum at 80 Hz. What makes identification possible is the relationship between pairs of points.
For each point in the constellation map, Shazam designates it as an anchor point and looks forward in time to a defined target zone, a window of nearby peaks. Each anchor-target pair generates one hash, encoding three values:
f1: the anchor point's frequency binf2: the target point's frequency binΔt: the time difference between them
These three values are packed into a 32-bit unsigned integer:
hash = (f1 << 20) | (f2 << 8) | (Δt & 0xFF)Each hash is stored alongside the absolute time offset of the anchor point from the beginning of the song. The database entry maps from hash_value → (song_id, time_offset).
When a query comes in from a phone, the same process runs on the short recording: STFT, peak detection, combinatorial hashing. The resulting hashes are looked up in the database.
Step Four: Why Time Offsets Matter
The hash lookup will return many candidate matches because some hashes appear in multiple songs by coincidence. The disambiguation step is what makes the system reliable.
For each candidate song, Shazam looks at the time offsets. If the query recording was captured starting at, say, the 47-second mark of a song, then every matching hash from that song should show a consistent time difference between the query anchor's position and the database anchor's position. Spurious hash matches from different songs will have random, inconsistent offsets.
The algorithm computes a time-offset histogram for each candidate and looks for a strong peak. A genuine match produces a cluster of hashes all agreeing on the same offset. A false match produces scattered offsets with no pattern. This scoring step is what separates "plausible matches" from "this is the song."
The result: the system is robust to starting at any point in the song, to noise, to compression artifacts, and to the room acoustics of the bar you're standing in.
A Different Approach: Chromaprint
Shazam's constellation map approach is optimized for speed and noise robustness. It has one significant limitation: it does not handle pitch shifts or tempo changes. If you slow down a recording by 5%, the time deltas and frequency bins both change and the hashes stop matching.
Chromaprint, the fingerprinting library behind the AcoustID and MusicBrainz databases, takes a different route. Instead of spectral peaks, it maps audio energy onto the 12 semitone bins of the musical scale, producing chroma features that represent harmonic content regardless of octave. A melody played an octave up produces nearly identical chroma vectors, since both C3 and C4 map to the same chroma bin. The fingerprint captures what is being played, not at which frequency.
This makes Chromaprint more suited to duplicate detection across recordings with minor pitch or tempo variations, and less suited to the noisy-bar identification problem where speed matters more than pitch invariance.
Where This Shows Up in Audio Tools
The core pattern, sparse feature extraction followed by translation-invariant matching, appears everywhere once you know to look for it.
YouTube's Content ID uses audio fingerprinting to match uploaded videos against a database of reference recordings. It needs to work even when someone has slowed a track down, pitch-shifted it, or recorded it playing through a speaker in a room. The matching strategy adapts the same principles to a more adversarial context.
Broadcast monitoring systems used by PROs (Performance Rights Organizations) like ASCAP and BMI run continuous fingerprinting against live radio and television streams to track when licensed music is played and generate royalty reports automatically. The system processes hundreds of channels in parallel, matching against databases of millions of tracks in close to real time.
For audio software developers, the constellation map principle also appears in audio synchronization tools that align multiple recordings of the same event, and in DAW features that detect duplicate takes or sample reuse within a session.
What This Means for Audio Analysis
The practical lesson from the algorithm is something every audio engineer should internalize: spectral peaks carry most of the identity of a signal. The diffuse energy between peaks is largely noise and room acoustics. The peaks are where the signal lives.
This connects directly to how vocoders, spectral repair tools, and source separation systems identify and isolate sounds. They all rely on some form of peak tracking because peaks are the stable, high-information content of a spectrum. The constellation map is just a particularly clean implementation of that observation, pruned to the minimum information needed for robust identification.
Wang's 2003 paper was describing a production system at Shazam that could identify a song in seconds on hardware that would now be considered primitive. The algorithm's efficiency comes not from doing more computation but from throwing away almost all the data and working only with what survives that filter.
Most signal processing works the same way.