Shazam 到底是怎么做到的？（互动式探索）

来源：https://perthirtysix.com/how-the-heck-does-shazam-work
音频指纹 + 连线小游戏，让 Shazam 在几秒内锁定一首歌。

Shri Khalpada（https://perthirtysix.com/team）

Shri Khalpada

2026 年 4 月 20 日

“How The Heck?”系列互动科普之一，带你拆解日常技术。

喜欢的话，可关注作者（https://bsky.app/profile/shrikhalpada.dev），请他喝杯咖啡（https://www.buymeacoffee.com/shrikhalpada），或来信点菜（mailto:[email protected]）。

你在咖啡馆，一段旋律钻进耳朵，却死活想不起歌名。掏出手机，点一下，几秒后答案蹦出来。

嘈杂环境里，手机只听了几秒，怎么就能在几百万首歌里精准命中？

你可能会猜：它在听旋律？还是识别歌词？都不是，它比你想的更狡猾。

声音逆向工程

太长不看版
手机用薄膜把声音录成波形，但波形没法直接“认歌”，于是用快速傅里叶变换（FFT）把它变成三维频谱图。

手机麦克风里有一张极薄的振膜，把空气振动变成电信号，再数字化成波形：一串数字，记录每一瞬间的气压。

就像你的耳鼓捕捉到压力波，大脑把它翻译成声音；手机则把它翻译成数字。

原始波形对识别几乎没用：同一首歌大声放和小声放，波形完全不同；两首不同的歌却可能长得很像；同一首歌在不同环境又长出新的波形。

必须把波形变成电脑能看懂的东西。手机对波形切片，跑快速傅里叶变换（FFT），把每片复杂波拆成“需要哪些纯音才能拼回这片声音”的清单。

把这些切片并排，就得到频谱图：X 轴是时间，Y 轴是频率，点的亮度代表该时刻该频率的响度。

FFT 到底干了啥？
任何锯齿状波形都能拆成不同频率、幅度、相位的正弦波之和。FFT 是一种高效算法，把 1 024 个采样点（CD 音质下约 23 ms）转成频谱，告诉你每个频率带多少能量。核心公式就是离散傅里叶变换：

对每个频率桶，把每个采样点乘以该频率的正弦波再求和。信号里真有这个频率，和就大；没有就相互抵消。

“快速”二字是关键。暴力计算要上百万次操作，FFT 利用对称性，把复杂度压到约 次（N 为采样数）。手机每秒能跑几百次。滑窗、切片、FFT、堆叠——频谱图就这么实时生成。

下面随便弹几个音或和弦，看波形和频谱图如何变化。

上图只是示意，用的是纯净正弦波。真实音乐层层叠叠，频率复杂得多。你可以直接播放音乐或对着麦克风哼唱，看实时频谱图有多“脏”，FFT 依旧能画出清晰画像。

手机通常以 44 100 Hz（CD 同级）采样，每秒几万次。每小片送进 FFT，输出可供推理的频谱。

少即是多

太长不看版
算法故意把频谱图大部分扔掉，只留最亮的峰，得到稀疏“星图”。

对电脑来说，存下整张频谱并逐条搜索慢到不可接受。于是算法反直觉地几乎全删掉。

拖动下方阈值滑块，观察变化：阈值越高，弱信号消失，只剩最亮的峰，形成稀疏点集。这些点才是声学“地标”。

这套策略抗噪：背景噪音会把能量均匀撒满全图，却极少能冒出“局部最亮”。真正的地标，是强到能穿透噪音的峰。

也正因如此，你对着 Shazam 清唱往往识别失败——哪怕你是专业歌手，生成的哈希也可能与原曲不同。新一代基于机器学习的系统才专门解决“哼唱搜歌”，靠旋律而非精确频率匹配。

连线小游戏

太长不看版
单峰信息量低，两峰组合就稀有得多。算法把邻近峰两两配对，生成唯一指纹哈希。

星图里一个点没啥用：1 200 Hz 这一刻可能出现在成千上万首歌里。但一对点——1 200 Hz 后 0.3 秒蹦出 2 400 Hz——就稀有得多。

算法让每个峰轮流当锚点，在其右侧定义一个目标区域（时间+频率窗口），把锚点与区域内所有峰配对。每对用三个数生成紧凑哈希：两频率 + 时间差。

哈希就像字符串缩写：输入相同，输出必同；任一输入微变，输出全变。Shazam 内部会容忍小漂移，但哈希本质绑定的是“具体录音”而非“歌曲旋律”，所以翻唱、混音难匹配。

下方可点击任意点选锚点，再点目标区内另一峰，看哈希生成。

一首 3 分钟的歌可生成几千条指纹哈希，数据库全存起来。现在手机录的 5 秒片段也有几十条哈希，而库里躺着几亿条，怎么瞬间找到命中？

找到完美匹配

太长不看版
每条哈希都是地址。系统把片段哈希全部查表，看哪些歌也拥有它们。

笨办法：以歌为先

直觉是“逐首歌搜”。得遍历每首歌，看哈希有没有重叠。时间复杂度 ，歌越多越慢。

下方有简化示例，可体验这种龟速搜索。

倒排索引：以哈希为先

电脑可以反着来。不问“哪首歌匹配这段声音”，而是问“这段声音里的每个哈希，都出现在哪些歌里”。就像书末索引：不翻全书，而查单词直接得页码。

这样查找近似 操作，100 首与 1 亿首歌耗时差不多。手机直接按哈希地址跳表，每个地址只存少量条目。

光有共同哈希还不够：得看时间间隔。如果片段里两哈希相隔 1.2 秒，那么目标歌里也必须相隔 1.2 秒。多条哈希的时间差都对得上，且数量足够，系统就能拍板。

整套流程全是电脑的拿手好戏：比数字、查地址。百万曲库，毫秒级完事。

更现代的做法

多数识曲服务（包括 Shazam）把音频片段上传到服务器，服务器用巨型指纹库匹配后返回答案。库大、更新快，但吃算力。

也有更轻量的方案：Apple 的 on-device 识别、Google Pixel 的 Now Playing（https://research.google/pubs/now-playing-continuous-low-power-music-recognition/）完全在本地运行。它们用精简曲库 + 优化模型，牺牲覆盖率换速度，并引入更抗噪的机器学习算法。

有得有失：本地方案秒出结果且离线可用，但曲库小、更新慢，还得根据地理位置拉取不同热门榜单——日本热歌与美国热歌并不重叠。

无论在哪匹配，核心套路不变：把 5 秒嘈杂片段扔掉 99% 的信息，只留下最强地标，就能在百万曲海里定位唯一一首歌。识别，原来是一场“精准忽略”的艺术。

本文大量细节源自 Avery Wang 2003 年论文《An Industrial-Strength Audio Search Algorithm》（https://www.ee.columbia.edu/~dpwe/papers/Wang03-shazam.pdf），想深挖信号处理与系统设计，值得啃一啃。

谢谢阅读！

喜欢这类内容，可在 BlueSky 关注我（https://bsky.app/profile/shrikhalpada.dev）。想请作者喝杯咖啡（https://www.buymeacoffee.com/shrikhalpada），更是感激不尽 ☕