你对着一台手机哼了两秒，屏幕上就跳出歌名、歌手、专辑封面——Shazam 这套"听歌识曲"的魔法，从 2008 年 App Store 上线起就让一代人觉得不可思议。它凭什么能在两三秒内，从几千万首歌的曲库里揪出正在播放的那一首？大多数人会本能地以为：它一定存了所有歌的完整音频，然后拿你录的那段去一段段比对波形。
恰恰相反。Computerphile 这期由 David Domminney Fowler 主讲的视频，把这套算法拆得干干净净，结论极其反直觉：Shazam 之所以认得准，恰恰是因为它把录音里 99% 以上的信息扔掉了。 它不存整首歌的波形，也不"听"旋律，而是把声音变成一张稀疏的"星点图"，再用组合哈希把星点变成可查的钥匙，最后靠一次数据库查找 + 一张直方图投票，在百万曲库里秒级命中。这期视频标题里那个怯生生的 "(Probably!)"——"大概是这么干的吧"——本身就是个诚实的好故事：Shazam 的真实实现是商业机密，但算法骨架来自 2003 年一篇公开论文，Fowler 当场搭了个 demo 给你看它怎么跑。看完你会发现，所谓"人工智能听歌"，其实是一场被精心伪装成音频处理的数据库检索问题。这个认知升级，对任何做搜索、匹配、去重的程序员都受用。
| 项目 | 内容 |
|---|---|
| 视频标题 | How Shazam Works (Probably!) |
| 频道 | Computerphile（约 263 万订阅） |
| 时长 | 约 14 分钟 |
| 播放量 | 约 19 万次 |
| 发布日期 | 2021 年 3 月 15 日 |
| 主讲人 | David Domminney Fowler（现场搭了可试玩的 demo） |
| 核心主题 | 音频指纹：如何用 FFT + 组合哈希在百万曲库秒级认曲 |
视频开篇就打破了最大的误解：Shazam 的曲库里根本没有完整音频。它对每首歌做的第一件事，是算一张频谱图（spectrogram）——把声音沿时间切成无数小窗，对每一窗做短时傅里叶变换（STFT），得到"这一刻有哪些频率、各有多强"。一张几秒钟的录音，频谱图可能有十几万个数值。
接下来是关键一步：峰值提取（peak picking）。算法只挑出频谱图里那些最亮的"局部高点"——也就是某个时刻、某个频率上能量特别突出的点。剩下的全部丢掉。保留下来的是稀稀拉拉几十上百个点，画在时间-频率坐标上就像夜空里的星座，所以叫星座图（constellation map）。一段几兆的音频，被压成了几 KB 的星点坐标。这是整个算法的第一次"大瘦身"，也是视频反复强调的反直觉点：识别不靠信息多，靠信息稳。
这一步是我想补充、视频点到但没完全说透的地方。为什么"只留最亮的星点"反而比"保留全部信息"更可靠？
因为麦克风录进来的，从来不是干净的原始信号：环境噪声、人声、回声、MP3 压缩、蓝牙传输、手机喇叭失真……每一项都会把波形搅得面目全非。如果你拿完整波形去比对，噪声一上来就全错了。但最强的那些频谱峰值，是信号里能量最集中、最抗干扰的部分——它们在嘈杂的咖啡馆里、在劣质蓝牙音箱里，依然会亮在那里。换言之，峰值之所以稳，是因为它们代表的是"信号里最打不死的那部分特征"。Fowler 在视频里直接演示：给录音叠上噪声后，波形已经糊成一团，但星点图几乎没变。这就是 Shazam 能在地铁里、聚会中照样认曲的根本原因——它从一开始就只信任那些噪声吞不掉的特征。
这给程序员的启示很硬核：做匹配时，"鲁棒特征"比"完整数据"值钱得多。 保留全部信息不仅贵，还会让噪声淹没信号。
光有星点还不够——你不能拿一张星点图去和库里的几千万张图逐一比对，那是 O(n) 起步的噩梦。Shazam 的天才之处，是把二维的星点对压缩成一维的哈希键。
具体做法叫组合哈希（combinatorial hashing）：在星座图里挑一个点当"锚点（anchor）"，然后在它之后的一个时间-频率窗口（target zone）里挑若干个"目标点"。每对（锚点, 目标点）生成一个哈希：
hash = (锚点频率, 目标点频率, 两点时间差 Δt)
同时记录这条哈希来自这首歌的哪个时间位置。一首歌能产生成千上万条这样的哈希，全部塞进一个巨大的哈希表里，键是 hash，值是 (歌曲ID, 锚点时间)。这一步把"两张图像不像"这种模糊问题，变成了"这个 hash 在不在表里"这种精确问题——而哈希查找是 O(1)。这才是 Shazam 能在百万曲库秒级响应的真正引擎：它根本没在"比较音频"，它在"查字典"。
这是视频里最该被程序员记住的一课。我们总觉得"识别 = 比较"，但 Shazam 把识别重构成了检索。
你录的那段声音，也走一遍同样的流程：算频谱图、提峰值、生成组合哈希。然后对每一条哈希去库里查。每次查询都是 O(1) 的哈希表 lookup，几秒钟的录音产生几百到几千条哈希，查起来毫秒级。库里有几千万首歌？没关系——哈希表的大小不影响单次查找速度。这就是为什么曲库越大，Shazam 反而越不慌：因为它的复杂度不随曲库规模线性增长，而是随"你录了多少条哈希"增长。
我个人的判断是：这套思路的精髓不在音频，而在"把匹配问题降维成查找问题"。任何"在巨量候选项里找最像的一个"的场景，只要你能定义出鲁棒特征并把它哈希化，都能套这个模板。这是比"Shazam 怎么认歌"更值钱的抽象。
光靠哈希命中还不够——几千万首歌，总有几条哈希纯粹是巧合撞上的。视频用一张图说清了 Shazam 怎么把巧合踢出去：时间对齐投票（time-alignment voting）。
逻辑很漂亮：如果某首歌真的是你现在听的那首，那你录的每一条哈希，在库里对应的位置，和它在录音里的位置，应该差一个恒定的时间偏移（因为你从歌的某个时刻开始录的）。于是算法对每条命中的哈希算 偏移 = 库内锚点时间 − 录音锚点时间，然后按歌曲 ID 分组，给每首歌画一张"偏移量直方图"。
得票最集中、峰值最高的那首歌，就是答案。这一步本质上是广义霍夫变换 / RANSAC 式的一致性投票——用"多数特征支持同一个时间假设"来筛掉随机噪声。Fowler 在 demo 里把这段讲得特别直观：错误的歌即便有几条哈希撞上，也凑不出一根尖峰。我个人觉得这是整套算法最优雅的一环：它没有去精巧地判断"像不像"，而是用统计让真相自己浮出来。
视频标题那个括号里的 "Probably!" 不是谦虚，是诚实。Shazam 的真实代码是商业机密，但算法的公开骨架来自联合创始人 Avery Li-Chun Wang 在 2003 年 ISMIR 会议上发表的论文《An Industrial-Strength Audio Search Algorithm》。这篇论文把星座图 + 组合哈希 + 时间对齐投票整套流程写得明明白白，是学术界和工业界引用最广的音频检索文献之一。
Fowler 的贡献在于：他不照搬论文术语，而是现场用代码搭了个能跑的小 demo，让你亲眼看到"录音 → 频谱图 → 星点 → 哈希 → 命中"的整条链路。这也是 Computerphile 一贯的风格——不卖弄公式，动手给你看。需要提醒的是，真实 Shazam 在工程上做了大量优化：抗强噪声的峰值筛选、针对人声哼唱的容错、海量哈希的分布式索引等等，这些论文里没全写。所以"Probably"——我们复原的是骨架，血肉是另一回事。
最后一点是我的延伸，视频没展开，但最能体现这套算法的复用价值。Shazam 用的是一种感知哈希（perceptual hash）思路，它和 MD5/SHA 这类密码学哈希正好相反：
Shazam 的 (频率, 频率, Δt) 就是一种感知哈希。而这套"提鲁棒特征 → 哈希化 → 库里查 → 投票去歧义"的模板，在别处遍地开花：图片搜图（pHash / aHash）、视频去重、论文查重、网页 near-duplicate 检测、甚至 DNA 序列比对，骨子里都是同一个范式。理解了 Shazam，你就理解了一大类"模糊匹配"系统的底层套路。这大概也是为什么这期 2021 年的老视频至今还在被反复推荐——它讲的不是一个 App，而是一种可迁移的算法思维。
flowchart TD
A["麦克风录入<br/>2-10 秒音频"] --> B["STFT 频谱图<br/>时间 × 频率 × 强度"]
B --> C["峰值提取 Peak Picking<br/>只保留最亮的星点"]
C --> D["星座图 Constellation Map<br/>丢弃 99%+ 数据"]
D --> E["组合哈希<br/>锚点 + 目标点 → hash键<br/>(f₁, f₂, Δt)"]
E --> F["哈希表查找<br/>O(1) per query"]
F --> G["时间对齐投票<br/>按歌曲画偏移量直方图"]
G --> H{"出现尖峰?"}
H -- 是 --> I["✅ 命中：得票最集中的歌"]
H -- 否 --> J["❌ 零散碰撞：无匹配"]
style D fill:#fff3cd,stroke:#d39e00
style F fill:#d4edda,stroke:#28a745
style G fill:#cce5ff,stroke:#007bff
图里标黄的"丢弃 99% 数据"是反直觉的核心，标绿的 O(1) 查找是性能引擎，标蓝的投票是去歧义的关键。整条链路把"听歌"重构成了"提特征 → 查字典 → 投票"。
给做搜索 / 匹配 / 去重的程序员： 下次遇到"在海量候选项里找最像的一个"，先别急着上向量数据库或暴力比对。问自己三个问题：① 我能从数据里提取出抗噪声的鲁棒特征吗？② 这些特征能被压缩成可哈希的键吗？③ 我能用一致性投票（直方图 / RANSAC）把巧合撞上的筛掉吗？三个都能答"是"，Shazam 模板就成立，复杂度从 O(n) 比对掉到 O(1) 查找 + O(命中数) 投票。
给做内容指纹 / 版权检测的团队： 感知哈希和密码学哈希别混用。存版权库要做"相似检索"就该用 pHash 这类鲁棒哈希；做完整性校验才用 SHA。两者混用是新手常踩的坑。
给所有读者的认知升级： "识别"不等于"比较"。当你发现一个问题本质是"在大量东西里找匹配项"，先想能不能把它降维成检索问题——把模糊的"像不像"转成精确的"在不在表里"。Shazam 用这套思路干翻了"存全量音频逐一比对"的直觉方案。很多时候，少即是多、扔即是准：与其堆数据，不如找对那几个打不死的特征。
numpy 做 FFT、scipy 找峰值、自己写组合哈希）复刻一版，几十行就能跑通识别单首歌的 demo，比看十遍视频都管用。imagehash / pHash 库，体会"输入小幅变化、哈希几乎不变"的特性，把它和 SHA-256 对比着用。Shazam 的魔法不是"听歌"，而是把声音扔成稀疏星点、哈希成可查钥匙、再用一张直方图投票——它告诉你：识别的最高境界，是把模糊的"像不像"降维成精确的"在不在表里"。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
youtube_transcript.py 提取字幕，因 IP 被 YouTube 拦截失败，改为基于页面 oEmbed/noembed 元数据 + 多源检索（Toptal、TechSpot、TechMoonshot）完成内容核验。lengthSeconds，时长"约 14 分钟"为估算，略低于 15 分钟门槛，内容深度足以补偿；如需严格 ≥15 分钟，可换 Hussein Nasser 的长篇 Raft/两军问题视频（但需另行核验播放量）。[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。