为decodeAudioData定义'有效的mp3块'（WebAudio API）

Question

我正在尝试使用decodeAudioData来解码并在javascript中播放更大的mp3文件的初始部分。我的第一个原始方法是从mp3的开头切掉一些字节并将它们提供给decodeAudioData。毫不奇怪，这失败了。

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

然而，没有关于有效mp3块的结构的澄清（前面提到的作者没有进入这个）。我知道存在的各种mp3分离器，但我想以编程方式处理它。 （我正试图在服务器端使用nodejs实现一种'穷人的流'）。

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

任何有关decodeAudioData期望作为虚拟数据的信息都将受到赞赏。

谢谢。

PS：我意识到这可能是对Fair Dinkum Thinkum的post的澄清要求，但我的低声誉使我无法发表评论。所以我不知道如何做到这一点，但有一个新的问题。再次感谢。

Answer 1

在使用decodeAudioData（在Chrome上）进行更多实验后，我发现了这一点：

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

Answer 2

如果您将文件拆分成有效的MP3标题（在字节边界上对齐12位'1'：FF Fx），您很可能没问题。