Closed Bug 950023 Opened 10 years ago Closed 8 years ago

Update the mp3-without-id3 sniffing algorithm when specced

Categories

(Core :: Web Audio, defect, P3)

29 Branch
x86
macOS
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: vadim.bulochnik, Assigned: padenot)

References

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20131213030203

Steps to reproduce:

On Mac OS X Mavericks I have the problem with decodeAudioData when trying to decode mp3 file into an audio source. I always see an error in console: "The buffer passed to decodeAudioData contains an unknown content type". And callback of decodeAudioData never fires.

Was tested on Firefox 26 and Firefox Nightly.
Worked perfectly on Firefox 25.1.
Severity: normal → blocker
Component: General → Web Audio
Thanks for filing this, Vadim -- What mp3 file are you trying to decode? Can you upload it or provide the header info from it?  Are you able to play this mp3 file back within Firefox (not using Web Audio)?
Flags: needinfo?(vadim.bulochnik)
I've made several tests with different mp3 files, and some of files are ok.
For example, here is the problematic file: https://www.dropbox.com/s/2mu7ywux7ypbp4w/sample_webaudio_firefox_bug.mp3
And here is the file that doesn't produce any error: https://www.dropbox.com/s/tzfnbu6kjj5mxn2/sample_ok.mp3

Both files plays perfectly using HTML5 <audio> tag.
Flags: needinfo?(vadim.bulochnik)
Assignee: nobody → paul
Yeah, this is an mp3 sniffer issue (I think), I'll have another look tomorrow.
Okay, this is because we are spec compliant when sniffing binary data [1], in the sense that we limit the number of bytes we take into account to 512.

I verified increasing the limit works (for example to 1024, since in this particular file, the offset to match is around 835). Thoughts on what we should do? Plumbing a flag from decodeAudioData to the mp3 sniffer would do. It's not great, but the spec does not address this use case, as it is, and fixing it will take time.

Also, I'm not sure how this could possibly work in Firefox 25, since that code has not moved. Also, this is not platform specific.

[1]: http://mimesniff.spec.whatwg.org/#reading-the-resource-header
Flags: needinfo?(giles)
Flags: needinfo?(ehsan)
Can't we fix the spec here?  Or if that takes time, raise our limit to 1024 for now and fix the spec later?
Flags: needinfo?(ehsan)
Note that webkit/blink don't care at all, and happily sniff the file past the 512 bytes limit.
I think we should fix the spec. 512 bytes is a nice idea, but I haven't found a reliable way to detect mp3 in less than ~1.5k. Many files do work with less, but not all.
Flags: needinfo?(giles)
Blocks: 879429
(In reply to comment #6)
> Note that webkit/blink don't care at all, and happily sniff the file past the
> 512 bytes limit.

Yeah, last I checked they basically don't implement any part of the sniffing spec!  (But I could be wrong of course.)
I posted [1] on the mimesniff bugtracker, and started to write the algorithm for the spec (see the attachment there).

[1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24220
Paul -- It looks like it's taking time to fix the spec.  So, can we bump our limit to 1K or even 2K (as a trivial work around) until the spec is fixed?  If so, I'd like to file a separate bug to increase our limit to 1K or 2K.  And keep this bug for the root cause/spec fix.  Are you good with that?

I'm making this a P1 so it doesn't fall off our radar.  But then I'd make "bumping the limit" bug a P1 once it's filed and this bug (which is the root cause fix) a P2.
Priority: -- → P1
Paul -- I forgot to do a needinfo to you. Please see Comment 10.  BTW, I'm not asking you to file or fix the "bump the limit" bug.  I just want to make sure you're good with the plan.
Flags: needinfo?(paul)
Maire, I agree, I'll bump the limit on the meantime, with a comment referencing the ongoing work. I'll attach the (trivial) patch later today, in a new bug.
Flags: needinfo?(paul)
I created bug 967007 for this, and attached the patch there.
Lowering this to P2 and making bug 967007 P1.  Also adding a dependency so we remember to revisit the fix in bug 967007 once we have a fix here.
Severity: blocker → normal
Depends on: 967007
Priority: P1 → P2
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is fixed in Gecko. This bug is just to remind us to update our implementation for when the spec settles on a way to do this. No need to track this for a specific release: the fix for this bug was written in bug 967007.
Summary: Mac: decodeAudioData on MP3 files failes with: "The buffer passed to decodeAudioData contains an unknown content type" → Update the mp3-without-id3 sniffing algorithm when specced
Priority: P2 → P3
This has landed in the spec. The spec algorithm is now exactly what we have in Gecko (in fact, the algorithm of the spec is derived from the Gecko implementation).

We can just close this.

https://mimesniff.spec.whatwg.org/#matches-the-signature-for-mp3-without-id3
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.