哼唱检索 (QBH) 系统面临着独特的挑战，这是因为人类生成的音频输入本身的特性以及将不精确的旋律与结构化音乐数据库进行匹配的复杂性所致。三个关键问题包括用户输入的多样性、不完善的特征提取以及对稳健的相似性匹配算法的需求。这些挑战源于哼唱本质上是不一致的，并且缺乏乐器生成的音乐的精确性。
首先，用户输入的多样性使预处理和分析变得复杂。哼唱在速度、音准精度、节奏和力度方面差异很大。例如，用户哼唱“生日快乐”可能会比原来的速度更快或更慢，跳过音符或添加意外的停顿。背景噪声或较差的录音质量（例如，来自智能手机麦克风）会进一步降低信号质量。与提供精确音符值的 MIDI 文件不同，哼唱需要系统猜测音符边界和音高，这通常会导致错误。用户以与原始歌曲不同的调哼唱旋律，例如，将“一闪一闪小星星”从 C 大调转调到 G 大调，也迫使系统在没有事先了解用户意图的情况下对音高信息进行归一化处理。
其次，特征提取难以将音频信号映射到可用的符号表示。如果用户跑调或在音符之间滑动，则音高检测算法（如自相关或基于傅里叶变换的方法）可能会错误地识别频率。节奏检测也面临类似的问题：用户可能会拉长某些音符或咕哝过渡，从而难以将音频分割成离散的节拍。例如，哼唱版本的“铃儿响叮当”可能会将断奏的八分音符模糊成连奏的乐句，从而混淆系统的定时分析。此外，用户经常遗漏或错误地记住旋律的某些部分，迫使系统处理部分或不正确的序列。这些错误会在匹配过程中累积，因为提取的特征不再与数据库的参考音轨对齐。
最后，相似性匹配必须考虑灵活性，同时保持效率。 QBH 系统通常使用动态时间规整 (DTW) 等算法来对齐具有不同速度的序列，或使用编辑距离度量来处理缺失的音符。但是，当应用于大型音乐数据库时，这些方法的计算成本可能很高。例如，将 10 秒的哼唱查询与数百万首歌曲进行匹配需要索引或降维等优化，这可能会丢失关键的旋律细节。此外，系统必须决定优先考虑旋律的哪些方面（音高轮廓、节奏、音程）。用户哼唱“致爱丽丝”的开头可能会强调错误的音符，因此系统必须权衡音高精度与整体轮廓，以避免假阴性。平衡速度、准确性和可扩展性仍然是 QBH 设计中长期存在的挑战。