similar to: No re-encoding?

[sorry; sending again from registered email address] Hmmm. Specifying a quality in the ices config: - changed what was displayed on the status page - didn't seem to change the bit rate displayed in xmms - did seem to improve the sound quality Is it possible to get ices to stream data without re-encoding? Does specifying the same parameters used to generate the original file do so, or does

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

hi all I use ices0.2.3/icecast1.3.12 on a linux box. I stream mp3 . I would like to make my listeners to discover ogg . My tracks are all in mp3 format. i reencode from 128/96 kbs and 44100Hz => 16kbs and 11kHz ( mp3 ) Is it possible , ( if yes tell me how ) to feed icecast with both mp3 and ogg stream , at different mount points . how to configure ices to play ogg ? i know i'll have to

On 22 Mar 2003, Karl Heyes wrote: > ethereal is a good tool for that, start a capture (maybe with a capture > filter of "port <port>" or "host <ip>" to limit it if the box has plenty > of traffic), connect the source, wait a second then stop the capture. > Pick one of the packets that relates to the source stream and do > tools->follow tcp stream.

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:

> > > current cvs version it'll work with icecast2. i am doing something wrong here ?? ( sorry if this is obvious ,) - mystifLY:/var/lib/cvs/ices# cvs -d :pserver:anonymous@cvs.icecast.org:/cvs/ice login Logging in to :pserver:anonymous@cvs.icecast.org:2401/cvs/ice CVS password: [ pressed enter , as suggested ] mystifLY:/var/lib/cvs/ices# cvs -d

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 Sat, 2005-02-26 at 22:47, Zenon Panoussis wrote: > Hmm. In some cases, the lack of mp3 support has the exact opposite > effect. To wit: I have a huge collection of mp3s which I would like > to broadcast as .ogg, but I don't want to recode them permanently. > If ices2 could read mp3 and recode it to ogg on the fly, I'd be doing > just that. Because it can't, I end up

It says here there hasn't been much interest in handling mp3 with ices2: http://www.icecast.org/files/ices_docs/faq.html I just wanted to mention that I'm interested in doing so. I use ices for a web-based jukebox project called Tunez. I have tried the other suggested icecast streamers and have had major problems with both of them (muse and liveice). It would be really cool if the

Hi all, I want to make a static database containing hundreds of thousands of very short audio files, each having not more than 100 milliseconds. These are made by splitting larger audio files into tiny pieces. I encode all the little files separately, but do not store 3 vorbis header packets, which are the same for all the files. I do not use ogg stream, only store plain vorbis packets.

The server doesn't control the rate, the source does. Provided you aren't getting corrupt stream data (and it doesn't sound like you are), you don't have a server bug in this case. At a basic level, the server level takes the data that comes in from the source, buffers it, and sends it right back out the door at the rate at which it came in. It isn't entirely clear to me

On Thu, 27 Jan 2005 11:38:06 +0200, Mohamed Eldesoky <eldesoky.lists@gmail.com> wrote: > Why you don't develop ices0.4 anymore ?? > Or even add the mp3 features to ices2 !! > Why maintain two codebases ?? Ices 0.x is still developed. So is ices2. They're independent codebases with substantially different capabilities and users. Yes, in retrospect naming it ices2 was a poor

Hello! I'm extremely new at this so don't hurt me. I want to stream CD content from my RedHat 9 box using icecast? What is the best way to do this? I'm getting confused with all the different pieces and configurations. Is there a simple guide that discusses what I want to do? thanks! __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site

On Wed 29 Jan 2003, Karl Heyes (karl@pts.tele2.co.uk) wrote: > On Wed, 2003-01-29 at 17:13, Marc Remijn wrote: > >> But when I did 'make' it broke with: >> >> encode.c: In function `encode_initialise': >> encode.c:91: storage size of `ai' isn't known >> encode.c:92: `OV_ECTL_RATEMANAGE_GET' undeclared (first use in this function)

hiya. i'm using ices 0.2.2 with icecast 1.3.10 and otto 1.0 (a web/db playlist mgmt tool). overall, i'm very pleased with the setup, but i'm having a few problems. 1) whenever otto plays a track (by exec'ing ices), that same track keeps playing over and over. i have to direct otto to kill the track (and the ices process) in order to get it to play the next track. i notice this

On 21 Mar 2003, Karl Heyes wrote: > There really isn't that much changed in ices wrt directory services, it > just invokes an added libshout API call on encode/reencode cases. Ices > could do with a tag to enable/disable it though. Check that you have > recent versions and if you still have the problem send me the http > headers that ices is sending. Well, it was current CVS

It's my understanding that the CELT layer of Opus has a maximum input sample rate of 48k, and frequencies above 20k are effectively not encoded. I've been trying to get up to speed on the specification, and studying its operation, but as far as I can infer, there is a fixed set of 21 bands distributed logarithmically to encode DC to 20k. If I were inclined to encode at say, 96k, and pass

Hi all I'm Toni from Italy and i have a problem with Icecast2 and IceS. I've get the source code from cvs and i installed them an a linux machine with 2.4.18 kernel (mandrake 8.2) with any problem. I've modified the conf files of icecast2 and IceS and I've done a playlist.txt file... i started icecast2 and IceS with no problems, (im using some .ogg with 96.00 kbps) no error comes

> I consider icecast as a testing application server. You just cant deploy it > all of a sudden becuse it needs a lot of work still and the UI needs to be > friendlier. Lets wait till the top programmers come up with a central I don't know why there's lots of problems lately. I assume some small libc implementation changed that icecast must have depended on. I ran icecast on 4

Yes, I have checked the archives :) I am running Ices 0.2.2 with icecast 1.3.10 and LAME 3.87. I have compiled Ices without any problems, it found lame.h and the libraries, my problem is that when I run ices, it doesn't re-encode the files. This is the command line I am using to play around with: ./ices -b 64 -H 64 -F playlist -h localhost -p 8000 -P letmein -r -v The log shows nothing