Mixed MP3/Ogg Streaming 19
This is the problem, when a client, like XMMS, connects it negotiates the stream type. After this it just assumes all data after this point is of the same type. At no point can it switch content types. You can use something like a play list which lists multiple connections to simulate playing different formats in a row, the thing is this requires a reconnection to the server each time.
You can blame the two dominant protocols, SHOUT and ICY. One was created for the Shoutcast server and the other was created by the Icecast folks. Neither of them really considered the issue of carrying any other payload then MP3, or more to the point, changing content type in midstream.
At some point it would be great if Vorbis/Ogg became dominant because of the silly copyright restriction with MP3 that make the use of the lame encoder pretty questionable. It still has a way to go though since the code for bit peeling has yet to be finished and until that is completed, to down bitgrade an Ogg stream you have to decode it to some format like PCM and then reencode to Ogg (which is certainly not optimial for real time demands).
mixed payload (Score:3, Interesting)
For instance, id3v2 has lyric tags that can be synchronized to the music. However, the reason you cannot have a player with the feature to sing-along to the bouncing ball is because the shoutcast, and icecast protocols don't support title streaming. They are also designed for one media type at a time... mp3 or ogg. Both were originally designed for just mp3 streaming.
The two methods both seem like hacks...
I'd like to see a new system that is based on xml for the meta data.. like the title-streaming. Maybe a multi channel system one being for the data stream, another for the Meta data.
Honestly the hard part isn't getting a new standard for streaming... its getting the people who make the decoders that have the issues. They would have to understand the protocals, and since these are the same people that came up with the two compeiting formats we have now... its pointless batle.
Re:mixed payload - and a shameless plug (Score:1)
There is a reason for this plug, this post has got a point
We'll see.
Re:mixed payload - and a shameless plug (Score:2)
Edna can do this. (Score:1)
Edna [sourceforge.net] sounds like it could do what you want.
Basically its a smallish python program that acts as a, tiny, webserver - generating lists of all your songs, and streaming them to your clients browser - where you have XMMS, or Freeamp [freeamp.org] setup to play the stream.
I suppose if the music is already on the same machine as your webserver then it may be a bit redundant to have a second server - but Edna is neat, (this is the one program that made me start hacking Python...).
Re:Edna can do this. (Score:2)
Re:Edna can do this. (Score:1)
Enda creates playlists, and a nice interface to them, so it doesn't directly support Ogg files.
.Still, if you edit the source code for the program, you can add a line to include them in your playlists - afterall its XMMS which plays them.
Patch below:
+ '.ogg' : 'audio/ogg',If you need any help with this then mail me..
Perhaps... (Score:1)
then recode them as
It would work, its not doing what you want,
but it would work.
Re:Perhaps... (Score:2)
Re: (Score:2)
An Update (Score:3, Informative)
Re:An Update (Score:2)
Re:An Update (Score:2)
Please correct me if I am wrong, but Mod_mp3 is actually sending the files to client. So if I create a playlist.m3u and specify MP3playlist playlist.m3u in the mp3.conf file when Mod_MP3 starts up it reads the file into memory, and then waits for a client connection. When the client connects Mod_MP3 says ok here comes the first file and starts sending it. It assumes the client as asking for files in
Winamp or similar is doing basically the opposite it reads the playlist of files its told to play and then can stream them back out to a recieveing source such as shoutcast which can then send them back out to the world. Winamp is reading the files in and playing them back, but at the same time through the streaming component sends the output as input in only one format to shoutcast to be sent back out agian. When I started I had hoped that I could eliminate the middle man by providing the playlist(which could be updated the same way one can add to the winamp playlist while its running) as a file to Mod_mp3 it would then "shout" them back out much the same as shoutcast/icecast do. Infact this is what it even appears to do until more than one format is put in the playlist. Its missing the internal conversion that is accomplished by what I did last night passing the files through winamp and then to shoutcast. This is still not ideal however, since it does support multipule file formats, but I can't easily code a web front end to add files to that winamp playlist.
Honestly I am only a web coder and know very little of C/C++ on the level that it takes to code such programs as winamp/mod_mp3 my job path took me away from that area over years so my skill in that area is very erroded, especially since I have not kept up over the years. So I really have been looking for a widget that fit into the back end side of what I am doing, and hoping to find the one size fits all soution which might not exist or for that matter even be possible.
For the Record if anyone is interested I can state the design goal(and I am thinking it might even be a good shake off the rust project were I to try to code it).
A program that can read a playlist which can be added to while the program is running. Ideally can be run from a command line, doesn't really need a GUI because its data is all those mp3s/oggs/or other format that might come along, and the playlist file which is intended to be added to/deleted from via another process such as a PHP/PERL/ASP/CGI script from a web site. It should do at least one of three things.
1. "shout" the files out onto a network port that a client connects to like a shoutcast/icecast server does.
2. Decode and then send the files to shoutcast/idecast like Winamp does, so the "ICY/Shout" protocol takes care of the rest.
3. Offer the files up like Mod_Mp3 does, but send them in such a way that the end client isn't concerned with the file type.
A note that there are programs that are avaiible, Idecast,IceS and Mod_mp3, that are almost capable of doing these things but each is missing one little piece of the equation.
Icecast/Shoutcast, currently has no support for Ogg, and in the current versions I can't see anyway of feeding it a changing playlist while it is running.
IceS, Currently no support for Oggs, but I am sure thats coming. Also I still see no way of sending it playlist changes while its running.
Mod_Mp3 really seems the best of the Crop for bing close to what is needed, in that it does support both formats, but can't handle a mixed playlist. It also seems to lack the facility for changing the playlist while its running.
Anyway a long brain dump for anyone interested.
Re:An Update (Score:3, Interesting)
Solution is to add a directive saying "mixed is ok", setting the default op to "send playlist" and then add code to load.c to tell the difference between ogg and mp3.
Once the "this is this type of file is written" the rest is trivial.
Re:An Update (Score:1)
Besides, I think mod_mp3 can do what they want.... mod_mp3 can act as a mp3/ogg repository.... and this is one way to use it. For example... store all our music on a mod_mp3 server, then load the mod_mp3 playlist (op=m3u2) into winamp, or xmms. Winamp can then simply act as a relay, and mod_mp3 can act as the source. THe question is if shoutcast, or icecast can then take the winamp input, and manage the change in formates from ogg to mp3, and back-and-forth. I don't think shoutcast can handle that situation... at least it couldn't a few versions ago (prior to the advent of mod_mp3)
Basically put, shoutcast make a few assumptions about the input stream based on what the input type was of the first item it streams... if that was an mp3... the rest of the stream will be handled like a mp3....
also... winamp is weird... if you notice... it has to first sample the input stream to check if it is ogg first, and then it check to see if the input is mp3. I found this info out after some serrious debug time with winamp... so.. if you want to have ogg stream... it had better be the first item that winamp gets.
Re:An Update (Score:2)
Re:An Update (Score:2)
Re:An Update (Score:3, Informative)
I have to say conversion sounds like more sense. (Score:2)