Free Music Can Be Good For Musicians

Our artists evidently think so, or they wouldn’t have allowed us to distribute it.

I still believe that the primary reason most artists choose to make music is to get their music heard. Buying a guitar, amplifier and a few pedals will cost about £1000.  Practice rooms are about a tenner an hour. Transport to and from practice and gigs is expensive.

It takes time, too.  Months writing music; weeks practicing it; days playing it live and recording it. Hours of burning CD-Rs, printing labels, folding, stapling and assembling. For what? 100 CD-Rs sold (eventually) at £5 a pop? A profit of £300-£400, split between the band. There are easier ways to make money. Lily Allen says free music damages these ‘up and coming artists’. How? They each lose £80 after spending £2000-£3000?

Against that, you can distribute your music for free. EL Heath would not have sold almost 5,000 CD-Rs; but he’s had that number of downloads from RoR and our uploads on Legal Torrents. Indeed, he probably wouldn’t sell that many CDs/LPs if he had a deal with a reasonably sized indie label and some nice reviews in  The Wire. The musician has lost their £80, but they have gained 4,900 listeners.

Releasing music for free can be good for musicians.

Free Music Can Be Bad For Musicians

There are limits on what you can do if you release your music for free.

You can never quit your job to become a full-time musician. You cannot use expensive studios unless you are already rich. You will not even make back the money you spend making your music. It is financially exclusive. Whilst new technology means anyone can make a decent sounding album for not a lot of cash, it’s always going to be beyond the financial means of some people. Yet given that any cash injection from sales or a label would only come after some initial recording, it is difficult to see how people financially excluded from making music are included in the present system.

Furthermore, we don’t believe it is the fault of free music that some people cannot afford to make music. It is a fault of the system. Our economics dictate that people are excluded from a number of activities. Free downloads can only be blamed for damaging DIY musicians from within the capitalist system.

Nevertheless, it is in a capitalist system that we find ourselves and this makes it difficult. Many of our dearest friends struggle to make music within that system and are finding it an ever greater struggle as people stop paying for their records because they believe music should be free.

Yet it is precisely because we are in a capitalist system that we will fight for something else. A system where people are not excluded from making music because they have no money. A system where people are not excluded from buying enough music to satisfy their desires because they have no money. Free music is a utopia, in the present; on behalf of the future…

Free Music can be Good for the World

We believe in things for themselves, not as market commodities. Hakim Bey laments the fact that the internet did not bring about the revolution it promised: he cannot find free carrots online. No, but he can now find free music. Perhaps our example will inspire others to think that they would like to share what they have produced with passion and love for others, for free. Perhaps if enough people did that money would be less important. A gift economy: from each according to their ability to each according to their interests. The prize carrot grower wants all to share her produce, and offers her carrots for free. Furthermore, she takes great pride in sharing her knowledge of how to grow such carrots.

In our utopia, all will be the property of all. The power of the commons will be restored to the people, and from the commons there will be land to farm, carrots to grow and music to listen to.

Free music is good for the world.

One of the things we say in our manifesto is that anyone could do what we are doing. This post (below the fold) describes the technical nuts and bolts of how this site works so you can maybe do the same. In particular it describes the genesis of the software that runs this site – Ribcage. We get a fair bit of e-mail about it, which I am always very pleased to answer.

Myself and The Fabulous Mr Eric Lee are going to host the first annual ROR hackathon in January – the intention being twofold. First to expand Ribcage beyond its current parameters – to interface with Last.fm and Musicbrainz properly, to add details of gigs for our various artists, to allow users to be informed of updates more easily. Secondly and more vitally, it is also to make Ribcage a WordPress plugin that anyone can install and use. The implication is, we hope, obvious: anyone who can run a blog will be able to run a download label. With the new WordPress 2.7 allowing plugins to be installed direct from the repository without messing around with FTP and the like, this means that you could go from a standard blog to a label blog in less than five minutes – imagine the possibilities!

Photo by flickring.

So without further ado, lets start at the beginning.

Specifications and Shopping Around

Over coffee sitting outside Aldo’s bar in Panicale, myself and Jell trashed out a list of stuff the site should definitely do or be.

• Be unbelievably clear and simple to use from users perspective
• Allow releases to be downloaded
• Allow releases to be streamed so people can have a listen, with a Flash MP3 player
• Allow decent levels of logging for these things so artists know if they are popular or what releases are liked more than others
• Embrace Bittorrent to save on server load
• Interoperate with big music databases online, for example Musicbrainz and Last.fm, be gently Web 2.0
• Allow the artists some easy way to get the files they wanted to release to us, without using the post
• So degree of automation in spitting out all the different type of music files we would like to be avaliable
• Be easy enough on the backend for almost anyone with basic net skills to use
• Obviously have profiles of the artists and details of their releases
• Open Source, standards competent – given the nature of the project

After a good Google around, there seemed to be no free tools for managing a website for a record label. Sneaking around the sites of other small labels I strongly suspected that most relied on custom made and proprietary scripts cranked out by the site designers, or just done with static pages.

This at first seemed an opportunity to hack together a full blown web application for record label and to open source it for anyone to use. Not wanting to start entirely from scratch, and given the recent explosion in popularity of such things, I considered doing the site in a web application framework with full MVC attempting to be as DRY as humanly possible. I settled on the name Ribcage, coz it works with Records On Ribs, innit.

My first port of call was the ever popular Ruby On Rails – which also has the initials RoR. Setting it up on my Mac was a huge chore and when I got down to developing it seemed quite clunky and difficult, but perhaps I didn’t ‘get it’ or even try hard enough. I know other people rave about it, but it just didn’t capture my imagination.

Then I tried the new kid on the block Django. Django is absolutely amazing. Once you SQL database is configured, it automatically creates an administration interface for you, with security and everything, saving acres of precious time. A few lines in a file could create a whole complicated XHTML view of the data. Hacking together the whole database backend adding bit took an hour or so, with familarisation chucked in. Developing for it had an elegance to it that was very attractive indeed.

Both, however, required me to master a whole new language (Ruby and Python respectively) and handle numerous learning curve head aches. I’d have to program simple things, like a custom bit of full blog software. Although drop-ins existed (for example Mephisto for Ruby On Rails, whipping up a blog in Django takes minutes), I didn’t like them, maybe in part because I plain didn’t understand them. I knew PHP and could probably have a bash at Perl, but I don’t have the soul of a programmer. So I wanted something fairly easy, and not something that was overkill for what was going to be a relatively simple site. A full-stack application framework was probably overkill.

I’d been using WordPress for ages to create various websites and blogs. It had a wonderful combination of simplicity and power. It also has a very helpful Plugin API, is extremely well documented and has a very friendly development mailing list. If I developed a plugin for WordPress I would have a very good blog backend interface that was well known and proven, as well as access to hundreds of other plugins and themes to customise almost every detail of the site to being precisely the way I wanted. It also allowed us to write copy elsewhere on another WordPress install and import it into the live blog.

In a wider picture, WordPress also had a significant advantage of being almost ubiquitous in the blog world. Any person with the skill to get through a WordPress install could just drop in our plugin and have themselves a fully functioning record label website, something which was highly attractive considering our manifesto commitments. A WordPress plugin seemed to be very much in keeping with the whole idea of what ROR was trying to do: it was DIY and could be passed on. It seemed like the perfect choice. Most people could not handle setting up a complex web application, and many ISPs don’t provide the ability to do so cheaply even if they could – most people could handle WordPress and a plugin with little hassle.

Developing Ribcage

During the development Ribcage I was very much influenced by the concepts of Agile Web Development and in particular 37Signal‘s book Getting Real. Ribcage needed to do what it needed to do well, not be over cluttered with pointless features or overcomplicated with confusing bits. All stages of the software cycle needed to be parallel. We needed to add little features here and there as needs be and have them live on the site within hours (or minutes). We needed to be super flexible, like the best Web 2.0 stuff.

For learning WordPress I learnt loads from simply reading the source code of other plugins and obviously from the WordPress Codex and hook/action reference found there.

To type the code I used Textmate and it’s project management features. I set up a little development environment on my Mac using the built in web server in Mac OS X and installs of PHP and MySQL that allowed me to test code before it went online. Version control and all that jazz is done with Subversion. It allowed me to collaborate with other people who have added bits and pieces when I have got stuck.

The advantage of Subversion is huge. Make a minor change to Ribcage and I can just use svn update in my Dreamhost shell to update the site: no buggering around with FTP or getting my mitts dirty. And with the amount of minor changes, as well as stupid mistake, I made, this saved a hell of a lot of time.

What Ribcage Does

Ribcage pretty much does all the things we set out for it to do. It allows downloads. It spits out streams and information left, right and centre. It has pretty much everything front-end we need, whereas the back end and portability are severely lacking. So here are the goals ticked off we met:

• Be unbelievably clear and simple to use from users perspective
• Allow releases to be downloaded
• Allow releases to be streamed so people can have a listen, with a Flash MP3 player
• Allow decent levels of logging for these things so artists know if they are popular or what releases are liked more than others The wonderful Mint provides high levels of information about our site visitors more generally.
• Embrace Bittorrent to save on server load – In the end this I thought was overkill.
• Inter-operate with big music databases online, for example Musicbrainz and Last.fm, be gently Web 2.0 - this is partially done, our January hacking will hopefully sort this out.
  
• Allow the artists some easy way to get the files they wanted to release to us, without using the post We did this in a slightly different way.
  
• So degree of automation in spitting out all the different type of music files we would like to be avaliable Ditto.
• Be easy enough on the backend for almost anyone with basic net skills to use The back end is fairly ropey but it works well enough. This will be improved in the push for a public version.
  
• Obviously have profiles of the artists and details of their releases
• Open Source, standards competent – given the nature of the project

Conclusion

I hope this short explanation might serve to give others ideas about how to develop your own small scale project as well as wheting your appetite for Ribcage’s forth-coming release.

In our manifesto we say that “Anyone could do what we are doing”. This is almost certainly the case, and like many labels before us, we are going to let you know, in the DIY spirit, precisely how we do what we do in a series of posts focused on technology and otherwise.

So how do we do it? First off, how do we get a record ready for digital release?

1. We either receive CDs through the post from our artists, or our artists upload their albums as lossless FLAC files to their FTP accounts on our server. FLACs are, as you might be aware, the same as CD quality, but somewhat compressed. With a CD I carefully rip it to FLAC using Max. Max is a free and open source Mac OS X program that rips CD and converts audio files from format to format with the absolute minimum of fuss. The well regarded Windows equivalent is Exact Audio Copy. I use it instead of using iTunes as a ripper even for importing CDs normally to add to my library. But more of that in a second.With FTP I just grab ‘em from the server. I use Cyberduck for FTP, which while not perfect, is very good, and quite acceptable in comparison to similar (but sexier) commercial applications like Transmit.
2. I tag the FLAC files with a program called Tag! It’s also open source and free and from the same programmer as Max. I ensure the files are tagged correctly with track names and other details and then use Max to automatically convert them to the four different types of music file we use on this site and do neat filenames and tagging. On Records On Ribs we have high quality variable bit rate MP3 (-v 0 --vbr-new LAME for you MP3 snobs out there), FLAC and Ogg Vobris for downloading, 128 kbps constant bit rate MP3 for streaming. To set Max to produce very good quality and potentially transparent MP3s at -v 0 --vbr-new follow these instructions. Originally the plan was to do all this in Ribcage on the server-side using command-line tools (the *nix versions of FLAC, LAME and Ogg), which we did with a couple of records. But our artist’s often odd song titles prevented the script from working properly without an extensive re-write and debug, so I opted for this method.
3. These files then wing their back over the internet via FTP to the site. To avoid too much carting huge files around around, I create the zip files in a SSH shell logged into our site rather than upload them. I just type in the command and bish bash bosh they are done.
4. All the details of the release gets added into Musicbrainz and then into our own Ribcage database with relevant copy. Within the next few days I’ll update Ribcage so I’ll only have to enter it on Musicbrainz and it will be slurped into our database with a single click. Artwork is scaled to different sizes and FTPed to the site. Once we click go, it appears live on the site.

Potentially the time between receiving the files over FTP from the artist and having the release live on the site is under two hours, dependent only on internet connection speed. The thing which takes the longest is writing copy about the record, which can sometimes take days if one if having a spot of writers block.

For example, I am assured that a certain artist will be sending a record over to me, possibly even tonight. I’ve got to cook dinner and watch Torchwood, but if he does it should be probably around and about, ready for me to write some copy and post it tomorrow morning, all going well.

Photography by Dan Machold.