一种基于哼唱的音乐数据库高效查询方法

摘要

本发明提供了一种基于哼唱的音乐数据库高效查询方法，其特征在于：(1)提取用户输入的待查询乐曲的旋律轮廓；(2)对旋律轮廓按照n元语法方法进行切分，并对生成的查询集进行扩充；(3)以扩充后的查询集中的每个元素为查找项，查找哈希索引，获得中间结果；(4)将所有的中间结果按照乐曲编码排序，得到与输入部分匹配的每个乐曲的旋律轮廓；(5)计算中间结果中的每个乐曲的匹配度；(6)选择匹配度最高的若干乐曲编码，取其相应乐曲名返回用户。有关试验结果表明，本发明所提供的方法的性能明显优于现有的其它方法。

说明书

技术领域

本发明涉及一种查询音乐数据库的方法，尤其涉及一种基于哼唱实现查询的音乐数据库查询方法，属于多媒体数据库技术领域。

背景技术

在数字图书馆、网上音乐销售、歌厅点歌服务、个人音乐欣赏、音乐研究、乐曲版权裁决等多个领域，每天都要大量使用数字化的音乐数据。这些音乐数据在使用上存在一个难题，就是很难满足用户基于内容查询非格式化音乐数据的要求。也就是说，如果用户听到一段很好听的音乐，想通过自己记忆的音乐片断来查询整首音乐的数据，目前在技术上仍然存在较大的实现难度。

现有的音乐数据库管理系统只能有效地管理格式化数据，支持对于歌名、作曲、演唱人等格式化数据的查询要求。但至今为止，没有任何成熟的数据库产品能满足对基于内容的音乐数据查询要求。近年来，基于内容的音乐检索技术吸引了越来越多人的注意，包括数据库技术、数字信号处理、模式识别、知识发现等众多领域的科学家开始共同探讨这一新的技术挑战。

在基于内容查询的音乐数据库检索中，通过哼唱内容实现查询是最基本的实现方式之一。它是指用户输入一段用乐器演奏的乐曲，或通过麦克风哼的一段曲子，吹的一段口哨，唱的一句歌，而且这些输入还可能包括某些错误时，系统能正确地返回用户想要查询的乐曲。

在基于哼唱的音乐信息检索领域中，查询处理算法一直是一个关键的研究课题。目前，已经提出不少算法，但这些算法中，可以容错的、查询准确率高的算法一般效率较低；而效率较高的算法，一般容错性能较差，只能执行精确查询。另外，在音乐数据库中，大多数情况下用户的查询输入是包含某些错误的，但希望系统返回的却是唯一的一首目标乐曲，而不是通常的一组结果。因此，有效评价一个音乐数据库系统的查询性能的不是查全率与查准率，而是查询的前三位的命中率。针对这一特点，目前提出的查询算法主要有三类：第一类是使用最多的计算编辑距离的动态规划算法。第二类是计算基本的欧式距离和为改进查找精度的各种改进的距离的算法，如：概率矩阵距离、转移距离(Transportation distance)等等。第三类是隐马尔科夫模型的方法。

在这三类算法中，计算编辑距离的方法与隐马尔科夫模型的方法具有很好的容错的功能，有关研究表明，隐马尔科夫模型的方法对不同类型的音乐还有很好的适应性。但是这两类算法对每个查询均要检查存放在数据库中的所有乐曲的特征表示，当数据库中的曲目越来越多时，查询的速度也越来越低。计算欧式距离及各种改进的距离的方法，虽然计算速度高于其它两类算法，但算法的容错性较差。

现有的技术已经可以实现在1000首到3000首的乐曲库中取得的65％～75％的前5位命中率。但这些技术中有的要求必须从乐曲的开头哼唱，违反了大部分查询是对乐曲的主题或者是高潮进行的这个客观事实；有的要求用户整小节地哼唱旋律，而事实上有相当多的乐曲，乐句与小节的起始位置是不一样的，即用户的查询不是从小节开始的；还有的要求用户必须在一个节拍器伴奏下哼唱，以保证节奏基本上是正确的，这是很不方便也不切合实际的。

另外，在上述基于哼唱的音乐信息检索领域中，实现较快的查询速度也是十分重要的。索引技术是加快查询速度的重要手段。在音乐数据库研究中已经提出一些索引方法，如：后缀树索引，表列索引(1D-List，2D-List)，基于n-gram(n元语法)的索引等。在这些索引中，后缀树索引，表列索引是内存索引结构，在数据量非常大时，显然是不能满足应用需要的。将n-gram方法和各类外存的索引结构结合，可以建立各类n-gram索引，但传统的索引结构只支持精确查询，要支持近似查询，必然要采用查询扩充的方法，将用户给出的查询，用添加错误的方法，扩充成包含1～n个错误的多个查询，再利用索引进行查询。对于音乐检索的情况，一般查询在12-25个音符之间，所扩充的查询数目是n的指数级，查询效率仍不理想。

公开号为CN1703734的发明专利申请“从声音确定音符的方法和装置”提供了一种提取高级别音乐结构的方法。利用该方法，哼唱或其他发音方式通过梯度分割等技术手段被转换成为一序列音符，以代表用户试图表达的旋律。这些检索音符的每一个包含信息，如音高，开始时间和持续时间，以及所述序列包含每个音符的相对顺序。利用该方法，有利于实现基于内容查询的音乐数据库检索。

公开号为CN1737797的发明专利申请“基于内容的数字音乐检索旋律特征数据库及生成系统”公开了一种基于内容的数字音乐检索旋律特征数据库及生成系统，包括：数字音乐素材库存储部、数字音乐文件读取和旋律特征提取部、旋律分段特征音符检测部、旋律特征模板生成部、音乐旋律特征模板库存储部。数字音乐文件读取和旋律特征提取部读取数字音乐素材库存储部的音乐文件，经过旋律分段特征音符检测部对其进行旋律段位置特征的检测及标注后，被送至旋律特征模板生成部，得到旋律特征模板数据文件，并被保存到音乐旋律特征模板库存储部中，同时由旋律特征模板生成部发出生成流程完毕的通知给数字音乐文件读取和旋律特征提取部。其中，旋律分段特征音符检测部是基于音符类别特征及其音符长度特征来进行的。先由消除可忽略静音段处理模块搜索标准旋律的音符特征序列，若查找到的音符长度小于某一预先设定的静音段长度阈值则将该音符加以删除，并将此段并入前一个音符的发音段，在删除了可忽略的静音段后，则由特征音符检测处理模块根据音符类别特征及其音符长度特征来对标准旋律中的每个音符进行检测，特征音符类别分为定位类特征音符和休止类特征音符，对于这两类音符均按其各自的音符长度是否超过事先所设定的特征音符阈值来确定该音符是否为分段特征音符。该发明既能保持对用户哼唱输入的容错性，同时还能提高系统对哼唱输入的匹配检索速度。

发明内容

本发明的目的在于，针对现有技术中可容错的算法查询效率低，而高效算法又难于容错的现实问题，根据人对乐曲相似的理解，提供一种基于单侧连续匹配、可容错的音乐数据库查询方法。

为实现上述的发明目的，本发明采用下述的技术方案：

一种基于哼唱的音乐数据库高效查询方法，其特征在于：

(1)提取用户输入的待查询乐曲的旋律轮廓；

(2)对所述旋律轮廓按照n元语法方法进行切分，并对生成的查询集进行扩充；

(3)以扩充后的查询集中的每个元素为查找项，查找hash索引，获得中间结果；

(4)将所有的中间结果按照乐曲编码排序，得到与输入部分匹配的每个乐曲的旋律轮廓；

(5)计算中间结果中的每个乐曲的匹配度；

(6)选择匹配度最高的若干乐曲编码，取其相应乐曲名返回用户。

其中，被查询的音乐数据库通过如下步骤获得：

(1)提取乐曲的旋律轮廓；

(2)对所述旋律轮廓按照n元语法方法进行切分；

(3)对所有切分后的片段，将其二进制编码作为旋律轮廓索引的hash码，以乐曲编码和片段的第一个音符在乐曲中的位置作为记录项，建立顺序的hash索引；

(4)建立乐曲编码与乐曲名的对照表；

(5)将乐曲插入音乐数据库。

所述旋律轮廓根据乐曲的音高和/或音长特征值获得。

将用户查询片段的旋律轮廓按照滑动窗口方法分片，每次右移一个音符，将查询分成更小的片段，然后再对查询结果进行合成计算，得到扩充的查询集。

从第一个匹配位置开始，检查输入的特征表示与中间结果的匹配位置，计算单侧连续匹配长度，并从第一个匹配位置开始，加上输入特征长度，再加一个阈值计算相应总匹配音符数。

取最大的相应总匹配音符数和与之对应的单侧连续匹配长度作为乐曲的总匹配音符数和单侧连续匹配长度，将所余乐曲的总匹配音符数和单侧连续匹配长度排序，取排在前列的结果作为结果集，取其相应的乐曲名返回用户。

对每一首乐曲的旋律轮廓按照滑动窗口的方法分片，对每一片段取其音高与音长的旋律轮廓的二进制编码作为索引项，与乐曲的编码和片段中第一音符在歌曲中位置共同组成数据记录，建立hash索引文件；

在所述hash索引文件中，按照乐曲的顺序排列索引数据。

本发明所提供的基于哼唱的音乐数据库高效查询方法采用了顺序hash索引，显著提高了查询的速度和精度。用本发明方法对217首MIDI乐曲和60个包含各种错误的查询进行查询测试，可以取得70％的第一位命中率和95％的前三位命中率。将数据集扩大为78000首网上收集的MIDI乐曲段，并将查询扩充至1000个，可以取得70％的第一位命中率，79％的前三位命中率和85％的前十位命中率。

附图说明

下面结合附图和具体实施方式对本发明作进一步的说明。

图1为本发明所示方法中，提取乐曲的特征、建立待查询的音乐数据库的流程示意图。

图2所示为进行音符基本切分时的音高示意图。

图3所示为进行音符细化切分时的音高示意图。

图4为通过上述的音乐数据库实现基于哼唱的音乐数据查询的过程示意图。

图5为基于本发明所述方法实现的一个基于内容查询的音乐数据库的整体框架示意图。

具体实施方式

本发明所提供的音乐数据库查询方法分为两个过程。首先是如图1所示的提取乐曲的特征，建立待查询的音乐数据库的过程。其次是如图4所示的通过已经建立的音乐数据库，实现基于哼唱的音乐数据查询的过程。下面，分别对此展开详细的说明。

在音乐信息检索中，对乐曲的处理都是通过对音乐特征值进行的。因此在音乐文件中提取乐曲的特征值是很重要的。在系统查询时，用户的哼唱也是先提取特征值，再与数据库中的乐曲特征值进行相似比较。

乐曲的特征值有多种，包括：音高、音长、强度、音色等。在现有的技术中，通常检索只采用音高、音长的特征，也可以只采用音高特征或音长特征。

在本发明所提供的方法中，是按照乐曲的旋律的音高、音长轮廓计算乐曲的相似度的。因此如图1所示，作为第一步，对所有入库的乐曲，首先要提取乐曲音高、音长特征值，并进一步提取乐曲的旋律轮廓。

对所有乐曲提取旋律轮廓特征后，每首乐曲可以由其旋律轮廓特征表示，索引的建立和用户的查询都是基于所提取的旋律轮廓特征进行的。

目前，最常见的数字音乐格式是MIDI文件和波形文件，如.WAV文件等。其它格式的数字音乐文件很容易通过软件转换为MIDI文件或波形文件。因此，在本方法的实施例中，规定乐曲库采用MIDI文件，而用户的哼唱采用波形文件。

参照《数字信号处理—原理、算法与应用》((美)John G.Proakis，Dimitris G.Manolakis著，ISBN 7-5083-2499-4)和《网上多媒体信息分析与检索》(庄越挺、潘云鹤、吴飞，ISBN 7-302-05584-X)中的有关说明，从MIDI文件中很容易提取出音符的音高和音长特征，而从波形文件中很容易提取出音符的音高特征。其具体的过程作为现有的技术，在此就不详细说明了。

在本发明所述的方法中，为了清楚起见，对乐曲的音高、音长特征采取相对表示的方法。具体而言，在乐曲中，后一个音符的音高与前一个音符的音高相比，只可能是：高、低、相同三种情况，我们分别用U(p)、D(own)、S(ame)三个字母表示，因此一般的旋律音高轮廓可以用U、D、S序列来表示。另外，在乐曲中，后一个音符的音长与前一个音符的音长相比，只可能是长、短、相同三种情况，我们分别用L(ong)、S(hort)、E(qual)三个字母表示，因此一般旋律音长轮廓可以用L、S、E序列来表示。

对于音长特征的提取，参照图2所示的音高示意图，本发明中采用基于能量变化和音高变化的方法进行音符切分，具体步骤如下：

1.利用能量变化进行基本切分

(1)判断起始点：利用信号能量的变化得到哼唱输入的起始点。当输入信号的能量超过预先设定的门限值，则认为是哼唱输入的起始点，滤除起始点的静音部分。

(2)判断结尾静音点：使用与上述相同的方法滤除结尾段的静音部分。

(3)确定切分点：使用动态门限的方法得到能量曲线的峰值点，将峰值点对应的音高曲线部分作为切分点(置为零)。

在完成基本的切分之后，将首尾部分的毛刺去除，得到音符的初步切分结果。这种对音符的初步切分方法在唱词过于连贯的部分不易得到准确的切分结果，因此可以进一步根据音高曲线的变化进行细切分。

图3为利用音符、音高变化进行进一步细切分的示意图。参照图3所示，在音高曲线上，从起始点开始，以一个很小的帧数值为窗长进行加矩形窗处理，计算窗内的音高均值，然后以步长1帧进行扩窗，每次扩窗的同时，计算窗内的音高均值，并对前后结果进行比较。如果差分结果在1个半音以内，则继续进行扩窗，如果差分结果大于1个半音，则停止扩窗，并作切分标记。如果遇到零点则自动停止扩窗，并从下一个音高不为零的位置开始新的扩窗操作，直到结尾静音点，得到最终切分结果。这一方法可以得到更准确的音符、音高切分结果。

在提取了乐曲的音高、音长旋律轮廓之后，下一步是对旋律轮廓按照n-gram(n元语法)方法进行切分。对所有切分后的片段，以其二进制编码作为旋律轮廓索引的hash(哈希)码，以乐曲编码和片段的第一个音符在乐曲中的位置作为记录项，建立hash索引。这里所说的n-gram方法是自然语言计算机处理领域常用的方法，以前通常用在大词汇连续语音识别技术中，。在音乐数据库查询中，由于与语音识别所处理的对象是类似的，n-gram方法很容易移植过来使用。

具体而言，本发明中，首先将所有乐曲的旋律轮廓按照滑动窗口的方法分片，窗口长度为n。对每一片段取其音高与音长的旋律轮廓的二进制编码作为索引项(对U、S、D分别用01，10，11表示，对L、S、E分别用01，10，11表示)，与乐曲的编码和片段中第一音符在歌曲中位置共同组成数据记录，建立hash索引文件。

在上述步骤所产生的hash索引文件中，具有相同的hash码值的记录放在相同的块中。hash记录中只有乐曲的编码和片段中第一音符在歌曲中的位置，其记录格式为：。

由于在建立hash索引文件时是一首一首乐曲来顺序建的，之后也没有更新操作，因此在hash索引文件中，有关的数据是有序的。换句话说，建立的是顺序hash索引。这种顺序hash索引在以后的查找处理时，可以大大提高查询的效率。

上述步骤完成之后，下面的步骤是建立乐曲编码与乐曲名的对照表，并将乐曲插入乐曲库。这是本领域一般技术人员都能胜任的简单操作，在此就不详细说明了。

通过上面所描述的步骤，就建立了一个待查询的音乐数据库。下面，结合图4对如何利用该数据库实现基于哼唱的乐曲查询进行详细的说明。

如图4所示，用户在通过哼唱进行查询时，首先需要按照图2和图3所示的内容提取乐曲的音高、音长旋律轮廓，并将旋律轮廓按照n-gram方法进行切分，得到待查询的数据。这在前文中已经有详细的说明，在此不予赘述。

但是，这一步骤所得到的待查询数据并不适合直接用作上述乐曲数据库的查询选项。这是因为由用户所哼唱的旋律往往会包含很多的错误，特别是音高、音长等参数，错误的概率相当高。因此，直接使用用户所哼唱的旋律进行查询，往往不能获得用户所希望的结果。在实践中，对于音乐数据库的查询，多采取近似查询的思路。近似查询的一般方法是将查询输入串的特征表示与音乐数据库中所有乐曲的特征表示一一比较计算，找出最接近输入串的乐曲作为查询结果返回用户。但是，当数据库所存储的乐曲较多的时候，这种方法因耗时太多，基本上是不可行的。支持快速查询的基本方法是使用索引，在现有的成熟索引方法中，大多数索引方法只能支持严格匹配查询。R树类索引虽然能支持近似查询，但当输入的特征向量的维数大于5时效率很低，不适用音乐检索的情况。

在本发明中，为了减少用户哼唱旋律错误所产生的影响，采取对已有的查询集进行扩充，使之包含一定范围内的错误查询集的解决思路。

具体而言，为了得到该扩充的查询集合，我们将用户查询片段的旋律轮廓按照滑动窗口方法分片，每次右移一个音符，将查询分成更小的片段，然后再对查询结果进行合成计算，给出最终结果。

滑动窗口的长度与数据库中n-gram索引中的n相同。若用户查询所包含的音符数为m，则查询所分片数为m-(n-1)＝m-n+1。将每一片作为一个查询，则所生成的查询数目远小于一般查询扩展方法。

例如：若查询片断为：“DDDSUDUDUD”，n＝4，m＝10，则查询分解为“DDDS”、“DDSU”、“DSUD”、“SUDU”、“UDUD”、“DUDU”、“UDUD”7个片断。所要执行的查询只有7个，大大小于前两种方法。

设查询目标序列为“DDDSUDUDUD”，而查询输入中错了一个音符，为“DDDSUUUDUD”(下划线所示)，则做n-gram分解后为：“DDDS”、“DDSU”、“DSUU”、“SUUU”、“UUUD”、“UUDU”、“UDUD”7个片断。而将查询结果按照片段位置合成后可以得到的目标序列及对应的音符位置为：

DDDSU D UDUD

1 2 3 4 5  7 8 9 10

可以计算得到目标序列的最长单侧连续匹配长度为9，总匹配数为9。

对于上述扩充后的每一个查询，查找hash索引。若扩充后的查询集合为k个，则查找索引后得到的中间结果集合为k个。对k个中间结果集合，采用类似合并排序的方法，按照乐曲序号和音符位置拼凑结果特征序列，计算中间结果中每个乐曲的匹配情况。

需要说明的是，这里的匹配是一种近似匹配运算。在本匹配算法中，是根据乐曲片断的总匹配音符数和最大单侧连续匹配的长度，判断哪一个目标乐曲的特征表示更接近输入串的特征表示的。

由于每个查找项对应一个中间结果，而这些中间结果中的数据是按照乐曲编码和片断的第一个位置顺序排列的，因此很容易找到同一乐曲与查找项匹配的所有位置。

为了便于理解上述的计算思路，下面介绍本发明人进行的一个有关实验及其结果分析。

该试验的具体内容是这样的：选10首中国传统民歌，每个歌选择一句，构造试验。

试验测试集是按照每隔3个音符，就按照旋律轮廓的方向提高或降低两个半音的方法生成10首乐句的测试集，再分别按照旋律轮廓的方向提高或降低3个半音，4个半音、5个半音和按照旋律轮廓的相反方向提高或降低1个音的方法，生成50首乐句的测试集。再每隔4个音符按同样的方法生成50首歌的乐句的测试集。再每隔5个音符按同样的方法生成50首歌的乐句测试集。

通过初步试听，我们得到如下结论：

1)人对旋律方向相同的错误的容错性最好，如果每隔3个音在与旋律相同的方向上改变6个半音，人仍认为是同一支歌，只是走调儿(包含错误)而已。

2)人对旋律方向不同的错误的容错性最差，对于80％以上的乐曲，如果每隔3个音在与旋律方向不同的方向上改变1-2个半音，人就认为不是同一支歌了。

3)人认为连续相同音符最多的两段乐曲最相似。

如：乐曲“两只老虎”的第一句，乐谱应为：12 31|12 31|3 4|5-|3 4|5-|，若为：12 31|12 31|3 4|5-|6 6|7-|，人们仍能分辨出是“两只老虎”，此时虽与原曲编辑距离为3，但连续正确的音符数为11。但如果改为下面乐谱：12 35|12 35|3 4|5-|6 4|5-|，此时与原曲编辑距离也为3，但没有一个人会认为要查询的歌是“两只老虎”，而认为要查询的是一首他们不知道的歌。将此查询的特征值与数据库中“两只老虎”的特征值比，发现连续正确的音符数为3、3、3、2，最长连续正确音符数只有3。

从这个例子可以看到，错误音符在查询中的位置对相似的识别非常重要。当错误音符分散出现在音符序列中间，使序列中连续正确音符分成若干段，而每个段都少于4个音符，人则认为不是同一首歌。如：查询是8个音符，错误出现在第3、6两个音符，则人们认为哼唱输入的与目标乐曲不是一首歌。

通过上述的试验结果发现，用户输入错误最多的是旋律轮廓所能包含的错误，如：本来乐曲的第i个音应比第i-1个音高半个音，而输入串中比第i-1个音高了一个音。其次是漏音符(称为删除音符)的错误，多音符(称为插入音符)的错误，较少(少于10％)是在旋律轮廓方向上的错误(如：本来应该第i个音比第i-1个音高一个音，却唱成比第i-1个音低一个音)。

为了使查询在包含不同的错误的情况下，仍能以接近人能容错的标准查到目标乐曲，我们结合上述的实验结果，提出了基于单侧连续匹配(one sideconsecutive match)的近似匹配标准。

设有字符串a1，a2，…….an，和b1，b2，……bm，若其中bi＝aj，(m＞i＞＝1，n＞j＞＝1)，bi+1＝aj+1，…….bi+k＝aj+k，bi+k+r＝aj+k+p，(r可取值0-2，p为根据经验给定的阈值)bi+k+r+1＝aj+k+p+1，…….bi+k+r+q＝aj+k+p+q，(m-k-i＞＝q＞＝0)则称字符串a1，a2，…….an，和b1，b2，……bm满足单侧连续匹配，k+q记为单侧连续匹配长度。

两个字符串a1，a2，…….an和b1，b2，……bm可以有多个单侧连续匹配长度，定义其中最大的一个为两个字符串的最大单侧连续匹配长度。

例如：字符串“abcdefgh”与字符串“abckmdefgh”根据定义满足单侧连续匹配，其连续匹配长度为8。字符串“abcdefghijklm”与字符串“abcdexyzjklm”根据定义也满足单侧连续匹配，其连续匹配长度为5，4，最大单侧连续匹配长度为5。

从给出的单侧连续匹配的定义和上例中可以看出，尽管输入串的特征表示包含插入、删除和唱错音符方面的错误，但均可以与目标乐曲的特征表示在不同程度上满足单侧连续匹配。根据视听试验的结论，在两个片断总匹配音符同样的情况下，单侧连续匹配长度越大，人认为越相似。

基于上述的分析思路，从第一个匹配位置开始，检查输入的特征表示与中间结果的匹配位置，计算单侧连续匹配长度，并从第一个匹配位置开始，加上输入特征长度，再加一个阈值(此阈值为允许用户漏掉音符的个数，根据试验，该数值以不大于5为好)计算相应总匹配音符数。

一首乐曲可能有多处音符与输入相匹配，本发明中，取最大的相应总匹配音符数和与之对应的单侧连续匹配长度作为乐曲的总匹配音符数和单侧连续匹配长度。

若乐曲的总匹配音符数少于输入长度的1/2，则将此乐曲放弃。

将所余乐曲的总匹配音符数和单侧连续匹配长度排序，取排在前列的结果例如前10名作为结果集，取其相应的乐曲名返回用户。

在本发明中，将数据库中乐曲与查询的旋律轮廓特征表示均按照n-gram方法分片，当n＝5时，每次查询所得到的中间结果不多，查询速度很快，一般在零点零几秒到零点几秒，但是这样在有插入删除错误或旋律方向错误，尤其是包含多个这类错误时，有可能得不到正确结果。对此可行的方法是减少滑动窗口长度，例如减为3，这样可以对包含更多错误的输入查出正确结果，但对于包含近10万首歌曲的数据库来说，查询的效率要降低2～3个数量级。为此，本发明人给出了如下的优化策略：

1.对用户给出的查询按照长度n划分。

如对查询序列“DDDSUDUDUUD”按照长度3划分，则得到“DDD”，“SUD”，“UDU”，“UDx”四个片断。(其中x为通配符)

2.用划分的片段，查找hash索引。

3.将查询结果按照片段所属乐曲序号和片段第一个音符位置合成后，计算音符总匹配数，若音符总匹配数＝查询音符总数。将结果直接返回。否则，执行4。

4.对用户给出的查询按照n-gram方法，取n＝3进行分片，查找索引，对查询结果计算按照片段所属乐曲序号和片段第一个音符位置合成后，计算总匹配数与单侧连续匹配长度，并按照其排序，将结果返回。

以下利用图5所示的基于内容查询的音乐数据库来介绍本发明所述方法在试验中获得的结果，以形象地说明本方法的优点。

为了检验算法的有效性，本发明人分别对217首经过人工筛选确认的MIDI乐曲库和网上收集的、未经筛选的(可能有重复的)78000首MIDI乐曲库分别作了对比试验。

实际的乐曲库为217首中国流行音乐MIDI乐曲时。得到如下结果：

当输入不包含错误时，三种方法的前三位命中率均为100％。当用包含各种错误的60个查询，查询长度为15，进行测试时，本文提出的方法前三位命中率为：95.5％，第一位的命中率为70％。

编辑距离的方法，查询前三位命中率为：92.5％，第一位的命中率为75％。计算欧氏距离的方法，对只包含一个错误的查询，前三位命中率为：55％，对包含两个以上错误的查询，前10位命中率低于30％。

测试结果由表1概括如下：

  查询方法  包含错  误情况  前三位  命中率  包含错误  情况  第一位命  中率  前三位命  中率

  计算编辑距离方法  无  100％ 含1-3个 错误  75％  92.5％  计算欧氏距离方法  无  100％ 只含1个 错误  40％  55％  基于单侧连续匹配  方法  无  100％ 含1-3个 错误  70％  95.5％

表1三种方法对217首MIDI乐曲和60个查询输入的命中率对比

查询一首曲目所用时间，如表2所示。

  查询方法  乐曲  数目  平均所用时  间  乐曲数目  平均所用时  间  计算编辑距离方法  217  12秒  10000  10分钟以上  计算欧氏距离方法  217  2.7秒  10000  约2分钟  基于单侧连续匹配  方法  217  0.3秒  10000  1.2秒

表3三种方法对217首和1000首MIDI乐曲库查询时间对比

从表2中可以看到，在217首的数据库中，本发明所提出的方法查询所用时间比编辑距离的方法快近两个数量级。

当实际的乐曲库为78000首中国MIDI乐曲时，计算编辑距离的方法与计算欧氏距离方法由于耗费时间太长，无法进行比较，本发明人只进行了本方法的测试。

由于实际大数据量的查询测试集难于收集，我们随机截取数据库中1000个乐曲片段(平均长度为14个音符)，按照10％无错误，50％为与旋律轮廓方向相同的错误，10％为包含一个旋律轮廓方向相反的错误或有一个插入、删除错误，10％为包含两个旋律轮廓方向相反的错误或有一个插入、删除错误，20％包含三个旋律轮廓方向相反的错误或有三个插入、删除错误，且随机选取错误的位置，构造了1000个查询。这里，我们将包含三个错误的查询增加到20％，为的是更多的考验效果最差的情况。

虽然只有较少的用户会唱出与旋律轮廓方向相反的错误，但在产生插入和删除错误时，也可能连带产生与旋律轮廓方向相反的错误，如：对乐谱1231 5，其音高的轮廓用USD序列表示则为*UUDU，唱成12 31 65，则其音高轮廓为*UUUDD，不仅多了一位，而且由于这多出的一位，后面的一位也错了，致使由于插入一个音符产生两个错误。这也是我们在1000个查询中构造40％的这类错误，以验证我们算法有效性的原因。

测试结果如表3所示。

 容错情况  第一位命中率  前三位命中率  前10位命  中率 不包含错误  100％  100％  100％ 仅包含与旋律轮廓方向相同的 错误(多个)  100％  100％  100％ 包含1个与旋 律轮廓方向 相反的错误  平均  37％  63％  87％  插入1个音符  60％  80％  80％  删除1个音符  40％  60％  80％  修改1个音符  10％  50％  100％ 包含2个与旋 律轮廓方向 相反的错误  平均  23％  53％  73％  插入2个音符  20％  70％  80％  删除2个音符  20％  40％  70％  修改2个音符  30％  50％  70％ 包含3个与旋 律轮廓方向 相反的错误  平均  21％  38％  54％  插入3个音符  25％  41％  55％  删除3个音符  24％  43％  58％  修改3个音符  13％  29％  46％ 1000个查询总计  70％  79％  87％

表3对78000首MIDI乐曲段，1000个查询输入的测试结果

从试验结果可以看到，当用户输入正确，或只包含与旋律轮廓方向相同的错误，可以得到100％的第一位命中率，因此，占有很大比例的只有这一类错误的用户，可以得到满意的查询结果。从试验结果还可以看到用户查询中所包含的错误越少，前三位的命中率越高。

在上述测试中，我们是采用随机的方法由程序自动产生错误音符的位置，检查没有进入前10位的，和没有进入前三位的查询，有相当多的部分是由于产生错误音符的位置在15个音符位置中是分散的，使得查询输入的旋律轮廓特征表示与目标乐曲的旋律轮廓特征表示的最大单侧连续匹配的音符数只有3，这样的输入，在人听来也不是目标乐曲，系统查不出来也是应当的。如果对来自网络的乐曲数据作了清理，去掉重复，命中率还可以进一步提高。

上面虽然通过具体实施方式描绘了本发明，但本领域普通技术人员知道，本发明有许多变形和变化而不脱离本发明的精神，所附的权利要求将包括这些变形和变化。