Re: decodeAudioBuffer, XHR and MIME headers

I think the Web Audio spec must refer to this specification <
http://mimesniff.spec.whatwg.org/> when it comes to sniffing mime types.
One of the problems we've had in the Gecko implementation is that we've had
to consistently update our sniffing algorithm (and the specification as
well) according to the MIME types that WebKit/Blink accept, for
interoperability sake, and it's not always clear what types of content
we're missing until people file bugs about them.  It would be great if all
implementation rejected content which did not adhere to the spec (or extend
the spec in case they want to support such content).

Cheers,

--
Ehsan
<http://ehsanakhgari.org/>


On Wed, Jul 24, 2013 at 6:45 PM, Jens Nockert <jens@nockert.se> wrote:

>
> On 24 Jul 2013, at 23:26, "K. Gadd" <kg@luminance.org> wrote:
>
> I cannot comment on precisely why the mime-type is important; I've never
> actually written an MP3 decoder. But I know that the lack of mime type
> information has at least caused problems with Web Audio in Firefox thus far.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=865553
>
> From what I understand, the problem is that they must automatically figure
> out what type an audio file is, and this is very difficult without having
> the assistance of mime-type. This certainly meshes with my understanding of
> things, given that canPlayType and <audio>/<video> sources all use mime
> types as part of their infrastructure for deciding what to play and how to
> play it. Given the amount of engineering effort that seems to be going on
> related to that bug, I assumed there was some sort of challenge involved
> here. Maybe it's actually a super easy problem to solve and I'm just
> missing something.
>
>
> I'm not an expert either, but I have at least implemented an MP3 decoder
> (and a few other common formats) and have a bit of insight into the problem.
>
> After reading the bug, it seems like they know what the issues are, and
> how to solve them, just that there is a bit of effort involved that could
> (not counting licensing reasons) be solved with copying the code from for
> example ffmpeg.
>
> a) One problem is that they are currently sniffing for an ID3 tag, not an
> MPEG-1 elementary audio stream. You unfortunately cannot expect an MPEG-1
> stream to contain an ID3 tag (many do not), you should sniff for audio
> frames.
>
> b) They also have not implemented MPEG-2(.5) support for MP3 yet, which is
> another stream format for MP3 (and layer 1/2), with the same MIME-type
> (audio/mpeg). You need to separate these two via sniffing, they have a
> version field in the headers for each frame.
>
> I also think that ADTS (AAC audio) may have the same MIME-type
> (audio/mpeg) which means that it is even more diluted.
>
> FLAC/Vorbis in an Ogg container would also share MIME-type (audio/ogg).
>
> Hugs,
> Jens Nockert
>