Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Music Media The Internet

Icecast 2.0 Released 152

ArcRiley writes "After 3 years of development and 6 weeks of beta testing, Icecast 2.0 has been officially released! Features include support for both MP3 and Ogg Vorbis, a web administration interface, support for listing in directories (such as, and is freely available under the GNU GPL for Linux and Windows."
This discussion has been archived. No new comments can be posted.

Icecast 2.0 Released

Comments Filter:
  • by Xpilot ( 117961 ) on Friday January 09, 2004 @09:10AM (#7927081) Homepage
    ..would mean 3 years of testing, beta or otherwise. It is after all an open source project...

    • Which is why they said "Beta testing" not "Alpha testing" or something else. Sheesh.
    • From their site:
      After years in development and years in alpha testing, The icecast development team has released version 2.0.0 of its streaming media server. Icecast2 supports Ogg Vorbis and MP3 streaming and has many features and functions you would expect from a world class streaming media server.
      • by Anonymous Coward
        has many features and functions you would expect from a world class streaming media server.

        Except some important relaying functionality is now dropped. In icecast 1 a relay would time out and stop sourcing the stream if no users are connected to it for a while, and resume the stream if someone connected. Good for saving bandwidth automatically. As far as I can tell this is gone from v2.

  • Icecast is great.. (Score:5, Interesting)

    by iantri ( 687643 ) <(iantri) (at) (> on Friday January 09, 2004 @09:12AM (#7927091) Homepage
    Icecast is a great piece of software.. I use it to stream music to myself when I am away from my PC.

    Any idea if there is a better interface for controlling which songs play, yet?

    Before, IIRC it could only shuffle through a bunch of files in a directory.

  • In case, you don't know, Icecast is an audio broadcasting system that streams music in both MP3 and Ogg Vorbis format. It is available under the terms of the GNU GPL. The main home page for the Icecast Project is located here [].

    Icecast is used mainly for a couple different reasons. If you are like me and work at a radio station, you may want to stream your live audio feed over the Internet. This provides access to listeners who would normally fall outside your nominal broadcasting radius. Or, if you wish to
    • thank you !

      I didn't find this information on the website...
    • by Anonymous Coward

      Why are you trying to impersonate Eric S. Raymond? Your account seems to be new (only two comments posted so far) and you are trying to fool people by having a name spelled Rayrnond instead of Raymond.

      Most Slashdot users know that the real Eric S. Raymond uses the account name ESR [].

    • Is the only recorded instance where the slashdot troll Eric S RayRNond is more articulate, informative (and sane) than the person he's pretending to be?

      Where were the fraudelent claims of importance? Where was the gloating about wealth? Where was the entirely-out-of-context firearm advocacy? Its a very poor ESR impersonation, if it lacks those things.

      On a lighter note, the real Eric Raymond is a tit man. []
    • Since when did sending data via a 1 -> 1 TCP connection become "broadcasting"?
    • You don't have to deal with the FCC, but you will have to deal with the royalties companies.

      Sound eXchange

      Do not confuse a tool to broadcast with a authority to broadcast. Even a talk radio show has to pay fees to be a legal internet broadcaster. I work at a radio station that is going through these troubles right now. If they want to REALLY appeal to the start-up Internet DJs, they would make a logging program to make it a little easier to be legal.
      • If you're a non-profit radio station, you can use the software I developed for WMBC radio to track your CD collection, spins, attendence, schedule, and more:

        If you're a for-profit radio station, you can contact me about using the software (probably no issue unless you're a ClearChannel station, which I find repulsive).

        If you have any feature requests or suggestions, please let me know.

      • You're saying that I can't "broadcaast" (IP Multicast) my voice (as a talk show) without a license? Yeah right... when did that law get passed.

    • Eat a dick. The GNAA, Clit, Trollkore, whoever the fuck you are representing this time, are irrelevant.

      I suggest you go outside and play in the snow.
    • I know I am being quite ignorant - but wasnt there a huge lawsuit that shut down many of the indipendent internet radio stations? Is this any different, or is the key that you are not allowed to stream copyrighted material? I am just hoping that this will bring back a lot of the indie stations that I used to listen to back in the day (grrl radio) that played a good mix of indie, and the good popular stuff (radiohead, tool, the sundays, the smiths, etc).
    • To legally broadcast, you're going to have to pay some fees, I reckon. Royalties come to mind first, as the DO in fact apply as my college radio station program manager learned (in fact, royalty fees are being charged in what seems to me to be an ex post facto manner... or at least retro active as I'm not entirely sure on how royalty laws' explicitly applied internet streams), but there are other fees [] as well. Granted, earlier last year the royalty fees for College Radio were cut a bit [], but they're still
  • by kaos_ ( 96522 ) on Friday January 09, 2004 @09:14AM (#7927105)
    I'd like to run Icecast in our office relaying to some external streams to utilize bandwidth for many listeners. Unfortunately, Icecast stays connected to the relays even when there are no listeners, which is a waste. I remember earlier versions of Icecast had this feature, but it has now since gone.
  • by osmethnee ( 717516 ) on Friday January 09, 2004 @09:18AM (#7927133)
    for non-pro/home broadcasting to take off, there needs to be an underlying p2p network layer. This is particularly true as live video-streaming becomes more popular. exists, but sadly doesn't seem to have been updated for 9 months, and activity in their forum is fairly low.
  • by FrostedWheat ( 172733 ) on Friday January 09, 2004 @09:21AM (#7927144)
    Does this support non-Vorbis Ogg codecs such as Speex or FLAC?
    • Flac streaming has yet to be implemented [].
    • Monty is working on something called OggFile, which will be part of libogg2 (currently available in CVS). Basically, the goal is that OggFile will work alot like current proprietary systems (Real, Quicktime, etc) in that any program that uses OggFile will be able to transparently support any codec which OggFile supports (via plugins).

      When OggFile becomes useable support for it will be added to Icecast, whereas we'll have support to stream Flac, Speex, Theora (video), any other Ogg codec available at the

      • OOC, how does this library fit in with existing multimedia architectures (I'm thinking Gstreamer, specifically, here)?
        • Gstreamer's function would not change, it's a layer of abstraction between applications and the media formats they support. The same can be said about SDL, etc.

          OggFile could simply add an extra layer of abstraction between Gstreamer (and other multimedia libraries) and the media they access. So, instead of Gstreamer needing specific support for each Ogg codec, it will be able to support just OggFile and let the codecs each be added as plugins to OggFile.

          You see, Ogg (.ogg) is just a multimedia contain

          • While I do understand the role of Ogg, it does concern me, though, that we're talking about yet another plugin API layered into an existing API (like Gstreamer). Moreover, something like OggFile is really a duplication of effort. See, Gstreamer, for example, was designed specifically to allow things like demuxing container formats and autoplugging decoders for various media types. So, rather than writing this OggFile thing, including creating a whole new plugin API, etc, the developers could be working o
            • On the up side, OggFile means that non-gsteamer projects get better support for the various codecs, too.
            • I think Ogg needs it's own framework for codec plugins, if for no other reason than for media players that want to support Ogg but don't want to include Gstreamer as a dependency.

              Also OggFile is going to be useful for functions other than encoding/decoding. Having direct access to libogg2 means being able to do things like bitstream manipulations (cutting, pasting, etc) and, of course, Icecast and libshout (neither of which do encoding/decoding, but just stream pacing).

              It seems like Gstreamer supportin

  • Debian Install (Score:5, Informative)

    by rudabager ( 702995 ) on Friday January 09, 2004 @09:24AM (#7927158) Homepage
    Incase anyone cant fig it out, icecast is avialable for debian as "apt-get install icecast-server".
  • by acomj ( 20611 ) on Friday January 09, 2004 @09:37AM (#7927234) Homepage
    Gotta love the slashdot effect. 15 comments and the servers down..
  • by alexatrit ( 689331 ) on Friday January 09, 2004 @09:41AM (#7927255) Homepage
    I used to run small stations in college, using Shoutcast on both Windows and FreeBSD. Very simple to install and run. I've read the Icecast FAQ, and I'm a bit confused. It says that it's compatible with Shoutcast servers. Does this mean's listing servers? Has anyone seen how Shoutcast and Icecast compare as far as memory footprint, system usage, bandwidth usage? or are they more or less the same?
    • I believe it means that a Shoutcast client can access an Icecast server as if it were a Shoutcast server. Icecast has potentially lower bandwidth usage, since it supports Vorbis. Otherwise, I've never noticed much of a difference (I've never used either of them for anything serious).
    • icecast is supposed to be able to get you listed in both icecast and shoutcast directory servers, though some people have had trouble with this.

      We started out running shoutcast after deciding to ditch Real. I moved to icecast mainly because the source was available and it was in Debian. I still have a bad taste in my mouth from Real's software keeping one of our servers stuck on kernel 2.0 and glibc 2.0, and I don't want to run anything dependent on one entity recompiling it.

  • For those using pkgsrc, cd to /usr/pkgsrc/audio/icecast and make install

    Thanks, I'll be here all day!
  • Mirror (Score:5, Informative)

    by arvindn ( 542080 ) on Friday January 09, 2004 @09:53AM (#7927336) Homepage Journal
    Mirror []
    • Regarding your .sig... That (complex) method is completely unnecessary.

      Obviously you know that you can simply check-mark the box for Yahoo to set the cookie, but I'm not really refering to that either.

      Although the plain HTML version requires javascript encryption, the SSL version does not require javascript at all, so you can just enter a URL like this: N AM E&pass
      wd=PASSWORD&.done= AH?
  • I have to admit (Score:3, Interesting)

    by silence535 ( 101360 ) on Friday January 09, 2004 @09:55AM (#7927350) Homepage
    that I was somehow annoyed that they declared the old version (1.3.2 or something?) as deprecated long time before releasing 2.0. And the website has been unmaintained for quite a long period of those three years.
    Actually I turned off my little community-radio-streaming-project just because ogg support was flaky and administration and monitoring was difficult.

    But hey, it is always easy to bitch and not to help hands on.

    Maybe now Iwill pick up this thing again..


  • Ogg rules (Score:4, Interesting)

    by wfberg ( 24378 ) on Friday January 09, 2004 @10:12AM (#7927496)
    .. especially for streaming, since a 64kbps stream sounds as good as a 128kbps mp3 stream, which means more people can listen to it, even on their congested at-work LANs, and if you don't attract more people, then at least you cut your bandwidth bill in half. Other codecs that sound sweet at 64kbps exist (windows media, real, quicktime) but they're not free, so you end up paying more than you save in bandwidth.

    And if you go legal with your streams, some licensing authorities (for want of a better word) haven't been clued in to how good ogg sounds at half the bitrate, so they'll give you a sucky-quality discount.

    If you want to go legal w.r.t. streaming BigFive content in The Netherlands, I don't recommend it btw. BUMA/Stemra seem to have a process in place that's relatively sane (i.e. flat fee for non-commercial use) but you ALSO have to pay SENA (not that it's not spelled SANE..) who are total fucktards in their pricingstructure (BUMA/Stemra are fucktards as well, but at least the pricing schedules seem doable. Anyway, having investigated the options I decided against it (and no, I don't stream unlicensed either).
    • >Other codecs that sound sweet at 64kbps exist (windows
      >media, real, quicktime) but they're not free, so you end up
      >paying more than you save in bandwidth.

      Darwin Streaming Server (Quicktime) *is* free and open source (APSL).

      • Re:Ogg rules (Score:3, Informative)

        by xiphmont ( 80732 )
        ... but the AAC+SBR you need to get low bitrate performance with Darwin is not.

        (He said Ogg, not Icecast, as Icecast is not a codec and neither is the Darwin Streaming Server)

    • "... more people can listen to it, even on their congested at-work LANs, and if you don't attract more people, then at least you cut your bandwidth bill in half."

      You have to pay for your LAN bandwidth at work? Wow! You do have tough IT department. Most places I've worked the IT department is a continual expense that managers don't understand. Your's must be profitable!

      • "... more people can listen to it, even on their congested at-work LANs, and if you don't attract more people, then at least you cut your bandwidth bill in half."

        You have to pay for your LAN bandwidth at work? Wow! You do have tough IT department. Most places I've worked the IT department is a continual expense that managers don't understand. Your's must be profitable!

        Reading must be hard. YOU might attract more people (THEM) on congested LANs, and if YOU don't attract THEM then YOUR (i.e. not THEM wh
        • Grammar isn't your forte, is it? With a LAN, there typically isn't a "bill". I guess I read better than you write. Of course, your over-sensitive reaction also indicates a humungous sense of humour failure. Most people who find something unfunny just ignore it and move on, they don't overreact like a petulant child!
          • Grammar isn't your forte, is it? With a LAN, there typically isn't a "bill". I guess I read better than you write. Of course, your over-sensitive reaction also indicates a humungous sense of humour failure. Most people who find something unfunny just ignore it and move on, they don't overreact like a petulant child!

            On to the ad hominems, are we? If you listeners are on a congested LAN (note how I'm not saying this LAN is not somehow inter-networked, as I'm assuming it is) and you're streaming from the in
    • Other codecs that sound sweet at 64kbps exist (windows media, real, quicktime) but they're not free,

      I was listening to a 64K (stereo) WMA not long ago, and it sounded like crap. It may be a step-up from MP3, but it's got a way to go to catch-up.

      Quicktime isn't a codec, so I can't say much there.

      As for RealAudio, who really wants to have streams that can only be played back with RealPlayer? With Ogg, you've got support in Winamp/XMMS/ZINF, so your regular audio player can handle it.

      Personally, the thin

  • Anyone know how to capture windows sound output?

    I would like to capture it and then broadcast with icecast2.
    Found you could use a winamp plugin to source icecast2. However winamp can not capture sound(I think?).

    Have fun!
    holepit []; a winders game.
    • I've seen quite a few live input plug-ins. Plus I've seen instructions on setting this up with the default shoutcast transcoder.

      Here's one winamp plug-in (from NullSoft) to try:
      Shoutcast Live Input Plug-in Download - 1.0b []

      I just set up a shoutcast server (not icecast ... yet!) to stream my band's original music (shameless plug []). Just an mp3 stream right now (well, two: 96kbps and 24kbps). I'm looking for an easy (open source?) way to also stream WMA. As many people have mentioned, some people just won't
      • Using the Shoutcast DSP (dunno about Odd or Ice), you can specify the soundcard as your audio source, not Winamp. Then, all you need to do is change your recording source in the windows mixer to "What-U-Hear" (not all sound drivers have support for this). Then you can capture anything that opens a windows wave handle. The quality will probably suffer a bit.
    • Why the hell would you want to output wma etc? That's basically closing your audience to people who run doze or people who gone to the trouble to set up the proprietary codecs on other systems. From a community standpoint, wouldn't mp3 be the best format for output? Ogg would be the most optimal, but unfortunately hasn't become common enough.
      • My main connection is a 96kbps mp3 stream. I'm using streamTranscoder from to provide a second 24kpbs mp3 stream. In no way do I want to run JUST a WMA stream. I just want a way to add another stream that's a WMA of the current mp3 stream. Getting a lot of complaints that the radio doesn't work from people who only have Windows Media Player.
  • So, are they using UDP as a transport yet? I doubt it. I know, I know, the Icecast people just build a server for the Shoutcast protocol, but dammit, it's always bugged me that the designers of Shoutcast decided to use TCP as the underlying transport. UDP makes metric assloads more sense for a time-sensitive application like realtime audio delivery, where the consequences of losing a packet or two are nothing more than a momentary audio glitch. One thing that caused me to give up on internet radio was the p
    • There is a spec for streaming Vorbis over RTP [] (which I belive is usually on top of IP directly). I don't know of any implementations of this, though...
      • Re:Vorbis-over-RTP. (Score:2, Informative)

        by poussiere ( 739579 )
        Vorbis over RTP is not usable as it is, as vital info regarding decoding header tranmission is missing. Anyway, UDP would be really interesting over a p2p multicast streaming network. MP3 over RTP is quite usable (with RFC3119 type streaming).

        Self-advertising: poc ( can stream ogg/vorbis over HTTP and mp3 over UDP (RTP, and UDP with FEC) and HTTP.
    • Three years of development
    • Six weeks of testing
    • Tweny four hours of having your site ./'d so nobody can try your leet code out
  • by bigberk ( 547360 ) <> on Friday January 09, 2004 @12:01PM (#7928613)
    All icecast 2 betas I tried were missing a vital feature; the ability to flood audio data out at the start of the TCP connection (rather than deliver it at the stream bitrate) -- this is vital because when you take too long delivering the data your stream can die due to filled queues.

    For example, there may be temporary packet loss on the network that results in TCP data queueing up at the sending side. Now unless icecast can correct for that rate mismatch, you're consistently behind and eventually the stream dies.

    I think they might have now added the fix, which is to step up its send rate from the stream bitrate whenever it has to, i.e. whenever the client falls behind (temporary network glitch). The unfortunate result otherwise is that your streams can die on a flaky network connection, even if the average bandwidth over time is more than enough to handle the audio stream!

    Or... let me know, try my stream []
    . Does it die on you quite quickly after connect?
    • From the Release Plan []:

      2.1 Release
      Feature: burst-on-connect
      Description: This functionality adds the ability to set internal icecast buffering parameters which affect listeners who first connect to a stream. Currently, listeners experience seeming high buffering times due to the fact that icecast does not send data out faster than data coming in from the source client. By adding burst-on-connect, listeners will be able to get a burst of data from icecast on first connect which may eliminate this buf
    • by xiphmont ( 80732 ) on Friday January 09, 2004 @07:56PM (#7934376) Homepage
      It always worked properly; you misunderstand how the timing has to work.

      When a connection is momentarily interrupted, the streaming server doesn't just stall the timing on the connection; it's still tracking how much data had to go out in a given period of time. The total output at any time will always be up to date. Thus, if the network connection is interrupted momentarily, the data will indeed burst forward to the correct point when connectivity resumes. It's like squeezing off a very stretchy hose for a short time.

      The connection is dropped only if connectivity disappears for longer than a certain threshold. Oh, and naturally, if you're trying to listen to a broadband bitstream over a 28.8 modem, you're going to get kicked pretty quickly. The hose only stretches so far, and if it bursts your connection gets dropped. That's not a bug.

      Also, a client that falls behind on its own will eventually burst the hose. That's a bug in the client; you won't fall further and further behind unless a) your playback rate is way off or b) your buffering is pooched. It's the client's responsibility to accept data at the rate the streaming server sends it. The streaming server's timing is correct; if something happens to mess with the client timing, the client has to deal with that.

      As for 'flooding data at the beginning of a connection', that doesn't really make sense in a system where every client has a configurable, different sized prebuffer.

      • Thanks for the reply xiphmont. I have been trying to debug my situation for a while now... what I can't figure out is that when doig a TCP transfer (like an FTP) to the host running my icecast server, I can transfer at ridiculous rates like 150 KBytes/sec. Yet my audio streams almost always die within a few minutes of connecting. This makes me think it can't be a bandwidth issue... then again, maybe it's a Winamp and XMMS bug I'm seeing?
        • You should probably describe more the setup and the situation under which this is happening; networks are finicky beasts and if this is passing over a cablemodem link or DSL or WAN routing, burst loss or bandwidth assymetry or ARP warring could certainly cause it. Or the clock on your PC may be way too slow/fast. It's unlikely WinAmp or XMMS, but there's easy ways to figure that out too.

          Slashdot is the wrong place to debug this further, but if this is causing you headaches (it seems it is) and you want t
    • maybe if you used ogg vorbis at a lower bitrate (which would have the same sound quality as mp3 at higher rate), then you would have fewer problems.

      plus, posting your server to slashdot can't be good for your bandwidth usage.
  • When will NSV get it's feet off the ground? I've always wanted a Net TV Station publishing all manner of crap on my hard drive!
  • Icecast is awesome for audio streaming, and a joy to use. Any video relay servers out there work as well and easy as Icecast?
    • Re:What about Video? (Score:2, Informative)

      by ArcRiley ( 737114 )
      See above thread about OggFile (Alternative Codecs). Icecast will likely support streaming Ogg Vorbis+Theora (and other codec combinations) when OggFile is released.

      Media players which support Ogg Theora alpha-2 (Xine and mplayer) already support streaming Ogg video. If you have one of these players compiled with Theora support, try opening it with a url from here [].

Sigmund Freud is alleged to have said that in the last analysis the entire field of psychology may reduce to biological electrochemistry.