Beta releases of music: how best to name and tag?

11.26.09 | 17 Comments

A possibly rather geeky, but ultimately practical, question, for people who make &/or listen to music in digital formats.

Hello all – my first post here. Thanks to Steve for the opportunity!

One of the things that’s very appealing to me about the new era of music on the net is the idea of beta releases. I really like the idea that as soon as a song’s ready I could upload some reasonable version of it, without committing myself to that as “the definitive version”.

But then I’m wondering how those song files would best be named and tagged. Because wouldn’t it be a bit confusing for the listener to end up with multiple different versions of the same song, that all had the same name?

OK, I’m thinking ahead here, as I’m still tinkering around with recordings at the moment. I’m just very aware that once a file goes out into the world, it’s out there forever. If I decide later on a better tagging convention, I can’t miraculously get back all the copies so I can upgrade the tags. So it seems like a thing to invent & think through before I start.

Date vs version numbers

In an earlier round of thinking about this, I already decided that for me, the date is going to be the best way to identify the different iterations.

I considered extending the software analogy and using some kind of version numbers instead. But I’m pretty sure that nearly every recording I released would be v1.x (one point something). Less than one would imply it didn’t have all its bits yet, in which case I wouldn’t release it. And only rarely would a song reach v2.0, implying a major evolution or reworking. (Though, for other people, that might well be more likely than it is for me.)

So I’m not sure that version numbers really add much over and above using the date – whereas they do have a disadvantage: the extra thinking! to decide “how big a fraction” was justified by each new version. (In any case, using the date has precedent in software versioning – Ubuntu, for example.)

I don’t think I’m likely to release more than one version of the same song in a day, unless there were some kind of big mistake or malfunction which I needed to correct immediately. So the date should usually be sufficient to identify a particular release.

Similar but better

It’s also worth noting that in my case, all the iterations are likely to be pretty similar – so much so that even I might need to look at the date to know which was which quickly. I’m not usually trying to invent different versions of a song; for me usually it’s more like aspiring to an ideal version, which I never quite reach but try to get closer and closer to. The differences might only be the quality of emotion in the singing, or the fact that it was a few bpm faster or slower and that suits the song better, or that in the intervening time I practised the bassline some more with a metronome :-)

So I don’t think it’s all that likely that people will prefer an older version and deliberately want to keep it – though I’m not ruling that out. What I’m more thinking of is the scenario where people are unwittingly listening to, and propagating to their friends, a not-quite-as-good version which according to me has been superseded. So I see it as very much in my interest to make it easy for people to see which is which.

Where to put the label

Well, but I’m not convinced that I want the actual song title to sprout a date. I mean, obviously that’s a fall-back position, one way to handle it, but it doesn’t seem very elegant to me. What belongs in the name space is the name.

Now I know that the ID3v2 standard includes TDAT = Date. But I’m not sure if that gets displayed on a typical MP3 player – or, more generally, which tags do usually get displayed, that would enable the listener to see which version they were about to listen to. Or how easy it would typically be for the listener to choose to access that other tag data, especially on small portable players. I know that some display artwork, so I could include the date in the artwork – but not all do.

I see there exists “TIT3 = Subtitle/Description refinement”… and there’s also the option of naming the actual file to include the date. But, again, I’m not sure how common it is to display either of those for the listener to see while listening (either optionally or by default).

In which I note my ignorance

I’m a bit hampered in thinking this through by lack of experience of relevant tech. Inconveniently in this context, the MP3 player I’ve used most is the Zen Stone, which doesn’t have a display at all!

Also, the investigations I’ve done so far have been about MP3 tags in particular. But I’ll probably start using BandCamp shortly, and I know there you upload a high quality original and they auto-port it to other formats, putting in tags as they go. I’m imagining perhaps it keeps the basic filename and adds text to the filename to show the format, e.g. [songname]192kHz.mp3 or whatever – but I don’t know if all the other formats it uses have equivalent tag fields, or what.

Key questions


Am I stuck with including dates in my song titles if I want the versions to be reliably differentiable on playback, do you think?

And if I didn’t do that… for you as a listener, given your typical/favourite gear, how easy would it be for you to find out the date if you wanted to? Can you easily access the official date field? Is there a more convenient place for the date to be repeated, such as the artwork? If it were in the artwork, what percentage of the artwork square would it have to take up in order to be readable on your size of screen?

Or, to come at the whole thing from another angle… people who have done beta releases already, how did you name and tag them? :-)

All clues and ponderings very welcome…

Tags: , ,


have your say

Add your comment below, or trackback from your own site. Subscribe to these comments.

Be polite. Stay on topic(ish). No spam.

You can use these tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>