xiph – Lucas Gonze blog

song pages at bandcamp

The song pages at Bandcamp are very good. For an example, see the page for the song “Mercury Vapor.”

They give the song a full page worth of real estate, which lets them elevate the song title to the page title and give the album art enough emphasis; that’s a great use of plain old semantic HTML for media metadata. The song title is also in the URL, which is good for search engine rankings; the pages have excellent search engine optimization overall, which allows musicians to capture search results for their own works. There are lyrics and a commentary by the musicians. You can download or stream the song. There is a link to the album containing the song and links to other songs on the same album.

And notice that the page isn’t empty. Giving the track a page of its own doesn’t waste space. The opposite — it lets the track have enough space for once.

benefits of song pages

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?

song page manifesto

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.

You could sketch out wireframes of application flow. Help to visualize the user interface. Help create the conventions of this new functionality.
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.
You could do a VLC extension which opened a browser window to the URL in the WOAF field.
You could document how to do this functionality in the Ogg container format.
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.
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.
You could evangelize this method to leaders in the recording industry, and get them to help apply pressure to vendors of leading media players.
If you’re on the artist development side, you could make sure that the WOAF field is set in your free downloads.
If you’re a client-side software developer, you could make an easy tool to set the WOAF field.
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.

dedicated page for a song

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.

no singles, please

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.

making a case for portable identifiers

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.