微信摇一摇搜歌技术原理分析.docVIP

华北水利水电大学 微信摇一摇搜歌技术原理分析 姓名： 刘 勇 学号： 201215708 摘要：给出一首歌利用cool edit等多轨录音和音频处理软件得出语谱图，然后利用傅里叶变换得到语音波形图，从中找到多个“音乐指纹”p，然后匹配哈希表匹配已知的音乐指纹，如果相同即为同一首歌；而经过版本改进之后的Local Sensitive Hash局部敏感哈希基于快速近邻搜索，抗噪性更强首先，一首MP3用cool edit之类的软件打开将是下图这样，以陈百强的《情人》片段距离，以下波形图示20秒片段。  接下来对这个波形做短时傅里叶变换(SFFT)，可以得到下面这个类似乐谱的图，叫做谱图(spectrogram)，纵坐标是频率，横坐标是时间。亮的地方代表能量高。每一首乐曲因为乐器、音高不同，所以它们谱图都不同。哪怕是不同的人用同一伴奏，甚至相同的人分开两次唱，语谱图都是有细微差别的，体现在亮的位置不同上。  PS: 傅里叶变换是可逆的，也可以将语谱图转化为波形放出来听，这也是现代频谱作曲流派的方法。 既然两首曲子亮的位置不同，我们就可以根据亮点来区分两首歌一不一样。如下图找到谱图上若干个最亮的点，比如下图找到了点1，点2，点3。它们的音高记作y1,y2,y3, 点1和点2的横坐标距离记作dx1, 点2和点3的横坐标距离记作dx2。我们用向量p=[y1,y2,y3,dx1,dx2]作为这个片段的特征，我们将p叫做音乐指纹。如果两首歌的p相同，那么我们就认为这两首个一样啦！否则就不一样 2、音乐指纹匹配哈希表 事实上为了稳定和抗噪，我们可能会对一首歌提取更多的指纹p，比如100录音环境经常会有噪音，如果匹配中了50个以上，我们就认为是同一首歌。而那些不一样的歌，基本上匹配数不会超过个位数。 这就是基本原理了，是不是很简单！ 当然另一个问题就是大数据量了，酷狗的音乐库动辄上百万，总不可能对用户录 制的片段一条一条去匹配吧？所以这里我用的不是逐条匹配，而是哈希表匹配。总的说来就是把每个p映射成不同整数，比如p=[24,8,46,13,29]可以映射每个p对应着一首歌的某个位置，建库的时候把所有曲目的指纹都插到这个巨大的哈希表中。如下所示。  那么加入我们想查应的曲子，就可以一瞬间找到。就像查字典一样，找到偏旁部首对应的页数一样。这样即使曲目再多也不怕了在很多应用领域中，我们面对和需要处理的数据往往是海量并且具有很高的维度，怎样快速地从海量的高维数据集合中找到与某个数据最相似（距离最近）的一个数据或多个数据成为了一个难点和问题。如果是低维的小数据集，我们通过线性查找（Linear Search）就可以容易解决，但如果是对一个海量的高维数据集采用线性查找匹配的话，会非常耗时，因此，为了解决该问题，我们需要采用一些类似索引的技术来加快查找过程，通常这类技术称为最近邻查找（Nearest? Neighbor,AN），例如K-d tree；或近似最近邻查找（Approximate Nearest? Neighbor, ANN），例如K-d tree with BBF, Randomized Kd-trees, Hierarchical K-means Tree。而LSH是ANN中的一类方法。 我们知道，通过建立Hash Table的方式我们能够得到O(1)的查找时间性能，其中关键在于选取一个hash function，将原始数据映射到相对应的桶内（bucket, hash bin），例如对数据求模：h = x mod w，w通常为一个素数。在对数据集进行hash 的过程中，会发生不同的数据被映射到了同一个桶中（即发生了冲突collision），这一般通过再次哈希将数据映射到其他空桶内来解决。这是普通Hash方法或者叫传统Hash方法，其与LSH有些不同之处。 局部敏感哈希示意图（from: Piotr Indyk） LSH的基本思想是：将原始数据空间中的两个相邻数据点通过相同的映射或投影变换（projection）后，这两个数据点在新的数据空间中仍然相邻的概率很大，而不相邻的数据点被映射到同一个桶的概率很小。也就是说，如果我们对原始数据进行一些hash映射后，我们希望原先相邻的两个数据能够被hash到相同的桶内，具有相同的桶号。对原始数据集合中所有的数据都进行hash映射后，我们就得到了一个hash table，这些原始数据集被分散到了hash table的桶内，每个桶会落入一些原始数据，属于同一个桶内的数据就有很大可能是相邻的，当然也存在不相邻的数据被hash到了同一个桶内。因此，如果我们能够找到这样一些h