Este lunes pasado mi reproductor portátil, pendrive mp3, me ha dicho un hasta nunca rotundo. Es mi gran oportunidad para adquirir un nuevo reproductor portátil, tipo pendrive, que reproduzca Vorbis; requisito imprescindible.

Desgraciadamente encontrar un reproductor portátil que reproduzca Vorbis, a día de hoy, no es tarea fácil. Lo primero ha sido consultar el wiki de la fundación xiph, en su apartado Portable Players. Busco un reproductor portátil barato, sencillo del tipo pendrive con memoria flash.

Como se puede ver en el wiki, la mayoría son marcas desconocidas o fabricantes que no se sabe bien quién distribuye o bajo que marca/nombre comercial se puede obtener. Otra opción son los, popularmente conocidos, mp3/4 chinos que suelen reproductor Vorbis pero no es indicado explícitamente. La única excepción es la marca Samsung, que toda apunta a ella para evitarme complicaciones.

He probado en tiendas de informática de mi barrio; para evitar las grandes superficies, aunque curiosamente ya no quedan tiendas independientes en mi barrio, sólo franquicias. Al dependiente de turno, por llamarlo algo y bien, le indico mis objetivos de compra: un reproductor portátil que reproduzca Vorbis. Le pido que consulte con su proveedor y le facilito mi número de móvil. ¿Resultado? Muy pocas ganas de complicarse y nadie me ha devuelto llamadas ni para decir que no han encontrado nada.

Qué nos queda, pues Internet. Continué buscando reproductores portátiles Vorbis más allá del wiki de xiph y lo obtenido han sido marcas o nombres todavía más indescifrables. No me complico, Samsung que es una marca bien conocida, el modelo YP-U5 que es barato y sencillo.

De nuevo, a las tiendas del barrio, no he encontrado nadie que venda reproductores portátiles de la marca Samsung y tampoco interés por pedirlo; supongo que por no darles un buen margen de beneficio dicha marca. Al final lo he pedido por Internet, que por cierto tampoco ha sido fácil.

Acabada la odisea para adquirirlo, voy hablar un poco de mi corta experiencia con el YP-U5. Su capacidad es de 2GB y batería cargado por USB con autonomía de 20 horas; calculo que unos cinco días de un uso intenso por mi parte. Por supuesto reproduce Vorbis, más le vale, y no tiene problemas con los tags de los archivos Vorbis.

U5 (MSC)

Decir que de fabrica viene configurado para actuar como reproductor MTP (Media Transfer Protocol). Un protocolo muy estrechamente ligado a Windows Media Player. Se supone que en GNU/Linux los dispositivos MTP funcionan sin mayor problema, mediante la librería libmtp en Rhythmbox. En mi caso Rhythmbox no ha reaccionado, ni para bien ni para mal, nada; por supuesto he activado el plugin.

Carpeta Playlist

Afortunadamente el YP-U5 se puede cambiar su forma de funcionar a USB mass storage device class o USB MSC. Un truco, para ser reconocido como un reproductor portátil es añadir un archivo en el disco usb llamado .is_audio_player

Rhythmbox (MSC)

Tengo intención, por último, de escribir a Samsung España para felicitar al incluir Vorbis en toda su gama de reproductores portátiles. Tenemos que dejar claro que la demanda de Vorbis existe.

I’ve posted a couple of times now about my experiences creating audio and video on OS X. A couple of weeks ago, I had a brief conversation with my friend Ian Hughes, aka epredator, who was trying to get himself setup:

Good one. All I knew was that DIVX AVI files were playing on my machine fine, through QuickTime.

The answer, which I’d evidently missed before, is Perian. This is a really simple, installable package which enables support for a whole range of “other” file formats in QuickTime. You’ll also want to install Flip4Mac, which gives support for Windows formats like WMV. It’s also worth adding the Xiph component for formats like FLAC and OGG. Once you’ve got those in place, you should be fine to import, play and edit in iMovie and other QuickTime-based applications.

One of my favorite applications in Linux is Streamtuner. I think, it’s the best application of its kind. You can browse all the radio streams provided by popular services as basic.ch, punkcast.com, Google Stations, SHOUTcast and Xiph, Live365. Streams are groupped by genre, but you can search through them. If you refresh the list, you can see the songs played at the moment, and choose between them, you can even record any stream (and they are saved as apart songs from most of the streams, if they are tag capable – I mean, if you can see the title of the song in your player), but for doing so you must install streamripper (it’s present in the repositories of almost all linux distributions).
As you may know, SHOUTcast recently changed their site structure, and sadly, you no longer can refresh their stream list in streamtuner.
A solution is to patch the sources, although there is no patch available.
My solution is easier, and works, at least

for me. Follow this steps:

1. Insert this line, as root in your /etc/hosts:

205.188.234.120 www.shoutcast.com

you can do it by typing (in ubuntu):
$ sudo gedit /etc/hosts

or

simpler is just to do so:
$ sudo su
(type your password), then:
$ echo ‘205.188.234.120 www.shoutcast.com’ >> /etc/hosts

2. Now refresh your SHOUTcast lists, and enjoy!

Reblogging elemental-consulting on how dedicated pages add value to single songs:

while I buy digital music on a regular basis, I still love the idea of CDs- something tangible that gives me more than just the music – liner notes, pictures, lyrics, all the writing/production credits etc. There’s no doubt in my mind that the advent of digital music has devalued music and the consumption of it. Quantity has overtaken quality in many cases – how many free songs can I download, how much can I fit on my iPod, how many new artists can I find today. Nothing inherently wrong with any of that, but it just means that, in these terms, a single, solitary song is seen as disposable and barely worth paying for.

…

1) Additional SEO-able content for your site

2) With the addition of comments, you can create community around one song and further engage your audience.

3) Adding all this value for one song adds an additional emotional appeal to your music. Not only can fans see the amount of care and attention that has been invested on the part of the artist but it broadens their experience of the song and their emotional attachment to it.

4) By using a Creative Commons license and encouraging derivations, the life of the song is extended.

What I take from this is that it gives reasons why musicians and their designated rights holders would want to create dedicated pages for songs. Given that you’ve invested in a song, you can enhance the value of your investment by giving it a page. The situation is a lot like music videos, except that the content type is anything that goes in a web page rather than strictly moving pictures.

The comparison to music videos is natural, and it gives a simple explanation for why you’d give a song a page. In the old days television was the medium for culture. These days it’s the web. So the existence of song pages is a straight transcription of music videos to the new medium.

But this way of thinking about song pages is in opposition to the perception of song pages as packaging. Are song pages more like big-ass gatefold albums or music videos?

The place for a dedicated song page is in the media player. Media players need to be extended to have the ability to show a web page associated with a song; they should always show the web page, and shouldn’t require the user to take action. Listening to media in a media player should come with a series of auto-loaded web pages, one per song.

Manifesto

Bare audio files are pretty crappy. All they have room for is bytes describing waveforms. Waveforms are part of music, but not all of it by any means. To come alive a piece of music needs a lot more.

Of course, a song needs a title, and the name of the musical act, and some more facts like the name of album and the length of the song. But even though these facts are part of music, they also aren’t enough to bring it alive.

What every song needs is a web page.

The web page might be anything. It might be a single graphic, similar to how album art is currently used. It might be a series of images, like a slideshow. It might be song lyrics. It might be guitar tab. It might be a list of Myspace friends. It might be Creative Commons licensing information. It might be a pledge drive for future releases or a tip jar for this release. Who the hell knows that the web page is; what’s important is that a web page is powerful and flexible enough for the demands of the music.

Application flow

So what does the software look like?

There would be a chunk of HTML associated with an audio file. It could be saved for offline usage or — easier to implement in the first generation — it could just be a link that was loaded when the user was online.

The HTML would be used everywhere album art is used. In offline media players like the iTunes client-side software, here would be a pane in the media player which displayed it while the song was on. iTunes cover flow would display a screenshot of the page while you’re flipping through your collection and switch to a live grab while the song is playing.

Non-graphical offline media players like VLC would have a button to open the web page in a browser window. They might also be able to enslave a browser window which would be constantly updated during the course of a playlist. Console mode players would display the link for easy copy and paste.

Online media players (in the browser) would give a section of screen real estate to the page. A player like FoxyTunes would give the entire document window over, while a player like XSPF Musicplayer would only give a badge-sized portion of the window. The JW FLV player, for example, would put an HTML window where the video is.

How would the HTML be associated with the audio file? The easiest way to start is with an ID3 tag in MP3 files. (Leaving the issue of how to do it in other media formats aside). There already exists a standard tag designed for this purpose — the WOAF field, which is defined as The ‘Official audio file webpage’ frame is a URL pointing at a file specific webpage. This is very easy to implement, adoption is the only hard part.

What would be in the page

Romancing the music. Providing esthetic context with imagery and text, poems, animations.

Factual information. Song title, copyright data, album name, a list of performers.

Social features. A friend list, a signup for the mailing list, fan chat.

Advertising. Musicians could release a free download and earn ad revenues on a page view per play.

Performance resources. To play along, sheet music and tablature. To sing along, lyrics. To remix, source files. These would encourage listeners to pull the music into their life.

Upsells. Concert listings, merchandise like t-shirts and hoodies, ability to purchase a high-res version of the audio file, ability to purchase the entire album. (Imagine how the ability to purchase the whole album would work: you grab a single song from a filesharing network or pay per download site; you’re listening and digging it; there before your eyes is a big link to get more music from the same artist — go!)

It matters

There is a lot to gain.

Listeners would enjoy the music more because the musical experience would be better. They would have better metadata; for example, context-specific data like the featured soloist in a concerto could be given. They would have a ton of artwork, rather than a little postage stamp. They would have interactive and social features. They would be able to see concert listings auto-generated by geolocation. Rather than a media player that is a spreadsheet for metadata, the media player would an explosion of web experiences.

Commercial musicians could turn free downloads into money much more easily. Right now they rely on a user noticing a song, taking action to do a search, and following links in search results until they came to one that could convert the listener into a customer. With the new way, the user would just have to notice the song and glance over at the web page being displayed. The old way is ten clicks, the new way is zero clicks.

Record companies could develop branding for baby bands, and they could own the URL for their artists rather than letting Myspace have it. They could turn casual listeners into customers by making sticky services like a mailing list one click away from the listening experience.

Avocational musicians could get connected to lead sheets and remix sources more easily.

Developers could extend the musical experience much more easily and to much better ends. It is nearly impossible to extend MP3. It is easy to build on web pages, and the frontiers are being extended every day.

What next?

In the comments on the post that started this, Ian asked: where does this go next? And how do I package/distribute the end result? The answer is to start working on broad adoption of the WOAF ID3 element in MP3.

1. You could sketch out wireframes of application flow. Help to visualize the user interface. Help create the conventions of this new functionality.
2. You could do a Songbird plugin which loaded the contents of the WOAF field into the document window. Songbird was frakkin born to do this job and would excel at it.
3. You could do a VLC extension which opened a browser window to the URL in the WOAF field.
4. You could document how to do this functionality in the Ogg container format.
5. You could figure out how to get the contents of the WOAF field in an AJAX app without needing standard media plugins to be changed.
6. You could evangelize this method to the developers of standard media plugins like Flash, Quicktime and Windows Media Player, and convince them to expose the WOAF field to AJAX developers.
7. You could evangelize this method to leaders in the recording industry, and get them to help apply pressure to vendors of leading media players.
8. If you’re on the artist development side, you could make sure that the WOAF field is set in your free downloads.
9. If you’re a client-side software developer, you could make an easy tool to set the WOAF field.
10. If you’re a blogger who knows why this is retarded, you could spell it out and help to fix the problem.

To summarize: a web page for every song, a page view for every play.

Background conversation

Here is relevant conversation from the comments on my post about a dedicated page for a song.

Jay Fienberg:

Someday, I’d like to be able to just put http://soupgreens.com/froginthewell/ in my “music player” and have it all in my library–which needn’t be just a collection of music files on one computer, but could be a very multi-medium, multi-source, multi-network, multi-device interlinked library of and about music.

[...snip...]

For Err or Man, besides album covers and the lyrics for each song, each song itself also has 2+ pieces of visual art. And, more a/v may come in the future. So, for each of these songs, I need to create not only a song “page,” but a song “(mini) site.”

But, this is the web, so it’s straightforward to create these kinds of multifaceted / relational collections of the mixed-medium info that make up what we call a “song.” What’s missing is the music player / web browser hybrid that understands the song as existing in this kind of interconnected context.

Crosbie Fitch said:

Let the page be the AUTHORITATIVE source for that work. Ensure the URL has the ISBN, or if that isn’t relevant, the MD5 digest of the FLAC (for integrity checking). Would be good to have a standard for indicating authoritative URIs for digital works.

Make the page the PermaLink for the work.

That page (with the artist’s domain in the URL) is gospel for the work. Encode the page’s URL in all metadata for all files.

Bung metadata in the page’s HTML.

As for a tip jar “I would have gladly paid $n.nn for this, let me rectify that now”, yes, you could put that on this page.

Pledging is a matter of chipping in a small amount contingent upon the production and release of future work, either any work or a specific work. So you could have a pledge button on the artist’s page “I’d like to pledge a quid to you for your next work, hopefully to be released soon” (qv http://www.quidmusic.com). You could also accept requests, and create pages for frequently requested works not yet embarked upon “I think you could do a great rendition of song X, there’s $N from me upon that fine day”, or for your suggestions of things you could do “Yup, I think your ideas of doing work along those lines would be worth exploring, I’ll chip in 50 cents for that”.

NB Pledges are not tips or charitable donations, but commissions/bargains/purchases/patronage, the new deal: art for money, money for art.

Your audience wants to pay you – you do not need to charge them for ‘possession with intent to supply’ on penalty of copyright infringement with 5 year jail terms and million dollar fines.

I have set up a dedicated page for my version of the song “Frog in the Well.” It is an experiment in packaging for internet music, since a bare MP3 lacks all the chrome that makes a CD an entertaining thing to open up. Design notes –

To draw you into the page and help the recording come to life, there is some text about the history of the song.

To enable interaction by remixing, there is a MIDI version, the recording length is given (which helps people looking for background music), the recording is under a license which permits remixing, and there is an offer to relicense if necessary. To enable interaction by playing it for yourself, there is sheet music and guitar tablature as both a downloadable PDF and an embedded image.

To handle limited attention spans, I crammed as much fun stuff as I could manage into the first screenful above the fold. Video gets prominent real estate, because that draws people in like nothing else.

To make the MP3 playable in-place I included Yahoo! Media Player.

The MP3 link is labeled simply “MP3″, which doesn’t provide metadata for either search engines or the metadata section of the media player, so I put metadata (which the media player will pick up) into the title attribute of the link:

<a href="http://soupgreens.com/wp-content/uploads/lucasgonze-froginthewell.mp3" title="Lucas Gonze - Frog in the Well.">MP3</a>

To optimize placement in search engine results, the page has a good clean URL (http://soupgreens.com/froginthewell/) and the song title is in the page header.

There is sheet music inline in the document in addition to the downloadable PDF. This is to inspire people who play an instrument to try it out.

In the downloadable PDF there is a (text) link back to the site. This is to improve the stickiness of the content — if anybody does print it out and read through it on their instrument and then doesn’t get to know the main site, I must have really messed something up. Also, I’m planning to give out printouts at shows and getting people to follow the link back to the site is the payoff.

Here’s the link again: Frog in the Well.

Back in 2002 I wrote a chapter for Game Programming Gems 3 about using Ogg Vorbis for sound in games.  Unknown to many gamers, Ogg Vorbis has gotten a lot of adoption in mainstream game titles.  Epic has long used Vorbis and Speex in their Unreal Engine, for example, and the list of other publishers is quite long and even includes Microsoft.  Apparently the chapter I wrote has helped a few developers learn the ropes, and the publisher has decided to include it in the recently released Best of Game Programming Gems. Keep reading to find out how you might score a free copy of the book.

What is this Ogg Vorbis thing?

For those who may not be familiar, Ogg Vorbis is an openly specified, patent free audio codec that has superior quality to the MP3 format.  The Ogg Vorbis reference implementations are open source software and of very high quality.

Ogg Vorbis was created because the patents on the MP3 technology prevent a whole range of businesses and software developers from using it, stifling innovation in the audio space.  Much has been written about this before.

Why Ogg Vorbis for games?

There are a several technical reasons that Ogg Vorbis makes a good choice for games without even getting into the patent licensing issue.

• Vorbis has sample accurate seeking and playback.  In MP3 the best you can do is get to the closest frame to the sample and start playback from there.  This problem even persists into MPEG-4 audio and is the reason that Apple and others have had to build in hacks to get gapless playback.  For sound effects, this is a major problem, and Vorbis solves it easily.
• Vorbis encoded files are smaller and higher quality. Because the Vorbis codec is so much better than MP3, it is possible to achieve much smaller file sizes for the same quality as MP3, much higher quality for the same file size, or even a little better quality and a little better filesize.
• Ogg is easily extensible to carry other formats.  It has been used for video, MIDI, subtitles and many other things along side audio payloads.
• The reference implementation is open, fast, and easy.  The Xiph.org Foundation, which shepherds Ogg and Vorbis and other open multimedia technologies, has provided multiple reference implementations that are open source and well debugged.  There is a floating point based engine and an integer based engine.  There are implementations suitable for embedded devices.

Back to the book…

The publisher of Best of Game Programming Gems has kindly sent me an extra copy of the book, which I would like to pass on to one of you.  If you are interested, please leave a comment.   A week from today I will select a person at random from the people who expressed interest and mail them a copy of the book.  Please note that this means your email address, or some other means of contacting you, will need to be included in the comment somewhere.

Leftsetz, who blogs compulsively, says Singles Only:

Don’t make an album. And whatever you do, don’t send it to me! I don’t have time.

Heritage acts. Classic acts. Cut one great single! That you can do your best to work. Shit, give it away for free… As an inspiration to buy a concert ticket, where the true money is. Why spend all that money and time to cut an album that almost no one’s going to hear?

New bands… One track only.

But wait, he doesn’t mean you only get one more song in your career:

you don’t give them ten more tracks… You give them a dribbling of killers. So they end up becoming fans of the act, not the track.

Ok, so what’s another word for dribbling? Blogging. The new format isn’t the *single*, the single is just as inert as the album. Singles are vestigial. The format is the *post*.

A couple real world examples: Jeff Harrington has a new violin sonata out and there’s a new song up on soup greens.

Una lista de webs donde puedes ver videos encodeados en Theora.

This is a list of sites where you can download videos encoded with Theora.

List of Theora videos – XiphWiki

One followup to my post on portable identifiers for songs using XSPF’s content resolution abilities happened on J. Herskowitz’ blog. I asked whether the problem in developing interoperability between music services is technical or economic. J’s answer was:

I think it is both. Since there appears to be a need for ongoing resolver work to map to lots of catalogs, the opportunity cost of one company to do so becomes too high. Just look at Paul Lamere’s work on Spiffy (http://research.sun.com:8080/SpiffyContentResolver/)- it was a great start, but he couldn’t rationalize the opportunity costs to keep it going.

As a consumer, I want it though…. I want to be able to find a playlist somewhere and then click “play” – by which enables me to determine what vendor fulfills it. Napster, Rhapsody, Yahoo, YouTube, free-range MP3s, etc.

Paraphrasing him, the value to users seems clear enough, but the work to enable it need to be shared across vendors, since no one vendor benefits more than the others. It’s social value which has to be funded by everybody and nobody.

Back here at home I asked the question slightly differently: does this technology provide enough business benefit to be worth implementing? If not, what would have to be different?

Jay Fienberg came back with an answer a lot like J’s:

I think there’s a bit of a mismatch here: catalog resolution of the type described is especially beneficial and necessary in “open” multiple-catalog systems–where the goal is linking / sharing info between as many systems as possible. And, the question is being asked of people involved in furthering the goals of “closed,” single-catalog systems.

These single-catalog systems have the goal of, more or less, focusing only on incoming links, e.g., focusing on making their single catalog a more unique authority.

I think another way to look at this would be: how hard would it be for these services expose to their own unique, permanent, identifiers to the public? (Not very, one would imagine.) Then, rather than these services building their own catalog resolution systems, they could make it possible for others to do so.

Similarly, Scott Kveton of MyStrands said: From the MyStrands perspective we’re simply not in the catalog resolution business. I would wager that Pandora isn’t either.

Jay’s trick of flipping the question around is insightful. Almost all online music businesses right now are in the distribution business, even if they see other functions like discovery or social connection as their main value, because they have no way to connect their discovery or social connection features with a reliable provisioning service from a third party. But provisioning is a commodity service which doesn’t give anybody an edge. They don’t want to import playlists from third parties because *that’s* where they are adding value.

Exporting playlists for others to provision, though, is a different story, and it makes much more sense from a business perspective. Let somebody else deal with provisioning. This is what it would mean for somebody like Launchcast or Pandora to publish XSPF with portable song identifiers that could be resolved by companies that specialize in provisioning.

Chris Anderson said:

The portability problem is a bit of a prisoner’s dilemma for music providers. If everyone addresses it, the benefit is great, but if only a few do, and in different ways, then the costs can outweigh the gains.

…

In the absence of a bottom-up revolution resulting in audio resources that can be resolved to, there has to be cooperation among audio brokers. Perhaps Imeem et. al. could provide an API that takes XSPF <track/> fragments and provides a flash widget with the appropriate content.

And Scott Kveton again:

What I would love to talk about is using something akin to Musicbrainz to be the public commons that companies like MyStrands, Last.fm, Pandora and others can use as a basis for playlist portability.

And that’s where internet music vendors are right now: stuck waiting for ways to cooperate without disarming unilaterally. The closest thing to cooperation is that companies are willing to export Flash widgets that can be embedded in any third party site, and the reason we’re using Flash is that it allows us to define and limit points of interoperability.

Ok, so let’s just say that the business and technical problems can be factored into separate projects. Yves has been working on the technical problem of mapping identifiers from different vendors into a unified framework:

I played a bit with such lookup algorithms (using metadata+acoustic fingerprints) when I experimented linking a Creative Commons label collection (Jamendo) and Musicbrainz – this is described here, and uses a technique close to the “similarity flooding” one in the record linkage community:
http://blog.dbtune.org/post/2007/06/11/Linking-open-data%3A-interlinking-the-Jamendo-and-the-Musicbrainz-datasets

Yves’ work deals with interlinking experiences based on the Jamendo dataset, in particular equivalence mining – that is, stating that a resource in the Jamendo dataset is the same as a resource in the Musicbrainz dataset.

For example, we want to derive automatically that http://dbtune.org/jamendo/artist/5 is the same as http://musicbrainz.org/artist/0781a….

It’s a fascinating and productive investigation. I am aware of at least one private proprietary effort to do this kind of thing, but no open project, and this is exactly where work has to be (as Scott says above) for multiple vendors to become interoperable without unilateral disarmament. One immediately useful result of this work is to make a direct connection between the XSPF concept of content resolution and the semantic web concept of Equivalence Mining and Matching Frameworks. This allows music developers familiar with the application domain of catalog management to benefit from high-academia research into techniques that can be used to auto-generate links between data items within different datasources.

Phew. I’m done. This was a hard post to write because I had to digest all the different strands in this conversation. It took a long time to figure out what people were talking about. Still, now that I’ve done the legwork I feel like I understand the problem better than before, even if parts are still a complete mystery.

have been wondering for some time why Apple won’t just freaking add ogg,flac, or any other Xiph formates to iTunes and iPods. It just hit me, it really is quite obvious; they want people to use their own proprietary formats. They don’t want people to be able to control their music because that is bad for their profits.

I need a new mp3 player (I have a 4GB ipod mini now) so I looked around a little bit, and I couldn’t find anything that is as nice as an ipod but also supports Xiph formats. Some of the Archos stuff is really cool but they are expensive and I can’t find them in stores so I can try before I buy. If there is anyone out there with one of these or something better please let me know about it. The other route is to just get an ipod and deal with it or install linux or what ever that firm wear thing is. I have done both of these things with my current ipod, but I got ride of them to save space.

Anyway, I digress. Apple wants to force people into their hardware, software, and music store. I for one only buy music on cds because I am a simi-audiophile and only willing to pay for music if I can get it in a lossless form. Apple, according to Slashdot, is preparing to offer a lossless iTunes store. I, of course, will still not buy this because the music will be DRMed (DRM= Digital Restrictions Management) and only available in Apple’s format; I won’t buy music that I may not be able to use in the future.

Die for the metal not the format.

Last Tuesday I took part in a media web meetup at Songbird HQ in San Francisco. I gave an hourlong talk about XSPF and internet playlist technology, then sat on a panel with Scott Kveton of MyStrands, Tom Konrad of Pandora, and Tantek Celik of microformats.org. The theme for the night was Portable Playlists and other POSH-ibilities. I did the XSPF talk not to promote it but to explain the advanced features. My slides for the talk are available at http://gonze.com/preso/mediawebmeetup/.

It was fun. First off, I got to do a long monologue about my guiding obsession (playlists) to a roomful of peers who had the background to get straight to the interesting stuff. Second, the panel was lively and interesting. However, the panel conversation was about general problems for open media on the web and not really portable playlists. Here’s what Scott Kveton had to say in his own blog post about the event:

We touched on quite a few topics (some of which I’ll comment on in another blog post) but the one I wanted to cover that didn’t get much airtime was (ironically) what it would take to make a portable playlist format a reality.

Before the panel both Tom and I were chatting about how there is really only one big problem that both Pandora and MyStrands face: catalog resolution. This is a huge problem that consumes quite a bit of developer time in both of our camps. Unfortunately, every playlist format out there simply punts on this problem. They point at some “resource” that is the catalog entry. Now, from a portability standpoint that’s great and I can appreciate the why’s of why you’d do that.

First off, what is this resolution problem I’m talking about? Imagine a user tells me they are listening to “These boots are made for walkin’”. I want to take that song and resolve it to some entry in my catalog. If I do a search for that I’m presented with oodles and oodles of possibles. Not only that, I may get the same song returned to me (that is the exact same waveform) that lives on a greatest hits album or a compilation of the 80’s, etc. We figure between Pandora and MyStrands we’ve got easily a couple of hundred thousand lines of code to solve the same problem. Bummer.

Just about everyone is going to have some sort of catalog entry. We have artist pages (for example, see U2) that are tied to specific catalog information that we get from several sources. We have to do resolution from ‘U2 – Beautiful Day’ to something in our catalog to give more information to the user when they click the link (or when we want to provide recommendations). It would be so much simpler if the user gave us an audio signature of that song so that we could use something like Musicbrainz to resolve what it is to our own catalog.

In my talk I speculated that resolvers which can do the kind of thing Scott is talking about haven’t taken off because they don’t solve a real economic problem. But this blogversation makes me think that the problem may be evangelization and communication. Too few people know that XSPF can be used to tackle exactly the problem that Scott is describing.

Here is how.

If relying on Musicbrainz as a centralized resource makes sense for a given project, then this playlist would allow services like Pandora and MyStrands to exchange unambiguous references to this song:

<?xml version="1.0" encoding="UTF-8"?>
<playlist version="1" xmlns="http://xspf.org/ns/0/">
    <trackList>
        <track><identifier>http://musicbrainz.org/track/c1ae3c2a-9e07-4f7d-81a2-49ce29e91caf.html</identifier></track>
    </trackList>
</playlist>

Given the above, a catalog provider like MyStrands could map the Musicbrainz database to its own via a variety of well known (though labor-intensive) methods. When it got the track reference above it would simply look up the corresponding entry in its own catalog.

If a centralized method is not ok for a given project, the metadata that MyStrands would have gotten from Musicbrainz can be embedded in the XSPF, like this:

<?xml version="1.0" encoding="UTF-8"?>
<playlist version="1" xmlns="http://xspf.org/ns/0/">
    <trackList>
        <track>
            <title>These Boots Were Made for Walkin'</title>
            <duration>4420</duration>
            <trackNum>13</trackNum>
            <creator>Nancy Sinatra</creator>
            <album></album>The Essential</track>
    </trackList>
</playlist>

No one of these fields is enough to do a really reliable lookup of the song. If all you have to go on is “These boots are made for walkin’”, there will be a ton of irrelevant results. (A search algorithm would call this “low precision“). Heck, if all you have to go on is an acoustic fingerprint, you’ll still get conflicting listings for all the different releases that contain the classic orginal recording. But if you have all this metadata, a lookup should be very reliable. Out of all the albums that contain the original release, how many had it as the 13th track? How many had a name which was a variation of “The Essential”? Out of all the covers and recordings of this song, how many were exactly the same length (in milliseconds) as the original? These bits of metadata are not reliable identifiers by themselves, but they are in reliable in combination.

The lookup is sloppy to some extent, but the error rate will be low enough for entertainment applications. Competing but interoperable providers like MyStrands, Pandora and Yahoo! would have no fundamental problems in meeting user needs overall.

Does all this answer the question? Am I addressing the right problem?

Or is the real problem still economic and not technical? Are there features which it would be profitable to support which entail portability? The problem isn’t how to enable portability, it’s why a business would want that. The status quo is lack of portability, with each music service an island. This sector as a whole hasn’t developed into a collective ecosystem, and businesses which do invest in portable identifiers don’t stand to gain any value until other businesses join them.

So here’s my question for Pandora, MyStrands, Last.fm, Project Playlist, Rhapsody, LimeWire, etc: does this technology provide enough business benefit to be worth implementing? If not, what would have to be different?