Join the Conversation


  1. 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 🙂

    1. 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 🙂

  2. 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.

    1. 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…

  3. 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.

    1. 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::)

      1. 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.

        1. 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?

          1. 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.


  4. 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.

  5. 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.

    1. 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.

      1. 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”.

    2. 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.

  6. 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.

Leave a comment

Leave a Reply to Wulf Cancel reply

Your email address will not be published. Required fields are marked *