为decodeAudioData定义'有效的mp3块'（WebAudio API） [英] Define 'valid mp3 chunk' for decodeAudioData (WebAudio API)

问题描述

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

I'm trying to use decodeAudioData to decode and play back an initial portion of a larger mp3 file, in javascript. My first, crude, approach was slicing a number of bytes off the beginning of the mp3 and feeding them to decodeAudioData. Not surprisingly this fails.

经过一些挖掘后，似乎decodeAudioData只能使用 Fair Dinkum Thinkum ，这里。

After some digging it seems that decodeAudioData is only able to work with 'valid mp3 chunks' as documented by Fair Dinkum Thinkum, here.

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

However there is no clarification about the structure of a valid mp3 chunk (the author of the aforementioned doesn't go into this). I am aware of the various mp3 splitters that exist out there but i'd like to approach this programmatically. (I'm trying to implement a kind of 'poor man's streaming' using nodejs on the server side).

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

So, would splitting on mp3 frame headers be enough or do I need to do more? (perhaps 'closing' every chunk by appending some data at the end?) How about the 'byte reservoir'? Would this cause problems? For the record, I'm currently working with 128kbps cbr mp3s. Would this simplify the process in any way?

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

Any info on what decodeAudioData expects as vaild data would be appreciated.

谢谢。

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

PS: I realise that this is perhaps a request for clarification on Fair Dinkum Thinkum's post but my low reputation is keeping me from posting a comment. So I can't see how else to do it but with a new question. Thanks again.

推荐答案

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

After more experimentation with decodeAudioData (on Chrome) this is what I've found:

• 任何初始 mp3块将被成功解码，只要它在mp3帧边界上被分割即可。找到边界可能并不总是微不足道的（例如涉及解析mp3头），因为即使是恒定比特率的mp3也不总是包含恒定大小的帧。例如，128kbps mp3文件包含417字节帧以及418字节帧。 （有些帧包含一个额外的字节作为填充）。


• 任意mp3块不保证可解码，即使在两侧的精确帧边界上分割也是如此。这种类型的一些块可以被解码，但是其他块会导致decodeAudioData抛出错误。我猜这与 mp3位库有关，这会产生依赖关系mp3帧。

• Any initial mp3 chunk will be successfully decoded as long as it is split on an mp3 frame boundary. Finding that boundary may not always be trivial (e.g. involve parsing mp3 headers) as even constant bitrate mp3s don't always contain constant-size frames. For example, 128kbps mp3 files contain 417-byte frames as well as 418-byte frames. (some frames contain an extra byte as padding).
• An arbitrary mp3 chunk is not guaranteed to be decodable even if split on exact frame boundaries on 'both sides'. Some chunks of this sort can be decoded but others cause decodeAudioData to throw an error. I'm guessing this has to do with mp3 bit reservoir which creates a dependency between mp3 frames.

这篇关于为decodeAudioData定义'有效的mp3块'（WebAudio API）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！