为 decodeAudioData (WebAudio API) 定义“有效的 mp3 块”答案

【问题标题】：Define 'valid mp3 chunk' for decodeAudioData (WebAudio API)为 decodeAudioData (WebAudio API) 定义“有效的 mp3 块”
【发布时间】：2012-05-15 06:59:52
【问题描述】：

我正在尝试使用 decodeAudioData 在 javascript 中解码和播放较大 mp3 文件的初始部分。我的第一个粗略的方法是从 mp3 的开头切出一些字节并将它们提供给 decodeAudioData。这并不奇怪。

经过一番挖掘，似乎 decodeAudioData 只能使用 Fair Dinkum Thinkum、here 记录的“有效 mp3 块”。

但是，没有关于有效 mp3 块的结构的说明（上述内容的作者没有对此进行说明）。我知道那里存在各种 mp3 分离器，但我想以编程方式解决这个问题。（我正在尝试在服务器端使用 nodejs 实现一种“穷人的流媒体”）。

那么，在 mp3 帧头上拆分就足够了吗，还是我需要做更多？（也许通过在末尾附加一些数据来“关闭”每个块？）“字节库”怎么样？这会导致问题吗？作为记录，我目前正在使用 128kbps cbr mp3。这会以任何方式简化流程吗？

任何有关 decodeAudioData 期望作为有效数据的信息将不胜感激。

谢谢。

PS：我意识到这可能是对 Fair Dinkum Thinkum 的post 的澄清请求，但我的低声誉使我无法发表评论。所以除了一个新问题，我看不出还能怎么做。再次感谢。

【问题讨论】：

一个mp3块是一个单帧，代表0.028秒的音频。该帧的大小是可变的，具体取决于编码音频的比特率。 CBR mp3 确实让事情变得更容易，因为帧大小在整个文件中是恒定的，您可以轻松计算音频中任何特定“时间戳”的偏移量。
事实证明这是不正确的，例如，128kbps mp3 文件包含 417 字节帧和 418 字节帧。（有些帧包含一个额外的字节作为填充）

标签： javascript mp3 web-audio-api

【解决方案1】：

在对 decodeAudioData（在 Chrome 上）进行更多实验后，我发现：

任何 initial mp3 块只要在 mp3 帧边界上分割，就会成功解码。找到该边界可能并不总是微不足道的（例如，涉及解析 mp3 标头），因为即使是恒定比特率的 mp3 也不总是包含恒定大小的帧。例如，128kbps mp3 文件包含 417 字节帧和 418 字节帧。（有些帧包含一个额外的字节作为填充）。
不保证任意 mp3 块即使在“两侧”的精确帧边界上分割也是可解码的。这种类型的某些块可以被解码，但其他块会导致 decodeAudioData 抛出错误。我猜这与mp3 bit reservoir 有关，它在 mp3 帧之间创建了依赖关系。

【讨论】：

【解决方案2】：

如果您将文件拆分为从有效 MP3 标头开始的片段（12 位“1”在字节边界上对齐：FF Fx），您很可能会没事。

【讨论】：

我也是这么想的，但到目前为止我的结果并非如此：目前我只是想解决播放 initial 片段的简单情况mp3。在此初始段中找到的任何帧显然都以有效的标头开头，但 decodeAudioData 仍然失败...
块的结尾呢，它是否在下一个 FFFx 标头开始之前结束？如果您留下一些额外的数据或将其剪得太短，可能会影响播放。
是的，这似乎可以解决问题。谢谢，我会发布任何新发现。