有没有一种好方法可以使用它们来测量两个剪辑的相似程度?
这是一个非常理智的直觉,但我在文献中很少看到 - 除了从压缩流中进行特征提取的外围想法(这里的动机只是减少计算负担)。
我认为主要原因是音频编解码器不存储音频数据的感知表示。相反,它们存储了一个非常以编码为中心的音频表示——熵编码、量化、变换系数——被选择为使得原始信号和编码信号之间的失真低于感知阈值。从某种意义上说,查看压缩的音频流并不能告诉您人类将如何感知音频信号。它只是告诉你,任何低于感知阈值的东西都被拿走了。编解码器“雕刻”有意义的音频信号,但从不接触它。
其中 L(x) 是声音剪辑 x 的压缩长度,C1||C2 是连接两个剪辑的结果?
这在字符串上是有意义的——我认为这个想法是在 Cilibrasi 或 Vitanyi 的一些论文中发现的——但这不是音频编解码器的工作方式。您提到的音频编解码器旨在以低延迟处理流式音频,因此它们一次只能“看到”一个短信号窗口,并且不会尝试消除长期冗余。就像图像的JPEG一样。一个接一个地复制同一音符的 10 个实例将导致文件变大 10 倍。音频编解码器具有固定比特率,或根据编解码器看到的窄信号窗口的内容调整的自适应比特率。
音频编解码器消除的冗余是非常短期的。
您的想法将需要一个更复杂的“面向对象”编解码器,该编解码器试图将音频分解为对象的层次结构,例如音符。这个想法在学术界还处于起步阶段。
另一种看待它的方法是检查解码过程是否与信号的生成模型相似。某些字符串压缩算法就是这种情况,其中压缩过程会恢复类似于字符串的生成语法(Sequitur,factor oracles ...)。基于 LPC 的语音编解码器就是这种情况,其中 LP 系数嵌入了关于发音的知识,以及关于韵律和发声/清音的剩余知识——压缩流可以被视为语音合成器的数据。但是,对于您提到的通用音频编解码器而言,情况并非如此-解码器与音乐制作过程没有相似之处。
或者可能通过简单的度量(例如,应用于 FFT 频谱的 L2 范数)找到最高比特率,使得 F(C1) 接近 F(C2))
您可能会做相反的事情 - 查看剪辑变得无法区分的比特率,但最终它不会比比较由感知函数修剪的正弦表示容易得多。