[icecast] a new directory service

[Jack Moffitt]

> 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.

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.

> 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.

> 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.

> > url
> > 	the url to the stream
> > 	ex.: http://streams.vorbis.com:8000/downtempo.ogg
> 
> 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 ;)

> Though we all know what kbps is, your average listener simply knows if they 
> have a modem, cable, DSL, or whatever.  Though I would never want kbps to go 
> away, maybe there's a complimentary way to represent that figure in terms 
> that your average listener will understand.

See comments from me in other emails about storate vs. presentation.
This is storage.  I probably should have mentioned that :)

> > genre
> > 	the genre of teh stream
> > 	ex.: downtempo or talk
> 
> the genre.  Having an optional subgenre would allow broadcasters not to be 
> left behind when sorted on a general list of streams while still being able 
> to accurately portray their stream and let people find them with ease.

This was not supposed to be a one genre field, but space separated free
form list of genres.  Probably capped in length to a reasonable value.
So you could have
detroit techno 
or whatever you wanted.

> A couple more suggestions shot from the hip:
> 
> world coordinates
> 	Optional longitude/latitude values that can be used for representing the 
> location of the stream in a variety of ways; on a map, text, etc.  Could also 
> be used for determining the timezone of the stream.

Consider this added.  A string for location is definately a must.  I'm
surprised I forgot it here :)

Coordinates would be a fun toy.  It actually plays in with a directory
browsing client I have been thinking about for a year or so. 

> 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?

> 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.

--- >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.