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
So…
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…
Jennifer, this is SUCH a great question. I need to give it some serious thought. It has all kinds of implications for the ‘semantic web’ or whatever it is we’re climbing towards with the accumulated metadata of the new-web. Brilliant question, great spelling out of the various problems. Hopefully the wise and learned nerds that frequent here will has some suggestions 🙂
Thanks, that was a lovely comment to wake up to!
It did strike me that if anyone in my “network” were interested in this particular specialist corner of data geekery, they’d probably be hanging out here – hence login request 🙂
May I have a login for this site please? Thank you so much! I would be so happy to be involved with this wonderful forum on music! ~Beatrice Boltz
I use a partial name and a number. So an intermediate version of “Drawings in the Dust” is dust3.mp3. Each new mix gets a new number. And yes geeks, they’re unique and monotonically increasing. The operating system dates the files anyway. If ut’s an outside project, I keep a spreadsheet with the name, date, and what’s changed in that version.
Philosophically, I really want the “beta” versions to feel like beta versions Hence the limited name. These beta releases in my case have a limited distribution and a limited life. In a perfect world, they would all magically disappear once the final version was released.
Interesting. Your example demonstrates that if you know the status at release time, the labelling problem is rather simpler.
For me, it’s not as clear-cut and binary as that. I’m even questioning now whether “beta” is the right term in my case; I’ve been thinking of them in those terms, and it seemed to fit here partly because I knew you all would know what I meant, but perhaps in my case they’re really better labelled “iterative versions”.
There is at least one unambiguous binary transition point: where they get put on a CD album. And in my mind that does seem to have some kind of implication that I’ve decided a version is “good enough” in some sense.
But I don’t expect to know “in the moment” when I’ve got to that version. It’s an integral part of how I work to do a recording and leave it for a bit, and then discover what it sounds like when I come back to it “with fresh ears”. And then it could go either way: either “Hmm, but such-a-thing doesn’t sound quite right now” or “Oooh yes, I like this”.
And for me, part of the point of betas-or-whatever-you-call-them is being able to share things at that interim stage – being able to share them before I’m sure “yeah, this is good, this can stand as my representation of this song”. Or to put it another way: I’d be releasing them before I’ve decided whether they’re betas.
I don’t think it’s unrealistic at all to imagine that a release of mine might be “best available” for a year or more and yet still be superseded later. (Especially as I’m likely to prioritise recording unreleased songs over revisiting ones that are already out there in some form.) Or, conversely, that I might release something while thinking “I’m not sure about this”, only to decide later “Actually I like that version, it’s better than I’d realised!”
So, a somewhat different problem from the one which is solved by your solution…
A piece of music isn’t the same as a piece of software. The latter might have bugs that bring your machine crashing to a halt and “beta” is the get out clause that says “you asked for it”. Hopefully the same won’t be true with a piece of music!
I liked what Miriam Jones did with her EP last year. If you pre-ordered, you could download (pretty decent) rough mixes before the CD itself was released. Steve did the same with his Lawson / Dodds / Wood trio.
I wonder if the place to look though is not the world of software but the world of music bootlegging. I’ve not looked at it for a long time but, somewhere, there used to be a site where you could download and trade recordings from bands who were cool with the idea (like Bela Fleck and the Flecktones). With the bands that like to jam, I’m sure you can hear ideas developing into songs and songs mutating over the course of a tour and there might be some relevant protocols to borrow from there.
Bootlegging angle = good idea!
Beta terminology: Hmmmmm. You’re right, it’s not the same. The more I think about this now, the more I think that beta is (in my case) the wrong analogy. (Though in practice, some beta software is pretty stable and only lacks some intended features, and sometimes the declaration of 1.0 is more of a ritual moment than a big increment in prime-time-readiness, so I think your characterisation of beta software is possibly a trifle unfair 🙂 )
Re Miriam Jones & L/D/W, what strikes me is, this is the same paradigm as what John described above. There’s the “half baked” stuff of interest to fans, and then there’s the “final” version for people-in-general. I think those examples arguably do justify beta terminology – don’t you think that if those early releases had been given version numbers, they’d be less than one? correlated with the term “rough mix”?
But this expectation that if there’s a hardware release (CD or whatever), then the “real version” correlates with the hardware release: it’s occurring to me now how old-world that assumption is. What if there’s never a hardware release? only an evolving series of digital files?
which is why the bootlegging angle is a closer model for what I imagine myself doing – there’s no binary rough/final, and there are different versions spread over time, some or all arguably equally valid with others. (Though it differs in that the bootleg connoisseurs probably do want multiple versions.)
Oh another better analogy just occurred to me – science. That any scientific theory is only provisional. And some of them have lasted a long time and not been disproven, but they still could be. That is a better metaphor for my song recordings.
(Of course it doesn’t solve the tagging question yet ::laughing::)
The pre-release bonus editions weren’t really half-baked; perhaps not as trimmed and polished but I haven’t thrown either set out in favour of only listening to the “hardware” release.
Moving away from those examples, how about the world of jazz? That is a genre which prides itself on constantly refining and redefining tunes and solos. Even an artists own works will vary from recording to recording – if I wanted to tell you what I’d been listening to specifically I’d have to tell you something like “Ron Carter’s version of Autumn Leaves from his 1973 Village West recording”. Whether that is better or worse than any other recordings of the track, by Carter or other artists, is a matter for debate. You can however clearly define which version you are talking about – for a track name, the date would be enough given other ways of finding out details like where and who.
The pre-release bonus editions weren’t really half-baked
Oh OK, I withdraw that label then. (No offence intended to any of the musicians!) But I still think that the term “rough mix” implies some connotation of <1.0 status.
I haven’t thrown either set out in favour of only listening to the “hardware” release.
::perks up at the sound of a possible data point::
Have you ever stored both at once on an MP3 player or in music-file management software, and if so, how did they show up different? Or have you only played the hardware copy on hardware so far?
how about the world of jazz?
Hmm yeah, another useful comparison.
You can however clearly define which version you are talking about – for a track name, the date would be enough given other ways of finding out details like where and who.
Yes. So then my question would be how in practice those tracks are tagged, when they appear as digital files. (I can imagine, for instance, two tracks with the same name but different album artwork.) Got an example?
Both have got separate folders for the pre-release tracks, which include “rough” or “rufmix” in the filenames. The idea of being unedited is also included in the file tagging. It works well although it does assume that there is only one pre-release version.
In effect, it is like having another album by each of them. The same is true for different jazz performances – each is clustered under an album.
Perhaps one way to go would be to have a “virtual album” for each month or quarter or year, depending on how often you expect to revise tracks. You can then identify each song by its name and the time period it appeared in. If you do several mixes over a short period, you could always append a suitable descriptor to each song name (eg. “Jennifer’s Song – handrum mix”, “Jennifer’s Song – multivox mix”).
Another approach might be to name every song including year, month, date and even hour and minute to pinpoint when you decided it was ready for others to hear (eg. my_song.2009112813.mp3). Period based directories would still form a way of organising these into virtual albums for the purpose of doing things like tracking who is playing what.
Wulf
A service like SoundCloud allows you to upload NEW versions of existing tracks, overwriting the track that’s already there. If you label your track in MP3 tags (comments field?) with SoundCloud then you could use SoundCloud as your “development release” area and Bandcamp as your “production release” area. Any MP3 with SoundCloud in the tag somewhere is then identifiable as your development mix.
It’s a little akin to using SourceForge or something like that for code development. I’ve been developing some code that sits in a SourceForge equivalent and gets tweaked, developed, new features and so to users is the “unstable but newest, latest” version. The version that gets uploaded to the “Official” release environment has to be tested, documented and is the pukka version that folks download if they want to know that it’s stable.
I wonder if a site like Soundcloud could be persuaded to implement versioning facilities and uploaders would have the option, rather than overwriting a track, to upload a new version along with an update history. The naming and labeling issues would still need to be addressed but I like the idea of the infrastructure being available to track updates.
This would both allow people to listen to tracks as they are being developed but also to go back and listen to earlier versions of their favourite tracks.
I think that would be very useful. Sometimes you build a deeper emotional connection with a particular version of a particular song – it might not be what the artist currently considers to be the best version but it is the one you have spent time listening to, perhaps at an important point in your life.
Maybe that is where the beta idea could work – tunes which are put up as works in progress but with no promise of being maintained forever. In contrast, a tune might have several “release” versions which form the artists discography and those would be kept available as long as possible.
The latter would be what we are used to, particularly in genres like jazz. The former is more like what you would get if the musician in question were a local friend of yours and you sometimes popped by for a cup of tea and got to hear what they were practising.
I like that analogy. I think one of the better ways that some musicians use the web is to allow us to metaphorically “pop in for a cup of tea and to see what they are practicing”.
rather than overwriting a track, to upload a new version along with an update history.
Yes. I already plan for each song to have a homepage on my own site, and the homepage link to be included in the file – so that would be a natural home for versioning info (not reliant on Soundcloud).
On the other hand, reading your comment I’m also thinking the music file itself could perhaps include a comments field for documentation of previous releases of the same song. It could certainly include a suggestion to check the home page for later releases.
On the other other hand… the problem I’m least feeling I have a solution for isn’t deciding what to embed – it’s where to embed it so that the average user (a) realises it’s there and (b) can easily access it while listening.
Two things strike me.
Modern recorded music is a lot like software. You take various elements, all on different tracks, and cut and fade between them – sometimes adding effects to a single track or to the whole thing.
You need a way to keep pace with all those different versions. Something like SVN, CVS, GIT. I’m sure there’s dedicated musical software.
That way, you can release the “source code” to your music.
Imagine, if you will, that you could download The Beatles’ Sgt Pepper in multi-track format. You could replace the horn section that you never liked with some saxophone. Because you’ve got the isolated vocals – before they’re mixed – you could sing in harmony with Paul, cutting John out of the equation. Don’t like the echo effect? Uncheck a button and / or replace it with something else.
In your own music, you could take the vocal track from take one, the bass from take 27 and use the drums from an entirely different song. As long as you’ve versioned them all correctly.
Open Source Music – versions, branched, forked, remixed. Could be very interesting.