search for: tposton1

--- Todd Poston <tposton1@swbell.net> wrote: > > > If you want to click > > > on a link in a web browser, you will need to > make a > > > PLS or M3U file with > > > the location data in it so that this is > downloaded > > > and opened by your > > > player. >...

> > If you want to click > > on a link in a web browser, you will need to make a > > PLS or M3U file with > > the location data in it so that this is downloaded > > and opened by your > > player. > Great - now we're getting somewhere. I can't find any > information about these file types on Icecast or > shoutcast's web sites. > >

* Andrew M. Wu <andrewwu@Princeton.EDU> [010419 03:49]: > Hi all, > > I've been trying to compile and re-compile ices-0.0.1beta5 with lame > support. > > I've downloaded the source to lame-3.88beta and compiled it and installed > it. The configure script allows for the compilation of a libmp3lame.a > and libmp3lame.la, but not libmp3lame.so (in the INSTALL

> -----Original Message----- > From: owner-icecast@xiph.org [mailto:owner-icecast@xiph.org] > On Behalf Of Eric L. Brown > My goal is to be able to take my collection of CDs (now in 256k mp3 > bitstream) and distribute through the house over the wireless > network (har-line network for other stuff). Just trying to > play with some of the existing technologies before

Good Luck. As mentioned before, this would be cool but not as simple, even in theory, as it sounds. You might be interested in this thread: http://www.xiph.org/archives/icecast/4849.html http://www.xiph.org/archives/icecast/4853.html Let us know when its done! ;) heh > -----Original Message----- > From: owner-icecast@xiph.org [mailto:owner-icecast@xiph.org] > On Behalf Of Mr I >

Just a follow up to this, Geoff... True, that is how you'd do it when you know what *n* number of streams/files you wished to serve at the time the client d/l's the playlist. There are cases when you may wish to dynamically change what the client hears (live radio for instance, or maintenance, etc.) without requiring the client to manually reconnect. Redirects would/could be handy _IF_

-----Original Message----- From: owner-icecast@xiph.org [mailto:owner-icecast@xiph.org] On Behalf Of Michael Smith >> >> This seems like a very useful thing to be included in a spec. And it >> doesn't seem unreasonable to include it in a client, except that there >> is no official spec that stream client developers use to develop >> against (or is there??).

This goes back a couple of months in the list.. But below refers to the idea of forwarding streams. *Is* there currently any way (with mp3 or ogg) to force the client to a new stream?? Is the "forward directive" referred to below in use by anything, if so what? And how is it implemented? This seems like a very useful thing to be included in a spec. And it doesn't seem

if you point most clients to an mp3 file the entire file must be downloaded before it can start playing. The .m3u and .pls files tell an mp3 client to start downloading and buffer the mp3 so that it can play it while it is downloading. The biggest issue with streaming this way is that if the file is encoded at a bitrate that is higher than can be downloaded by (or served to) the client due to

> > For pls files: > > http://www.shoutclub.com/help/linking.php3 > Thanks. It says that I can use the URL by appanding > listen.pls as in > http://194.109.227.136:8000/listen.pls > > In this case it still wanted to drag down some > multibegabyte files. What happened? you read: Well the simplest method is using your SHOUTcast servers built in Web server, this feature