Radio,

Whats up?  Has the encoder example changed at all?  Sorry I have been gone for a while, busy dealing with my mother, and now my own medical issues came back. ;'(

Hit me back via email.

Crazy KayCee!

Thanks once again for making this possible, Radio42, Ian, I am indebted to you, especially since you intend to add icecast 2 stuff also.  Here is the thing, I just found out today...  My mom will not make a speedy recovery, the doctor said they can't kill the cancer, not even with chemo, as it is in her neck, bones, and lungs.  Radio42, I appreciate you giving me something to work on once again, because right now, I really really need something to take my mind off of this.  My mom, won't even tell me, my little brother had to tell me, as she don't even want to fight, which is a major problem, and looked at my brother and asked him if he was ready to see her die.  She made him swear not to tell me, which he had to anyways, he snuck and told me via IM.  I can't call her to tell her, or make her an appointment in the sarah canon cancer center because I'm not supposed to know.

I just wanted you guys to know how important this application was to me, and how much I appreciate all of your work, to help me do something good, to help out, with expenses etc..

Thank you very much.

Ken aka Crazy KayCee!

Kick Ass, we have finally done it Radio42!!!!  I could not have done all this without your help.  BTW, you also have a complete copy of Bionic Stream Caster - Broadcast edition coming, which includes lots of goodies, that the other broadcast applications out there do not include - such as an integrated intelligent soundboard, for on the fly promos, bits, prank calls, etc.. and it also includes, intelligent playlist handling, including certain defaults, which when combined with my alarm clock feature will allow anyone / dj to setup their shows ahead of time, throw the schedule time in there, and pull off a perfect flawless show, complete with recording for further playback as desired.  Here is the thing, I am building in certain AI features which will allow you to do things like say, start show 9:00am, Play ADS and it will pick either a specific ads playlist you specify, or will based on an intelligent weighted selection method, play the randomly selected ad carts, then the same type thing can also be accomplished with the show itself, including pieces, or playlists, etc.. and it is smart enough to know how often a piece has been played, and automatically move onto another piece.  Whats more, adding new material, is a simple matter of creating a folder in your main Bionic folder, put your material there, and each time Bionic Stream Caster is started, or if you hit the doublecheck button, it will automatically update its records in the database.

I have thought long and hard about this application, and have tried virtually everything that is out there, and they are all lacking in one way or another, and because of this, is the reason I started work on Bionic Stream Caster.  Thanks to Radio42, it is now a reality.  I already have much if not all of the other code done, it is simply a matter of porting some of the code from VB to C# Dot Net.

All work from this point forward is being done with Visual Studio 2005, so if anyone is interested in being on a team to change the face of internet radio forever, please email me at: comedy@pkradio.net.

My hats are off to Ian and Radio42, I love you guys.  Thank you so much from the bottom of my heart.

Radio42, this couldn't have come at a better time man, I just spent some time with my mother today, whom has been diagnosed with cancer for a 3rd time, this time in her lungs, and she is not looking good, her arm and leg is swollen from the previous surgeries where they removed her lymph nodes, and the fluid, is causing adema and severe swelling in her leg and arm, as such on Tuesday, her doctor appointment with the cancer doctor, will most likely end, in her being put in the hospital.  She really had an affect on me.  Lots of crying and asking god why.  So this came at the right time, it gives me hope, as I have also been looking for a sign that I would ever be able to finish this application, so now, I have hope, and some coding ahead of me, to keep my mind off other really bad feelings and things.

Thanks again,
Ian for making such an awesome library, and Radio42 for making the Dot Net version, and helping a friend out in his moment of need.  Truely, thank you, please make me an mp3 add or banner ad for either Bass and/or your radio station Radio42, and I will whole heartedly advertise you, and your station, and of course bass for such an awesome product.  I love you guys, God Bless, and all of us programmers out there, trying to break the mold.

radio42 any progress yet?  Just wondering.  Let me know how you make out.

KayCee!

also, you can email me at: comedy@pkradio.net

I think he also wants to stream the video and audio.  Which is something I am also interested in, as an added feature for my broadcast application.

I have the sourcecode to a delphi application that does this, if you give me some time, I will try to port it to either C++ Builder or C# or VB, which one do you want some sourcecode in?

Just thought I would mention it.  I think the name is VideoLan, it has both the client and server.

Hope this helps,

KayCee aka Ken

Thats okay though, we are still looking for team members, and I like your coding style, so I believe you would make a good addition to the team.  If you are interested, please email me, and I will give you the location for the project specs, and progress reports page on my home website of PKRadio.Net.  Basically, I am opening a new forum thread just for the broadcast project.  Another one for the games I am working on.

Thanks to everyone for all the help!

Crazy KayCee!

I don't have problem with ICY Protocol, I am the one who wrote the document on the Real ICY Protocol.  I was posting it to help the others out.  My issue is encoding a wav device such as mixer, mic whatever to either an mp3 or ogg formatted buffer, that I can stream to the winsock control.  On the contrary, my application makes the connection to shoutcast or icecast quite nicely, and I get the OK200 just fine, and am able to stream already encoded files to the server.

I think you have misunderstood.

We are working on the encoding portion of a shoutcast / icecast source/broadcast application.

Thanks for trying to help though, I will have a look, just to make sure it matches up with what I have.  I wrote, dug this information about ICY Protocol a long, long time ago.  If you dig on Planet sourcecode you will find, my document as the only one, do a search on there for ICY and see what pops up, or ICY shoutcast either should work.

Thanks again, we can use another member on the team, if you can help with this portion of the equation though.

KayCee! aka Ken

ok, first of all, I get errors about binding etc.. when I try to load the project.  2nd of all this appears to be a stream recording application.  We are working on a stream broadcasting application.  This might help as far as all the ICY protocol stuff, which I believe we already had.

check this out, now that we have several people interested in this, why don't we join forces and see if we can make this work.  If you are interested, please email me at: comedy@pkradio.net

I think if we all join forces, and work on different parts, we can knock out the bugs, and get it up and running much faster, and will benefit all of us.

Thanks,

KayCee!

Right, okay check this out, here is how the shoutcast server and the source know what rate to accept data at..

Basically when you setup the protocol ICY stuff, you tell it what rate the mp3 data is encoded at ex. 24Kbps Mono 22050 Khz. which for example is about 2.9Kps, so what I was told, is if you setup a simple double buffer, one for encoded data, and one to encode from, (*NOTE*) this was before I found bass that encodes on the fly itself, prolly no need for the un-encoded buffer now, but still the same, you make like a 4K Buffer, or 8K depending on whatever you are encoding at, so that you always have a little more in the buffer than what you are sending, but not so much as to overwhelm your system, and slow it to a crawl, since the server will not receive it fast enough and eventually you will load up your memory, although it will continue to work.  I know for a fact, from my m3u example version, I used no buffering at all, except to create a single buffer the size of the mp3 file itself, each one that was loaded one after the other, and sent it all straight out the winsock to the shoutcast server, and it worked great!

Hope this helps clear the fog a little more.

I think we can setup some sort of a buffer and just monitor it to make sure it doesn't get to loaded down, if so, then delay pushing anymore into it, until it clears itself out.  I think this is why applications like SAM have a 30 Second delay in the broadcast, because when you have more than one server connection, ex. I have a 24K Mono, and a 64K MP3 Pro at stereo, and still only get like a 30 second delay, so it is managing the buffer pretty good.  I think if you buffer @ like 15-20 seconds of audio, then start sending, I think if the broadcaster or source is using broadband to broadcast it should not be an issue.  You have to have broadband anyways, as there is strict rules to how fast of a bitrate to setup vs. your internet connection speed, to deal with this issue, that shoutcast mentions.  Also, the server itself, is / or should be on a T1 or something similar and will handle the playing at the correct bitrate on its end, once the ICY bits are setup and the handshake is good to go.

So I say just make 2 - 4K Buffers, one you are filling up from the encoding callback, and one you are sending from to the winsock control, then you swap them.

I hope this is helping.

PS. I can't wait to look at his sample, this is going to rock with 3 of us working on it!

KayCee!

comedy@pkradio.net

comedy@pkradio.net or you can hit me up via msn at: storm3@twlakes.net

Please see my other post, my friend, for all of the description that I have for the ICY Protocol.  It is very simple as you will see.  I will also post my handshake code here very soon as well.  I am not sure you understand about the give and take.  Shoutcast, once the handshake is made, and you receive the OK200 response, it will expect next Mp3 or OGG encoded data, hopefully with the header that describes what is coming next.  Then you merely continue to feed it mp3 data, in a continuous stream, from time to time if anything is changed in the initial values like Station name etc.. you would have to make a disconnect and reconnect, the only other data that would get sent during the transmission of the data, would be if it had scripts embeded in the stream, which if so, all it does is send a string with the current song title, and is not supported by all clients, so I would ignore doing the in stream scripts.

So, your first two lines in the MyShoutcast(...) are not really needed, as shoutcast doesn't tell you how many samples it wants.

but you are on the right track with the rest of your functions.

Thank you so much for helping, there are alot of other people out there, that simply turn a blind eye, and it has become something of a secret like it was when cavedog first brought out total annihilation, and people claimed they had written unit editors, but would not tell anyone how they did it.  Which in turn pissed me off to the point, I stayed up for 48 Hours straight and reverse engineered the 3do file format, and made THE FIRST DXF -> 3DO Convertor.  Then Kinboat joined in with me, and we made a kickass unit editor, that pissed off cavedog, they actually emailed us asking us to stop.  Which we ignored of course, because they told us, that our editor turned out better than their inhouse one.

Why did I tell you this story?

To give you a nudge to keep after it, I think you are on the right track for something awesome for all of us, and if you want my help on anything, just email me, or msg me, or post a reply here.

Thanks Radio42, Like the other guy said, you are a life saver!

Crazy KayCee! aka Ken aka StOrM3

The Real ICY Protocol Information for all to use here.

The dialog goes something like this (I will use SHOUTcast as the example)

1. The source makes a connection to the service port (shoutcast's is the port +1)
2. The source then sends the password like so password\r\n
3. If the password is correct, the server will reply with OK2\r\nicy-caps:11\r\n\r\n, this basically informs the source that the server has authorized the dsp to be the source and it is ready for data. If the password is incorrect, the server sends invalid password\r\n.
4. If the source recieves the OK2, it then begins sending information about the stream to the server. Usually in this form:

Code:
icy-name:Unnamed Server\r\n
icy-genre:Unknown Genre\r\n
icy-pub:1\r\n
icy-br:56\r\n
icy-url:http://www.shoutcast.com\r\n
icy-irc:%23shoutcast\r\n
icy-icq:0\r\n
icy-aim:N%2FA\r\n
\r\n


Then The source will begin sending the mp3 encoded stream
* icy-name is the name of the stations
* icy-genre is the genre that the station resides in
* icy-pub is basically a switch to either allow the server to publish itself in the directory or not (1 meaning yes and 0 meaning no)
* icy-br is the bitrate of the stream
* icy-url is the homepage for the stream
* icy-irc is yp shoutcast specific (used for contact information)
* icy-icq is yp shoutcast specific (used for contact information)
* icy-aim is yp shoutcast specific (used for contact information)

You can also pass this optional data:
Code:
content-type: mime/type\r\n
icy-reset: 1\r\n
icy-prebuffer: ??\r\n


* content-type is the data type to expect from this stream. (HTTP spec header)
* icy-reset tells the server whether it should clear out the buffer. (neccessary for NSV/NSA streams.
* icy-prebuffer, we aren't quite certain what this is for, how to use it or even whether it works, but it exists.

The optional params are not neccessarily passed to the client, content-type is of course but as for the others it is not clear.

This is just a simple walk through of how the source communicates with the server. No other information is passed on this port as far as I am aware.

Title streaming from source to server
This is a simple one, the server recieves the title of the song and the URL of the page simply by having the source make the URL call

Code:
http://www.host.com:portnumber/admin.cgi?pass=Server%20Password&mode=updinfo&song=Song%20Goes%20here&url=http://someurl.com


When this gets called by the source or a browser even, the title of the song changes in the clients which support shoutcast style title streaming. This communication always happens on the public port (defaultly 8000) never on the service port as it is used for strictly sending the stream to the server.

You also must make sure that when you make your HTTP calls that it comes from a browser or program that specifies the User-Agent: header as Mozilla.

Client to Server
The Client to Server communication is handle in a similar fashion to the way that a browser communicates with a webpage server. This is known as the HTTP protocal. However SHOUTcast and icecast do not handle in exactly the same manner, the headers are different. I have yet to pin point exactly what is so different. I think it may have something to do with the notification error, as it is HTTP/1.0 200 OK on all webservers using HTTP, this may confuse some clients and causes the headers to not exist.
1. The client connects to the server and sends information about itself, if it can handle title streaming it sends and extra field like so:

Code:
icy-metadata:1\r\n


In addition to the normal headers sent. This tag signifies that the client has the ability to stream the title streaming tags from the stream, therefore the server will send the extra title information, if this were not possible, some clients would hiccup when the title information is sent
2. The server then responds with

Code:
ICY 200 OK\r\n (signifying that the server was successful)

icy-notice1:<BR>This stream requires <a href="http://www.winamp.com/">Winamp</a><BR> (redundant notice)

icy-notice2:SHOUTcast Distributed Network Audio Server/posix v1.x.x<BR> (tells the client what server it is and version)SHOUTcast Specific

icy-name:Unnamed Server\r\n (Name of the server)

icy-genre:Unknown Genre\r\n (what genre the server falls under)

icy-url:http://www.shoutcast.com\r\n (homepage for the server)

Content-Type:audio/mpeg\r\n (Content type of the stream to follow)

icy-pub:1\r\n (whether the server is public or not)

icy-br:56\r\n (bitrate of the server)

icy-metaint:8192\r\n (if icy-metadata:1 was signified this was shown I will discuss this further later)

\r\n (end of header)


3. At this point the server begins sending the audio data.

SHOUTcast Meta Title Streaming
Earlier we discussed how the server gets the title of the song from the source, but we didn't quite get into how the client gets the title of the song.

When the client signifies that it is title streaming compatible, the shoutcast server adds an extra header tag set like so
Code:
icy-metaint:8192\r\n

this tells the client exactly how many bytes of data to read out of the stream before it can expect the beginning of the Meta-Data (which is where the title is stored) It also always starts counting at the beginning of the stream (not the header)
After this the client then reads 1 byte, this byte tells the client how large the Meta-Data Tag is divided by 16, so if the byte was 4 then the client would know that the meta-data tag was 64 bytes long. But, you ask, not all titles are going to equal 64 byets or 48 bytes etc...? Well the simple answer is that SHOUTcast places blanks or "\0" in the unused space untile it equals the length, after that is read, then it is back to the mpeg data to start the process all over again.

Pretty simple huh?

In Closing
I am sure that this technology will change, and I will try my best to keep this article up to the specs as I know them. If you find anything incorrect in this article, or any oversights, then please email me

Feel free to leave a comment if you feel that I have missed something. Do not reply with questions. Questions should go in the Audio Streaming forum. Questions will be split from this thread and moved to appropriate forums.

I think that the icy-backup: will specify an DNAS id or IP that is used to help create clusters -- so when this is sent to a DNAS it will \"know\" that backups exist to it can redirect when full.

The Last Part is something I found missing, as to how other stations managed to make a cluster.

Cheers Buddy, Thanks soo much Radio, I hope this helps you as well.

Thank you for at least steering me in the right direction, I noticed a few bugs in the pseudo code, like the N & M mixed around, and one call ahead of another, but it still guided me in the right direction I believe.

I will keep you posted.

Thank you ever so much!

Crazy KayCee! aka Ken

I understand that Shoutcast has their own format, which I have completely figured out.  I have all my icy protocol stuff working fine.  What I can not get to work, is encoding any wav device to mp3 or ogg format, to a buffer that I can then send to the server once the handshake is complete and I get the OK200 response after initializing all the entries.

Using the Winamp DSP is not an option, as this is what we are trying to get away from.  Also, using ODDCast is not an option, as we can not include someone elses DSP Plugin into an application we want to do.

Did I mention I have it working fine with already encoded mp3 files, like if I have my application load an m3u playlist, it will load each one in success and stream it just fine using my protocol information.  I actually wrote the article that was listed at #1 on google for along time, about the Real Shoutcast ICY Protocol, also available on Planet Sourcecode.

I am just having a hard time getting bass to encode to a buffer, or to be able to setup a callback function, which will fire off the encoded mp3 or ogg data to the winsock control as needed, once the connection has already been established, and say I click the record button in my app, which should work, but doesn't for some reason.

;'(

I have been working on this for quite a while now, and am beginning to wonder if anyone else on here has done this or not.

What is the point of encoding the data to a buffer if you can't use it to send via a winsock control.

Thanks for any and all help you can provide.

KayCee

I understand that Shoutcast has their own format, which I have completely figured out.  I have all my icy protocol stuff working fine.  What I can not get to work, is encoding any wav device to mp3 or ogg format, to a buffer that I can then send to the server once the handshake is complete and I get the OK200 response after initializing all the entries.

Using the Winamp DSP is not an option, as this is what we are trying to get away from.  Also, using ODDCast is not an option, as we can not include someone elses DSP Plugin into an application we want to do.

Did I mention I have it working fine with already encoded mp3 files, like if I have my application load an m3u playlist, it will load each one in success and stream it just fine using my protocol information.  I actually wrote the article that was listed at #1 on google for along time, about the Real Shoutcast ICY Protocol, also available on Planet Sourcecode.

I am just having a hard time getting bass to encode to a buffer, or to be able to setup a callback function, which will fire off the encoded mp3 or ogg data to the winsock control as needed, once the connection has already been established, and say I click the record button in my app, which should work, but doesn't for some reason.

;'(

I have been working on this for quite a while now, and am beginning to wonder if anyone else on here has done this or not.

What is the point of encoding the data to a buffer if you can't use it to send via a winsock control.

Thanks for any and all help you can provide.

KayCee

Hello Ian, Radio42:

Long time no see.  Question, Radio42 was telling me that this question / issue was solved in the forums, because alot of people were requesting this, and I have searched the forums extensively and have found alot of questions about it, but none with examples demonstrating it.

Thanks,

Ken aka KayCee

Nei:

Do you have this example showing how to stream live data, like what is input via a mic or mixer device ?

Thanks,

KayCee

Shoutcast or Icecast Radio42!  Long time no see, sorry, I have been out of it here lately pushing hard to get this radio station pumping.  Now I have some freetime, and some new sourcecode to work from, which currently works with icecast and x-http servers.  The issue is the sourcecode is still in C++, and I prefer to work in Visual basic, or VB.Net if at all possible.

Now, I took your instructions about making sure no visual updates were done while encoding, and now it appears to encode, and I am not getting the runtime error anymore!  But!!!  I am not getting the mp3 encoded data streamed out to the server properly, or something, I attempt to listen and I hear nothing, and it disconnects from the server, because when the server does not get any data for a period of time, it drops the connection.

If you, and some of the forum frequent flyers can help me solve just a simple example showing how to encode whatever is playing on the soundcard mixer or wav device -> to -> either oggenc or lame.exe and then I want this encoded data deposited into a buffer of some sort, so I can merely take the data on a timer based operation and stream the data, after sending all my icy commands to initiate and get the OK200 response from the server.

Please email me, or msg me back!  My email is: comedy@pkradio.net

Thanks in advance, and I have a request for the new 2.3 version of bass and bassenc, make it easier to use with visual basic, meaning, more compatible with a custom type, and make it easier to stream what is encoded just like WMA.  Also, I 2nd the request for being able to transcode one encoding to multiple bitrates and being able to stream to multiple servers, I suggest at least 3, this is the perfect number, anyone streaming to more than 3 servers, needs to really be building their own custom setup anyway or be using more than one copy of an application or more than one client or source computer.

Please hit me back, I am eager to finish this project as soon as possible.  Thanks.

Crazy KayCee!

on the fly, using stdin and stdout ?  So I can then send the buffered mp3 data to a server ?

Hello,

I have been all through the examples for the Dot Net Framework and it is lacking an example showing how to use bass encode from them, to encode to mp3 what is playing on the soundcard device for example...

This is puzzling as I was under the impression from radio42 that the dot net versions had all the examples I would need, or the same examples that the non-dotnet framework version for bass-encoder has.

Any assistance in this matter would be greatly appreciated, since I read another post from another user that was getting a crash on a continuous loop from inside vb 6, so looks like the only way to do this is to use dot net, but there are no examples.

Radio can you hook it up, how about those that I provided the links to?

Thanks,

KayCee

Where are all the samples you told me about, specifically the encoder examples for dot net.  I have checked both archives and neither of the solutions contain an encoder example, showing how to record from the soundcard and encode to an mp3 buffer.

Your assistance on this matter would be greatly appreciated.

Ken