Wednesday, March 25, 2009

The Importance of Playdar

One of my most recent posts discussed (and/or ranted about) "content resolution". In that post I mentioned a very compelling new open-source project called Playdar. This project was started by some of the folks from Last.fm, but is rightfully gaining attention of the digital music innovators very quickly. What is it exactly, and why is it so important?


Playdar - About: "

About Playdar

Playdar is designed to solve one problem: given the name of a track, find me a way to listen to it right now.

It will search your local disk (iTunes library, MP3 folder etc.), it will search your home or office network (kinda like searchable iTunes shared libraries) and it will search other sources. You can write plugins for Playdar to enable it to search additional sources. It's fast. If a matching song is within reach, it can start playing in less than a second.

This is called Content Resolution. Playdar is a "Content Resolver" - it will take metadata (artist, album, track names) and resolve them to a location of a matching music file. This might be on your disk, or over the network - regardless, sources are always presented as URLs that point to your local machine. Playdar runs a lightweight webserver on your machine - this is how you talk to it, and it's how other desktop apps and web apps talk to it.

Playdar has an HTTP API that returns JSON. It supports JSONP, so any website that you authorize can use Javascript to talk to the Playdar server on your machine. This means:


  • Websites can automatically put play buttons next to songs they reference.
  • Streaming services and music blogs can save bandwidth by playing you your own copy of a song instead of streaming it from a central server.
  • A lot of interesting web-app mashups are possible. Pull interesting music data from an API, and play people content they already have.
  • You could build an iTunes-Genius-like web app using Playdar and the Last.fm API, all in-browser.
  • You could build a playlist sharing site that shares playlists, not mp3s. Think muxtape, but it will only play songs found on your machines.
  • If you run Playdar on your laptop and desktop on the same network it will take advantage of songs on either machine.
  • Music on the web can be marked up so you can always take advantage of local content."


Sure, there are other remote access/webserver solutions out there that enable you to access your content (and your friends') remotely - see Simplify Media and Orb. And there are P2P clients and torrents that enable you download virtually any song available. But, what gets me excited about this is the single interface with cascading resolution logic that it enables - and how it can seamlessly integrate the (existing) web with local/network/free-range/streaming service content. In short, it keeps checking sources in priority order until it finds what it's looking for.

It fosters the development of sites and apps that can add value with context (editorial, informational, social) and discovery features without putting them in a position of having to deal with content licensing and streaming costs.

It has the potential to drastically cut costs of existing music services since they wouldn't have to foot the bill (both royalty and bandwidth) to stream content to users that they already have - thereby helping enable more viable economics around music discovery and sharing sites. Or perhaps lets existing music content sites exit the content licensing/streaming business altogether (some speculate that Last.fm's recent moves away from free streaming everywhere but US, UK and Germany are the first step in this direction) and instead focus on adding value *around* the content.

Sites and applications without their own music content could be marked up to support Playdar... adding click-to-play scenarios in Google search results, Facebook, Twitter (site and apps), IM clients, Wikipedia, news articles and more.

It promotes the use of standard markup to identify music content (e.g. hAudio, XSPF, etc.) that enables users to share content (links) and playlists across different service providers. You keep your provider of choice, I keep mine.

It could be extended to support comparison shopping of content across multiple vendors.... e.g. "just give me the cheapest MP3 provided that it is at least 256kbps".

It could tie into your existing social graph, giving you a single view and interface into all of your friends' local/network content. For example, you see in your AIM status that one of your friends is listening to a certain song... you click play. If you have the song, it plays from your machine. If you don't have the song, it streams to you from your friend's machine, if that friend doesn't have a local version of that song then it streams from another friend's machine that does have it. If none of your friends has a local copy of the song, then it finds it on the web. You don't need to know where the song is, Playdar does the work of finding the best source for you.

It could enable the darknet, where you can get access to all of the content on not only your and your friends' machines...but also the friends of friends (of friends). All unmonitorable and untrackable (unlike torrent sites) since each person only accesses content via people they trust - no one in the chain has knowledge of where the content originated from or where it terminated (see OneSwarm for more on this). Taken with the notion of "six degrees of separation"... you theoretically could get access to any file/song from anyone in the worlds in 6 hops or less.

There are a lot of directions this project could be taken and extended, which is the beauty of it being open-source. Have some ideas? Contribute.

In my opinion, this has the potential to be one of the most disruptive music/tech developments we've seen in a long time.


Reblog this post [with Zemanta]

4 comments:

Unknown said...

I think that the biggest impediment to Playdar being widespread is the use of C++ to write plugins. Why C++? Couldn't they use a language that is a bit more accessible to people? Maybe a scripting language like Python or something?

jherskowitz said...

There is working currently being done on a Playdar gateway plugin so you can write resolvers as perl/ruby/python/etc scripts. (via @metabrew). :-)

Anonymous said...

Their main concern w.r.t supporting multiple languages is the overhead of packaging/embedding interpreters so that runtimes can be guaranteed across platforms. Performance could be a secondary issue.

Anonymous said...

You can write resolvers as either c++ plugins, or simple scripts. Obviously users need perl/python/ruby installed if you write a resolver script in another language - but that seems a small price to pay.

I updated the playdar site with some extra links to an example here : http://www.playdar.org/resolvers.html