基于指纹的原则，具体的音乐检索

在以前的博客基于指纹音乐检索于，我们介绍的基本流程，现并未做过多介绍。本博客将详细叙述检索的详细原理和实现。

1 搜索引擎的工作原理

       在介绍音乐检索的原理之前，我们先介绍一下搜索引擎的工作原理，这是由于音乐检索的工作原理和搜索引擎的工作原理很类似。

       我们使用搜索引擎的时候。一般是这个流程：输入一些关键词，提交给搜索引擎。搜索引擎通过后台分析返回与关键词最相关的网页。

这个过程非常快，往往仅仅有几毫秒。可是眼下互联网上存在的网页总数有数百亿之多。搜索引擎是怎样在这么短的时间内找到用户须要的网页的呢？这确实非常奇妙。

       最朴素的方法肯定是一个一个网页进行相似度匹配。每个文件计算一个相似度，然后对相似度进行排序。返回最相似的网页。

可是这也是最笨的方法。这须要每次查询都须要遍历一般全部的网页，复杂度很高。搜索引擎通过採用一种叫倒排索引的结构避免了朴素的匹配，在此之前我们先介绍一下朴素检索的实现方法。

       依照朴素方法，我们须要依据网页文件构造索引。如图一所看到的。每个网页都会首先进行分词，然后统计不同词的词频或者其它特征。

有了这个索引结构。就能够设计最朴素的搜索引擎。当用户输入的关键词进入搜索引擎之后。就会将关键词进行特征转换，转换成一个带有权值的特征向量，之后就能够和每个网页的特征向量进行相似度匹配，比如余弦相似性度量等，最后对匹配的结果排序就可以。

图一 网页的词组索引结构

倒排索引这个名词听着非常玄乎，事实上非常easy理解。朴素方法採用网页的索引结构，构造单词的统计信息。倒排索引则相反。以单词为索引结构。构造网页的统计信息，如图二所看到的。

图二 倒排索引示意图

       在倒排索引结构中，每个单词都相应一个倒排列表。倒排列表记载了出现过某个单词的全部网页的列表和单词在该网页中出现的位置信息或者词频。比如，单词1出如今网页6和10中，词频各自是a₁和a₂。

       搜索引擎在获得用户输入的关键词之后，就查找关键词相应的倒排索引表。然后将多个关键词的倒排索引表求交，获得出现过全部关键词的网页。然后对这些网页进行相似度计算。

能够看出。通过採用倒排索引结构，使须要匹配的网页数量急剧降低，因而大大加快了搜索的速度。

       上面是最简单的搜索引擎原理，假设大家想深入了解搜索引擎，能够參看《这就是搜索引擎》一书，该书具体介绍了搜索引擎的各个部分和检索原理。

以下開始介绍基于指纹的音乐检索原理。

2 基于指纹的音乐检索工作原理

       基于指纹的音乐检索工作原理和搜索引擎很相似。也是构造一个倒排索引结构，只是不是单词的倒排索引，而是指纹的倒排索引。

在基于指纹的音乐检索 中，我们介绍了指纹的构造，在此不做过多介绍。

指纹能够看做搜索引擎检索中的关键词，可是与关键词不同，每一个指纹代表的信息量较少，所以在音乐检索中须要提取许多的指纹完毕单次检索。

比如。15s的片段往往须要提取几万个指纹才干查找到正确的音乐。这就意味着搜索引擎几个关键词的单次检索在音乐检索中变成了几万个指纹的单次检索，检索时间大大添加。

       每个指纹都是一个整数。依据指纹的构造不同。可能须要24到30位不等。所以能够利用一个int型整数存储每个指纹。

这样全部指纹的空间就限定于一个int型整数所表示的范围，也即0到4G。当音乐库较小时，全部音乐产生的不同指纹数也较少，为了避免空间浪费。存储全部的指纹能够採用散列表形式，如图三所看到的。

图三 散列表形式的指纹检索结构

       当音乐库很大时。差点儿全部的指纹都可能会出现。这时採用散列表结构就没有什么优势，能够直接分配一个大数组来存放全部的指纹，然后每个指纹都指向一个该指纹相应的倒排列表。如图四所看到的。在图四中假定每个指纹的位数是24位，则须要分配一个长度是2²⁴的数组，然后每个指纹都指向一个倒排列表。

倒排列表中存储的是音乐id和该指纹在该首音乐中出现的位置。

图四 基于指纹的倒排索引表

       获得图四的倒排索引结构之后。检索过程就比較easy了。

可是过程却和搜索引擎不同，搜索引擎须要对不同关键词的倒排列表求交集。对交集内的网页进行相似度计算。基于指纹的音乐检索则须要一个间接的匹配过程，匹配步骤例如以下：

1. 将client传递的音频提取指纹。每个指纹伴随有一个时间属性；
2. 对每个提取的指纹都查找倒排索引表，获得该指纹相应的倒排列表；
3. 将倒排列表中每个音乐相应的时间和提取的指纹相应的时间进行相减。假设时间差大于零。则保存该时间差到图五所看到的的相应音乐中。
4. 对每首歌中的时间差进行排序；
5. 统计每首歌中时间差同样的个数，并返回个数最多的音乐。

图五 统计匹配的相似度

       基于指纹的音乐检索和搜索引擎相比，复杂度大增，主要体如今两个方面：首先。针对client录制的音频，提取的指纹往往上万，而这上万个指纹都须要訪问倒排索引表，这意味着一次音乐检索能够完毕上万次搜索引擎的检索；其次。因为单次检索须要上万次訪问倒排索引表，所以无法对音乐求交，因为求交的结果必定为零，我们仅仅能将倒排列表中相应的音乐时间和提取指纹相应的时间相减。然后统计每一首音乐中不同一时候间差的个数。然后将个数作为匹配的结果。正是由于以上这两个因素，因此，在一个独立的音乐库不能做太多。而相应的倒排列表每个指纹应该限制长度。

版权声明：本文博主原创文章，博客，未经同意不得转载。