I’ve been thinking about way to do music distribution where people don’t have to host files.
Specifically, with a player like Songbird you could make an XSPF playlist that you could then send or post somewhere. On the other end people receive the playlist and find the audio using search engines, downloading from artists’ websites or buying.
…
Pros: no one gets sued, bands that host their mp3s retain ownership on the data about who is listening to them
Cons: at this point it’s too much work for the benefit.
About the amount of work for the recipient, it’s true that On the other end people receive the playlist and find the audio using …
, but this doesn’t mean that the recipient manually tracks down every file. The XSPF plan is for the recipient to have a piece of software which knows how to locate the tracks automatically given a minimal amount of guidance from the user; this relies on the sender to provide enough metadata to support an automated search.
As it stands people share music references by uploading their own rips to a hosting service. That ensures that the songs they have in mind are globally available. This is a reliable process which is easy to figure out: rip, upload, send the URL via email or web. Most of the time the sender doesn’t even need to rip, since they were listening to an MP3 in the first place.
What are the drawbacks of this process?
* It’s inconvenient to have to upload. But not *that* inconvenient. And it’s getting easier all the time. I’d be surprised if there isn’t client software which integrates everything about the process.
* The media URLs go 404 pretty quickly because of takedown requests and the general instability of life in the underground.
* The file hosts are often sleazy.
Anything else? If the plan is to compete with file hosting, that’s not much to work with.
Greg’s comment in the Attributor thread comes to mind:
Content trackers get it from all sides. In the new Hype Machine redesign, a fear of the record labels is plain as day. And, in reducing access to mp3s — de-emphasizing playlist-access, etc. — they’ve greatly angered many of their users (they’ve actually done a good job responding to the feedback and so have moved to reinstate some of these types of features in the weeks since the relaunch).
It seems to me that content trackers are going to have to become diplomats. Stuck between the copyright holders and the users they have three choices: 1) Take the side of the users, a la The Pirate Bay: ‘User experience is all, quaint local copyright custom be damned!’; 2) Take the side of content holders, a la Attributor: ‘I’m taking my ball and going home; and if you don’t like it, taste the business end of my 1000 staff lawyers!’; 3) Find a third way that tries to negotiate a peace between both sides. This third option is the one that is the least obvious, but also, I think, holds the most business opportunities: if you grant both sides the right to exist, and take it as a given that both have demands that need meeting, you have twice the number of possible products and you stand to be in the best position to participate in really sustainable solutions that constitute wins for all sides.
I’m hoping it would be automated by Songbird too. You would set a preference for how to find it, as in: if the URL location fails, then go to skreemr, then pull a 30 second sample from last.fm, etc.
It’s especially too much work for the recipient when you compare it to the highwater mark: mixtapes.
But I think it would be great if there were a process where bands that want to host their own mp3s can see who is listening to them and where.
And I think that’s the business that Songbird more or less wants to be in — brokering music transactions. It’s surprising that they haven’t gone after that more directly.
About bands that want to host their own mp3s getting stats on their listeners, the first step is for people to use the band’s hosted versions of the files rather than uploading the own ripped versions to some random file host. But getting listeners to do this has a few different problems —
* Nuking the stupid custom against direct linking to multimedia, which some people consider bandwidth stealing.
* Getting bands to realize what they stand to gain, and empowering them to get their URLs over to listeners.
* Making it easier to find and link to stable existing multimedia URLs rather than posting transient new versions of the same files.
Lucas, I’d add two bullet points to your list of obstacles:
– A very low percentage of bands are actually tech savvy enough to create their own websites.
-MySpace, which is by far the most popular way for bands to gain a web-presence, hosts mp3s and makes them available for listening, but goes to relatively draconian measures to prevent them from having reliable, publicly available urls.
Together, these two obstacles constitute a killer one-two punch: MySpace lures artists into using it as a stop-gap against building a real website; MySpace only lets artists put their music online in a crippled innovation-hostile way (in a flash widget, hidden behind temporary on-demand-generated urls, un-linkable, and un-discussable).
This means that most of the indie, unsigned, and local bands — exactly the ones who should have the most to gain from making access to their music for bloggers, fans, and other people in the conversation as easy as possible — are locked into a service that reduces the ability of their music to participate in things like mp3 blogs, XSPF content resolvers, and more general content detection services.
I don’t think the solution to this problem is going to come from bands moving from MySpace to running their own sites, even on services that make it really easy like Blogger. Just like we talk about when it comes to the labels’ ongoing role in distribution/promotion, the only thing that bands can be relied on to do for themselves is make music. Everything else is beyond their core competencies and interests.
Our best hope here is to pressure Virb, Facebook, and the other services jockeying to suck away some of MySpace 100 million users to do the right thing in regards to music as an online resources (i.e. putting it up at permanent publicly accessible urls that are well-described with extensive metadata). And the best way to do that is to show the bloggers the benefits that accrue to them in publicity: my band’s best publicity successes have come from contacting all the mp3 bloggers who I thought might like our stuff and sending them links to mp3s on our own site (where we host permanent links to all of our music). You’d be amazed how many of the bloggers commented, both to me and in public posts, about how refreshing it was to find a band putting all their music up with good urls. It’s like they never see it — and it greatly increases their odds of writing about you.
If we could get bands to think of lightnet music hosting as a can’t-live-without feature in their social network/web-presence, things would really start to get interesting for all the developers waiting in the wings to build the next generation of exciting music apps.
Lucas –
I love the notion of having XSPF resolvers for the user’s content vendor of choice (Napster, Rhapsody, YouTube, user’s local library, MP3 Search such as Skreemr) but who/where are the resolvers? Who is/should be writing those?
Jason, from an architectural perspective any XSPF player is a resolver. They have ultimate latitude to do what they think the user wants. But that’s not the answer to your question.
Who would be the resolver is any app that mediates between the user’s personal catalog and the cloud. Winamp, for example, both manages a local collection of MP3s and handles incoming URLs for multimedia.
You’d expect provisioning services to step up and write these. The makers of Rhapsody, the iTunes store, Yahoo Music Unlimited, or even LimeWire et al. Also, software that manages the user’s personal MP3s should make it possible to map song metadata to files on disk.
“A very low percentage of bands are actually tech savvy enough to create their own websites.”
This is a bit unfair. The reason most bands don’t have their own website is likely more financial than technical. It also takes a long time to do it right, time that most bands don’t have.
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).
Farsheed, I really like your idea of enabling musicians to create ultra-solid URLs for their works. It’s inspiring.
More comments in the next public post…