> 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 streamsI 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 streamsyou 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 touchYep, 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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> Do you mean the coordinates from where the broadcast originates, or the > where the relay servers are located?It would be boring if it was the server location I think. I think where it originates is more appropriate, although for people running streams from multiple djs at different times, this might be an issue :) 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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
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 popularity?> > 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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Mon, 17 Sep 2001, Marek Pawlowski wrote:> On September 17, 2001 12:01, you wrote: > > 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, ...ACB radio interactive is, when it's on, always live. That's the whole point. Geoff. --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> > 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. Couldalso> > 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.Do you mean the coordinates from where the broadcast originates, or the where the relay servers are located? Brian --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Forgive the lack of antecendents. I just now joined the list, but will respond generally to what I saw in the list archives. I think jack's suggestion of distinguishing between static and time-depended data is a smart one. I would also suggest that many of the ranking issues people are concerned about can be addressed through the description field. Punting things like 'now playing' to a metadata stream seems like a good idea. Directory servers can watch this directly and add it to their displays if they think that's worthwhile. The ttl field does provides some time-dependence capabilities, and it can be abused by setting it too short as well as too long. The latter case can be solved though a no-ping expiry policy on the directory server as jack suggested. Probably we should just design so '0' is also an acceptable setting, and let individual maintainers decide on a minimum individually. The ttl field in dns is mostly there to control propagation through a distributed cache. Are we planning something like that for the icecast directory(ies)?> auth > authorization string. this is a md5sum of of some > random data. > ex.: echo 'jack@xiph.org|Jack Moffitt|password' | md5sumAs written, this adds little security over sending the password in plaintext. Some folks at mit recently wrote a nice summary of how to do secure auth over the web: http://cookies.lcs.mit.edu/pubs/webauth:tr.pdf Unfortunately, anything more secure requires a shared secret, and thus and ssl-connection over which to send it. For example, running the contents of the update through the hash in addition to the password would let the server verify each update directly and block replay attacks. Of course, this assumes the connection in between is more vulnerable than the server and/or the client's machine, so perhaps in practice it's so much better. Still, I think it's worth trying to do this right.> We could add a second tag 'rate', which could be in kHz for audio, and > in fps for video based streams. We could also add a 'channels' to > describe the number of audio channels (it's not unlikely we will see > surround sound Ogg streams) and maybe a 'size' for picture size (ex.: > 160x120).I think a separate table is needed with stream urls and this specific metadata, all of which sits under the more general data like stream name, homepage and description. That easily takes care of both mirrors and alternate bitrate versions of the same content. All the extra bits get complicated fast, but bitrate, samplerate, number of channels, and size seem like a good starting point. Maybe 'size' should be replaced by 'format' which can be the resolution/aspect ratio for video and the surround format for audio. You might also want some sort of sub-description that could say things like 'Pacific Mirror'. Otherwise, the general layout looks good. Program 'guides' for a particular station with scheduled programming is another nice feature, but it's somewhat orthogonal to what jack has suggested. I do think it's perfectly reasonable for the same software to support it, but we should think about it as a separate piece of information. Anybody know if here's an xml working group for program listings? :) IMHO, -r --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Mon, Sep 17, 2001 at 10:01:41AM -0600, Jack Moffitt wrote:> 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.As Aldous huxley once said : "truth is not a question about statistics" In this context i would translate "truth" with good taste ;-) -- Venlig hilsen/Kind regards Thomas Kirk ARKENA thomas@arkena.com http://www.arkena.com We are using Linux daily to UP our productivity - so UP yours! (Adapted from Pat Paulsen by Joe Sloan) --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> 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..yes, this discussion is important, and these questions are good ones. Now, acknowledging that a quick 'what's cool' glance is desired and/or a 'what's popular' metric, is there a way to do this outside of pure listener counts? I think there is. And I think there are a few ways to do these... - reviews/ratings. you can make this so a quick glance is possible. you can certainly have 'charts' as you described without using listener count. and the charts you refer to are not done by listener counts always. - volunteer organization. someone can manually make charts. this is probably not a practical idea, but it's worth discussing. it may be possible to code enough of it to make it practical. human filtering is the best kind. :) - some metric based on clicks through to the stream. we can measure this from the directory server. we can't measure this well unless we're the primary interface, which i'm going to assume we won't be. but surely there's some implied information we can glean from logs and user habits. I think any of these things would result in a better system than one based on listener counts. Most of the impetus for internet radio and peer broadcasting is choice and selection and getting away from listening to top-40 radio or what 8 songs are cool in the whiney-bitch-rock genre this month. 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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.