Point taken, but we have tried to be conservative. The releases we've done have been betas and release candidates, but most professional shops would have started at 1.0 much sooner, and release 2.0, 3.0 etc.
We had a very clear picture of the features for 1.0. When the decoder was feature complete and frozen, we called the release RC1. As far as implementors are concerned, this is a feature complete release.
There was actually a bug found in RC1 decode that was fixed in RC2 decode. Since then, no chances to decode have been made, although new API additions were added to make developers happy.
Now the encoder is much more difficult. Getting good audio is hard, and it's only with RC2 and RC3 that we're exploiting the features that we solidified in RC1.
These have all been release candidates. But you have to look at what the important part is - the decoder. The encoder is going to constantly improve for the rest of time. It's the decoder you've got to lock down.
The current plan is to release an RC4 soon that fills out the rest of the missing modes and turns on bitrate management for non 44.1kHz audio. That will be the first completely feature frozen encoder. After some bugfinding fun, that will become 1.0.
My dreamcast plays Ogg Vorbis CDs. And I believe that it still is floating point. Already one company (iObjects, which makes the OS in the HipZip) has produced an integer-only decoder. It can be done, and I'm sure we'll see them rampant before too long.
It does not use LGPL. The license file in both the libogg and libvorbis distributions, as well as the top 20 lines of every source file clearly state that it is licensed under the BSD license.
Not only that, but I have several contacts at EA and have met personally with many of the audio people there and they are all aware of this to the best of my knowledge.
One of the primary motivators for this decision was EA asking for an easier license.
Please contact me directly or give me the info to talk to your lawyer. I can easily straighten this out.
I've been playing with Webware, which is similar to the Java sevlets + JSP model, but totally in python.
You can find it at http://webware.sourceforge.net.
So far I really like it. It has more structure that PHP, which is very nice, and it's in a language that is fun and easy to program in, Python. (I like the structure of the java stuff, but java is just hte wrong language for web application stuff, I'm just too used to the faster dev cycle).
icecast can do it. if you drop files into the static_dir, you can get them from http://icecast-server.whatever.com:8000/file/some. mp3 icecast isn't built for on demand streaming, since apache does that job quite nicely. just get an m3u file, and link to the mp3 on the web server. it works quite nicely. try this for details.
Icecast is the solution for these kinds of problems. 1) It is the most support streaming server available. It supports all mp3 clients, RealPlayer G2 (PC AND Mac), and Windows Media Player. Nothing else currently does this. 2) It's free, it's open source, and it runs on basically anything. It's the only server running on Linux MIPS (Cobalt Raq's!) and it's been ported to BeOS, OS/2, and every flavor of *nix imagineable. hell.. someone even had a Novell one going for a while. 3) No expensive hardware needed. You dont' need a powerful machine. A p2 class CPU and 128MB ram will go a long way. You could encode and server on the same machine, probably to around 1000 clients simultaneously. No one's ever shown me a box that couldn't saturate the pipe it was on. Buy an 800$ Celeron box, with 128MB memory. put your favorite version of *nix on it, and have fun. Any questions? Visit Icecast
Ok, shoutcast is not ahead of the game. Icecast supports more players. We FULLY support Winamp, Sonique, Kjofol, Xmms, mpg123, and pretty much any mp3 player you have heard of. We also support RealPlayerG2, and Windows Media Player. We have the most support streaming architecture there is. Period. Yes, we aren't fully shoutcast compliant. But this is by choice. I don't want to implement something that's broken by design. They impose many limitations... no admin interface, single streams only, only reencoding (wasting cpu). Icecast is not limited in this fashion.
There's problems with this. One, you ahve to have two macs. With icecast, you can have one of basically anything you want. Two, it's way more expensive than an icecast solution. no matter which way you cut the cheese. We have people successfully running stations on 386 hardware. You don't pay any licenses. basically you're only real cost is the webcasting license to ASCAP and BMI if you are streaming commercial music. Tell your professor that he needs to do some more reasearch.
icecast WILL work live. it's all a matter of what production tool you are using. if you use shout, yes, you need playlists and preencoded mp3s. use the winamp DSP, or liveice, and it will work perfectly well with microphoen in, line in, cd + linein, playlsits + linein + cd + microphone or any other live combo you can come up with. the delays i've experience are about 2 secs on average depending on what your clients buffers are set at.
I beg to differ. I hardly ever use my windows box. Mostly i use it when I'm watching something on the linux box and find it more convient to type or web browse on the other screen.
I'm sure the processor would be great at cruncher mp3 files. Now, where's that mp3 encoder optimized for the G4? Oh.. there isn't one... well where's that superawesome mac programmer? Oh... forgot. they all moved off of apple hardware:(
actually, in all tests, NT really doens't like it when you have 1000 or so simultaneous TCP connections. It does not handle it well. On the other hand, places running BSD are getting 5000+ connections going. Icecast does run well on NT, and it will handle moderate loads, but for very large load, I wouldn't trust anything that inherently unstable.
There are a few reasons. 1) the way shoutcast does this metainfo is stupid and broken. 2) this is a very new technology, and live365 is basically the biggest deployment. it will be a while before all the kinks are out. they are doing quite a good job these days, except for a few very minor details.
1) speed is encoder specific. You can rip anything in no time with Xing. To get maximum quality with Fraunhofer's you'll need about 2x the length of the track in time. 2) Icecast will server out multiple streams from the same server, and liveice will produce multiple streams from the same live source at different bitrates.
You could easily run both streams simultaneously with liveice under linux using the Xing encoder. Xing is noticeably faster than all hte other encoder, but it doesn't have quite the quality that FhG does >64kbps. You could easily get two mp3enc's going at reasonable levels with a Dual CPU celeron.
MP3 sounds noticeably better than Real at the same or sometimes even lower bitrate. You may just be using a bad encoder as they aren't all equal quality wise. For the very best in quality use FhG. Some encoder are VERY bad at low bitrates, Xing and Bladeenc being good examples. LAME is doing pretty well now, but it's still not up to the commercial par.
Slashdot Mirror
Point taken, but we have tried to be conservative. The releases we've done have been betas and release candidates, but most professional shops would have started at 1.0 much sooner, and release 2.0, 3.0 etc.
We had a very clear picture of the features for 1.0. When the decoder was feature complete and frozen, we called the release RC1. As far as implementors are concerned, this is a feature complete release.
There was actually a bug found in RC1 decode that was fixed in RC2 decode. Since then, no chances to decode have been made, although new API additions were added to make developers happy.
Now the encoder is much more difficult. Getting good audio is hard, and it's only with RC2 and RC3 that we're exploiting the features that we solidified in RC1.
These have all been release candidates. But you have to look at what the important part is - the decoder. The encoder is going to constantly improve for the rest of time. It's the decoder you've got to lock down.
The current plan is to release an RC4 soon that fills out the rest of the missing modes and turns on bitrate management for non 44.1kHz audio. That will be the first completely feature frozen encoder. After some bugfinding fun, that will become 1.0.
We're very nearly there.
My dreamcast plays Ogg Vorbis CDs. And I believe that it still is floating point. Already one company (iObjects, which makes the OS in the HipZip) has produced an integer-only decoder. It can be done, and I'm sure we'll see them rampant before too long.
There are patents on the technology, which means it is of no more use to the open source community than True Type font hinting and MP3.
:)
I hope that they address the patent issues, and not just brush them aside like the DivX guys have done.
There's a reason the Xiph.org project is trying to develop a video codec too
It does not use LGPL. The license file in both the libogg and libvorbis distributions, as well as the top 20 lines of every source file clearly state that it is licensed under the BSD license.
Not only that, but I have several contacts at EA and have met personally with many of the audio people there and they are all aware of this to the best of my knowledge.
One of the primary motivators for this decision was EA asking for an easier license.
Please contact me directly or give me the info to talk to your lawyer. I can easily straighten this out.
I've been playing with Webware, which is similar to the Java sevlets + JSP model, but totally in python. You can find it at http://webware.sourceforge.net. So far I really like it. It has more structure that PHP, which is very nice, and it's in a language that is fun and easy to program in, Python. (I like the structure of the java stuff, but java is just hte wrong language for web application stuff, I'm just too used to the faster dev cycle).
icecast can do it. if you drop files into the static_dir, you can get them from http://icecast-server.whatever.com:8000/file/some. mp3 icecast isn't built for on demand streaming, since apache does that job quite nicely. just get an m3u file, and link to the mp3 on the web server. it works quite nicely. try this for details.
Icecast is the solution for these kinds of problems. 1) It is the most support streaming server available. It supports all mp3 clients, RealPlayer G2 (PC AND Mac), and Windows Media Player. Nothing else currently does this. 2) It's free, it's open source, and it runs on basically anything. It's the only server running on Linux MIPS (Cobalt Raq's!) and it's been ported to BeOS, OS/2, and every flavor of *nix imagineable. hell.. someone even had a Novell one going for a while. 3) No expensive hardware needed. You dont' need a powerful machine. A p2 class CPU and 128MB ram will go a long way. You could encode and server on the same machine, probably to around 1000 clients simultaneously. No one's ever shown me a box that couldn't saturate the pipe it was on. Buy an 800$ Celeron box, with 128MB memory. put your favorite version of *nix on it, and have fun. Any questions? Visit Icecast
Ok, shoutcast is not ahead of the game. Icecast supports more players. We FULLY support Winamp, Sonique, Kjofol, Xmms, mpg123, and pretty much any mp3 player you have heard of. We also support RealPlayerG2, and Windows Media Player. We have the most support streaming architecture there is. Period. Yes, we aren't fully shoutcast compliant. But this is by choice. I don't want to implement something that's broken by design. They impose many limitations... no admin interface, single streams only, only reencoding (wasting cpu). Icecast is not limited in this fashion.
There's problems with this. One, you ahve to have two macs. With icecast, you can have one of basically anything you want. Two, it's way more expensive than an icecast solution. no matter which way you cut the cheese. We have people successfully running stations on 386 hardware. You don't pay any licenses. basically you're only real cost is the webcasting license to ASCAP and BMI if you are streaming commercial music. Tell your professor that he needs to do some more reasearch.
icecast WILL work live. it's all a matter of what production tool you are using. if you use shout, yes, you need playlists and preencoded mp3s. use the winamp DSP, or liveice, and it will work perfectly well with microphoen in, line in, cd + linein, playlsits + linein + cd + microphone or any other live combo you can come up with. the delays i've experience are about 2 secs on average depending on what your clients buffers are set at.
I don't see how lots of diskspace addresses the issue of this most likely coming from a live source :)
I beg to differ. I hardly ever use my windows box. Mostly i use it when I'm watching something on the linux box and find it more convient to type or web browse on the other screen.
I'm sure the processor would be great at cruncher mp3 files. Now, where's that mp3 encoder optimized for the G4? Oh.. there isn't one... well where's that superawesome mac programmer? Oh... forgot. they all moved off of apple hardware :(
actually, in all tests, NT really doens't like it when you have 1000 or so simultaneous TCP connections. It does not handle it well. On the other hand, places running BSD are getting 5000+ connections going. Icecast does run well on NT, and it will handle moderate loads, but for very large load, I wouldn't trust anything that inherently unstable.
There are a few reasons. 1) the way shoutcast does this metainfo is stupid and broken. 2) this is a very new technology, and live365 is basically the biggest deployment. it will be a while before all the kinks are out. they are doing quite a good job these days, except for a few very minor details.
1) speed is encoder specific. You can rip anything in no time with Xing. To get maximum quality with Fraunhofer's you'll need about 2x the length of the track in time. 2) Icecast will server out multiple streams from the same server, and liveice will produce multiple streams from the same live source at different bitrates.
You could easily run both streams simultaneously with liveice under linux using the Xing encoder. Xing is noticeably faster than all hte other encoder, but it doesn't have quite the quality that FhG does >64kbps. You could easily get two mp3enc's going at reasonable levels with a Dual CPU celeron.
MP3 sounds noticeably better than Real at the same or sometimes even lower bitrate. You may just be using a bad encoder as they aren't all equal quality wise. For the very best in quality use FhG. Some encoder are VERY bad at low bitrates, Xing and Bladeenc being good examples. LAME is doing pretty well now, but it's still not up to the commercial par.