So I've been doing some research and thinking here and there about what
a _good_ directory service for icecast would be like. I'd appreciate
some feedback and some discussion on this topic, before I start putting
a lot of effort into developing it.
First off, I think getting rid of # of listeners is a must. It just
creates a self-fulfilling prophecy and encourages cheating. I think the
best way to facilitate finding streams that you really want to listen to
is to make the information sortable, searchable, and filterable etc.
I'll probably be making a stand alone client to help with this, although
the web interface will still be there. How else can we present the
information that takes the focus off of stupid, irrelevant things like
number of listeners?
Here's my current list of information that each directory entry would
contain. If you don't understand what 'auth' is, don't worry.
it's
there to provide a modicum of security. What else would you guys like
to see or think should be there?
DIRECTORY VALUES
===============
url
the url to the stream
ex.: http://streams.vorbis.com:8000/downtempo.ogg
type
type of the stream
ex.: audio/mpeg or application/ogg
bitrate
bitrate of the stream in kilobits per second
ex.: 64
name
the name of the stream
ex.: Jack's Funky Beats
genre
the genre of teh stream
ex.: downtempo or talk
homepage
the homepage of the stream
ex.: http://streams.vorbis.com/
email
email address of the streams maintainer
ex.: jack@xiph.org
description
short description of the stream
ex.: All the funkiest beats from the funkiest people. Tune
in now for some great downtempo music.
ttl
time to live. number of minutes an entry is valid for. subsequent
directory changes will refresh this value. when the value
reaches 0, this entry will be removed.
ex.: 5
auth
authorization string. this is a md5sum of of some
random data.
ex.: echo 'jack@xiph.org|Jack Moffitt|password' | md5sum
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.
> > type > > type of the stream > > ex.: audio/mpeg or application/ogg > > > > This would be confusing to the end-user just looking for something to > listen to. The average user doesn't understand what a MIME type is. I'd > suggest just something like "MP3" or "Ogg" instead.Note that this is information stored in the database. Not all of it has to be presented as stored. It's easy enough to map a mime type to MP3 or Ogg. But I think using the canonical type definition is a good thing at the lowest level.> > auth > > authorization string. this is a md5sum of of some > > random data. > > ex.: echo 'jack@xiph.org|Jack Moffitt|password' | md5sum > > Now this I like. Using an auth string to authenticate yourself to the > directory server is a Very Good Idea(tm).It should stop almost all forms of misuse besides forgery. But since there's theoretically no reason to forge, this shouldn't be a problem.> Personally, I'd also still like to see a quality indication of some sort > (22.1khz Mono, etc) along with the bitrate field. But that's just me > wanting detailed info. I do, however, think that some sort of "Location" > field would be good to have. You could tell whether a stream was in the US > or the UK or whatnot, which would give you an idea of how good your > connection to the server would be.Ogg streams might also have video at some point (I hope to start testing this soon). I'm not sure how best to store diveres info like this. I assume fps, khz, channels at the very least. I'm still trying to think of a really convinient way to store arbitrary things, so that the data is extensible, instead of having to put out a new version of icecast every time we want to add a variable. Any ideas? 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 01:31, you wrote:> So I've been doing some research and thinking here and there about what > a _good_ directory service for icecast would be like. I'd appreciate > some feedback and some discussion on this topic, before I start putting > a lot of effort into developing it. > > First off, I think getting rid of # of listeners is a must. It just > creates a self-fulfilling prophecy and encourages cheating. I think the > best way to facilitate finding streams that you really want to listen to > is to make the information sortable, searchable, and filterable etc. > I'll probably be making a stand alone client to help with this, although > the web interface will still be there. How else can we present the > information that takes the focus off of stupid, irrelevant things like > number of listeners?I'm going to have to take the opposite point of view on this one, but with a slight modification.. Number of listeners is not irrelevant, especially to broadcasters and their competition. Granted, broadcasters get their own statistics with more detail than just a simple number - so the information is still there - but I think it's a bit of a stretch to go as far as to say that the number is irrelevant, rather, it's relevance has been misconstrued to mean other things. My personal reason for paying attention to this statistic when faced with thousands of possible streams is that I am looking for music of a specific genre and stand a better chance of landing in a stream that actually falls in to that category when it's being listened to by a majority of people (e.g. It leaves the general impression that a consensus has been reached as to the quality of the stream and the accuracy of it's description.) Of course, this is simply a hacked way of making up for the various shortcomings of current directory services and broadcaster oversights and doesn't always work, but it helps. I imagine that other people use this logic extrapolated to meet their own personal needs and desires. Furthermore from a listeners point of view, it does seem to be a powerful general motivator/gravitator ("What is everyone else listening to?" "Where's the party at?") to plug in to a stream based on number of listeners - this technology we're using is unique in giving us that ability, taking advantage of it is not a bad thing in my opinion, tied in with the fact that we are social animals and like to hang out in groups it almost seems as a necessity to me and has the potential to adversely affect the success of such a directory listing after having people conditioned by other directory services, hit counters, etc.. 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. In addition, the abovementioned sentiment that seems common among listeners has created an undesired emphasis on this head count, which I think is the actual root of the problem. Perhaps one or all of two things can be done to filter down it's importance while getting the same kind of usability in the grand scheme of things in addition to investigating as to how cheating can be significantly reduced: 1 - Represent the listeners on a different scale (was it live365 that represented listeners by displaying one to four stars?) 2 - Don't sort streams according to their alleged listenership (maybe even go so far as not allowing that column to be sorted), certainly don't present the default listing of streams prioritized by this statistic. In the case that number of listeners is no longer a value displayed to the public I would place emphasis on *greatly* increasing the accuracy/importance of other statistics to compensate for this possible removal, which is what I think Jack is trying to accomplish below anyway. At least I've got to voice my opinion that I feel it's a valuable statistic and rather would like to see effort put in to strengthening it's validity while representing streams without this number being the primary emphasis ... :)> Here's my current list of information that each directory entry would > contain. If you don't understand what 'auth' is, don't worry. it's > there to provide a modicum of security. What else would you guys like > to see or think should be there?I'll add my musings below, though I am quite aware that some of it may break some rules :)> DIRECTORY VALUES > ===============> > url > the url to the stream > ex.: http://streams.vorbis.com:8000/downtempo.oggIn 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)?> type > type of the stream > ex.: audio/mpeg or application/ogg > > bitrate > bitrate of the stream in kilobits per second > ex.: 64Though 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.> name > the name of the stream > ex.: Jack's Funky Beats > > genre > the genre of teh stream > ex.: downtempo or talkI'd like to see sub-genre(s) or a method to allow for tighter genre definitions.. Let me illustrate by this observation: There's techno, and then there's Techno - why? - because people aren't always aware of the proper genre, some people call all electronic music techno, while others are far more specific. We've had to resort to this minor, silly distinction.. It'd be nice not to have to use valuable space in the description field to emphasize that indeed one does play 'proper' techno, or a specific sub-set of 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.> homepage > the homepage of the stream > ex.: http://streams.vorbis.com/ > > email > email address of the streams maintainer > ex.: jack@xiph.orgA 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. type A boolean distinction between live and playlist driven streams alternate contact A general text field that can include alternate methods of being in touch with the people behind the particular stream. ex.: Phone number for the studio ICQ/AIM id IRC channel Link to another URL that can be used to trigger a chat system, message board, voting mechanism or something..> description > short description of the stream > ex.: All the funkiest beats from the funkiest people. Tune > in now for some great downtempo music. > > ttl > time to live. number of minutes an entry is valid for. subsequent > directory changes will refresh this value. when the value > reaches 0, this entry will be removed. > ex.: 5 > > auth > authorization string. this is a md5sum of of some > random data. > ex.: echo 'jack@xiph.org|Jack Moffitt|password' | md5sum > > > > 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.
> It may be meaningless to most listeners, but having it tracked (and > public-domain) is valuable to admins and marketing types alike, if your > goals lean that way.That's what logs are for. This is not a public log. Things are not tracked over time. The information is only valid for a 'ttl' period.>Froma marketing angle, you might even argue the other way, that peopledon't want this information published (except to advertisers).> >type > > type of the stream > > ex.: audio/mpeg or application/ogg > > I find this pretty irrelevant myself, especially from a user > perspective.It's not for the users.> It can (and should) be indicated on the specified URL,Go read a basic document on Internet Standards. Encoding meta information (especially type) in a filename or URL is broken and wrong.> you'll pardon me for saying, seems to violate the "spirit" of your > reasoning behind wanting to remove listener counts. I think the only > people that would give a damn about this are people who endorse a certain > technology over another (Mpeg vs. ogg vs. wma vs. whatever).Or people who value freedom and want to use only Free technology. This serves a few purposes though. a) a directory admin could lock this field to a single value, doing service for only Vorbis for example. b) supporing legacy and discontinue or nonupgradeable products that are MP3 only will need to know. And of course, if you think that people don't care about quality at lower bitrates, then I disagree with you. I would chose a Vorbis stream over a MP3 stream any day, if the rest of their attribute were similar.> >ttl > > time to live. number of minutes an entry is valid for. subsequent > > directory changes will refresh this value. when the value > > reaches 0, this entry will be removed. > > ex.: 5 > > I don't think this should really have anything to do with the directory > itself. It should be a transparent server-side configuration > parameter. If clients can set it then you just end up with clients that > connect once with 9999 (or whatever your max value is) and then never > connect again to spam the server.. fill the directory up with all kinds of > garbage.We want clients to be able to set it, and if it's documented, they will likely set it responsibly. You don't want someones commercial stream that is on expensive bandwidth and never goes down to hit the server as much as everyone else. This will help scaling a bit I think, as people who are knowledgeable about how things work can change the default values to be more efficient. This also brings up another reason to ditch listener counts, and that is that it's TIME DEPENDENT. All of these other values are not time dependent. They will be valid the entire ttl, or until the server goes away.> > >auth > > authorization string. this is a md5sum of of some > > random data. > > ex.: echo 'jack@xiph.org|Jack Moffitt|password' | md5sum > > What is the purpose for this? Is one of the other mentioned fields going > to be dependant upon this being correct?This string is set buy the listing client. The server will contact the server for that URL and a compare process will happen. If the entries match, It will get listed. Clients do not have access to this value, except listing clients which set it. Once you're in the directory, updates must contain this value too. This prevents people from forging your information, or hijacking your entry.> yp, but really in icecast as well) a more robust template facility, like > shoutcast has.We had templating a good long while before shoutcast did. And people did some crazy things with it. Hardly anyone ever used it, and it fell into disrepair. I'll keep this in mind for icecast 2, which already outputs XML documents.> It's very easy for me to give my mirror maintainers a > template file that they can use to generate their stats for inclusion into > my mirror list if they're using shoutcast; using iceast is a hassle > involving either modifying the current templates and screwing up god knows > what, or writing scripts to hit one of the current status pages and then > post-processing the output before including it on the webpage.You won't need this for icecast if that's your use. You can use request and parse the stats.xml which will dump all stats on the server. You can also connect as a stats client, which will give you a dump, and then realtime stats updates while you stay connected. And that _already_ works :) 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.
> I'm planning to cast a couple or 3 of stations that are _not_ > monographic and will be "sports" from x to y hours, "pop" from > y to z hours, "talk" from z to p hours and so on. > > That is because people that are listening the same genre for > hours want to change. Why letting them to switch to another > station? Just give them a variety that does not make them feel > tired to listen. > > This is specially true for "live" radio and I think "live" is > not to be considered a genre (as some directories do), but > a property to be filed separately.I agree. The reason 'live' is a genre is that most people just broadcast all the music on their harddrive in random mode. Only a minor portion of the people actually worry about programming, etc.> Could be proposed to be defined under a "genre standard" following > this format (I invent it now, so, reply improving this):[SNIP] While that's not a bad idea, I'd like to keep this field human readable and freeform. Certainly you can mix genres, and I should have noted that multiple space-separated fields were valid.> Then the user (only if he has a login) is notified by mail on > the next Thursday: > > Subject: Icecast Directory Remember Service > Body: > Remember that on xx/xx/xxxx at xx:xx you wanted to listen to: > Radio XXXXX at http://hnjkcdhejkceh:45854218 > - Click "here" to listen > - Click "here" to remember in [xxx] hours > - Click "here" to remember again "xxx" hours before the event starts > > Also, as a secondary effect, this could be used to send > "mail-bookmarks" to the users because they can store in a > mail-folder some quantity of messages similar to this: > > Subject: [Directory Bookmark] Radio XXXXXXXX > Body: Radio XXXXXXX is at http://hvdjjhvihwviuw:4678239Now this idea I like. :) So not to discourage your earlier thoughts, this is probably best done in the 'description' field, since a longer description will contain things like "We have a talk show at 8PM EST", etc. Traditional radio stations have a format they adhere to. That's easy enough to describe, as their are only a handful of formats. My vision is that users searching the directory will only search for something new to listen to, and that they will have many of their favorite streams bookmarked that they keep returning to. So a user searching for new stuff, will read the description, and probably glance at the site if it looks interesting. 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.
> >First off, I think getting rid of # of listeners is a must. > while it seems to be a very popular desire to get rid of this metric all > together, it is my opinion, that you cannot get rid of this metric > entirely. The reason why it is so hotly debated, is because it is > important. what is needed is a way to measure the popularity of a > station. What I want as a listener is the ability to find out which > stations are professionally done and which are simply playlists of mp3s on > shuffle play. For mp3 streams, for me this was done through the listener > counts. Taking away this metric (or effectively eliminating it) is, in my > opinion, not a good thing.Listener count is not a good indication I don't think. I think that it's possible to figure out this information from the other information provided. Ie, what's in the description tag? Also, this is time-dependent data.> how about instead of bitrate, something more generic like "Quality". This > should be a number, which (in the case of application/ogg) might be 64 (as > in kbps) or (in the case of audio/mpeg) might be 30 (as in FPS). I would > say, for most media types, it would be a bitrate, but not all.Video still has a bitrate, and that is a better judge of quality. Certainly with current technology, I'd rather eat the framerate at lower bitrates, than watch a bunch of blurs. 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).> >email > > email address of the streams maintainer > > ex.: jack@xiph.org > > is this necessary ? you don't want people scraping the directory for email > addresses (this was done in the past with the SC list)I think so. I want people who like my station to be able to contact me. Certainly some fields are mandatory, but I think people who listed their email (or a contact email in general, even if it's stationmaster@mystream.com) probably care more about their station. I have emailed plenty of broadcasters in the past who were doing interesting things. And it was always a pain in the ass to fidn their address, especially if they didn't list it on their homepages.> what happened to "Currently playing" ? In addition to this, "last 3 songs" > would also be very good. would require a bit more storage on the server > side, but not that much.It's time-dependent data. If a client wants that, it shoudl request it from the server to make sure it gets a valid answer. It does us little good to display what people played 10 minutes ago and say that's what they are playing now. 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.
> 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.
Hello. About your idea, I think that it is important for a radio to "check" multiple styles. I'm planning to cast a couple or 3 of stations that are _not_ monographic and will be "sports" from x to y hours, "pop" from y to z hours, "talk" from z to p hours and so on. That is because people that are listening the same genre for hours want to change. Why letting them to switch to another station? Just give them a variety that does not make them feel tired to listen. This is specially true for "live" radio and I think "live" is not to be considered a genre (as some directories do), but a property to be filed separately. For example, the genre that you propose as this:> genre > the genre of teh stream > ex.: downtempo or talkCould be proposed to be defined under a "genre standard" following this format (I invent it now, so, reply improving this): Suppose that the genre is to be expressed, in fact as a collection of genrenames, for example, let's suppose that a radio casts pop and classical music. The genre could be "pop & classical". Let's suppose that in fact, the styles are not mixed, simply they cast pop from 3h to 18h (GMT) and they cast classical from 18h to 3a.m. Then the loop is closed and they start over again. The syntax could then be: "pop [T= 3:00 - 18:00] & classical [T= 18:00 - 3:00]" In this case, we provide that "T=" string to identify that we are going to define a "time" property. We could also think of "Date" properties (to specify that genre is "pop" but on "wednesday" it will be "talk"). And we could think of a different property that applies to every programming unit: "live radio", "recorded piece of live radio", or "hard-disc based playlist". Here I write some kind of "syntax" (I do not follow any standard, but I try to imitate those who define syntaxes), and below I give a couple of examples. Syntax: Programming_Unit ["&" Programming_Unit [...]] Programming_Unit: Genre_Name [ Genre_Property [...]] Genre_Name: Any string Genre_Property: "[" Property_ID "=" Property_Data "]" Property_ID: "T" | "S" | "D" | "C" Property_Data: Depends on Property ID. If PropertyID is "T", it means "Time" GMT_Time "-" GMT_Time If PropertyID is "S", it means "Source" Source If PropertyID is "D", it means "Date" Date If PropertyID is "C", it means "Classification" Any string. GMT_Time: HH ":" MM Source: "R" | "L" | "P" (R=Recorded live, L=Live, P= Playlist) Date: DayOfWeek | DayOfMonth | FullyQualifiedDate DayOfWeek: "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", "Sun" DayOfMonth: Any integer between [1 to 31] FullyQualifiedDate: DayOfMonth "/" Month "/" Year (provided that it makes sense) Year: Any integer with 4 digits. We could add and define a much more rich standard with much more "tags". But before I loose time writing all possibilities, I prefer to write down some examples to see if the method is accepted or people do not like this idea (I hope yes, but we never know). For example, let's suppose that I want to listen to talk radio talking about computers: I perform a search: "talk computers" and I could find a radio that outputs this result: " slowtempo [T= 00:00 - 08:00] [S=P] talk [T= 08:00 - 12:00] [S=L] [C= Sports] talk [T= 12:00 - 14:00] [S=L] [C= News] talk [T= 14:00 - 18:00] [S=L] [C= Magazine] mixed [T= 18:00 - 22:00] [S=P] [C= Pop, Rock, Contemporary] talk [T= 22:00 - 0:00] [S=R] [C= Social] dance [T= 22:00 - 0:00] [S=R] [D=Sun] talk [T= 22:00 - 0:00] [S=R] [D=Mon, Fri] [C= Computers] " Then we could think that this radio perhaps does not talk about computers just now but but, if GMT is on monday and it is 20:00 in a couple of hours I'll be able to listen what I want. As an added value, you could ask the directory to send some bookmarks and/or call your attention by mail or other methods. For example, I want to listen to "Economy" and we are on saturday. Let's suppose that a radio has the following line: talk [T= 15:00 16:00] [S=L] [D=Fri] [C=Economy] Then a simple link "beside" the programming unit (the directory could interpret the syntax and present it finely on a html table) could say "remember me one day before" and/or "remember me [??] hours before" Then the user (only if he has a login) is notified by mail on the next Thursday: Subject: Icecast Directory Remember Service Body: Remember that on xx/xx/xxxx at xx:xx you wanted to listen to: Radio XXXXX at http://hnjkcdhejkceh:45854218 - Click "here" to listen - Click "here" to remember in [xxx] hours - Click "here" to remember again "xxx" hours before the event starts Also, as a secondary effect, this could be used to send "mail-bookmarks" to the users because they can store in a mail-folder some quantity of messages similar to this: Subject: [Directory Bookmark] Radio XXXXXXXX Body: Radio XXXXXXX is at http://hvdjjhvihwviuw:4678239 Now I place this in mode "request for comments" See you! Xavi. --- >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.
At 12:31 AM 9/17/2001, you wrote:>First off, I think getting rid of # of listeners is a must.while it seems to be a very popular desire to get rid of this metric all together, it is my opinion, that you cannot get rid of this metric entirely. The reason why it is so hotly debated, is because it is important. what is needed is a way to measure the popularity of a station. What I want as a listener is the ability to find out which stations are professionally done and which are simply playlists of mp3s on shuffle play. For mp3 streams, for me this was done through the listener counts. Taking away this metric (or effectively eliminating it) is, in my opinion, not a good thing.>Here's my current list of information that each directory entry would >contain. If you don't understand what 'auth' is, don't worry. it's >there to provide a modicum of security. What else would you guys like >to see or think should be there? > > >DIRECTORY VALUES >===============> >url > the url to the stream > ex.: http://streams.vorbis.com:8000/downtempo.ogg > >type > type of the stream > ex.: audio/mpeg or application/oggyes!>bitrate > bitrate of the stream in kilobits per second > ex.: 64how about instead of bitrate, something more generic like "Quality". This should be a number, which (in the case of application/ogg) might be 64 (as in kbps) or (in the case of audio/mpeg) might be 30 (as in FPS). I would say, for most media types, it would be a bitrate, but not all.>name > the name of the stream > ex.: Jack's Funky Beats > >genre > the genre of teh stream > ex.: downtempo or talkI would agree with a statement that Genres should be freeform and not predetermined values.>homepage > the homepage of the stream > ex.: http://streams.vorbis.com/ > >email > email address of the streams maintainer > ex.: jack@xiph.orgis this necessary ? you don't want people scraping the directory for email addresses (this was done in the past with the SC list)>description > short description of the stream > ex.: All the funkiest beats from the funkiest people. Tune > in now for some great downtempo music. > >ttl > time to live. number of minutes an entry is valid for. subsequent > directory changes will refresh this value. when the value > reaches 0, this entry will be removed. > ex.: 5 > >auth > authorization string. this is a md5sum of of some > random data. > ex.: echo 'jack@xiph.org|Jack Moffitt|password' | md5sum >what happened to "Currently playing" ? In addition to this, "last 3 songs" would also be very good. would require a bit more storage on the server side, but not that much. oddsock --- >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.
At 11:31 PM 9/16/2001 -0600, you wrote:>So I've been doing some research and thinking here and there about what >a _good_ directory service for icecast would be like. I'd appreciate >some feedback and some discussion on this topic, before I start putting >a lot of effort into developing it. > >First off, I think getting rid of # of listeners is a must. It just >creates a self-fulfilling prophecy and encourages cheating. I think theI sympathize with the anti-cheating attitude.. but I'm against any enforcement of this sort of policy. That seems just horribly MySQLish to me.. It's trivial to include that information in the server, and equally trivial to leave it up to the server admin to enable/disable that functionality. It may be meaningless to most listeners, but having it tracked (and public-domain) is valuable to admins and marketing types alike, if your goals lean that way.>best way to facilitate finding streams that you really want to listen to >is to make the information sortable, searchable, and filterable etc.Absoloutely a must. The "genre" field is a reasonably good idea for this stuff, but I think it requires a different approach. Let the listeners define their own genres, based off artists played on the stream or something to that effect. This could be integral to the server software, or written into a PHP (or insert-your-script-language-of-choice) front end (thus keeping the server in the role of a server, and not a server-client hybrid.)>DIRECTORY VALUES >=============== >type > type of the stream > ex.: audio/mpeg or application/oggI find this pretty irrelevant myself, especially from a user perspective. It can (and should) be indicated on the specified URL, and if you'll pardon me for saying, seems to violate the "spirit" of your reasoning behind wanting to remove listener counts. I think the only people that would give a damn about this are people who endorse a certain technology over another (Mpeg vs. ogg vs. wma vs. whatever). I don't think it's terribly interesting to listeners.. if they have a client installed that supports that MIME type, then it will play.. if not, then it will tell them that they don't have the appropriate software installed to listen. Users are used to this interface and trained (for the most part) to know how to handle it, so I don't think it's a problem.>ttl > time to live. number of minutes an entry is valid for. subsequent > directory changes will refresh this value. when the value > reaches 0, this entry will be removed. > ex.: 5I don't think this should really have anything to do with the directory itself. It should be a transparent server-side configuration parameter. If clients can set it then you just end up with clients that connect once with 9999 (or whatever your max value is) and then never connect again to spam the server.. fill the directory up with all kinds of garbage.>auth > authorization string. this is a md5sum of of some > random data. > ex.: echo 'jack@xiph.org|Jack Moffitt|password' | md5sumWhat is the purpose for this? Is one of the other mentioned fields going to be dependant upon this being correct? I think all we really need in the current yp listers is a better search facility, as you've mentioned. I would also like to see (not only in the yp, but really in icecast as well) a more robust template facility, like shoutcast has. It's very easy for me to give my mirror maintainers a template file that they can use to generate their stats for inclusion into my mirror list if they're using shoutcast; using iceast is a hassle involving either modifying the current templates and screwing up god knows what, or writing scripts to hit one of the current status pages and then post-processing the output before including it on the webpage. --- >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.
> >First off, I think getting rid of # of listeners is a must. > while it seems to be a very popular desire to get rid of this metric all > together, it is my opinion, that you cannot get rid of this metric > entirely. The reason why it is so hotly debated, is because it is > important. what is needed is a way to measure the popularity of a > station. What I want as a listener is the ability to find out which > stations are professionally done and which are simply playlists of mp3s on > shuffle play. For mp3 streams, for me this was done through the listener > counts. Taking away this metric (or effectively eliminating it) is, in my > opinion, not a good thing.How do we determine the quality of a terrestrial station? Do you check the Arbitron numbers? I use my ears.> >bitrate > > bitrate of the stream in kilobits per second > > ex.: 64 > > how about instead of bitrate, something more generic like "Quality". This > should be a number, which (in the case of application/ogg) might be 64 (as > in kbps) or (in the case of audio/mpeg) might be 30 (as in FPS). I would > say, for most media types, it would be a bitrate, but not all.I think people may confuse quality with uptime or as a rating of the streams content. I prefer bitrate.> >email > > email address of the streams maintainer > > ex.: jack@xiph.org > > is this necessary ? you don't want people scraping the directory for email > addresses (this was done in the past with the SC list)I agree. I get plenty of spam as it as. 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.
Oddsock wrote:> how about instead of bitrate, something more generic like "Quality". > This should be a number, which (in the case of application/ogg) might be > 64 (as in kbps) or (in the case of audio/mpeg) might be 30 (as in FPS). > I would say, for most media types, it would be a bitrate, but not all.I think the bitrate is important, since the user is usually concerned about the network load his listening will cause. --- >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.
Jack Moffitt wrote:> So I've been doing some research and thinking here and there about what > a _good_ directory service for icecast would be like. I'd appreciate > some feedback and some discussion on this topic, before I start putting > a lot of effort into developing it.As I'm involved witth broadcasting a traditional radio station on the net, the important thing for me is to be able to indicate the type of program currently going on in the radio. Such a radio can not be described by one genre (like 'techno'), as the different programs may wary (there are programs dominated by speech, there are d&b programs, punk, ethno, etc.) I see that with the ttl field in your approach, this goal could be achieved. I could set up a system which updates the info at the start of each program, with a ttl of the program's length. I'm only interested now in how this could be achieved (how could I update the directory info from cron, for example.) --- >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.
> I see that with the ttl field in your approach, this goal could be > achieved. I could set up a system which updates the info at the start of > each program, with a ttl of the program's length. I'm only interested > now in how this could be achieved (how could I update the directory info > from cron, for example.)Please dont' abuse the fields before we've even implemented them :) How about we add a 'playlist' or 'guide' variable for a url to showtime, playlist, or whatever? That way the user has an easy way to find more information. I'm trying to keep time dependent information out of the directory. What's the purpose if it's always wrong about much of the information? 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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, Sep 16, 2001 at 11:31:50PM -0600, Jack Moffitt wrote:> First off, I think getting rid of # of listeners is a must. It just > creates a self-fulfilling prophecy and encourages cheating.Amen. I got sick and tired of the little cheats that people would use to boost themselves to the top of the various directory lists.> type > type of the stream > ex.: audio/mpeg or application/ogg >This would be confusing to the end-user just looking for something to listen to. The average user doesn't understand what a MIME type is. I'd suggest just something like "MP3" or "Ogg" instead.> auth > authorization string. this is a md5sum of of some > random data. > ex.: echo 'jack@xiph.org|Jack Moffitt|password' | md5sumNow this I like. Using an auth string to authenticate yourself to the directory server is a Very Good Idea(tm). Personally, I'd also still like to see a quality indication of some sort (22.1khz Mono, etc) along with the bitrate field. But that's just me wanting detailed info. I do, however, think that some sort of "Location" field would be good to have. You could tell whether a stream was in the US or the UK or whatnot, which would give you an idea of how good your connection to the server would be. - -- "Nothing's the same anymore." - Cmdr. Jeffrey Sinclair, Babylon-5, "Chrysalis" -----BEGIN PGP SIGNATURE----- Comment: For info see http://www.gnupg.org iD8DBQE7pY2ZAmwSMwnpLHgRAntOAKCnBJzolJ+WQb5FdUiP3Bb33FNnmACgvKoj kWU+JGUXCHlDqakJDF15QFA=6ctl -----END PGP SIGNATURE----- --- >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.
Xavier Montero wrote:> Hello. About your idea, I think that it is important for a radio > to "check" multiple styles. > > I'm planning to cast a couple or 3 of stations that are _not_ > monographic and will be "sports" from x to y hours, "pop" from > y to z hours, "talk" from z to p hours and so on.I think Xavier has pointed out the same issue as I have: on some stations, directory information changes on the stream with time. Moreover, usually the changes are according to some predetermined schedule, thus can be automated. I think having a system that makes managing this easy would be a great help to everyone. Akos --- >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, Oddsock wrote:> >bitrate > > bitrate of the stream in kilobits per second > > ex.: 64 > > how about instead of bitrate, something more generic like "Quality". This > should be a number, which (in the case of application/ogg) might be 64 (as > in kbps) or (in the case of audio/mpeg) might be 30 (as in FPS). I would > say, for most media types, it would be a bitrate, but not all.Bitrate is essential. Unless you're directly wired to the internet backbone, you need to know if you can play the stream. There are still lots of modem users out there. I do agree with expressing sampling rate and channels for audio, and so-on. Maybe an atributes field? 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.