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.
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.
This is great. The next step is “who will write the open source non-technical-user-friendly template which does a lot of these functions?”.
This manifesto makes a lot of sense.
This is a great vision, but I think there’s a key piece of the puzzle you’re missing: musicians will not necessarily be able/want to make these themselves. They’ll need savvy designers to step in and create these for them. And the number of those that could create this multimedia webpage experience is much smaller than the number that can do old fashioned album covers today
Today, bands have their album covers made by everyone from professional top end designers to the guy in the band who knows how to use a scanner to the company doing the CD manufacturing.
The narrower, more technical skills required to make this new kind of art (or to even understand what it is) limits the potential size of the maker pool. One of the main groups of people you’ll need to sell is the MySpace designers, the ones who spiff up your MySpace page for you.
And there you’ve got a chicken-and-the-egg problem: how does this pool of artists arise without the artists already knowing that this is something they need. How does the market get created without the demand being in place? And how does the demand come into place without experts trying to explain it to the poor artists so they can make a sale?
I’d love to see this become real, but how do we get around the same old problem that artists won’t/can’t make their own websites?
Excellent!
When RSS was the hot new thing, I suggested its success was not so much because RSS was a good format, but because RSS was really designed as what I humorously called the RSS Combo Meal (also, here).
The “combo” design is: an authoring tool, a player / reader, a data format, and an information structure. So, in this case of web music:
* a way to publish song web pages
* a way to play song web pages
* a song web page format
* an overarching structure for what songs are in relationship to things like albums and artists, and to each other
At this point, since we’re talking about info in HTML / web pages, I think the real hurdle is getting a media player that is primarily web page oriented, rather than binary file oriented. If we could get some players to treat the web page as the “song” instead of treating the media file as the song, that would catalyze a lot of efforts around authoring, and exploring options with the format and structure.
So, in this particular chicken / egg problem, I definitely think it’d be good to get some chickens first!
It’s a good point Greg, but if the reward for doing it is there, then the early adopters will train those that follow.
Of course, you need facilities that make these things a cinch, but an artist does need something that says “This is the real McCoy, this is where you’ll find the straight dope”.
It’ll probably be a bit like bloggers either using an external platform such as WordPress or installing a blogging site on their own server. When artists become so popular that they can afford/need a better guarantee of authenticity then they can find someone to go through the administrative hassle of setting up a webserver.
Thus one could set up a custom Mediawiki based artist self-labelling system. The newbie artist would still buy their own domain, but would have it resolved to this central site in the first instance. Eventually they’d point it to their own system. It’s possible the central system could even export/upload the necessary code and data as and when required.
@Crosbie: I definitely think tooling can help here for the small minority of musicians who are motivated. And don’t get me wrong, I think the idea is great (I’m already poking around with what it would take to build the Songbird add-on that Lucas suggests), but I have some experience trying to get artists to do things in their own interest and, in my experience, it’s a miracle that they use a platform that is as sophisticated and web-friendly as MySpace (i.e. not that sophisticated or web-friendly) let alone anything this forward looking.
Maybe part of this concern would be helped if we don’t think of the artists as being the only people who can create the “Song Pages”. Just as fan communities have often created the best web presences related to individual artists, maybe active, highly motivated fans, would be a good candidate to do this work. Also maybe music bloggers: when I write about a song, I’ll make sure the mp3s I upload have good Song Pages attached to them and then others can edit and improve them as the files move around…
@gurdonark: maybe there’s a business opportunity to write that tool. A page builder for pages like http://soupgreens.com/froginthewell/ would be a good project that might even reap a few bucks.
@jay, you’re right that the whole ecosystem has to happen at the same time. The setup won’t be ready for any end users before both ends of the pipe are connected. The only way I can think of to do that on the client side is for the majors to pressure Apple and Microsoft to build it into their players.
I posted some additional comments from a “music perspective” in the new music player / library.
sort of tracks greg’s comment above
How do you resolve WOAF field spam and/or hijacking? If you believe the pages can produce $$ (and I do) then don’t you need a cononical source that correctly identifies the rightful page owner for a given track or set of metadata? Because of the power law (80-20 rule etc.) a hacker who picks off the most valuable sites (ie by providing doctored mp3s to the ecosystem) might remove trust from the system to the point where artists don’t bother.
I think I agree with Crosbie – why not make the web page the home of the track, that happens to have many different representations attached to it (audio, video, score, etc).
You’d be playing a playlist of HTML pages with linked audio, rather than a playlist of audio files with linked HTML.
@lucasgonze if someone wrote that tool, including templates to liberate artists from the “captive” things like soundclick, then this template would work.
It’s also not hard to see its analog in visual arts, in literary matters and elsewhere.
Imagine a one-stop short story page, etc.
@greg you make a good point about not being too exclusive about who uses the tool. It could be artists, it could be fans, it could be whomever.
The key thing is that if someone built the tools, then all “stakeholders” would use them. I think it’s a great micro-business idea, as Lucas suggests, this tool provision.
Here’s the kind of thing I’m imagining, maybe with an option to autoplay the main track in each loaded page:
http://alf.hubmed.org/webplayer.php
I read this blog daily but hardly comment because I feel way out of my league with you guys but wow is this ever a great movement.
I’d just like to add from a remix point of view, trackbacks to these pages for remixes, videos containing the song, podcasts it was featured in, etc… linked to the song page (like for remixes at ccmixter) would also make the web a nicer place.
What you guys are talking about makes so much sense. Even to someone like me. : )
@SteveR: to prevent hijacking you have to be the dominant distribution source of the file. That’s good because it gives labels an incentive to license.
Also, it’s an interesting incentive for them to push their licencees to support this whole mechanism, and as a result to help the mechanism get started. They should be adding contract clauses to require that they own the WOAF (or analogous) field.
@teru, man, you outclass me by a long shot. Thinking about the mixter case, it would be totally natural to have the cchost set the link to point to the song page there. The ccmixter song page could manage mixbacks, and listeners could follow from there to any page you want to set as your personal link.
@alf, about playing pages-with-audio vs audio-with-html, either way is better than the current situation.
The tricky thing about playing pages-with-audio is knowing when the song is over, so that the master controller can manage the playlist as a whole. If the media renderer is in the target page, it would need to communicate with the controller. In client software like songbird or foxytunes it’s possible for the client to arrange out of band comms using browser extensions. If the controller is pure AJAX, you’d probably need a cross-frame technique like local cookies; but how to figure out when the controller in the target is hosed? Tricky hacking ahead.
Instead of associating an audio file with a web document, why not associating it with web data? I always thought an audio player should act as an aggregator, and allow me to display the aggregated information in any way I like. For example, I may aggregate information about chords and want to display that. I may aggregate geographical information and plot my collection on a map. etc.
I did a small implementation of that some time ago [1]. Basically, I put a RDF URI in the WOAF field of tracks within my collection. Then, the collection management tool aggregates information by crawling from these URIs. Easy. Then, I can play with all this data in whatever way I like – I have a tailored database for my music collection. “Create me a playlist of musical works composed in the 30s and performed in NYC in the 70s”, “Create me a playlist of artists married to each others involved in my collection”, “Give me two tracks with a similar chord progression”, “Sort me hip-hop artists in my collection by murder rates in their city” :-) All that are the sort of interaction we can do right now by considering a media player as an aggregator.
Cheers!
y
[1] http://blog.dbtune.org/post/2008/05/14/Data-rich-music-collection-management
The artist can also have an RSS feed that exclusively lists each new work they produce.
One small suggestion: this is about song *home* pages. As with web pages, the “home page” and then the “website” became the important web concept for designating official / authoritative information.
Each song needs a home page.
In many cases, songs will deserve their own websites–or, at least, the song home page will be an index to other web pages about and/or relevant to the song.
Jay, isn’t an artist and their art like a parent and their children? Isn’t there a natural hierarchical relationship?
http://artist.com/index.html is the artist’s home page.
http://artist.com/song1/index.html is the home page for one of their songs.
Perhaps you’re suggesting that it should be a subdomain? Thus http://www.fred.com is the artist’s primary website, http://singer.fred.com is the site about the artist and http://song1.artist.com is the site about their first song?
Once upon a time, just over four years ago, on a distant mailing list called Pho…
Lucas said something that inspired Chris Grigg, and I among others posted a reply:
————————————————————————
Subject: RE: pho: Blogging of Rhapsody playlists
From: Lucas Gonze (panix.com)
Date: Mon, 31 May 2004 22:55:14 +0100
I’m sorry to see conversation about playlists get pulled onto the old P2P
merry-go-round.
Done right they are a form of hypertext that makes music a first class
object on the web for the first time. They are a supremely social and
community-oriented technology. They are an evolutionary algorithm for
developing hits. When they are portable enough to be syndicated, they get
drawn into the orbit of RSS, weblogs, and web-scale architecture.
Talking about filesharing, stealing and the RIAA in the context of
playlists is not wrong, but since playlists don’t add anything to that
conversation it strikes me as a waste.
– Lucas
————————————————————————
Subject: pho: RE: Blogging of Rhapsody playlists / music::
From: Chris Grigg (grigg.org)
Date: Tue, 1 Jun 2004 05:36:19 +0100
At 5.55p -0400 2004.05.31, Lucas Gonze wrote:
>…playlists…
>>
>Done right they are a form of hypertext that makes music a first class
>object on the web for the first time.
>…
Now .that’s. an interesting architectural concept. Maybe a new URI
scheme… not http:: … but rather, music:: …?
music::The_Beatles/Sargeant_Pepper’s_Lonely_Hearts_Club_Band/She’s_Leaving_H
ome
So instead of the Domain Name System and our DNS servers, we’d have a
global Artist Name System and everyone would have their ANS server.
The albums/songs tree for each artist could be browsable, allowing
artists to publish their definitive “disc”-ographies this way. A
client request to a specific song or album path could return either
the audio recording(s) itself, if the artist wants to do that, or
else a unique ID for use in searching a separate set of content
servers (Rhapsody, iTunes, p2p, anything). Maybe with hints on which
content server(s) the artist recommends/prefers you use.
Gotta think about this a little more.
— Chris G.
—————————————————————–
Subject: RE: pho: Re: music://
From: Crosbie Fitch (cyberspaceengineers.org)
Date: Tue, 1 Jun 2004 21:22:02 +0100
A guide to publishing a music recording online. (just to start the ball
rolling as ’twere)
1) Ingredients
~~~~~~~~~~~
* “MyDigitalMaster.Dat”
This is a file that represents the highest quality version of your music. It
doesn’t matter what format it’s in, but it should be good enough to derive
any other format from. We’ll call it the digital master.
* You have a website, e.g. http://www.example.com
2) Identifying your recording
~~~~~~~~~~~~~~~~~~~~~~~~~~
You need to create a serial number for your recording.
Download the following command line utility:
http://www.fourmilab.ch/md5/
Let it generate a serial number for your file like so:
MD5 -L -N MyDigitalMaster.Dat
It will output a number like this:
609f46a341fedeaeec18abf9fb7c9647
You also need to create a name for all formats of your file. If your
recording was entitle “Yellow Brick Road” then you might name files of it
‘yellowbrickroad’.
3) Creating a place for your recording on your website
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Create a new toplevel folder on your site with exactly the same name as the
serial number, e.g.
http://www.example.com/609f46a341fedeaeec18abf9fb7c9647
All web pages and other formats of this recording that you create will go in
this folder.
4) Describing your music recording
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Create a default web page for this folder that describes this recording to
your audience, e.g.
http://www.example.com/609f46a341fedeaeec18abf9fb7c9647/index.html
5) Making compact/low quality versions of your recording available for
direct download
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Create a version of your recording a format of your choice, e.g. MP3, WMA,
AAC, Ogg Vorbis, etc.
Name this file appropriately, e.g. yellowbrickroad_128.mp3
Note that the ‘128’ is the bitrate.
This can be linked to from your index page (or anywhere else) as:
http://www.example.com/609f46a341fedeaeec18abf9fb7c9647/yellowbrickroad_128.
mp3
6) Making the digital master available for download
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you choose to release the digital master then copy MyDigitalMaster.Dat as
the file ‘master’ and make it into a torrent as described here
http://bitconjurer.org/BitTorrent/guide.html, such that the link to the
master will become:
http://www.example.com/609f46a341fedeaeec18abf9fb7c9647/master.torrent
Because it’s the master its format does not need to be identified.
Note that you are implicitly granting the public the right to download and
perform this master privately. Any other rights you wish to grant can be
described separately.
7) Indexing, cataloguing, and format information
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Given a DTD (to be developed) all information concerning this work should be
specified in an XML file called 609f46a341fedeaeec18abf9fb7c9647.xml
—————————————————————–
This is the Pho mailing list.
Help?! http://www.pholist.org/help.php
—————————————————————–