similar to: mp3 checking

I've installed the openss* rpm's from metalab.unc.edu/pub/Linux/distributions/redhat/contrib/libc6/i386 on a redhat 6.2 system. sshd is running but refuses all connections from all hosts including localhost. The client reports debug: Connection established. ssh_exchange_identification: Connection closed by remote host debug: Calling cleanup 0x8056160(0x0)

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

Hello everyone, I am running Icecast 2.0.0 with ices-3.0. I run ices on a machine which has all the mp3 files I am playing and stream these mp3 to Icecast which is running on another machine. Every now and then, say 2 hours. Ices keeps churning out errors saying updating meta data and socket errors and keeps retrying and after some time it suceeds for one file and then when playing the next file

> 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

> Hi Ady, > > On 2016.02.25 02:08, Ady via Syslinux wrote: > > There is an "extra" sector, in comparison to... what exactly? > > Sorry if I wasn't clear. I think I implied that the Large FAT32 fat size > had an extra sector compared to minfatsize, when of course I meant the > opposite (the Large FAT32 has one less sector than the minfatsize >

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:

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

fwiw erver icecast 1.3.7 / ices 0.0.1beta5 erver on a dsl line (384kbps) client on a LAN separate to it going through several hops winamp has the drop client problems. And recently another weird problem, it spawns with only one channel balance way over to the right. this can suck if your windows has no balance control for its audio! onique: stays connected for hours and hours xmms/unix .

I am pretty sure that the integrity of my mp3's is okay. I know that music match shreds the mp3 data and produces mp3 files that are not ISO compliant. I always use WaveLab and the radium codec to encode my sets and enable the ISO compatibility option at all times. This problem only seemed to come about with winamp 2.7 but if sonique is doing it to, I don't know... What about relaying? Do

At 4:37 PM -0400 7/6/01, Brendan Cully wrote: >On Friday, 06 July 2001 at 13:21, tom erbe wrote: >> At 1:48 PM -0400 7/6/01, Brendan Cully wrote: >> > > 0.2 doesn't segfault, but it seems to overrun the server (if that >> >> makes any sense), it plays a 3 minute file in seconds. >> > >> >I'd like to know more about this. Are you

I have been following flac development for some time now, but with the release of 1.0.4 I thought I would finally start the task of encoding my entire cd collection into flac format. After looking through the list archives and the webpage I still have a few unanswered questions. 1. What is the best method tagging method to use? Josh mentioned that id3v1 was preferred over id3v2 since it

I am trying to set up Icecast and IceS. I have icecast 2.0.1 up and running. but when I try to start IceS 0.3 I get a seg fault. Here is the output: # /path/ices -r -c /confpath/ices.conf -F /playlistpath/playlist.pl -P password Logfile opened DEBUG: Sending following information to libshout: DEBUG: Stream: 0 DEBUG: Host: localhost:8001 (protocol: xaudiocast) DEBUG: Mount: /example1.mp3,

Hi Ady, On 2016.02.25 02:08, Ady via Syslinux wrote: > There is an "extra" sector, in comparison to... what exactly? Sorry if I wasn't clear. I think I implied that the Large FAT32 fat size had an extra sector compared to minfatsize, when of course I meant the opposite (the Large FAT32 has one less sector than the minfatsize computed by the unpatched code, hence the check

Awesome, I'm psyched for 1.0.3.... the ID3v1 winamp2 support will be a neat addition, as is the faster decodes. Will 24-bit audio play nice with the final public version of 1.0.3? MW On Tue, 11 Jun 2002, Josh Coalson wrote: > One more thing... you will probably have to > > chmod +x flac-1.0.3_beta/test/test_streams.sh > > before doing the 'make check'. > >

> Please try a stable version of LAME. I don't really know what to do > with this backtrace. It would also help immensely if you could > reproduce the crash reliably (eg on the same song). DEBUG: Using LAME version 3.93 (gdb) bt #0 0x402b7585 in III_dequantize_sample () from /usr/local/lib/libmp3lame.so.0 #1 0x402d1200 in ispow () from /usr/local/lib/libmp3lame.so.0 Cannot access

Yeah, ezstream is a source client just like ices0, but the manner in which they go about processing files or playlists may differ. I don't know too much about ices0 but in the configuration for ezstream you can either specify a single file to stream or you can point it to an m3u playlist and it will play though that, I'm not sure this is compatible with how you currently queue media.

> 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

Testing the DOS-based Syslinux installer, syslinux.com, with the "-m" parameter, I found that it works as expected under MS-DOS and its DOS variants, but it seems to fail under FreeDOS (please correct me if I'm wrong). Using FreeDOS kernel v.2041 (386f32), Syslinux v.6.03-pre11 and either FAT16 or FAT32 partitions, executing: syslinux.com -m -i c: or: syslinux.com -f -m -i

I just added code to the Winamp 2 plugin that reads/writes ID3v1.1 tags in FLAC files from the 'Get File Info' dialog and properly reports the artist and title information to the playlist. In what format would you prefer the new code? Additionally, do you think it would be worth adding this functionality to the FLAC API? It would be cool to have the capability to write ID3v1 tags from the