RE: An Opportunity To Make Money: NOT An Ethiopian Plea for Y
1) An XML format for playlists is worthy. 2) The ranking is not about a/v being different for the web. Yes, links are required for pagerank because pagerank attributes authority not downloads. The stats needed for airplay/downloads would be more complicated. That is why the service is worth purchasing, hence the title of the thread. Otherwise, just Google. This is about a service that enables a trad radio station to determine when a song crosses over from web play to the trad radio formats. Payola will never be obsolete as long as radio program managers make about $35k a year. Because the web is still an audio ghetto and radio airplay determines performance royalties, nothing is changing except we are breeding a generation of IP thieves to work with the regional promoters. When counties are dry, preachers and bootleggers work together to keep them that way. len From: Lucas Gonze [mailto:lgonze@p...] Bullard, Claude L (Len) wrote: >Yes, I am thinking about a ranking system. ... >The radio production staff doesn't have time to review. The web does >and it votes on a regular basis. ... >Playlists are votes of a kind. So you have a service that a ranking >service can use. That's cool. The web supports voting nicely. That >is all that PageRank is. Yes, PageRank and related algorithms do support voting very nicely. The problem, though, is that few people link to songs, so there is little data for PageRank to work with. This is why I chose to create (with Webjay and XSPF) a community of people writing hypertext playlists -- because you need the social practice of linking to exist before you can harvest the link data. >Now it is a matter of focusing on song >downloads (one kind of vote) and streams (another kind of vote) and >downloads+purchase (another kind of vote). Then there are the >automated rating systems that players such as Windows Media Player >provides. Well, I don't see why you'd need to monitor downloads/streams/purchases for music any more than you'd need to monitor downloads/streams/purchases for HTML. Yes it's useful data, but it's not any more important for A/V than for web pages. The way that Alexa stats are gathered on the client is the same kind of thing you're thinking of, and even though they're useful they're not essential. Any time you find yourself thinking that the existing web is not able to handle audio and video, take a step back. There are only three things special about audio and video in comparison to readable web pages -- they exist within a timeline, they're opaque, and the legacy industry associated with them is less able to adapt to the internet than the print publishing industry was. I'd like to take this back to the main themes of xml-dev, though, and talk about where XSPF fits in. There is a general need for XML playlists; we can see this in the fact that virtually every MP3 player invents its own XML playlist format. There is also a need to get audio and video onto the web; we can see this in the broken XML and HTTP of most MP3 players. Lastly, there is a need to get web search and relevance to work for audio and video; we can see this in the continuing payola scandals. How XSPF accomodates the first two of those requirements is pretty obvious. The last one is a little less obvious -- it maps to the "shareable" plank of our goals. We wanted to bootstrap a link economy for A/V. By definition, playlists are the hypertext format of audio and video. Existing playlist formats were not publishable, though, because they weren't able to travel from one machine to another without breaking. We needed a playlist format that (1) was in sync with web architecture and (2) accomodated the special requirements of A/V. - Lucas
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format