Ah, Shoutcast. It will always hold a special place in my heart [0], if only because it reminds me of a more care-free time in my life.

But in addition to the complexities of licensing if you want your stream to be legal, it seems to me that there's at least one flaw in the design. To receive an uninterrupted Shoutcast stream, you have to have a persistent, unbroken TCP connection with the server. IIUC, this is a recipe for frequent interruptions on mobile. I think that Apple's HTTP Live Streaming and MPEG DASH have the right idea; instead of an actual stream, you get chunks of media from an HTTP server, based on a playlist. In Apple HLS, that playlist is even a variant of the Winamp .m3u format. I understand that these systems are primarily used for video, but I wonder if any radio stations use HLS or DASH for their online streams. Of course, the downside of these systems is higher latency, but that might not be so bad [1].

[0]: One of my first real projects in Python was Supercast (http://supercast.sourceforge.net/), a Shoutcast-compatible server. I was also a DJ on the Internet radio station for which I wrote that server. Not a particularly good one, mind you, but it was fun for a little while.

[1]: Back when I was into Shoutcast, I did think the latency of large buffers was a bad thing. One difference between Shoutcast and my Supercast server was that Supercast didn't send an initial large audio buffer to each listener. But priorities change sometimes, and now I think it's more important to avoid drop-outs.

iHeartRadio streams support both HLS and Shoutcast. You can find the stream info for each station embedded in a JSON object on the stream page. For example, for a iHeartRadio station that I listen to occasionally, there's the following:

  "streams":{
    "hls_stream":"http://c8.prod.playlists.ihrhls.com/609/playlist.m3u8",
    "shoutcast_stream":"http://c8icyelb.prod.playlists.ihrhls.com/609_icy",
    "pivot_hls_stream":"https://us.api.iheart.com/api/v3/adswizzhls/redirect.m3u8?url=https%3A%2F%2Fc8.prod.playlists.ihrhls.com%2F609%2Fplaylist.m3u8&marketId=51",
    "secure_hls_stream":"https://c8.prod.playlists.ihrhls.com/609/playlist.m3u8",
    "secure_shoutcast_stream":"https://c8icy.prod.playlists.ihrhls.com/609_icy"
  }

Interesting, thanks. So, I'm not crazy to think that using HLS for audio might be worthwhile. I wonder if iHeart does it for robustness over mobile connections, or just browser compatibility (particularly with iOS Safari).

That secure Shoutcast stream is an interesting mix of old and new. It has the expected "icy-" HTTP headers, but it's using HTTP/2 and, of course, HTTPS. The fact that it even returns a valid response for an HTTP HEAD request puts it ahead of real Shoutcast and Icecast streams in terms of standards compliance. It looks like iHeart has their own streaming server.

All the licensing overhead of a Spotify, all the market opportunities of "Bob's Gas Station and Deli".

Because most cars aren't fitted with cellular connections to stream? And most people don't actually want to play with a phone while driving. Tesla's got it nailed down with their radio interface. Everybody else is cumbersome or you have to wake your phone to bluetooth pair and then fuck with your phone.

> Everybody else is cumbersome or you have to wake your phone to bluetooth pair and then fuck with your phone.

uh, i've got a years old subaru where i just turn on the engine, and by the time i've backed out of the driveway, it is playing music over bluetooth. phone stays in my pocket the whole time.