On audio formats

Over identi.ca there has been some short discussion about audio container formats.. you might remember that Ogg is an old pet peeve of me and thus I really can understand people not implementing it as it is.

What I said on the microblogging platform is that in my opinion, we should be pushing for the so-called MKA format; which is the usual Matroska format, just with a single audio track rather than both audio and video tracks. I think this is one thing that makes quite a lot of sense, especially if the track you host in it is the usual Vorbis audio. It’s not just a matter of what Ogg does wrong, but also the fact that Matroska/Vorbis is a combination that is sponsored nonetheless than by Google itself, with WebM.

Okay so WebM is actually a subset of Matroska, so there isn’t an absolute certainty that using a WebM decoder will let you play MKA, but given that most software is likely going to use one of the already-present Matroska demuxers, which play both WebM and MKA, there is really little work to be done to support this. As I have tested this before, mplayer, xine and VLC all play back MKA just fine.

It’s not even just a random chance, or a hack that might not work on the long term, or something entirely new that hasn’t been tried before. Ogg itself is able to support either a single audio track or multiple audio and video streams; heck, even the M4A format derived off Apple’s MOV format has the same design. This means that most of the software out there is already designed to work this way and does not expect a given container to always contain either only audio or audio and video.

Now, speaking about the Ogg shortcoming – on which I have ranted before – I would like to point out that a lot of self-appointed Free Software advocates are still suggesting that it’s perfectly fine as a modern format because it solves a number of issues that there are with mp3; if you’re one of those, I beg you to check your calendar: we’re in 2010. So yes, even though Ogg does solve some of the mp3 problems (but causes a few more), it doesn’t really compare with the modern used formats such as M4A/MP4 used by Apple, Sony, Android, …

Some of the limitations are actually taken directly from mp3 itself, like the design that allows for a single Ogg file to be created simply by concatenating a number of other files, or the fact that you need to know the content of the stream itself to be able to decode the containers’ data. But I think that the most iconic (sorry for the pun) is the support for album art/cover art.

If you want to add cover art data to an Ogg file, you have to add it as a comment (which is the freeform implementation of tracks’ tags for Vorbis; yes for the codec not the container); by its own design you cannot push binary data in a comment, so you have to encode it in Base64 (which is a representation of the 8-bit binary range into an ASCII-compatible alphabet). Unfortunately, encoding in this format means that the size is increased by an average 30%. This wasn’t much of a problem when you used simple icons to recognise one file from the other, but once again, we’re in 2010, and Apple actually spoiled us with their CoverFlow (and Amarok with CoverBling): you are now supposed to use high-resolution cover art in your files, to have the best effect at showing off the file you’re playing, and that 30% is now quite a lot of wasted space.

So, while Vorbis as a codec is not that bad, let’s stop pretend Ogg is a fine, modern format, and move on. We have Matroska, let’s use that!