Separate ICY parsing from visualisation

[jovanbulck]

Some thoughts on how ICY messages are currently processed and displayed:

ICY Considerations

1. The Shoutcast/ICY protocol seems to be the de facto standard for meta data in online radio streams
2. This protocol sucks in many ways:
   • proprietary: there seems to be no official documentation. This page describes ICY internals a bit, as found out by reverse engineering..
   • the meta data is interweaved in the audio stream and only shows up at regular intervals
   • there is only a single field StreamTitle to hold all the most relevant info: current song's title and current song's artist and name of the current radio program
3. As a result, ICY messages are inherently station-specific:
   • the value of the StreamTitle field is typically alternated with (i) radio program info and (ii) current song's artist and title
   • the current song's artist and title are formatted at will (e.g. dash-separated, capitalized, ...)

Software Requirements

IMO, yamlradio should:

1. exploit station-specific behavior by allowing users to plug in code that "knows what to expect from a station" (as you proposed in issue display current and previous ICY information #3 ), while at the same time clearly separating these code stubs from the rest of the code base.
2. allow a pluggable visualization scheme for everyone's needs (cf. kotnetcli): some users want the song title to be colored bold, whereas others want an OS-specific notification, ...
3. remain relatively lightweight by default, yet extensible as needed

Current Situation

The station-specific communicators from issue #3 meet criterion (1) above, but fail criterion (2). They encapsulate station-specific behavior, while at the same time enforcing one specific layout (e.g. non-colored and non-capitalized plaintext on the stdout of a 80-char-wide terminal).

Proposed Solution

We need to separate station-specific ICY handling from common visualization concerns. On every arrival of ICY meta data, yamlradio should:

1. pass the StreamTitle field to a station-specific parser (if any). This parser "knows what to expect from its station" and thus returns:
   • an indicator for the type of the meta data (e.g. "current song info" or "radio program info")
   • finer-grained info, dependent on the meta data type (e.g. split the "current song info" into the artist and song title)
2. pass the fine-grained info (if any) to a pluggable communicator interface that handles the visualization as desired (cf. kotnetcli). If no custom parser was found in step (1) above, pass the raw ICY data via a dedicated method.

Other fixed ICY meta data such as icy-name, icy-genre and icy-description (cf. issue #14 ) are updated when switching a radio station through a corresponding communicator method.

The communicator interface might thus look like:

• displaySongInfo(artist, title)
• displayRadioShowInfo(title)
• displayRawICYStreamTitle(streamTitle)
• displayRadioInfo(icy-name, icy-genre, icy-description)

Final Thoughts

I think the above will improve end-user's experience, since a real added value over plain mplayer will be created. IMO, it won't blow up the code base too much (3th criterion above), since the existing station-specific communicator scheme can be transformed into a station-specific parser scheme.

[GijsTimmers]

Hi Jo, thank you for looking this up.

I agree that the ICY part is pretty messy indeed. There are lots of methods to make sure the right stuff is parsed to the custom communicators, and this can be improved.

Although I myself don't see much use for displaying other ICY information except for the StreamTitle, I do agree that using streamscrobbler is a much cleaner solution. Also, I'd love to experiment with mpv instread of the tried-and-true mplayer.

Regarding your proposal to switch to station-specific parsers, this will probably be a wontfix for the time being. The reason is that I'm happy with the way ICY messages are displayed at the moment and the amount of possible customisation. Also, as I mentioned, I don't see much use for using anything but the StreamTitle in the output.

Of course, yamlradio will remain open source, so you can fork it whenever you want to.

[jovanbulck]

I do agree that using streamscrobbler is a much cleaner solution. Also, I'd love to experiment with mpv instread of the tried-and-true mplayer.

Ok, so that means issue #14 will be considered?

I don't see much use for using anything but the StreamTitle in the output.

Yes, no doubt StreamTitle is the most relevant field. The station-specific parsers are not meant to provide other ICY information (that's the job of the streamscrobbler library), rather to give more meaning to the StreamTitle field. Recall that this single field is typically used to broadcast alternately (i) the current song's title, (ii) current song's artist and (ii) name of the current radio program. Station-specific parsers could identify what has been broadcasted and pass finer-grained info to a communicator for visualization purposes.

Of course, yamlradio will remain open source, so you can fork it whenever you want to.

Ok, will do if I feel like working on it :)

[GijsTimmers]

Ok, so that means issue #14 will be considered?

Yes, just need to find a bit of spare time