The trick is getting rid of all the middlemen, and having a *really* reliable URL that represents the band. From there the band can dish out reliable URLs to MP3s (could be 3rd party) which can get aggregated and indexed by search engines. That will in turn improve the search relevance of indexed mp3 links so that music bloggers, Songbird, Google, Facebook, etc can quickly see that the most relevant and reliable source for music is the band itself, and link directly.
Perhaps the simplest solution is just encouraging ultra-solid URLs. Have bands register their domain name, and maybe have a service or script using Apache rewrite that resolve to the most current mp3 of a file
Example:
http://www.radiohead.com/album/in_rainbows/song/nude
I do think they need their own domain name to maintain ownership over the URL, even if the root domain redirects or redisplays their myspace page.
I could see a whole service being built around providing redirect links to other webservices, but giving the band control over these redirects (or having multiple sources to cycle through).
I really like the idea of enabling musicians to create ultra-solid URLs for their works. It’s inspiring.
Over on Webjay we found that the stability of URLs was highly variable, and stable URLs out-competed transient ones. This worked courtesy of viral URL sharing — people got new instances of songs by copying URLs rather than by uploading their own rips, and it takes enough time for a URL to get passed around that only the stable ones can really compete.
Stability is correlated with being on the up and up.
Authorized hosts are in a position to keep the URL going. The system administrators work *towards* stability rather than against it. Unauthorized ones get a DMCA takedown request, or an internal audit discovers a file that is counter to policy, or they were based on a transient account like a college student’s.
In my visualization of a Webjay-friendly future for internet music, I pictured bands actually changing the target of the URL as time goes on and their needs change. At the beginning they just need exposure and the URL would be a full length MP3. Midway through they would have a dispute with the label over rights to the recording and would convert the song to a 30 second sample. Further on they would have the full song, but with an an audio ad appended. They might provide a high bit rate version if your cookie indicated that you had filled out a survey. They might use HTTP content negotiation to return a version in the file format which is best for your player.
Etc — the general point is that the URL would be persistent, while the representation of the underlying song would change. It’s RESTful, and because of this the musicians would be taking advantage of web architecture.
The hardest part about selling permalinks to less-technical musicians is that the value proposition is very abstract. Myspace’s angle: “get a bunch of people on your profile and maybe they’ll come to your shows.” Compare that to the open web: “put your music out there where anything can happen to it, and over time your rewards will be greater.”
The open web seems scarier (the loss of control) and its upside so much more vague. Even for geeks, the value of URI-following can be hard to understand. Once you get it, you see that things aren’t “really” online until they are permalinked. The question is: How can we show artists the value of being really online?
The biggest single argument for the open web is the flourishing of conversation across the blogosphere. Music blogging is still in its infancy, but as MP3 blogs become the routine way for new music to break, I expect a change in the way artists and labels value being online.
We’ve heard a lot about how music bloggers are wading through crappy file-hosts and legal grey-water. Perhaps the best thing to do is build tools and examples that lead to communities of practice among MP3 bloggers, where permalinks and open standards can prove their value. If we want the creators of culture to respect the open web, the best strategy is to encourage music bloggers to understand and embrace those same principles.
I suppose it isn’t an all-or-nothing deal, between myspace and the open web. After all, myspace is part of the web too. But I think trying to communicate to bands that myspace is only part of the puzzle is important; that myspace is a resource to actually drive more traffic to their own site, where they will gain greater long term rewards (if setup correctly).
For bands that care, I think they will see the benefit of this, if the benefits are made apparent and the tools are *easy* to setup.
Solid links to MP3 downloads, search engine relevancy, more streaming media, email listserv, paypal store, are all great benefits to having your own website.
Encouraging bands to create a rock solid online presence, while at the same time encouraging MP3 bloggers to link to the band directly, will hopefully lead to a convergence of ideas about how music can flow through the web.
I agree with Chris that music bloggers make a much more promising audience for arguments about the value of persistent, well-designed urls, that bloggers. As those of us who are musicians and who work with them know, musicians are just not that — let’s see, what would be a polite word for it here? — ‘proactive’. The vast major are very unlikely to ever take any extraordinary effort to do something that helps themselves, no matter how easy and simple it might seem to us.
The only reason for joining an online service that will ever be convincing for musicians is peer pressure. And to overcome their overwhelming slothfulness, the peer pressure would have to be so great that it would probably need to come not only from their fellow musicians, but from a few tens of millions of their closest friends. And even then, the service must be so easy to use and understand that you’re really looking at a ‘lowest common denominator’ kind of offering. The only sites that can fulfill these criteria are gonna look a lot like MySpace or Facebook. To whatever extent these walled garden social networks become open and modifiable (and I think it’s a close call between Facebook and MySpace as they currently stand) it will be easier for people like us to offer the bands that use them services that take advantage of proper web architecture to help them spread their music.
Music bloggers, on the other hand, take linking as their main activity. This means that they’ve felt the frustration of trying to link to songs trapped in the frozen prison of the MySpace flash player; they’ve been bitten by the venomous snakes of temporary file hosts; they’ve bathed in the warm glow of increased PageRank from bigger bloggers ‘deep linking’ to the permalinks of their old posts; etc. All of these experiences make the bloggers valuable potential customers for services that offer to relieve the pain coming from the broken non-webish bits and expand the pleasure coming from link love and other webish virtues.
I agree with you about persistent URLs, in light of the compelling reason that the annual cost is minimal and the freedom from “hosting hostage” is maximum.
A band URL and a URL for each key release gives one the power to redirect from host to host, as the situation permits or requires.
One thing about musicians online who use MySpace or similar sites as the main web interface: we’re still early in our stages of transition to web-music. It’s not unlike how, for many years, a lot of people thought that AOL was the web. Right now, some musicians maybe think of MySpace as the web, in some sense. That will change a lot over the next 2-3 years, IMHO.
***
I think of this opportunity with URLs as being something like citations in books. In the music as information age, everyone is getting and sharing music via references–technically, even when you are clicking in iTunes to play an mp3 file on your hard drive, your actually clicking an icon or some text that is just a reference to the file.
So, like with citations in a book’s footnotes, there’s a need for some format for music references that is compact, concise, portable (in terms of reuse across systems), flexible (in terms of representing a concept that doesn’t break with minor version changes) and works permanently as a reference.
If you look at URLs and web pages in these terms, the thing you’d want is a permanently reliable source to ensure that a URL always represents the specific conceptual form of the thing you want to reference.
For example, the Wikipedia page for Purple Haze could be a good source reference for that song, if versions of that song were also part of the page, e.g., you could essentially push play on the Wikipedia page in your music player, and hear the song. A page like that could also link to other pages representing more specific versions of the song.
I think, over time, musicians are going to see this kind of IDing their songs online as being as essential as giving the songs names. You don’t have to name your songs, but you need to permanently name them to some degree when they become recordings that get distributed. When you really distribute those songs on the web, you need to give the songs a permanent URL too.
There’s a hook for these persistent identifiers in XSPF — the identifier element. That’s not necessarily a playable version of the content, just a consistent way to identify the content across any number of locator URLs. The wikipedia “Purple Haze” page is a completely valid XSPF identifier, even though it doesn’t return a media file.
This is valuable when you need a level of abstraction beyond a direct locator for a file. For example, a content resolver might try to map the wikipedia page title to the id3 title tag of free range audio files.
As a musician, maybe the thing I want to do is release my album as a XSPF file that associates each specific mp3 URLs with an identifier that is also my URL, e.g., the page I’ll create for each song, or the fragment for that song on the album’s tracklist page, etc.
Although acting as a database of “authority” records is not particularly within the scope of XSPFs use cases, there’s some sense in this in that one of the biggest issues is getting music players to use more concept-oriented identifiers than just file locations–there might be a natural step for players who support XSPF in general to evolve to more interesting uses of XSPF identifiers.
That’s a completely valid use of XSPF. It takes great advantage of the semantics, and I like it a lot.
Something like this would make the statement that the URLs in the location elements (“locators”) are equivalent, and the URL in the identifier element is a name for the abstract song which both locators are pointing to specific instantiations of:
playlist
tracklist
track
identifier
http://en.wikipedia.org/wiki/Purple_Haze
location
http://example.com/one-version.mp3
location
http://example.com/another-version.mp3
Cool — I am planning out the pages for my new album, and I’ll include identifier URLs in the XSPF playlist just like that.
And, maybe some folks into Wikipedia or MusicBrainz can start using XSPF like this on those sites too. . .