What's a music file container format?

It's wrong to think of music files as simple, monolithic buckets of audio. They can be, but most modern music file formats are what is known as a container format.

It's easy to think of music files in this way. There they are on your computer; double click them, they play! That's the function of a music file, right? One file, one action, music comes out. This mental model is also re-inforced by the fact that this is pretty much the way the world's most popular file format, MP3, is structured.

The reality is, of course, that music files generally contain more than just a raw audio stream. They also contain metadata; information about the music contained within the same file. The difference between a music file format which is monolithic, such as MP3, and one that adopts a container format, is that the latter has a more standardised approach to storing data other than that raw audio stream.

In the world of computer music collections, a container format is a music file format that is standardised to contain different types of data. So as well as the audio, and the metadata, it may also contain images and even video.

Is newer better?

Some old formats, such as MP3, have to adopt "hacks" to store metadata. ID3, which is by far the most supported type of MP3 tag, is slotted in at the start or end of a "frame" inside an MP3 file. This has been adopted as a convention, rather than mandated by a standards body. Because MP3 was never specified as a container format, it would be unclear to programmers how to interpret different data types. It's only because metadata is so popular that a de-facto solution has arisen.

But it's not the case that all old file formats got it wrong. Some venerable formats such as WAV have been container formats since inception. While it has taken a good deal of time for the foresight of WAV's creators to be recognised, the flexibility of the container format is now proving useful as audiophiles adopt the WAV format.

In most cases, newer music file formats are container formats. What might be seen as MP3's successor, MP4, is a container format (the comparison isn't really analogous, but still), and then of course there's the likes of FLAC which even offer the choice of two (count 'em!) container formats (the standard FLAC container format is the one normally chosen, but you can also package into an Ogg container).

There's an interesting battle playing out here between DSF and DFF, the two main DSD file formats. DSF supports metadata, suggesting it's a limited type of container format, whereas DFF doesn't support metadata in a standardised way, and is oriented purely around the packaging of the DFF audio stream. This gets a little contentious because the actual layout of a DFF file borrows much from AIFF which is a container format, but the "chunking" approach is quite limited in DFF files and used only for packaging audio within.

Advantages of container formats

Are there any advantages to having a container format?

In the context of music only libraries, there aren't many. Programmers have an easier time of it if the file format is more standardised and doesn't arise over time, like as happened with MP3 and ID3. Such a process would also allow competing tagging formats to arise; this then leads to more work, to support more tagging formats.

This also means the 'hacks' for crowbar-ing in metadata are less likely to lead to file format errors. These are particularly troublesome with MP3s.

For those interested only in music, and those that tend to adopt popular, mainstream file formats, there aren't so many advantages. They can get by with hacks like ID3-inside-MP3 and they don't care for video, so why bother? There's a potentially small risk of damage to music files caused by software if a file hasn't been written in a strictly correct manner.

Given most lossless file formats are container formats, this is just another reason to make the jump!

Thanks to whatStefanSees for the image above.
tags: coding standards

The Music Library Management blog

Dan Gravell

I'm Dan, the founder and programmer of bliss. I write bliss to solve my own problems with my digital music collection.