icy_metadata purpose

[iSerganov]

Hey team!

I am using Liquidsoap 2.2.5 and Icecast 2.4.4.
Trying to impact somehow the icy metadata in the stream and not really lucky there.

I am always having 4 tags only:

Input #0, mp3, from 'http://station.com/radio.mp3':
  Metadata:
    icy-name        : music
    icy-pub         : 1
    icy-url         : https://my.station.com
    StreamTitle     :  Artist - Title
  Duration: N/A, start: 0.000000, bitrate: 85 kb/s

In liquidsoap I am trying to impact ICY metadata using icy_metadata in output.icecast func arguments, e.g.:

output.icecast(%mp3.vbr(id3v2=true, quality=output_stream_quality),
  host = icecast_host, 
  port = icecast_port,
  password = icecast_pass, 
  mount = mount_endpoint,
  name=station_name, 
  send_icy_metadata=true,
  url=url,
  icy_metadata=["song", "title", "artist", "url", "my_custom_tag", "album", "genre", "date"],
  radio)

However whatever I set to icy_metadata=[], the result is the same and I always see only above 4 tags when probing the output stream.

Could you please advise what is the purpose of icy_metadata in output.icecast call and what can I set there?

[gAlleb]

Hi @iSerganov.

Link about icy metadata - https://www.liquidsoap.info/doc-dev/icy_metadata.html

Taking Icecast and mp3 format into account you can send: icy-br, icy-description, icy-genre, icy-name, icy-pub, icy-url, StreamTitle, StreamUrl and a few others. It differs from version to version (icecast 2.2.4, icecast-kh, icecast-2.5-beta3). e.g. icecast-kh gives me this:

Input #0, aac, from 'http://radio:8020/coma.aac':
  Metadata:
    icy-br          : 192
    icy-description : ...
    icy-genre       : ambient, drone, field recordings
    icy-name        : ...
    icy-pub         : 0
    icy-url         : https://
    StreamTitle     : Rudy Adrian - Netherworlds
  Duration: N/A, bitrate: 192 kb/s
  Stream #0:0: Audio: aac (LC), 44100 Hz, stereo, fltp, 192 kb/s

When you use mp3 - send_icy_metadata is true by default. LS sends StreamTitle automatically too, combining artist and title song metadata.

You can also do curl -i -H 'Icy-Metadata: 1' http://domain/mount to see icy-meta.
Ogg stream is different. It is the container format and holds more metadata. But it's not much of a use.

---

Basically you can alter only the fields mentioned above. If you'll install icecast-2.5-beta3 or icecast-kh you'll be able to use StreamUrl as well. You cannot put more. LS uses icy metadata mechanism to update metadata in icecast’s streams because mp3 or aac icecast streams do not support in-stream metadata. It returns artist and title metadata by default in StreamTitle field. Lots of web radios try to put everything into StreamTitle. Like:

def apply_meta(m) =
title = m["title"]
artist = m["artist"]
album = m["album"]
if artist != "" and title != "" then
[...list.assoc.remove("artist", m), ("title", "#{artist} - #{title} - #{album}")]
else
m
end
end

This will give you: SreamTitle: Artist - Title - Album.

So not much space for imagination) To send description, genre and public=0 you can:

output.icecast(... ,
name = "....", 
description = "...", 
genre = "...", 
url = "...",
public=false
)

---

Regarding icy_metadata itself. Oh, I'm not sure about it at all and its use case)) Say we have such script:

s = playlist("./music")

def apply_meta(m) =
title = m["title"]
artist = m["artist"]
album = m["album"]
if artist != "" and title != "" then
[...list.assoc.remove("artist", m), ("title", "#{artist} - #{title} - #{album}"),("dj", "DJ"),("tracknum", "999"),("comment", "no-comments-please"),("song", "new song"),("next", "next-song"),("date", "today")]
else
m
end
end
s = metadata.map(update=false, apply_meta, s)

output.icecast(%ffmpeg(format="ogg", %audio(codec="libopus", samplerate=16000)),host = "", port = 8000, password = "", mount = "music", fallible=true, s, name = "Rock Radio", description = "Hard Rock", genre = "ddd", public = false, url = "...")

it would output something like this and editing icy_metadata doesn't change anything)

  Metadata:
    icy-br          : 96
    icy-description : Hard Rock
    icy-genre       : ddd
    icy-name        : Rock Radio
    icy-pub         : 0
    icy-url         : ...
  Duration: N/A, start: 0.000000, bitrate: N/A
  Stream #0:0: Audio: opus, 48000 Hz, stereo, fltp
    Metadata:
      album           : BIRP! Best of 2020
      comment         : no-comments-please
      date            : today
      dj              : DJ
      genre           : Indie
      next            : next-song
      title           : Beauty Queen - Sweet Memory - BIRP! Best of 2020
      track           : 192
      year            : 2020
      encoder         : Lavf60.16.100

@toots is there a use case for icy_metadata=[] at all?

[toots]

Hi all!

This is all confusing, I have to admit.

You have 3 distinct things:

1. The metadata you send when connecting the source to the icecast server
2. The metadata updates you send from the source client to the icecast server
3. The metadata updates received by the client.

Initial metadata

These metadata are sent once when initializing the connection and cannot be updated.

As far as I know there are only a few fields: "icy-name", "icy-url", "icy-pub", "icy-genre" and "icy-br"

(Icecast has a little more, all named ice-*)

These fields are filled via specific arguments of output.shoutcast (genre, public etc..) except for icy-br which is inferred from the encoding.

Ogg formats vs. others

Before we go deeper, it's good to remember that, for ogg formats, metadata updates are handled in-band via the ogg container metadata support. Thus, the following only applies to format who do not have a canonical metadata support such as mp3, aac, etc.

Metadata sent from the source client to the icecast server

These metadata are sent out-of-band via a HTTP GET call. The metadata are passed as parameter to the GET url.

This means that you cannot tightly control synchronicity between metadata updates and media content with this method.

Metadata sent via this update are itemized values such as "title", "artist", etc..

The list of sent metadata is controlled by icy_metadata.

There is one special metadata called "song" which is calculated by the operator if not provided. By default it is something like "#{artist} - #{title}". If only one of artist or title is available, they are used for this metadata. We'll explain this one below.

Those metadata are used to update the listening clients but, also, to update the icecast admin page and yellow pages.

Fun hack fact: Liquidsoap also supports manual metadata update with this method using the icy.update_metadata operator.

Fun hack fact: icecast also support source client metadata update for ogg/vorbis and is able to insert them in-band in this case. Don't know why!

Metadata updates received by the client

This is the last bit.

Because formats such as mp3, aac, etc do not have a canonical notion of in-band metadata, shoutcast introduced its own support.

At regular intervals, the media stream is interrupted and a metadata string is inserted.

The format for that string is very rought, it looks like: "StreamTitle='%s';StreamUrl='%s'".

Listeners client are expected to display StreamTitle as the current metadata. As you can see, no other itemized metadata is passed to the client.

The spec for this is both completely outdated and absolutely undocumented. In particular:

• There is no provision to escape single quotes inside the quoted strings
• It was initially sent using the latin1 character encoding
• The de-facto format for StreamTitle used to be #{artist} - #{title} again with no provision to escape - if the artist or title has one in it.

In other words, a total mess.

The value for StreamTitle is filled using the song metadata if provided. Otherwise, Icecast/shoutcast may make one using the other itemized metadata. The logic for making this string should be the same as for computing the song metadata in liquidsoap.

It is nearly impossible to reliably parse the StreamTitle back into itemized metadata unless you tightly control which listening client are allowed and implement your own logic between the streaming server and listener.

Lastly, most source client will now send metadata update in utf8, resulting in a StreamTitle also being encoded in utf8. This can confuse old clients that may still expect latin1 for this string and there is no way to make it work for both cases as string encoding are usually not auto-detected.

Hope this helps!

[gAlleb]

Thanks, Romain.
So editing or adding/removing meta from icy_metadata array won’t impact client side meta, which has only ever changing “StreamTitle” and “StreamUrl” in case of mp3/aac.

[toots]

Unless you remove artist or title, no.

[iSerganov]

Thank you very much for such detailed explanation gentlemen!
That seems much clearer to me now!

As to this statement - These metadata are sent out-of-band via a HTTP GET call. The metadata are passed as parameter to the GET url.

@toots , does that mean that I can make these calls to icecast myself from withing Liquidsoap code, e.g. on metadata change event? If yes, are metadata tags that can be provided there restricted? Or can I send any metadata I want?

[toots]

Thank you very much for such detailed explanation gentlemen! That seems much clearer to me now!

As to this statement - These metadata are sent out-of-band via a HTTP GET call. The metadata are passed as parameter to the GET url.

@toots , does that mean that I can make these calls to icecast myself from withing Liquidsoap code, e.g. on metadata change event? If yes, are metadata tags that can be provided there restricted? Or can I send any metadata I want?

You can make the call yourself if you have a use for it, yes. You might want to set send_icy_metadata=false on output.shoutcast/output.icecast in this case to avoid double sending it.