<audio>, the silent browser killer
Firefox doesn’t support MP3 in it’s HTML5 <audio> tag. Either they’re doomed or we’re all screwed.
Occasionally my wife and I will record a song together and release it on our blog. I was using the WP Audio Player plugin to show off these little ditties, but at some point this month it unexpectedly broke and ceased loading.
I couldn’t be bothered to track down and fix the bug or even another audio plugin. In a brief “A-Ha!” moment, I thought, “Why not just use HTML5?” So I threw in the brand new HTML5 <audio> tag and…
Instant success! Sure, it’s not the prettiest thing in the world but if the browser is working the magic it’ll never break again and I’m satisfied. I was pretty elated and began thinking about how this would positively impact and speed up a music blog I help run. I was drunk on simplicity.
Firefox #Fail
I remembered that some of my friends still use Firefox as their primary browser so I thought I’d just check the site in Firefox and take a peek at the design of their HTML5 audio player. Unfortunately, all I saw was a big ol’ “X”.
Some quick googling led me to the answer. Firefox’s <audio> tag implementation only supports Ogg Vorbis and WAV. I was shocked and astonished at the fact that a browser as great as Firefox doesn’t support MP3.
The <video> Wars
It appears the problem connected to the same issue the <video> tag is facing: codec licensing issues. This lack of standards issue is raised a lot in the HTML5 vs. Flash debate. I personally don’t care what standard is decided – I only use H.264 because that’s what ships on my Mac – I just want a standard. Although it would be nice if H.264 was the standard and the majority of the web didn’t have to re-encode their videos, I understand that licensing it from Apple could potentially bankrupt Firefox. As inconsequential as this codec thing may seem, this quibble is making HTML5 impotent.
How does the <video> tag make my life better if I have to create 3 different versions of the same video for cross browser support? Answer: none better. It renders it useless.
Unfortunately for Firefox, in reality there’s never going to be a massive shift in the web towards Ogg. Especially if at YouTube, every minute there’s 20 hours of video being uploaded that’s immediately encoded in H.264.
No one uses Ogg Vorbis. The web uses MP3.
The Open Source Utopian Dream is great: a world without restrictive licensing. But when the rubber meets the road, no one is going to spend the time to specially convert audio files to Ogg just so they works in Firefox. In the case of Austin Town Hall, it has (to-date) 1,196 songs on it – all MP3. It would take seconds to create a plugin that would change the current shortcode tag to output HTML5 instead of Flash. However, it would take hours or even days to hunt down, convert, and re-upload to each post in an Ogg format.
I could understand if Firefox chose not to support AAC or M4A, but MP3 however is non-negotiable when it comes to audio. It’s ubiquitous. It’s the established slang term for “digital audio file”. It’s an inseparable part of the web’s history.
The Bottom Line
If Firefox cannot support MP3 in their <audio> tag, it’s as useless as a CD player. If Firefox will not support MP3, one of 2 things will happen. One: HTML5 will remain dead in the water or Two: Firefox will lose browser share bit by bit and eventually go belly up in this episode of the Browser Wars. In the meanwhile, if Firefox cannot license MP3 they should at least be cognizant of the fact the web uses MP3 as its standard and degrade their <audio> tag if the source file is unsupported.
So what can you do? Not much really. It’s a total stalemate. Web developers have to sit around and wait for the working groups to get over themselves and come to consensus. Someone needs to make a website called Write Your WHATWGressman. Then we can let them know that this needs issue to be solved… and FAST!
Good points, but isn’t the fallback the beauty of and ? It might not make the designer’s experience any better, but it will ensure that the user never has to see a “You don’t have what you need. Please download something” message.
You’re right!
The problem with degradation in this circumstance is Firefox’s fall back for audio+mp3 is the black X. Which is maybe more simply my point. You have get into feature detection (with modernizr or what have you) to determine if MP3 is supported by the browser and then implement a fall back.
The IE6-8 fallback is to ignore the audio tag and just output what’s in between. That would be the preferred fallback if the browser doesn’t support that type of audio. Ironically, IE beats Firefox in this.
But even more importantly, there is really no excuse for not supporting MP3 on the world wide web.
I look forward to the day I never have to download a plugin again.
What I mean by fallback is this:
Source: HTML5 Doctor
Again, I agree, its alot more work for the developer, but if you provide the right formats, it should improve the user’s experience.
According to that article, Firefox does have the unfortunate problem of not actually falling back to another format, but if you put .ogg before .mp3, everyone should play nice.
This is all totally theoretical (for me), as I have yet to try out
</audio>and</video>. But as much as I’ve read, the solution seems solid.yah. my only problem with that is that it’s a lot more work. and uploading duplicate content violates the DRY (Don’t Repeat Yourself) principle. Basically we’re filling up the internet with duplicate content. so i’m kind of fundamentally against it.
In the case with Austin Town Hall i’d have to re-encode thousands of MP3s, upload them by hand to properly associate them to one of the 6000+ posts, teach our editors how to do that in the future, and then implement a system of custom fields to support both types of audio files.
When this falls on Occam’s Razor, we see that the simplest solution, the best solution, is for FF to just support MP3 so we can all move on.