[icecast] a new directory service
marekp at intallect.com
Mon Sep 17 18:23:11 UTC 2001
On September 17, 2001 12:01, you wrote:
> > That said, we are all aware of the fact that there is a large amount of
> > cheating going on, and therefore that number may not be so relevant nor
> > accurate.
> With the system I've outlined, there is no reason to cheat. There's
> no need to fake listener counts because it's not there. Certainly
> people can make this available in the 'description' field, ie, how many
> listeners they normally have, etc. But making this a datapoint is
> kinda silly. I don't go to the record store and ask "How many people
> bought the Tricky album?" Because that number doesn't say how many
> people _liked_ the tricky album, or more accurately, how many people
> whose tastes are similar to my own liked it. One number is a poor
> replacement for the other. In our society we're trained to go after the
> things that are the most popular simply because they are popular. You
> see this with people not thinking that software is a choice, and with
> how the record industry makes it's money.
Let me pull this back and then out for a bit, as I see that going after
things that are the most popular simply because they are popular is a
(perhaps sadly) standard criteria to which many people adhere..
Obviously, that number does not tell you how many people liked the Tricky
album, but it does tell you how many people bought it. People DO buy based
on that criteria: It tells you what the nation is listening to this week, it
keeps you current, and gives you something to talk about with your peers and
co-workers around the watercooler, and at the very least, it'll give you an
idea as to what you might want to buy in to if you have no clue as to what
you want to be purchasing and have nothing better to go on.. It's the reason
why film studios release their figures for the weekend, it's the reason why
there are book bestseller lists as well as top 40 charts for music. It's
condusive to creating a community. For some people (and I would
pessimistically venture, a majority), it's quite a valid reason to invest
their time and/or money.. For others concerned in quality, they will use
reviews etc. - but I'll bet people would still want to know how their
investment ranks up in the general scheme of things.
> If you want to figure out how popular a stream is you can still do it.
> If you hear about the stream from someone else, etc.
> We can also gauge popularity in other ways. For instance, ratings,
> reviews, or whatnot. This is how people typically decide what books to
> buy at amazon, etc.
Of course, this *I* like - it seems that it might serve the goal of
identifying the popularity of a stream without spitting out a number based on
amount of listeners. Might. However even if it did, it does not seem to
address the issue in real-time or in an easily digestible format.. What if
you're bored and on IRC and are looking for a channel with people in it so
that you can socialize? Without a headcount for all the channels you
wouldn't know where to go.. Waiting for someone to tell me about a
cool/popular channel does not address the need for real time information
that's summarized with one number. With the attention deficit on a global
rampage, isn't it just convenient to read one number instead of pages of
reviews? And wouldn't relying on reviews simply be a muddled way of guaging
> > 1 - Represent the listeners on a different scale (was it live365 that
> > represented listeners by displaying one to four stars?)
> Or with a different value entirely. Ratings and reviews is probably a
> good solution for this.
Like said above, ratings and reviews go as far as giving you a feel for the
quality, but what about popularity? What if I am looking for or building a
web site who's core function is to combine a live stream of music with a chat
room? If the answer to that is that I'm responsible for finding my own
favourites based on referrals or, from a site owner's perspective, that I
should rely on other points of advertising - then what is the point of the
directory server? Why would I want to be listed on this one as an
alternative to the others that do offer listener counts and will give justice
to my promotional efforts? How do I find out, at a glance, what is
*popular*? Where's the incentive to get listed? This is probably the exact
kind of behaviour you are trying to deter, and I for one would be comfortable
and quite satisfied with ranking based on ratings, not popularity, but I
don't yet see why one would entirely want to do away with such a figure..
Of course I know the point of a directory server - comparing it to a phone
book might not be too far off base - but I feel that removing listener counts
severely limits the directory server's potential as a means of advertising
your stream - whether or not that is your intention, I'm not sure. But
having the success of a stream measured by it's popularity, and having a
directory server that doesn't address that seems counterproductive. Even a
phone book has it's problems; "AAAAAAAA Computers" is an actual listing in my
phone book, right beside "AAAAAAA Computers".
Questions that arise: How will I stand a chance of getting someone's
attention on the directory server if my stream plays Zimbabwean folk music
which has a small demographic and a deadly first letter? What incentive is
there to be listed on the directory server if no one bothers scrolling down
to the Z's? How can I get the attention of those that are just browsing and
not specifically looking for something and are unwilling to read reviews?
How do I increase the popularity of my stream on this directory server?
Won't my advertisers/investors (who would laugh me out of the room if I told
them to go read the reviews) be interested in my performance in relation to
other streams based on listeners as well as ratings?
> > effort put in to strengthening it's validity while representing streams
> I still don't see the validity. Give me an example not related to
> radio. Do you buy a car based on how many of that kind are in the lot?
> Do you go find the sales figures and buy the most sold car? Or do you
> actually read the ratings and reviews? Or do you just pick the best
> sounding/looking one?
> I'm willing to bet that with almost every choice, you employ some
> heuristic that is not a the number sold, or the number representing
> relative popularity, and that you make choices based on other things,
> even if they are as trivial as the name.
I will have to presume to speak for the general population here, as my
personal buying decisions are probably far more fine-tuned than the general
populace. Though *I* would almost never buy a car, or any product based
strictly on it's popularity, there are limitless examples where others would,
and I'll bet that all of you could name off a dozen people off the top of
your head who's decision making process is primarily based on popularity,
fads and trends.. Think about the stock market and how popularity drives it
and maybe we can come to a consensus that popularity is indeed an important
component for many people in the decision making process.
Do people buy books based on the one that has sold most copies? Do people
buy their clothes based on what they see a majority of other people wearing?
Do people buy their media based on the most popular platform?
How do people that do not have this common sense that we're taking for
granted make their decisions?
All of these need to be adressed - I'm all for what you are proposing Jack,
and am thrilled that such a discussion has been created on the topic.. But
these aren't little questions, and I think that finding an alternate solution
for the specific issue of popularity-at-a-glance is a worthy subject rather
than pursuing the notion that a measure of popularity or listener count can
be somehow replaced or ignored..
> > In general: What about exploring the possibility of having multiple
> > bitrates of the same stream represented on the same row (perhaps 'auth'
> > is geared for enabling that kind of functionality)?
> I'm still thinking about the best way to do that. I think I had solved
> this once before, and didn't write it in my notes, because I have no
> mention of it there. I suppose that we could allow a broadcaster to
> define 'groups' under their auth. So each entry would represent a
> 'group', and that might have mirrors and multiple bitrates, which is
> what we want. Two streams of the same ocntent differentiating only by
> channels or bitrate should _not_ be two entries. I'll think on this and
> post something later, or if people have ideas, please speak up ;)
Provided that auth is some kind of unique identifier per-stream - but not too
unique - perhaps some logic could be used to come up with the relation
between the streams.. Bah, that was too abstract to be useful /me ducks :)
> > type
> > A boolean distinction between live and playlist driven streams
> you probably want to call this 'live'. I don't know if it warrants it's
> own field the way you described it. Maybe 'live' should represent
> whether it's a live event, but remember that the directory shouldn't be
> time-dependent. No one is _always_ live are they?
Hmn, no, no one that I know is always live - though the distinction of the
two is the desire I want to get across, I see your point; with TTL your live
stream can expire to be replaced with the prerecorded one with new data - but
would that not once again place reliance on the description field to get this
information across? I would definitely like to let people know that what is
happening now is a live event, be it including that in the description field
or having one of it's own.. I think the latter might be slightly more
desireable in that it'd be nice to sort or filter out the playlist-driven
streams (personally, I gravitate toward the truly live ones) which might be
more difficult if one relies on a word in the description field..
> > alternate contact
> > A general text field that can include alternate methods of being in
> > touch
> Yep, I was thinking that I could do this with the extensible stuff. But
> maybe it's not worth worrying about. It's definately a must.
--- >8 ----
List archives: http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to 'icecast-request at xiph.org'
containing only the word 'unsubscribe' in the body. No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.
More information about the Icecast