similar to: 'corrupt' mp3s/icecast reencoding/mpglib

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 touch the 1 minute load average in the normal kbps/KHz range. With re-encoding, however, the 1 minute load average varies between 0.7 and less than 2.5, which could impact server performance with high listener counts. The files I was testing were not

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

hello anyone of you who has used the reencoding option of ices to bring the stream at a constant bitrate would be kind to share the experience (the impact on resources and, quoting the README file - "...mpglib part of lame (what does the decoding) is rather unstable and will call exit(0) when errors are encountered." - and stability of the stream). thanks, petre -- Petre Bandac -

I do use metadate since i need people to see the titles. I use livecast in mixer mode. The chopping starts right away I don't use VBR (I commented it out at least). The mp3's are made with XING audiocatalyst (for windows) so I don't really know. Sorry. Arvid ----- Original Message ----- From: Jack Moffitt <jack@icecast.org> To: <icecast@xiph.org> Sent: Tuesday, March 27,

Hello Sirs, > > Have you ran them through mp3check and mp3_check? > >Yep. Found a couple with a few bad frames and deleted them. Other than >that, nothing worse than a missing ID3 tag or two. Could you please give me the address of these tool(mp3check, mp3_check). I have many bad coded mp3, When Icecast streaming these bad! mp3s it kicks the connected clients. I want to delete

On Tuesday, 27 November 2001 at 18:14, Bolt Thrower wrote: > I recently upgraded ices from 0.1.0 to 0.2.2. I have found that it > is not reencoding my mp3 stream, even though I have it configured to. > > This is on a RedHat linux 7.0 system, kernel 2.4.11 > > ices build commands: > ./configure --with-perl --with-lame \ >

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

Moritz Grimm wrote: > > Bolt Thrower wrote: > > > >From my ices.conf: > > <Bitrate>64</Bitrate> > > > My mp3s are encoded with the following command: > > /usr/local/src/lame3.86/lame -S -V 1 -b 128 -h -m j \ > > --tt "title" --ta "artist" --tl "album" \ > > --ty "year"

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 Jack, interesting that you should mention NTP. With the problem that I am having, I am getting actual libshout errors. I have run all my mp3s through mp3check and my disk subsystem is 7200 RPM SCSI. Why would NTP cause issues? ----- Original Message ----- From: "Jack Moffitt" <jack@xiph.org> To: <icecast@xiph.org> Sent: Wednesday, February 06, 2002 1:48 PM Subject: Re:

I recently upgraded ices from 0.1.0 to 0.2.2. I have found that it is not reencoding my mp3 stream, even though I have it configured to. This is on a RedHat linux 7.0 system, kernel 2.4.11 ices build commands: ./configure --with-perl --with-lame \ --with-lame-includes=/usr/local/src/lame-3.89/include \ --with-lame-libraries=/usr/local/src/lame-3.89/libmp3lame/.libs gmake

I need to make a Asterisk 18.0's offline compiling, SVN mp3 support sources downloading does't particulary works cause my asterisk is in an isolated network with NO network access whatsoever, I ve read this thread ( http://lists.digium.com/pipermail/asterisk-users/2013-June/279298.html) but I 'm not understading one thing, because I download the file and run the script but there is no

Hey there again On Wed, Feb 28, 2001 at 12:16:12PM +0100, Thomas Vander Stichele wrote: > The tests I've done in-house were with winamp as a client, and the > following server/streamer combinations : > icecast 1.3.0/shout 0.8.0 > icecast 1.3.7/shout 0.8.0 > icecast 1.3.8b2/shout 0.8.0 dont use shout! its buggy use ices or use libshout > icecast 1.3.8b2/ices 0.0.5 another

On Wed, 6 Feb 2002, Jack Moffitt wrote: > THen I suggest you start to look elsewhere for your problem. libshout > is quite well tested and every time someone has thought it was skipping, > it turned out to be NTP chaning their clock or a slow harddrive or > something similar. I'm saying "Here's this problem I'm having, how do I fix it?" I don't care if the

Stupid question - how do you increase your buffer size? Gary ----- Original Message ----- From: "Jack Moffitt" <jack@xiph.org> To: <icecast@xiph.org> Sent: Wednesday, February 06, 2002 1:48 PM Subject: Re: [icecast] Stuttering stream <p>> > Done, and it's working... but not significantly better than before. > > Whereas before I couldn't clear a

Apologies if this is off topic, but could anyone recommend a utility for checking/repairing mp3's? I'd like to be able to * convert id3v1 tags to v2 (or vice versa) * make sure the filename fits in fat32 restrictions * be automatable (plugged into ices.p[m|y] for dynamic playlists) Mp3check is pretty good, but doesn't do those first two items (perhaps it could in conjunction with

> Hey there again > > On Wed, Feb 28, 2001 at 12:16:12PM +0100, Thomas Vander Stichele wrote: > > > > The tests I've done in-house were with winamp as a client, and the > > following server/streamer combinations : > > icecast 1.3.0/shout 0.8.0 > > icecast 1.3.7/shout 0.8.0 > > icecast 1.3.8b2/shout 0.8.0 I don't know what it is that causes

> Done, and it's working... but not significantly better than before. > Whereas before I couldn't clear a single song without the stream devolving > into skipping, now I'm averaging between 15-20 minutes. Better, but still > not acceptable. THen I suggest you start to look elsewhere for your problem. libshout is quite well tested and every time someone has thought it was

Hello Icecast group, I have a problem with compiling lame or other programms, I get always the message from stupid libtool libtool is installed, I use Solaris9 (sunOS 5.9) has any person a idea? thank you for help Daniel # make cd . \ && CONFIG_FILES= CONFIG_HEADERS=config.h \ /bin/bash ./config.status config.status: creating config.h config.status: config.h is unchanged

Hello, We have a system which creates thousands of regression/classification models and in cases where we have only one input variable NaiveBayes throws an error. Maybe I am mistaken and I shouldn't expect to have a model with only one input variable. We use R version 2.6.0 (2007-10-03). We use caret (v4.1.19), but have tested similar code with klaR (v.0.5.8), because caret relies on