`Thanks, backlines are missing so for clarity:
sudo apt install build-essential git
bash <(curl -sL https://raw.githubusercontent.com/node-red/linux-installers/master/deb/update-nodejs-and-nodered)
sudo systemctl enable nodered.service
For FIP, I installed Icecast on my Synology ⊠but not node-red so I tried to install it on my Roon W10 server.
Everything looks âokâ but I forgot something (?)⊠no metadata under Roon.
I set the address in flow configuration, IP synology instead of localhost.
So icecast on 192.168.1.101 and node-red on Roon server on 192.168.1.89.
I had changed the password and the IP in the flow but not through the web interface of node-red.
Now⊠Its good⊠
With a simple bat file to launch ânode red.jsâ on Roon server startup.
Icecast on my NAS and Node on my Roon server (w10)
Icecast sur mon NAS et Node sur mon serveur Roon (w10)
Merci SĂ©bastien et Merci RĂ©mi (from zaurux)
So, I looked a bit further, here are my findings.
Icecast is not able to add metadata on FLAC streams.
Each word is important here:
1/ âAddâ metadata is not possible, but broadcast metadata already embedded in source FLAC stream is ok -> this is why it works with Motherearth for example (I had a chat with the owner - thanks Florian )
2/ âon FLAC streamsâ: actually, Icecast can add metadata on aac and mp3 streams -> this is the âtrickâ I used for FIP, which is broadcasted in aac
So, what are the options to have Radio Paradise broadcasted in FLAC with metadata ?
1/ Use another server - thatâs what I did with RSAS instead of Icecast - RSAS supports embedding metadata on FLAC streams on the fly
2/ RP to tag FLAC streams before broadcasting to Icecast
2 Likes
Thank you @Sebastien, very interesting. This explains why icy-metaint was missing on the Motherearth stream; the Icecast server knew nothing about the metadata.
So why do more stations not do the same? Because it is easier and simpler to provide metadata separately from their audio streams and rely on the Icecast server to deal with it rather than incorporate it directly?
To get stations to alter their Flac streams and incorporate the metadata is going to be hard; easier to get them to use RSAS and (from their point of view) easier still to update Icecast. Do you know if Icecast has such development in mind?
Thanks Sebastien,
Just dumbing it down so I can understand, are 1 and 2 both necessary or are they alternatives ?
I donât think there will be any such development on icecast, have a look on this interesting post:
http://lists.xiph.org/pipermail//icecast-dev/2017-June/002619.html
So why do more stations not do the same is a mystery for me. It does not sound very complex, but I guess that RP and others have some good reasons - remember the âif we could, we wouldâ statement on RP webpageâŠ
Regarding RSAS: yes, itâs an easy solution (RSAS setup takes a couple of minutes, it is intended as a 1:1 replacement for Icecast), but RSAS is not free - although we are talking about 25$ per month 
Would be good to hear from RP on this.
Hi Andy,
I guess that you are referring to those 1 and 2:
So, what are the options to have Radio Paradise broadcasted in FLAC with metadata ?
1/ Use another server - thatâs what I did with RSAS instead of Icecast - RSAS supports embedding metadata on FLAC streams on the fly
2/ RP to tag FLAC streams before broadcasting to Icecast
Well, I am not aware of any alternative unfortunately. Note that anybody could do 1), that what I did, but it requires some technical knowledge on Linux.
A fascinating thread, thank you again. It seems that Icecast will not do the same fix for flac as they do for mp3 and aac.
Interestingly, from one of the subsequent posts:
Reading OPUS OGG fileformat, the metadata is limited to the second
âpageâ. In a live-stream, you could not send a new metadata
information⊠unless you send a logical âEnd of Streamâ to the icecast
server followed by a new âStart of Streamâ followed by new metadata. I
wonder if that is transparent to the client, because the client I use
stops reproducing when finding the EOS mark.
And
As far as I know, EOS followed by a new stream is the only way to pass
metadata in ogg-embedded streams. Clients didnât support that very well
back some years ago but I would hope that this is better now⊠Only other
alternative to avoid stream concatenation is to remove all subsequent
metadata, Iâm afraid.
I think this explains why Roon stumbles at the end of each song in Motherearth.
Yep, very interesting indeed.
Note that, as explained, I tried multiple ways to add metadata through Icecast but never succeeded - but, interestingly, I ended up with Roon stumbling as with Motherearth.
More precisely, I had the following setup:
- Icecast server
- Local client (Chrome browser)
- Local client (Roon)
-> when I tried to ingest metadata, no metadata displayed, the client in Chrome browser continued playing seamlessly but Roon stopped; had to click âPlayâ on Roon to resume.
And second point: why is RSAS not affected by this ? Honestly I have no clue (RSAS source code not available). If you tried my second post on my blog, youâll notice that Roon works flawlessly with RSAS: tags are added when available, and Roon player keeps playing gently.
I only tried the first - icecast + node-red (on rpi3 with dietpi).
Yes. What I donât understand is whether you have to do both 1 and 2 to achieve the result, or only one of them.
As I understand your reply, you were able to achieve the result by only doing 1, meaning they are alternatives (or options, as you describe them).
They are alternatives.
Option 1 is like Bluesflac, miss out Icecast altogether.
Option 2 is like Motherearth where the metadata is in the stream before Icecast sees it. However, this necessitates an End of Stream flag being sent at the end of each track so that new metadata can be issued in a new stream. Roon canât deal with this at present, but no reason why it canât be fixed.
1 Like
Correct Brian.
Note that if one of you guys want to give a try to Radio Paradise / FLAC / metadata, I can share the URL of my RSAS setup in private message - just let me know.
1 Like
This works well but I noticed that Icecast actually pulls all streams all the time, eating 250kBytes/s of my limited bandwidth (25% of it actually). Worth to be known to people without fiber connection
I kept FIP only and now back to 30kBytes/s permanent incoming data.
You can add the âon-demandâ setting for the radios youâre the least likely to listen, e.g.:
<relay>
<server>icecast.radiofrance.fr</server>
<port>80</port>
<mount>/fipworld-hifi.aac</mount>
<local-mount>/fipmonde</local-mount>
<on-demand>1</on-demand>
</relay>
It adds some latency for those streams, but for personal use it is fine.
1 Like
SĂ©bastien, I have tried to add the âon-demandâ setting, unfortunately it didnât work, i.e. I lost the metadata in Roon (I stopped and restarted the ICecast2 service, even rebooted).
Removing âon-demandâ --> it works again.
Hi RĂ©mi,
This is expected as per the way I implemented the node-red flow: it updates the stream at each metadata update, but if the corresponding stream is not active, then there is nothing to update.
So, if you enable the âon-demandâ setting, then when you launch the stream you will not see any metadata until the next song starts.
1 Like
Just as another data point, 440hz Radio sends 48k ogg/flac to Icecast with metadata. VLC successfully extracts it. I assume itâs in the Flac stream directly at the session starts (Roon stumbles at end of each track (EOS presumably))
For experimental purposes, I have added for limited times a stream for FIP radio in Roon that should contain Metadata. Itâs the AAC stream ending by 8000/fip.
Let me know if it works and thanks again @Sebastien for the Icecast/Node-Red hack!