admin note

I’m moving gonze.com, including this blog, to a new ISP. This is a pretty complicated handshake between four different service providers, including two DNS changes, so things may be a mess for a few days. Don’t be surprised if the site doesn’t come up at all.

I have already exported and imported this blog’s contents to the new setup, so this post and any comments made from this moment will disappear.

This change includes my personal email setup, so mails may well bounce or disappear, or I may not be able to get to them.

eMusic economics

hypebot does the numbers on eMusic:

eMusic collects 30 or 40 cents per track downloaded. Because some subscribers don’t download their monthly allotment, eMusic pays 30-35 cents per download. From that 35 cents most labels pay 10-20% to a distributor. Using 15%, that means the distributor pays that label 29.75 cents per track. The current statutory rate that songwriters receive is .091 cents per song, leaving just over 20 cents to be divided between the label and artist. That’s less than half the net payout from a similar iTunes transaction.

I’m glad to see him throw down the gauntlet and finally say what he has against eMusic. And I think he’s speaking for much of the recording industry, so this counts for a lot. Just saying what you really think helps us to move forward.

So here’s what I really think: if you don’t mention volume, price is meaningless.

I’ve been an eMusic subscriber for about five years now, though with a break of a year or so. During that time I have forked over $15 a month every single month. Also during that time I have bought about twenty songs on the iTunes music store.

I use most of my monthly allotment at eMusic, meaning that my money does get passed through to the labels and musicians. Four years of being a subscriber times 60 downloads a month times 20 cents a download = $576.

Out of my twenty songs on the iTunes music store about 70 cents (liberal back of the napkin estimate) went to the labels and musicians. 70 cents a download times 20 songs = $14.

$14 earned, but a higher per-piece rate. Or $576 earned at a lower per-piece rate. That just doesn’t make sense.

But here’s a commenter on hypebot with a more precise view on the economics of eMusic, one which uses staggered release dates to get a higher price from more-passionate buyers:

I’m sure that a lot of labels’ thinking is that if they aren’t on eMusic, then the demand for their catalogue will be greater on other sites where they are getting paid more per download. Therefore, people who are downloading will go elsewhere to get an album and the label will get more money. If a label gets, say, 30 cents/song on eMusic, they have to sell an entire album on eMusic to compete with selling 4 or 5 songs on iTunes. Sure, they may technically sell MORE songs on eMusic compared to iTunes… but they still want that “per track” number that iTunes offers. This is why you see a lot of new releases showing up on eMusic several months after release date. They want to capitalize on the demand for the album on higher paying services. It’s not a dumb move.

Now this is effective economics! They’re segmenting the market to accomplish price discrimination. People who are willing to pay more get earlier access to a release, and needing earlier access strongly suggests that you’re willing to pay more.

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?

netlabels and webcasting contrasted with on-demand

Here are David Porter’s calculations on the health of webcasting as a business:

Internet radio revenues, however, were estimated at a mere $92,000,000 — not so impressive. A quick bit of math is revealing: $92m/4.85bn = $0.0190 per hour. That is to say, revenue/hour was just shy of 2 cents. Unfortunately, the rate for digital sound recording performance royalties (the thing I wrote about a lot last year) is $0.0011 per performance (per track, per listener). Based on an average of 14 tracks/hour, this equates to an hourly cost of $0.0154. In other words, the sound recording royalty by itself consumes 78% of advertising revenues.

Assuming these figures are accurate, the internet radio sector is paying the labels a 78% share of their revenues. By contrast, traditional (aka terrestrial) radio pays 0% of their revenues — nothing — to the labels. And satellite radio pays 6-8% of its revenues to the labels.

For internet radio services, the remaining 22% of their revenues must be divvied up between the musical composition royalty (probably 4-5%), bandwidth, employees (which is typically the most expensive component of cost), overhead, and, well, profit. Or not. The math doesn’t work.

David’s data is flawed, but the overall picture is about right. The internet radio business is pretty sucky. It’s not miles underwater like the on-demand business, but it’s still not very sensible.

OTOH, consider David Porter’s comment on the Silicon Alley Insider piece:

The $10 eCPM argument is one I’ve made a lot over the last couple of years. The tough thing with ad-supported on-demand is that with ubiquitous broadband wireless (not quite there yet but getting closer), such access is increasingly substitutional for music acquisition (purchased or not). While I see your volume angle, it seems unlikely that the labels (the majors, at least) would consider an on-demand rate in an range supportable by advertising.

While it just got a lot more expensive, the radio rate under the US compulsory license is the only type of delivery that’s at least close to being sustainable for a free/ad-based model. And, arguably, this style of delivery (passive, programmed) lends itself to advertising more so than the hunt-and-peck required for on-demand access.

That is, as bad as the webcasting business is, it’s still better than the on-demand business.

Now consider that internet music businesses have to compete for investment capital with internet businesses that don’t pay royalties. Craigslist, Google search, and Twitter do nothing but move bits around!

Lastly, returning to the conversation about netlabels the other day, I want to point out that netlabel and other net-native music doesn’t have a lot of listeners, but as long as it stays clear of copyright infringement it can have economics just like Craiglist, Twitter etc. Maybe not at that scale, but definitely at that level of profitability.

And I know that people on the business side of internet music see net-native music as a joke. That’s right big shots, I’m talking to you specifically. Make free and legal music popular enough for your traffic to scale and you can have the grail — an internet music product that makes sense as a business. Which is exactly what Phlow-Magazine is working on by slicking up the presentation of those sources.

reactions to ad-sponsored music

My earlier blog entry on the economics of ad-sponsored on-demand music was reblogged on Silicon Alley Insider.

One thing that I should point out is that SAI did some rewrites and though these were mainly improvements to tighten up and clarifying the writing, the new headline is something I would never say: Ad-sponsored music won’t work. Blame the labels. I don’t think either of those statements is true. I think that the future size of the recording industry is determined by how much of the online ad industry it can slice off, with a bit of upside for soundtracks and per-unit sales. I think that the labels are caught in their own very real economics and contractual obligations and are making plausible business decisions within their constraints.

The comments over at SAI are an excellent in-depth discussion from industry notables, and are worth reading through to get a more detailed view of the situation. There were two that I want to respond to here.

Michael said: If an ad supported music business wants to experiment they should pay for that, otherwise plenty of time for labels to wait until a viable business emerges. So really no pressure there to make a deal.

This is a very significant consensus within the recording industry. It means that the labels are just waiting for some internet music business to survive the gauntlet. They cash in here and there, losing value in tandem, and patiently working through round after round of dead internet music startups until one is hardy enough to last. What this means for on-demand ad-sponsored music is that, as I said in the comments at SAI, I think that iMeem etc can’t sustain at the current rates, and we’ll have to wait for the next generation of royalty rates (and possibly startups) before ad-supported streams are an important business.

Devon Copley said:

In the near term, though, I think the relative “success” of iTunes — in Western markets, anyway — makes it difficult for the majors to embrace such a model for on-demand. There’s just too much likelihood of cannibalization. How many of those 700 plays actually substitute for an iTunes purchase? If that number >1, then they’re going to need to see more than 700x revenue per play — maybe much more.

The issue of volume is crucial. Two things have to happen. One, an internet music product has to be cashflow-positive on plays, so that growth doesn’t kill it. Two, listeners have to embrace ad-sponsored on-demand plays for catalog that they wouldn’t pay for at all, so that completely unmonetized listening becomes monetized. (For example, by doing on-demand plays of weaker album cuts that nobody is buying at the iTunes store).

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.

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.

clean netlabel highlights

The site Phlow-Magazine is a slick compilation of activity in the netlabel scene.

The netlabel subculture is growing a layer of editorial filters around the inner core of musicians (who came first) and publishers (who came second).

I wonder whether a bigger market would be reached by emphasizing or downplaying the idea of “netlabels.” Emphasizing it helps the site stay connected to a healthy existing community, but is a turnoff for people who don’t identify with that scene. And if not “netlabels”, what? Is there some other way of thinking about this music which is more intuitive?

When are the MP3 bloggers going to discover the netlabels? Why do they still draw on releases primarily intended for the offline market? Who reblogs Myspace, YouTube and blog bands? Or is this already happening and I just don’t read enough MP3 blogs to see it?

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.

license claims in HTML

When you put a Creative Commons license in a web page, it usually applies to that page. For example, if you generated HTML for the Attribution-ShareAlike license using the license chooser at CreativeCommons.org and put that claim into a web page at http://example.com, it would mean that the page at http://example.com could be freely shared as long as there was attribution and the sharer applies the same license to their copy.

By using the “about” attribute specified in RDFa, you can modify that claim HTML so that it applies to a different URL and not the page in which the HTML is embedded.

Let’s say you have a media file “my.mp3″ (which may or may not have embedded license info), it is online at http://example.com/my.mp3, and you have a web page at http://example.com. Let’s also say you have a chunk of HTML for saying that the current web page is under an Attribution-Sharealike license.

Your web page containing that chunk would normally have HTML along these lines:

      <html><head><title></title></head><body>
      [the HTML for the license claim]
      </body></html>
    

The modified HTML would look like this:

      <html><head><title></title></head><body>
      <div about="http://example.com/my.mp3">
      [the HTML for the license claim]
      </div>
      </body></html>
    

This is a new way to publish a license claim for a media file. The existing way is to embed the claims into the file using a tool like liblicense. The reason you would use the new method is that the benefits and drawbacks are a better match for your needs.

Pros of embedding within media files:

1. A license claim inside a file travels with the file, so that the license claims on the copy are still identifiable. If you use the external HTML method, the only way to tell that a copy at a different URL is under the same license is to do a byte-for-byte comparison of the files.
2. A license claim inside a media file is instantly accessible to any program which is already accessing the file and only slightly less accessible to a program which already has a copy of the file. A license claim in external HTML requires the HTML page to be found, fetched, and parsed.

Pros of using an external HTML file:

1. A license claim embedded in a media file can only be recognized by fetching the file and parsing it. AJAX techniques usually can’t be used to parse a binary file. Bandwidth and latency limits may also prevent this. In contrast, an HTML file can be parsed by JavaScript, and is often small enough that bandwidth and latency are not a problem.
2. A license claim inside a media file is hard for web spiders to see, and most search engines won’t index it. In contrast, a license claim in HTML is easy for a spider to see and all search engines will index it.
3. A license claim inside a media file requires a dedicated program like liblicense on the client side to edit. A license claim in HTML can be generated using a simple web application like the license chooser at CreativeCommons.org, and any decent content management system (like Drupal or WordPress) could easily do it.

You don’t have to choose between these methods. There is no reason why these two methods can’t be used together, which would give you the good parts of both.

As with all implementation proposals, this method may not work. It may be that the RDFa “about” element isn’t widely available enough, given that it is specific to XHTML 2 as far as I know. It may be that the rel-license microformat can’t be extended like this.

There’s one improvement to this method that I don’t know how to do — making it work in existing search engines with no changes on their part. If it’s possible to tweak the HTML syntax so that existing search APIs or query arguments could be used to find Creative Commons works, the entire open media ecosystem would benefit.

1 YMP free in every box of FoxyTunes

FoxyTunes Blog:

FoxyTunes 3.0 for Firefox is finally here!

This version adds a very cool new functionality – it can turn any webpage into a playlist you can play right there on that page – without needing to launch any external media players or programs. How is this possible? With the new Yahoo! Media Player.

What’s Yahoo! Media Player?

Yahoo! Media Player is a really cool music player that lives on the web and can play music found on web pages as a playlist. The player floats ‘above’ the page content, so even if you scroll up and down the page, the player stays at the same position right in front of you.

Up until now, in order to add this player to a web page, you had to be the owner of that page. But what about sites that still haven’t added this to their pages? FoxyTunes to the resque!

Yahoo! Media Player + FoxyTunes = Play any page

The latest version of FoxyTunes enhances any page that has music on it by automatically adding the Yahoo! Media Player to that page. Then, you can conveniently play any track on that page or even the whole page as one big playlist!

The deal is basically that FoxyTunes can now act like a Greasemonkey plugin which auto-inserts Yahoo Media Player into any page you visit. This is totally handy.