Every year since 2007, I’ve created a compilation of my favourite tracks first heard that year and shared them with friends. Last year I made a mini-site built around an invisible, javascript-controlled Flash player, and for this years collection I decided to experiment with HTML 5’s new audio features.
You can find my best of 2009 collection here. Twelve of the tracks include audio commentary (click the “Why?” button in the top left). I learned quite a lot doing this and I want to share that.
Supported browsers
The site works in Firefox, Chrome and desktop Safari; these are the major browsers that support HTML 5 audio at the moment. Due to their support of CSS animations and the HTML 5 range input, I recommend using Chrome or Safari to check it out; they get the added bonus of a master volume control in the bottom-right corner of the page.
The site navigation works fine in mobile Safari but music doesn’t play. Unfortunately mobile Safari doesn’t support HTML 5 audio, which is a shame. I’m hoping this will be something they’ll fix in time for the iPad launch.
That’s a small fraction of the market
It doesn’t work in Internet Explorer, which would be a problem for a lot of sites, but although I wouldn’t suggest going solely with HTML 5 audio for the mass-market at this time, it’s definitely worth investigating. There’s a good chance that HTML 5 audio represents a part of the future direction of the web, and if that’s the case it’s likely IE will pick up these feature eventually.
The site as it stands doesn’t support a Flash fallback for two reasons. The first is that adding the Flash fallback would have made the code messier. The second, more important reason is that it would have been absolutely no fun.
Pain points and gotchas
As usual, what I thought would be difficult was not as hard as what should have been easy. There’s plenty of gotchas when it comes to HTML 5 audio.
- Rapidly queueing new audio in your browser can cause it to crash. Hitting the play button, and then advancing rapidly to subsequent tracks, can take out your browser.
- To support Firefox, Safari and Chrome, I was required to encode and upload two sets of audio files: one in MP3, the other in OGG format. Though I appreciate the position the Firefox team is taking regarding the patent issue, uploading 200 megs of files on a home DSL connection is a right pain in the bum.
- By default Amazon S3 serves .ogg files as “application/x-ogg”, which Firefox refuses to play. Getting S3-served .ogg files to work in Firefox required going in and changing each individual content-type to “audio/ogg”.
- Creating new Audio objects isn’t a great idea, at least in this case. Twenty of them will kill Chrome so bad you need to quit the browser. The best way to add audio dynamically in HTML 5 seems to be adding <audio> elements to the DOM.
- Some browsers seem to throw the “ended” event too early. Overall, there appears to be a bit of a lag between what the browser thinks is going on and what is actually happening. Firefox appears to be the worst offender: songs continue playing for a few seconds after you close the tab.
- Google Chrome, at least the version on my Mac, doesn’t support variable bit-rate MP3s very well. Chrome will happily report VBR MP3s as finished seeking and tell you that the playhead is at the start of the file, but when you attempt to play it you’ll hear what appears to be the sound going in reverse.
- The “canplaythrough” event seems to be thrown a bit optimistically.
Overall impressions
HTML 5 audio support is nice but unfortunately it’s still pretty buggy across browsers that support it. It’s probably fine for smaller audio needs (like sound effects in a web app) but multitrack playback with multi-megabyte files seems a bit flaky at present.
It’s also a shame you can’t do a lot with the audio itself, other than change the volume. You can do some pretty cool stuff with HTML 5 video but unfortunately things like audio filters, graphic equalisation or any sound visualisation are impossible as far as I can tell in the official versions of these browsers (unofficial builds are a different matter).
Typefaces
“By” is set in Bickham Script Pro, but everything else is in Alte Haas Grotesk, a font I’ve been dying for an excuse to use. It’s free, too.
19 Comments
I love your best of site from source to screen. Fantastic work.
Posted by Stewart Curry at 1:37 pm on 9 February, 2010.
Cool. Love it.
Nice choice of music too!
Posted by Diarmuid at 7:05 pm on 9 February, 2010.
The music gets louder when the next track starts. Chrome/4.0.249.78
Posted by Alisey Lebedev at 9:07 pm on 9 February, 2010.
Good catch, Alisey. Seems to be another Chrome-only bug.
Posted by David Barrett at 11:19 pm on 9 February, 2010.
I like this a lot.
Posted by Naomi at 11:43 pm on 9 February, 2010.
Massive!
Posted by Angel Luis Gonzalez at 11:50 pm on 9 February, 2010.
That was a real pleasure, and really interesting to hear a total stranger explain their choice of tracks. Thanks for the little window in to your life, it made my afternoon really interesting.
Posted by John Noble at 6:15 am on 10 February, 2010.
Nice recap, and nice audio page. Did you report the various issues you encountered on the respective browser’s bug trackers? And did you re-check them against “nightlies” of them?
Posted by masklinn at 8:07 am on 10 February, 2010.
You should use MP4 AAC instead of MP3. Despite common misconception of it being Apple’s, it’s actually an open standard with licensing less restrictive than MP3 (guess why Linux doesn’t play MP3 in pure distros).
AAC and Vorbis have much better size/quality ratio, so that pair shouldn’t need much more bandwidth than MP3 alone.
Posted by kl at 11:56 am on 10 February, 2010.
Why are all the sub-titles here rendered in Flash????
Posted by mj at 1:16 pm on 10 February, 2010.
Meh. This page is completely unreadable in Opera!
Posted by sdfs at 2:04 pm on 10 February, 2010.
It would be nice if the HTML audio specification would allow or other identifiers.
And to easily stop playing sound, or simply fade out effects (should be trivial and not that CPU intensive really).
Posted by mark at 4:18 pm on 10 February, 2010.
What about anchors? What if I want to link the 2nd song?
Posted by John Tantalo at 1:06 am on 11 February, 2010.
Anchors can certainly be implemented, but weren’t as this wasn’t a priority.
It is tempting to tweak this a little more at the weekend. I’m curious as to what people consider “missing features”. My primary focus here was to facilitate a good experience of flicking through music played back via HTML 5 audio. I feel this site achieves that for the most part, aside from some unfortunate browser bugs that I’ve worked through where I can.
Posted by David Barrett at 1:40 am on 11 February, 2010.
@kl
Most Linux distros can’t play AAC either, since it’s patented and has very restrictive licensing. Considering that modern MP3 encoders such as LAME create higher-quality, lower-bitrate files than AAC encoders, there’s no reason not to use MP3.
Besides, MP3 plays on every handheld device made in the last 10 years, AAC on only a handful.
Posted by name at 6:43 am on 11 February, 2010.
Oh, perhaps you can give it a http://onepagelove.com
Posted by Angel Luis Gonzalez at 10:10 am on 16 February, 2010.
Came for the html5 audio, stayed and listened to all the music. Thanks for sharing that great list David! The personal notes are an EXCELLENT idea, and they’re beautifully implemented, i’d love to hear more
Posted by George Terezakis at 10:12 am on 26 March, 2010.
Nice article, just wanted to contest one of your points:
“Unfortunately mobile Safari doesn’t support HTML 5 audio…”
Mobile Safari does support HTML5 audio in iPhone OS 3.2 and 4.0 beta. In 3.2 autoplay doesn’t work and playing the audio causes the quicktime player to appear in another ‘page’. In 4.0 audio plays in-page.
Posted by Mark Boas at 8:25 am on 13 April, 2010.
Hi Mark,
Reports seem to indicate that is indeed the case. I’ll need to have a look myself when I have access to an iPad / OS 4.0 of iPhone.
However, these OS versions were released after this article was published. I stand by my comments as they were accurate at the time of publication.
If 3.2 behaves as you claim, then it breaks the experience I’d hoped to provide the user and does so in a rather horrible manner. Let’s see how 4.0 gets it.
David
Posted by David Barrett at 9:50 am on 13 April, 2010.