该存储库包含一个与音乐推荐系统集成的Web应用程序,该应用程序利用了3,415个音频文件的数据集,每个数据集持续30秒,利用对局部敏感的散列(LSH)实现来确定节奏相似性,作为大数据分析基础(DS2004)基础的一部分。
音乐信息领域的检索领域提出了一个挑战,这是由于可以表示音频的各种方式,因此很难确定在查询中应优先考虑哪些功能。为了简化此问题,我们的实现专门针对歌曲的节奏作为唯一的查询功能。虽然先前的研究探索了基于节奏的音乐查询,但当前的方法却遭受了效率低下的困扰,因为它们需要查询整个数据结构以匹配歌曲节奏。为了克服这一限制,我们提出了对局部敏感哈希(LSH)的利用,该技术可有效地识别大型数据集中的类似项目而无需详尽的搜索。
对局部敏感的哈希(LSH)是一种广泛采用的技术,用于近似最近的邻居搜索。它通过将它们映射到较低维空间来有效地识别大型数据集中的类似项目。但是,传统上,对局部敏感的散列(LSH)采用了另一种称为Minhash(或最小独立排列的位置敏感散列方案)的方法来估计集合相似性。 Minhash通常用于数据挖掘和信息检索。尽管Minhash通常可以有效地估计集合相似性,但它具有某些限制,可能会阻碍其在特定应用中的有效性。
为了解决这些限制,我们选择使用另一种称为近似最近邻居(ANN)的高效技术实施LSH方法。该技术非常适合在大型数据集中找到大约最近的邻居。通过利用最近的邻居(ANN)而不是Minhash,我们旨在提高我们项目中对区域敏感的哈希(LSH)实现的有效性和性能。
大约最近的邻居(ANN)为区域敏感的哈希(LSH)提供了更通用的解决方案,因为它可以大约用于各种距离指标的最近的邻居。相比之下,Minhash专为Jaccard的相似性而设计。与Minhash相比,这种更广泛的适用性使我们的方法可以提供更准确的最近邻居的估计,尤其是在处理基于不同距离指标(例如欧几里得距离或余弦相似性)的高维数据集时。
关于时间复杂性,大约最近的邻居(ANN)和Minhash方法最终实现了带有局部敏感性哈希(LSH)的哈希表,从而在任何一种情况下都产生了检索的O(1)时间复杂性。但是,我们的重点更多地在于记忆效率,其中大约最近的邻居(ANN)接近Minhash。由于我们使用的音频数据集非常大,重量为3.3 GIB,因此此方面对于我们的实施尤为重要。
因此,通过利用大约最近的邻居(ANN)而不是Minhash,我们在估算最近的邻居的同时,在保持有效的检索时间和更好的内存效率方面达到了提高的精度,从而确保了使用较高的音频数据集实现的最佳性能。
Music Recommendation Based on Rhythmic Similarity Using Locality-Sensitive Hashing (LSH).ipynb - 包含我们对局部敏感的哈希(LSH)实现的实现,以训练和评估音频数据集中的音乐推荐系统。app.py - 音乐推荐系统附带的Web应用程序(烧瓶)的源代码。templates - 包含网页的源代码,即index.html和predict.html ,由Web应用程序(烧瓶)渲染。static - 包含Web应用程序(烧瓶)使用的所有图标和视觉元素。staticfiles - 用户在Web应用程序(烧瓶)上上传的音频文件的目录。features.pkl - 包含用于培训的所有音频文件的MEL频率Cepstral系数(MFCC)功能的对象文件。music.ann - 使用大约最近的邻居(ANN)的Music推荐系统的内存映射(MMAP)文件。 app.py文件并访问给定链接到主机端口。/predict页面后,您将同时收到上载的音频文件的最佳和最差建议。pied_piper_download.csv的文件将保存在当前目录中,该目录将包括从上传的音频文件标识的类似音频段。 该项目的存在得益于为此做出贡献的非凡人物。