ICY Protocol

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 passwordrn
3. If the password is correct, the server will reply with OK2rnicy-caps:11rnrn, 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 passwordrn.
4. If the source recieves the OK2, it then begins sending information about the stream to the server. Usually in this form:

icy-name:Unnamed Serverrn
icy-genre:Unknown Genrern

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:
content-type: mime/typern
icy-reset: 1rn
icy-prebuffer: ??rn

* 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


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:


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

ICY 200 OKrn (signifying that the server was successful)

icy-notice1:<br />This stream requires Winamp<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 Serverrn (Name of the server)

icy-genre:Unknown Genrern (what genre the server falls under)

icy-url:http://www.shoutcast.comrn (homepage for the server)

Content-Type:audio/mpegrn (Content type of the stream to follow)

icy-pub:1rn (whether the server is public or not)

icy-br:56rn (bitrate of the server)

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

rn (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

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 “” 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 &amp; 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

Check out this website I found at un4seen.com