Oh wow, original author here. Never thought this would ever be picked up by HN after 12 years... :) I lost the credentials for this account, so no fixes for this script. I hope it will inspire people to reverse engineer MP3, it was very interesting for back in the days.

I found some poorly documentation on the winamp website. And basically it comes down to this: - you recode the MP3 to the lower bitrate - get rid of all headers - concatenate all audio into one big stream - inject every x bytes a "StreamTitle=[title]" regardless of frames

Very simple format.

I really love the fact that there's no framework, no composer, no autoloading, just plain PHP. That's how you get the job done!

Well, part of that is it predates Composer by a few years (and especially popular adoption of Composer). PEAR never really had the adoption that Composer did. The popularity of frameworks didn't soar until Composer was adopted by the community, either. And the overall application is actually fairly simple, assuming that getid3 folder is a third party library as it appears to be.

That said, I'm not discounting anything done here. I've had to do deep dives on streaming video before. Even built my own h264 streaming protocol prior to HLS and DASH being introduced more than a decade ago now. Figuring out the format, finding obscure documentation on the file headers, figuring out how request and send it in pieces, hell just finding documentation that long ago... it's not easy. And at least when I did it, I was working on PHP 5.4 which had namespaces. This was likely built on 5.2 if I had a guess, which lacked that luxury

You need to recode your audio files with ffmpeg for example to the desired bitrate you want to stream.

Thanks for the reply, I thought it was changing the bitrate on the fly.

Yeah, this is fun. I remember back in 2007 setting up a dinky audio stream for a 3 day jam session. Using php on Dreamhost, which had practically unlimited bandwidth back then. Worked great. The alternatives were either expensive livestream services or required a colocated box.

PHP is now run mainly as fcgi server. For streaming data that needs some fix on the server side so that the http server doesn't try to fetch the complete page before sending that data to client. And I am not sure how to achieve that.

This wasn't a problem 12 years back as then Apache's mod_php had been the default way to serve pages. Your http server was the PHP interpreter.

You need to disable fcgi buffering in whatever http server you're using. For exemple in nginx, the option name is "fastcgi_buffering". Then flush() and the likes will work again.

Note that if enabled you need to disable gzip compression too since that has its own buffering.

Buffering can still be accomplished php side when needed with ob_ functions.

with buffering disabled presumably this would disable seeking / dropping in at a random timestamp?

There is no seeking in a shoutcast stream, it works like a web radio.

understood, thanks

I already ran into apache issues back then, that's why there is a line in the script to stop apache to do chucking or buffering for example:

header("Content-Length: ".$settings["max_listen_time"] * $settings["bitrate"] * 128); //suppreses chuncked transfer-encoding

There is the sendfile header, but IIRC that’s not how shoutcast works.

There are newer standards that do actually use individual requests for each segment, this is how you do it with web video.

mod_php is still the most popular and fastest way.

Comes with sample music in the repo :)

A long time ago I tried streaming video using PHP because we need to track users progress on the video, it was very hard on the hardware.

I've been wanting to run a shoutcast server on my android (AOSP) for too long. Anyone knows if this runs fine under termux?