Or https://shonanbeachfm.out.airtime.pro:8000/shonanbeachfm_a if you want to use a web radio app like https://f-droid.org/en/packages/org.y20k.transistor/ etc.

One unfortunate property of radio.garden is it doesn’t give you the actual stream links (IIRC it proxies the M3Us through its own server), because lock-in I guess? I’d be happy to be proven wrong here, because the site is otherwise excellent.

I came upon a French-language radio station catalogue a while ago, and that did have the original links, but I’ve lost the tab since then :( ETA: It was https://www.programmes-radio.com/en/streaming/, and I was misremembering: they don’t show the original playlist link either, but they do use it in their streaming widget, so it’s a only short trip to the Network tab of the browser’s devtools away.

Hello I'm the developer of programmes-radio.com (but non-French people should probably use https://www.radio-addict.com instead) (also the website is open source, https://github.com/conradfr/ProgRadio/)

I don't show the streaming links but it's not for lock-in but because I've never got that request :) You can just look them up using developer tools though (same for radio-garden). Not ideal on mobile I guess.

I haven't look at what radio.garden does but I proxy some http only streams that don't work well when requested from an https audio element, maybe that's what you're referring to.

A lot of Icecast/Shoutcast streams either lack HTTPS support, or they don't have CORS headers, or not the right CORS headers.

Like a very common issue is - if you don't have an access control allow headers header for icy-metaint - you can't pull out the embedded Shoutcast metadata client-side. You now have to pull now-playing type data via some other method, like polling the Icecast API - which may not be available. A lot of servers don't send any CORS headers, some only send the allow-origin header.

In theory stream producers can use Ogg to encapsulate the stream and use bitstream chaining to have in-band metadata. That limits the codecs to Vorbis/Opus/FLAC, which are all great codecs - bigger issue tends to be how the browser handles chained bitstreams in audio elements. My understanding is - they just don't handle it at all.

So - if the goal is to play the streams in the browser and ensure you have a consistent experience, it makes sense to proxy them all into some common format like HLS and serve it over HTTPS. You can have timed ID3 metadata, and eliminate CORS and mixed-media issues. This does mess with the stream's ability to accurately measure things like, how many people are listening.

AFAIK the https://www.skytune.net/ portal gives you the original .mp3/aac/m3u ... adresses

Thanks! I typically access through Apple Music, which itself goes via TuneIn. Not a delightful experience, but the only one that works on a HomePod.