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.


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 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.


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 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.