yep, they simply forward the bitstream to icecast. And in general, bitrate changes are handled by most listening clients, although very few I have found (if any) can handle samplerate changes appropriately. oddsock At 10:03 AM 9/14/2004, you wrote:>You mentioned these programs and their "no-reencoding" mode. Can they >handle collections of MP3s of different bitrate? > >On Tue, 14 Sep 2004, oddsock wrote: > > > Date: Tue, 14 Sep 2004 09:08:17 -0500 > > From: oddsock <oddsock@oddsock.org> > > To: icecast@xiph.org > > Subject: Re: [Icecast] Questions on setting up icecast > > > > At 04:14 AM 9/14/2004, you wrote: > > >JLB wrote: > > >>Sorry, gang. The FAQ didn't seem to answer me, nor did Googling... > > >>I merely want a simple solution to do the following: > > >>I am setting up a streaming server for in-house use. > > >>I want it to broadcast the RAW MP3 DATA from my actual MP3 files, as I > > >>listen to them in xmms. > > >>In other words, I DO NOT want: > > >>XMMS ---> decode to wave ---> re-encode to MP3 ---> icecast ---> > listeners > > >>I want: > > >>XMMS ---> icecast ---> listeners > > >>Surely this is do-able using a VBR stream? In other words, I DO NOT want > > >>my MP3s to be decoded, then re-encoded, then sent over the network (the > > >>re-encoding, of course, introducing further lossiness). I want the actual > > >>raw MP3 frames to be sent as a VBR stream to the listeners. I want > the MP3 > > >>to sound PRECISELY as good on the listening machine as on my machine. > > >>Surely this is do-able? > > > > > >http://www.oddsock.org/tools/oddcastv2_xmms/ > > > > my plugin reencodes, so I don't think that's what you want. In fact, I > > don't know of any way to use XMMS in this way. The problem, is that by the > > time the DSP plugin gets the audio data, it's already been decoded. You'd > > have to write an XMMS input plugin to somehow intercept the data and send > > it along to an icecast server. Nothing like this has been written as far > > as I know. > > > > alternatively, you can use ices or ezstream in "non-reencoding" mode, which > > is the closest to what you want. > > > > > > oddsock > > > > >Stephen > > >-- > > >LiveIce Project http://liveice.sourceforge.net/ > > >_______________________________________________ > > >Icecast mailing list > > >Icecast@xiph.org > > >http://lists.xiph.org/mailman/listinfo/icecast > > > > > > > > > _______________________________________________ > > Icecast mailing list > > Icecast@xiph.org > > http://lists.xiph.org/mailman/listinfo/icecast > > > >-- >J. L. Blank, Systems Administrator, twu.net
On Tuesday, 14 September 2004 at 10:38, oddsock wrote:> yep, they simply forward the bitstream to icecast. And in general, > bitrate changes are handled by most listening clients, although very > few I have found (if any) can handle samplerate changes > appropriately. > > oddsock > > At 10:03 AM 9/14/2004, you wrote: > > > >You mentioned these programs and their "no-reencoding" mode. Can they > >handle collections of MP3s of different bitrate?It might be worth mentioning that ices 0.4 will do lazy reencoding. That is, if the bit rate, channels, and sample rate of the source file match the declared bit rate, channels and sample rate of the stream, ices will just pass the MP3 data through. But if there is a mismatch, ices will reencode the file to match the stream parameters.
What's the difference between bitrate and samplerate? Samplerate is like 44KHz or 48KHz? On Tue, 14 Sep 2004, oddsock wrote:> Date: Tue, 14 Sep 2004 10:38:50 -0500 > From: oddsock <oddsock@oddsock.org> > To: icecast@xiph.org > Subject: Re: [Icecast] Questions on setting up icecast > > yep, they simply forward the bitstream to icecast. And in general, bitrate > changes are handled by most listening clients, although very few I have > found (if any) can handle samplerate changes appropriately. > > oddsock > At 10:03 AM 9/14/2004, you wrote: > >You mentioned these programs and their "no-reencoding" mode. Can they > >handle collections of MP3s of different bitrate? > > > >On Tue, 14 Sep 2004, oddsock wrote: > > > > > Date: Tue, 14 Sep 2004 09:08:17 -0500 > > > From: oddsock <oddsock@oddsock.org> > > > To: icecast@xiph.org > > > Subject: Re: [Icecast] Questions on setting up icecast > > > > > > At 04:14 AM 9/14/2004, you wrote: > > > >JLB wrote: > > > >>Sorry, gang. The FAQ didn't seem to answer me, nor did Googling... > > > >>I merely want a simple solution to do the following: > > > >>I am setting up a streaming server for in-house use. > > > >>I want it to broadcast the RAW MP3 DATA from my actual MP3 files, as I > > > >>listen to them in xmms. > > > >>In other words, I DO NOT want: > > > >>XMMS ---> decode to wave ---> re-encode to MP3 ---> icecast ---> > > listeners > > > >>I want: > > > >>XMMS ---> icecast ---> listeners > > > >>Surely this is do-able using a VBR stream? In other words, I DO NOT want > > > >>my MP3s to be decoded, then re-encoded, then sent over the network (the > > > >>re-encoding, of course, introducing further lossiness). I want the actual > > > >>raw MP3 frames to be sent as a VBR stream to the listeners. I want > > the MP3 > > > >>to sound PRECISELY as good on the listening machine as on my machine. > > > >>Surely this is do-able? > > > > > > > >http://www.oddsock.org/tools/oddcastv2_xmms/ > > > > > > my plugin reencodes, so I don't think that's what you want. In fact, I > > > don't know of any way to use XMMS in this way. The problem, is that by the > > > time the DSP plugin gets the audio data, it's already been decoded. You'd > > > have to write an XMMS input plugin to somehow intercept the data and send > > > it along to an icecast server. Nothing like this has been written as far > > > as I know. > > > > > > alternatively, you can use ices or ezstream in "non-reencoding" mode, which > > > is the closest to what you want. > > > > > > > > > oddsock > > > > > > >Stephen > > > >-- > > > >LiveIce Project http://liveice.sourceforge.net/ > > > >_______________________________________________ > > > >Icecast mailing list > > > >Icecast@xiph.org > > > >http://lists.xiph.org/mailman/listinfo/icecast > > > > > > > > > > > > > _______________________________________________ > > > Icecast mailing list > > > Icecast@xiph.org > > > http://lists.xiph.org/mailman/listinfo/icecast > > > > > > >-- > >J. L. Blank, Systems Administrator, twu.net > > > _______________________________________________ > Icecast mailing list > Icecast@xiph.org > http://lists.xiph.org/mailman/listinfo/icecast >-- J. L. Blank, Systems Administrator, twu.net
JLB wrote:> What's the difference between bitrate and samplerate? Samplerate is like > 44KHz or 48KHz?Yes. Sample rate says how many samples of the sound are taken per second. The bit rate is how many bits are used to store a representation of those samples. Lets use an example. Suppose we have three files, all at 64kbps. One is 44.1kHz mono, one is 22.05kHz stereo and one is 22.05kHz mono. Now, all use 64000 bits per second to store the sound. The 22.05kHz mono file should, at least in theory, be the most faithful reproduction of the 22.05kHz sound, since it's using the same amount of data to compress half the sound of either of the other two versions. The 22.05kHz stereo file is using the same amount of data to compress two channels, so the amount of data per channel that is available is less, resulting in a lower quality representation of that 22.05kHz sound. The 44.1kHz signal has twice the resolution of the 22.05kHz signal, but again is only using the same amount of data. It's like trying to squash a picture that's twice the size into the same amount of data - it can be done, but depending on how well that compression works, the result mightn't be very good. Streaming formats are always a compromise between sampling rate and bit rate. If you're wanting to set up a stream for a modem listener, you need to ask yourself - do I want the highest sample rate possible knowing that it might not represent very well, or do I want a lower rate which will reproduce better, or maybe do I want a stereo stream versus a mono one. Geoff.