[
Lists Home |
Date Index |
Thread Index
]
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@panix.com]
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
|
