[icecast] a new directory service

Marek Pawlowski 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.
> jack.

- Marek

--- >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 mailing list