1 数据库的建立：
1.1 特征提取：对每个音频提取spectrogram，横轴为时间，纵轴为频率，用每个坐标上点的颜色来表示能量高低，选取能量较高的作为特征点。
1.2 每秒提取三个特征点，如果数据库中总共有一百万首乐曲，每首乐曲的长度大约为4分钟，也就是240秒，那么一共大约有 个特征点。
1.3 采用Hash Table建立数据库。Key值为每个特征点对应的频率，桶内存放的数据为特征点的偏移量以及音频的ID。那么假设对频率保留五位有效数字（有效数字太多，抗噪性能会变差），最多也只能建立 个桶，用10bit来表示每个Key，平均每个桶中有 个元素，碰撞会十分严重，检索效率太低。
1.4 为了提高检索效率，必须提高Key值的熵，也就是增加Key值的位数。这里采用特征点对的方法，每个Key值用三种特征值表示 ，f表示anchor的频率， 表示anchor和target zone中特征点的频率差值， 表示他们的时间差值，这样就可以建立 个桶，大约是原来的 倍，平均每个桶中只有一个元素，大大减小了碰撞的几率，检索一次的速率提高了 倍。
1.5 由于采用了特征点对的方法，需要检索的次数是原来的100倍（数据库中多了10倍，被检索音频多了10倍）。即使这样，整体速度依然提高了10000倍。这就是一种以空间换时间的方法。
1.6 如果每个特征点仅仅检索一次的话，抗噪性能会大幅减弱。假设一个特征点匹配的概率为p，那么特征点对匹配的概率为 ，概率值减小了很多。因此采用target zone的方法，每个anchor对应一个target zone，每个target zone中有10个特征点，这样针对每个anchor都形成了10个特征点对，这10个特征点对中有一对能匹配的概率是 ，也就是每个anchor匹配的概率和原来（p）近似相等。
2 检索
2.1 对找到的匹配特征点按乐曲的ID进行分类，针对每一个ID得到一系列时间对，即数据库中音频特征点的偏移量和样例音频中特征点的偏移量。如下图：
2.2 当两个音频匹配时，这些特征点对将形成一条对角线，当能够检测到这样一条对角线时，说明两个音频匹配。
2.3 通过计算每个点横纵坐标的差值可以得到一个柱状图，找出其中最高的那根，就可以判断是否匹配了。
上文来自：http://blog.csdn.net/koala_bupt/article/details/4404827
我们常常会遭遇到这样的尴尬：在大街小巷邂逅一段熟悉的旋律，无奈又听不清歌词。遗憾也许这辈子就这样失之交臂了。
不必懊恼，Shazam 是一款能够识别音乐讯号的应用。相信不少朋友对它并不陌生。它在 iPhone 和 Andriod 手机里出现的频率很高，诺基亚的某些手机甚至预装了这样一款软件。
它的基本原理就是通过采集十几秒的声音样本，通过网络将音乐信号发回 Shazam公司，经过数据分析，很快便将该乐曲的相关信息发回手机。你对此一定不满足，幸运的是我们找到了开发者的一份材料。
我们都知道，一段音乐信号可以通过频谱图表示。横轴表示时间，纵轴为频率，另一个轴表示强度，即一个三维的频谱。那么，一条水平线代表一段连续的音频，垂直线代表一个瞬间的白噪声。如下图，图中的每一个点都代表特定时间点的频率强度，即为选定的“锚点”。图中的红色标记代表该时间点声音强度的峰值。
由开发者的材料看，他们大约是每秒提取 3 个锚点。然后，他们会把收集到的信息建成一个哈希表（Hash table），其键值就是频率。当 Shazam 收到一段音频，以下图为例，它会以第一个键值，即 823.44 Hz 搜索匹配项。
哈希表可能如图所示：
他们不只是标注频谱的一个点，而是一个点对，每个峰值加了第二次锚点，即一个散列的两个点的频率，这样就能减少搜索时因噪声干扰而可能产生的误差。
接下来就是检索的过程了，如果一段音频多次匹配，就会自动坚持这些频率所对应的时间是否与哈希表一致。当两个音频近似时，这些锚点连成一条连线，如果能检测出这条线，就说明音频匹配。
据悉，类似的技术最早由一家名为 Melodis 的公司推出，它推出的一款应用—— Midomi ，与 Shazam 相似。当然，也不乏基于电脑的应用，比如前不久测试的百度哼唱，是首次在国内推出的哼唱搜索引擎。
搜索引擎发展的趋势就是越来越简单，越来越以人为本。在搜索引擎刚起步的阶段你能想到我们可以在移动设备上语音搜索 Google Map 吗？现在，我们可以想象了，有一天我们摆脱了键盘、鼠标，我们用感官，用意念，遨游于整个互联网。
Via Gizmodo
来自：http://www.ifanr.com/21133