Tuesday December 22 2009

Playdar and a browser for the music web

Lately I’ve been working on an exciting piece of technology called Playdar. It’s downloadable software that lets you find playable sources for music content. Give it a track name and it returns a list of available MP3 URLs with ID3 tags that match (or AAC or any other format).

At the most basic level, it does this by maintaining a searchable index of your local music collection. By default, it exposes two interfaces to this index, one via an HTTP API running on localhost, and the other over a UDP listener. This lets you query the LAN for other machines running Playdar.

Here’s a slightly wonky diagram to illustrate a basic example:

Playdar architecture diagram

  1. A Query for a track comes in via the localhost HTTP API.
  2. Playdar checks its local index for tracks that match Query.
  3. One matching track is found locally.
  4. Playdar also forwards Query to the LAN via UDP broadcast.
  5. Another Playdar instance running on the LAN picks up the query and checks its local index for matches.
  6. Two matching tracks are found.
  7. It sends these matches back over UDP.
  8. All results are combined in a JSON Response object and returned to the initial localhost request.

The resulting list of MP3s URLs all route through localhost so they can only be played by whoever made the initial request. All Playdar has done is expose an HTTP interface to the music that you already have access to, there’s no illegal file sharing going on here.

Extending Playdar

This architecture can also be extended via the resolver plugin API to search other free and legal sources of music, such as Magnatune, or Soundcloud. Here’s a list of resolvers that are available right now.

And more exciting, there’s also the possibility of working with paid subscription services like Spotify or Napster to make their content available via Playdar. If I’m paying for legal access to licensed music, I should be able to query it how I wish.

This raises a few issues in relation to the custom player that Spotify and others rely on as a DRM-protected delivery mechanism, but this could be worked around by providing an API to control the player, rather than exposing mp3 URLs directly. Indeed, Spotify already have a basic controller API with their spotify:// and http://open.spotify.com URL schemes.

What can we build?

So now we have an architecture for access to individual tracks, what can we build with this? Well, there are already a few applications out there taking advantage of Playdar, including Playgrub, a bookmarklet for extracting playlists from web pages; and my own Playlick, which lets you create playlists and syncs with other sources from the web.

Both of these use the Playdar.js client library I wrote for interfacing with the localhost API, it’s a good start if you’re building a web app to use Playdar.

Towards a Universal Playlist Parser

Both Playlick and Playgrub rely on parsers for extracting track metadata from the web, through a combination of regular expressions, DOM access and JSONP apis. There are many ways track data can be encoded: XSPF, Podcasts, custom API responses, hAudio RDF Music Ontology or just plain old HTML tag soup.

What I’d love to see is a universal parser for music data. Something along the lines of Mark Pilgrim’s Universal Feed Parser that abstracts away the differences between the common metadata formats and returns data that can be treated consistently by any application that wants to use it.

This could even be exposed as a module in the Playdar API. Pass in a URL and get a structured JSON response with any parsed data from that source. Playdar so far deals very well with the atoms of music—individual songs—but still lacks tools for dealing with the wider context songs exist within—albums, playlists, charts, etc.

The music browser bit

Zed Shaw recently wrote about a “Secret Project Which Has No Name” he’s been working on that uses SPARQL to parse RDF music ontology data via JavaScript embedded in a Qt app. He’s trying to build a browser for music within its wider semantic context.

This is exactly the sort of application that could benefit from a Universal Playlist Parser, and seems to fit quite well within the Playdar ecosystem.

When I mentioned this to Zed on Twitter, he expressed concern about centralisation, no doubt because I linked to two centralised web sites that use Playdar. I hope I’ve demonstrated that the Playdar architecture itself is actually decentralised, but you’re free to build whatever you want with it, whether centralised or not.

Comments welcome via email or Twitter