Audio/mp3 handled differently by SeaMonkey vs Firefox

[Pim]

I need some help on this one, because I don't know what to check.

If I have an <audio> element with an MP3 file, it doesn't do anything in SeaMonkey, while it works fine in Firefox on the same computer.

So say, for instance, I have this:

Code: Select all

<audio src="http://scdm.wdfiles.com/local--files/1969/ScDM-1969-t11-L-s1.mp3" controls="controls" type="audio/mpeg">MP3 doesn't seem to be working</audio>

(or http://temp.strictquirks.nl/test-audio.html if you're unwilling to copy and paste this) it works as expected in Firefox, showing the controls and actually playing the file if you press the play button.
But in SeaMonkey, the controls appear for a fraction of a second and then they disappear. And the error console says Warning: HTTP "Content-Type" of "audio/mpeg" is not supported. Load of media resource http://scdm.wdfiles.com/local--files/19 ... 1-L-s1.mp3 failed.
The same <audio> element with an OGG file from the same location works OK in both browsers, so it's specifically a issue with MP3, not a connectivity problem.

So what's the difference? Like I said, I don't know what to check. The two browsers have the same add-ons, so that's not it.
This is on a 64 bit Linux under KDE, in case it matters.

[patrickjdempsey]

I don't think SeaMonkey supports the new HMLT5 MP3 handling that Firefox does. Basically Firefox passes HTML5 MP3's off to a player at the OS level. It's all very weird to me considering that Embedded MP3s will play in whatever your MP3 plugin is.

[Pim]

Yes, audio called up with <embed> or <object> does work, except that you're at the mercy of your plugin, and you you don't have as much control over how it looks, things like autostart etc. Oh well.

By the way, I've tested with a SeaMonkey Nightly (Gecko rv:36.0) and it works in there too, so maybe it's just a matter of having to wait for the next release.

[Frenzie]

Yes, audio called up with <embed> or <object> does work, except that you're at the mercy of your plugin, and you you don't have as much control over how it looks, things like autostart etc. Oh well.

Use OBJECT as a fallback to get the best of both?

[Pim]

Use OBJECT as a fallback to get the best of both?

Good idea in theory, but unfortunately this fails in practice. The fallback mechanism only works for browsers that don't recognise the <audio> element at all (in other words, very old browsers). You can put anything you like in the content of the <audio> element, it won't show up.

Unless you mean more elaborate fallback schemes, like using Javascript to detect if the audio file has loaded successfully and to inject an <object> if it failed. But I think that might be taking it a bit too far.

My chosen solution is to use two <source> elements, one with an ogg file and one with an mp3. Then browsers that can't handle mp3 files will use the ogg and vice versa.

[patrickjdempsey]

In a perfect world, Apple and Microsoft would support WebM and all of this mess would JUST WORK. What a fantastic waste of a new "standard".

[Frenzie]

Use OBJECT as a fallback to get the best of both?

Good idea in theory, but unfortunately this fails in practice. The fallback mechanism only works for browsers that don't recognise the <audio> element at all (in other words, very old browsers). You can put anything you like in the content of the <audio> element, it won't show up.

Huh, you're right. I'd always assumed you could simply do something like this:

Code: Select all

<audio src="bla.whatever">
<object data="bla.whatever">
<p>Sorry, bro.</p>
</object>
</audio>

Apparently, it's by design ("The idea is that there will be a common codec that all browsers support, so that this is not an issue. Getting such a codec is an ongoing effort.") Last I checked IE and Safari still hate the open web by not implementing Vorbis or WebM. Still, requiring JS just for a fallback is annoying.

[Pim]

Huh, you're right. I'd always assumed you could simply do something like this:

Code: Select all

<audio src="bla.whatever">
<object data="bla.whatever">
<p>Sorry, bro.</p>
</object>
</audio>

Well, you can, but that's a different kind of fallback, for very old browsers. This works, for instance, in Safari 5 (the last Safari that was made for Windows).

All modern browsers (that can handle the <audio> element) can use the W3C standard of using multiple <source> elements.

Code: Select all

<audio>
 <source src="bla.this" />
 <source src="bla.that" />
 <source src="bla.theother" />
</audio>

They will simple pick the type of source they can handle.
Of course there's no way to indicate an error if none of the sources are compatible. Oh well...

[Frenzie]

Not just very old browsers. I like Elinks and Netsurf, just to name a couple. But it sure is bizarre that Safari 5 might get a better user experience than SeaMonkey 2.30 if you're not careful. (Operating under the assumption that e.g. a plain link to the media as fallback is a better user experience than non-functioning media controls.)

[patrickjdempsey]

This is exactly the kind of situation that I'm talking about when I tell people that HTML5 Audio and Video is largely a failure. If you want to make *sure* someone can see/hear the content, you still just have to use Flash, with HTML5 offered for Mobile and some browsers. Also, you can do the detection you need up front with a UA sniffer (I know EVIL!!!) and then just feed them the correct content using php templates. Or you can use JS to detect the browser and then inject the correct content. This is the kind of thing most big websites do to get this stuff to work. For a basic static page, it just doesn't work IMO.

[Frenzie]

Also, you can do the detection you need up front with a UA sniffer (I know EVIL!!!) and then just feed them the correct content using php templates. Or you can use JS to detect the browser and then inject the correct content. This is the kind of thing most big websites do to get this stuff to work.

Maybe I'm missing yet some other piece of idiocy, but all that sounds like really stupid things to do. For IE and Safari you'd need AAC and H.264, which combined with Vorbis and WebM (VP8/Vorbis) should cover all browsers as far as HTML5 goes.* In that case the OBJECT element would work as a fallback for older browsers combined with the plain link fallback inside the OBJECT element for those without a Flash plugin. Of course you could put a couple more OBJECT fallbacks in there first because I'm sure e.g. the VLC and MPlayer plugins would handle both formats just fine. I admit it lacks the finesse one would expect from the dedicated AUDIO and VIDEO elements, but oh well…

Or if one feels that some automated dual encoding from master or automated reencoding (worse, but alas) is stupid,** there's still object detection through e.g. canPlayType. Which raises the question, why would anyone ever do any sort of UA detection in JS? What's broken about object detection? And is it so broken that just detecting one specific broken UA is not enough?

* Add Theora/Vorbis in OGV if you really want all browsers.
** It is. Apple and Microsoft should just support Vorbis/VP8 out of the box.

[patrickjdempsey]

No, for IE and Safari and Firefox and Chrome you'd just feed them all h.264 via Flash. For Mobile you'd feed them <video> h.264. Not hard, and guaranteed to work. When and IF all of the browsers agree to support the same codecs for <video>, then it's time to start putting it on webpages... and even then you need to keep Flash support for older browsers... so err... why bother really?

[Frenzie]

Because HTML5 AUDIO/VIDEO doesn't eat my keyboard input, so it's much nicer for playing things in browser, and it also allows much easier access to the raw video URL and thus loading it in a proper video player if desired. On the flip-side, Flash can be easily kept on a leash through click to play, whereas implementation of similar functionality for HTML5 VIDEO has been lacking despite associated promises in the spec with regard to the AUTOPLAY attribute.

But as to the question you put forward, because even ignoring user experience it sounds much easier and less error-prone to generate two or three files from the same source than to set up complicated server-side UA sniffing. Clearly you disagree.

[patrickjdempsey]

UA sniffing is required to support Mobile anyway because no-one has bothered to fix HTML to properly detect it. And everything else you said is only true in a perfect world where HTML5 video/audio actually "just works" which it clearly doesn't.

[Frenzie]

UA sniffing is required to support Mobile anyway because no-one has bothered to fix HTML to properly detect it.

That's one opinion.

And everything else you said is only true in a perfect world where HTML5 video/audio actually "just works" which it clearly doesn't.

Everything I said is simply describing my own user experience over the past three or four years. Two years ago I didn't even notice I didn't have Flash installed for weeks. Nevertheless, I think I gave some clear indications as to how that's nowhere near a "perfect world."

Anyway, now you're just repeating what you said before without clarifying why you say it. Do you think generating two or three encoded files from the same source is just too much trouble (or not future-proof) or is it the case that it doesn't "just work" as long as you provide Vorbis and M4A or WebM and MP4 (and Theora)? That is, do I disagree with you or am I ignorant of some fact?