Speculations. The ID3 tag is a simple symbol that you may have recognized if you used Winamp back in the day or curated an MP3 collection. It’s what makes up the metadata for an MP3 file. It was very limited in the ID3v1 version. They added tons of features and fields to the 2.0 version, as well as removing character limits. Then it became ID3v2. While ID3v2.4 is the latest specification, ID3v2.3 seems to be the most popular. Recently, I found myself having to look into this specification. If you want more background on it you can find it at id3.org.
ID3 has been my favorite type of standard. A de facto one. MPEG, and specifically MP3, didn’t allow embed metadata. One was created. It is added at the end. It is at the beginning of ID3v2 files. It is a binary format. This is not as easy to read if you’re used to JSON and XML data storage. As far as binary formats are concerned, it is fairly straightforward I believe. I have never seen one of these before. The spec documents are mostly clear and understandable but not at all mobile-friendly (I suggest browsing them via mutagen instead, they are better).
This post is not about technical details of the format. It is possible to write more about how it works with MPEG synchronisation. It is easy to implement parsing with Elixir thanks to the powerful binary pattern matching syntax. I could also talk about how easy it can be to encode new binaries using IO data. We are not doing that. This is about a simpler era, when people were more concerned about files than music and computers. This is one of the most entertaining and interesting things I’ve seen in the spec.
Note: I’m not a scholar of retro computing or someone who does a lot of research typically. This article will not include too many footnotes.
Parts in an ID3 tag are known as frames. Frames are a part of an ID3 tag. Although I don’t know which of these were used in production, I believe they offer a powerful picture of a different future.
There are many useful things like embedded images, links and embedded anythings. Recent developments have included additional specifications for Chapters or Table of Contents, which allow podcast episodes to include chapter information and chapter artwork. Fabulous stuff. It is very useful in my daily life. If you pay attention to what I do, the reason I looked into ID3 may lead you back to this use. If you’re interested in more information, the newsletter is available after this post.
What first brought to my attention is what made me look at the MP3 + ID3 files in a new light. Play counter (PCNT). This tiny frame has a number. It is the number of times that the file has been played. It should be incremented once the file starts playing, according to the specification. The file will change as users “consume” it. It gives one song a memory and a low-resolution story. The only files that I expect to be updated regularly are documents, text files and production projects (image/video/audio). Most of the files I deal are copied and converted by others.
It is absurd that your MP3 player changes your song files. It is worse, however, that people are putting MP3 files in their players of all kinds these days. This is something I doubt most players would do, but it’s possible. These are some of the strange cultural touches that could flourish. Personally I’ll never consider listening to any song with less than a 100 play count. Files that are well-known will be preferred. You can also find a legitimate single-digit playcount copy for a popular rip. This means that you are close to the source.
I know that I am being silly, but it makes my imagination tickle to think of that world.
The play counter is the smaller, simpler brother to a more wild frame . Popularimeter (POPM). It allows storing an arbitrary number of (up to the max frame size of 16 Mb I believe) email and rating pairs. An email string, a rating from 0-255 and a personal play counter. The ID3 Wikipedia Page was the topic. It is believed that some OS:es or players use this rating to show a star rating for a song. This frame is fantastic, I think!
Note: If you’ve heard the episode of the Regular Programming podcast where I get into this (not released at time of writing) I had forgotten about the personal playcount on the POPM frame.
Alright, I can rate your song. Please note. The file may have many ratings due to the email address. You can accumulate a lot of ratings if you keep sharing the same file. It is easy to see who has played it and how many times. This could be quite charming. I know it is. I am a sucker for songs.
I wonder if this was intended to be used in a way that a sample of a song could be downloaded in MP3 format and pre-loaded with ratings from some site. Is it really just an evolving file that allows for crowd-sourced wisdom? You can put ratings and Personally Identifiable Information into more files, and let the world hear what you have to say. It’s a beautiful thing.
The idea that ratings might be pre-loaded from a site and baked into a sample document is not something I thought of. Another odd one is here that will get to the business. The Commercial Frame (COMR). “This frame enables several competing offers in the same tag by bundling all needed information.”
Every offer includes the following. You can specify prices in any currency, the date that the price will be valid for, the contact URL to reach the seller, and a “Received As” field which indicates what product was delivered. There are many options, such as “Standard CD without other songs”, File over the Internet, or “Stream over The Internet.” You can also find merchandise and other useful items, as well as a lot more musically inclined people. It can include the seller’s name and an embedded logo ..
Store front is a standard. In a file. It is quite inspiring, especially considering that everything is a SaaS.
Some honourable mentions as truly useful frames are Synchronized or Unsynchronized lyrics. Although I think there might be one for captions in Accessibility Extensions, I am not certain.
The Event codes frame looks like fun. You can use the event codes for many purposes, including setting off explosives or controlling lights. You can also specify custom ones.
Since SQLite has become very popular, there’s no reason to not insert a SQLite file into the file embedding portion. 16Mb for a frame, 256Mb is the limit for the entire tag from what I gather. This thing can hold a lot.
I really wonder how much of this was ever used. It seems to be well-constructed. It is just so irrelevant to the current state of things. This makes me want to do silly things with MP3 files. You don’t really need an MP3 file. ID3 can be used in many places. It doesn’t even require any media.
The possibilities seem endless to me. While I find the current usages of ID3 to be completely irrelevant, I still want to know more. I have just started to explore ID3, so if you are familiar with the history and current day, please reach out. If you have written about it, I would love to hear more.
Note that this format can also be quite dense. You can’t use curly brackets unless they are in your text field. It is impractical at times to deal with a binary format but it does make me happy that the tag header provides more info in 10 bytes than what it would take me to idiomatically express the version of the tag in JSON.
"version": 3 (15 bytes)
ID3 3 0 0 0001 (10 bytes)
| | | |
| | | |______ 8 bit flags, here zeroed out
| | |
| | |________ spec revision: 0
| |__________ spec version: 3
|______________ starting indicator "ID3"
This stuff was a lot of fun to work with. As my implementation improves and becomes more useful, I will be sharing more. As I have enjoyed getting to know the specification and sharing my speculations as I encountered them in my work, I felt the need to share the human side of it.
If you have questions, comments or insight to share, do reach out at email@example.com or find me on Twitter as @lawik.