Define 'valid mp3 chunk' for decodeAudioData (WebAudio API)

Question

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.

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

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).

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?

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

Thank you.

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.

Answer 1

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

• 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.

Answer 2

If you split your file into pieces starting with valid MP3 headers (12 bits of '1' aligned on byte boundary : FF Fx), you most probably would be fine.