similar to: VBR reencoding @128k problem

I did some further investigating into this issue and here's what I found: It appears somewhere between ices0.1.0 and ices 0.2.0 is where the "bug" (for lack of a better term) was introduced that i'm noticing. When I compile ices0.2.0 w/lame 3.89beta, the VBR is *NOT* reencoded, but instead streamed out at full VBR bitrate(s). However, when using ices0.1.0 w/lame 3.89beta, it

On Wednesday, 28 November 2001 at 12:43, Bolt Thrower wrote: > > The format of ices.conf changed somewhat in 0.2, to support multiple streams > > from the same playlist with different reencoding options. In short, these > > settings have been moved into the Stream node. For more info have a look > > at the sample ices.conf included with the distribution. > > I did

Carsten Henkel wrote: > hi, > if i reencode a stream that is in mp3pro (streamed with sam) to a > lower bitrate by using ices/lame, is the reencoded stream mp3 or mp3pro > ? MP3. LAME does not do MP3Pro. And in fact, the stream that is reencoded will also only be a reencode of the MP3-compatible layer of the MP3Pro stream, as Ices does not know how to decode MP3Pro streams

Guten Tag Geoff Shang, Am Freitag, 14. Januar 2005 um 13:22 schrieben Sie: GS> Carsten Henkel wrote: >> if i reencode a stream that is in mp3pro (streamed with sam) to a >> lower bitrate by using ices/lame, is the reencoded stream mp3 or mp3pro GS> MP3. LAME does not do MP3Pro. And in fact, the stream that is reencoded GS> will also only be a reencode of the

hi, if i reencode a stream that is in mp3pro (streamed with sam) to a lower bitrate by using ices/lame, is the reencoded stream mp3 or mp3pro ? thank you -- Mit freundlichen Gr?ssen Carsten Henkel mailto:carsten@chatlabel.de Eine gl?ckliche Frau braucht 4 Tiere: einen Jaguar in der Garage, einen Nerz im Schrank, einen Hengst im Bett und einen Esel, der alles

Brendan Cully wrote: > > The format of ices.conf changed somewhat in 0.2, to support multiple streams > from the same playlist with different reencoding options. In short, these > settings have been moved into the Stream node. For more info have a look > at the sample ices.conf included with the distribution. I did modify my ices.conf when I made the upgrade. Here's my

Hi! Inspired by the discussion about mixing Vorbis streams and so on I came to the question whether Vorbisstreams can be, just like MP3, reencoded without further loss. As I heard, and I am pretty sure that it's true, MP3 files can be decoded and reencoded unlimited times without further quality loss (of course the same encoder with the same preferences has to be used all the time). Is this

Ok, not bad -be sure to rm config.cache if ices has already been compiled. Then ./configure --with-lame-libraries=/usr/local/lib --with-lame-includes=/usr/l ocal/include/lame/ >configure.out Check configure.out for: updating cache ./config.cache checking for lame/lame.h... yes checking for lame_init_old in -lmp3lame... yes checking for lame_encode_flush_nogap in -lmp3lame... yes updating

On Sat, Mar 23, 2002 at 07:13:44PM -0700, Jack Moffitt wrote: > > I posted a while back about having trouble with ices 0.2.2 being > > able to re-encode VBR mp3s, and the response was that ices 0.2.2 did > > not reencode VBR mp3s. Are there any plans to include such support > > in future ices versions? If so, any ideas as to when such versions > > would become

Hi, I'm having trouble getting ices 0.2.3 to reencode MPEG-2 LSF mp3s, the files are playing back around twice as fast as they are supposed to, ie the "chipmunk effect". I'm not encoding the originals but I've tried encoding them with lame to the same effect which causes me to believe the problem is with ices' decoding. The source files are of varying bitrates and

Ok so I'm up and riding with Icecast2 and ices2, thanks for all of you who pointed me in the right directon. I can stream fine without reencoding but when I change the nominal-bitrate tag its not happy. Comments in the xml file say: <!-- Live encoding/reencoding: Currrently, the parameters given here for encoding MUST match the input data for channels and sample rate. That restriction

---[start]----- <!-- Stream bitrate, used to specify bitrate if reencoding, otherwise just used for display on yp and on the server. Try to keep it accurate --> <Bitrate>64</Bitrate> <!-- If this is set to 1, and ices is compiled with liblame support, ices will reencode the stream on the fly to the stream bitrate. -->

Hello: I am running the icecast2.3.2 server and ices0.4 with a perl script which provides the filename of the next track to play. I am reencoding in advance using ffmpeg, which has been very reliable. My main stream is mp3, 64kbps / 44.1 kHz (mono) and I have pre-reencoded the tracks to 32kbps / 22.05 kHz (mono), for a lower data rate stream. At this time, I have not figured out how to get a

I posted a while back about having trouble with ices 0.2.2 being able to re-encode VBR mp3s, and the response was that ices 0.2.2 did not reencode VBR mp3s. Are there any plans to include such support in future ices versions? If so, any ideas as to when such versions would become available? Thanks, -- "Shall life renew these bodies of a truth? Steve Chadsey All death will

another solution would be to reencode mp3 files at the wanted bitrate first, and then serve them via ices to icecast ;) On Wed, 5 Oct 2005 11:43:27 -0600 (MDT) Anno Domini, the honourable Robert Muchnick wrote using one of his keyboards: > On a Linux server (2.4.29) with 3.0GHz PIV and 1GB memory, ices 0.4 > sending to icecast 2.2 on the same machine without re-encoding will > not even

i have installed ices with lame suport (thanks to all who helped!), and it happily reencodes bitrates. i have installed otto, and that too is brillient however i can't get otto to call ices in such a way that it will reencode stuff streamed thru otto... when i have had ices working with reencoding, i've configured it via the xml config file rather than with command line switches

I'd like to use the Bitrate and Reencode features of ices and understand I must recompile with lamelib. However, it's Very Unclear where to begin here. This is noted in the ices-0.2.3 INSTALL file: I installed lame as a debian package so lame.h is in /usr/include/lame/lame.h and libmp3lame.a is in /usr/lib. configure finds everything automatically. <p>I assume we

> > The response I got at the time from Brendan Cully: > > He's the man in the know, so what he says is probably true. Maybe if > you asked him nicely he'd cook up a small patch for you :) > > jack. > I worked out a patch for ices-0.2.2 that forces ices to *always* re-encode the stream if Reencode is enabled: --- CUT HERE --- --- src/stream.c.orig Thu Jul 26

hi icecast/ices/lame/otto all work beautifully (most of the time!) however, certain tracks, encoded as VBR files with either grip+lame (linux), or audiocatalyst (win2k), are unplayable (using ices to reencode and stream at 128kbps)...ices streams a few hundred millisenconds then quits... from reading on the FAQ/BUGlist, the only thing i can see if that these may be 'corrupt', causing

I'm trying to reencode my mp3 with the ices, but with ices0.1 an 0.2.2 i got a segmentation fault. in other try, i have used `ices -F etc/playlist.txt -R -H 32 -P teste` and i got these errors: ---- Logfile opened Error setting LAME parameters. Check bitrate, channels, and sample rate. Connected to server 127.0.0.1... Streaming 12672896 bytes from file /home/staff/alfredo/mp3/queen/Queen -