Project

General

Profile

Feature #205

Separate ICY "track-name" field into separate title and artist fields

Added by Carlos Giamante almost 7 years ago. Updated over 2 years ago.

Status:
Rejected
Priority:
Minor
Assignee:
-
Category:
-
Target version:
-
Start date:
November 09, 2012
Due date:
% Done:

0%

Estimated time:
Affects version:

Description

When I'm listening to the radio URL in Audacious, when i see track information such as song title and artist, everything appears in the title, as shown in the attached image.

I tested this on other players, and they show the information correctly, as in the other attached image.

The URLS I tested if it is useful for you to test, I used these: http://uk1.internet-radio.com:15763/
http://212.45.104.50:8014/

The correction of this will be useful as eg the Plugin RirycWiki of Audacious, which show letters, and useful for other devices that dependendem such information.

Sorry for my bad english, I hope the images expounding better.

In audacious.png (33.8 KB) In audacious.png Carlos Giamante, November 09, 2012 14:01
Other player.png (35.3 KB) Other player.png Carlos Giamante, November 09, 2012 14:01

History

#1 Updated by John Lindgren almost 7 years ago

  • Tracker changed from Bug to Feature
  • Subject changed from Track Infomation from URL Radios Stream. to Separate ICY "track-name" field into separate title and artist fields
  • Priority changed from Major to Minor

The information you see in Audacious is exactly the same information the server sends. I guess other players assume that the "track-name" field will always contain the song title and artist, but I don't think that is a safe assumption to make.

#2 Updated by Carlos Giamante almost 7 years ago

John Lindgren wrote:

The information you see in Audacious is exactly the same information the server sends. I guess other players assume that the "track-name" field will always contain the song title and artist, but I don't think that is a safe assumption to make.

Intends to implement?

In this case it is safe to implement, because all I know URL Radio, uses it by default.

#3 Updated by Nevik Rehnel almost 7 years ago

Carlos Giamante wrote:

In this case it is safe to implement, because all I know URL Radio, uses it by default.

Only those which YOU know; I know plenty of radio stations that do not always send title information formatted like that.

I don't know how much work it is to add something like this, but what would be more feasable for the user base as a whole is the splitting of the track-name field by a custom pattern (e.g. a setting like "Assume stream track-name field to be formatted like: [%a-%t]" or so)

#4 Updated by Carlos Giamante almost 7 years ago

Nevik Rehnel wrote:

Carlos Giamante wrote:

In this case it is safe to implement, because all I know URL Radio, uses it by default.

Only those which YOU know; I know plenty of radio stations that do not always send title information formatted like that.

I don't know how much work it is to add something like this, but what would be more feasable for the user base as a whole is the splitting of the track-name field by a custom pattern (e.g. a setting like "Assume stream track-name field to be formatted like: [%a-%t]" or so)

Hi, sorry for the delay, I was out.

As for the servers that send the information correctly, and I do not know if it exists, is surely a small minority, but in general, behave this way.

The feature would be implemented only to the servers that send information that way track - name, those who send correctly, is not necessary.

And sorry for the delay in my response.

#5 Updated by Carlos Giamante almost 7 years ago

Mr John Lindgren, sorry to post again, but you go implement this feature? The servers that send the information correctly as track and name, will remain so, only when they send this information together feature take effect.

That would be ideal for the OSD and RicLyric Lyrycs.

#6 Updated by Michael Jacobs over 6 years ago

To me, it seems (as John stated) that it is more a convention, that the servers always transmit [artist - title] in the title field than a reliable rule. After all, for other stream formats (e.g. ogg), there might be a different convention, or there might be sufficiently many meta data fields defined already in the stream s.th. there is no need for information mangling at the server side. To solve that issue, I would rather think of allowing the user to locally define meta-data rewrite patterns that can be applied to specific streams. In that sense, one could think of a default rewrite pattern for MP3 streams that always treats it like [artist - title]. I have not yet thought about that for too long, but that might be an idea. I would think of a meta data rewrite plugin or something similar.

#7 Updated by Carlos Giamante over 6 years ago

Most famous players have the feature as Clementine, Deadbeef and etc.

Why is this important?
The plugin LyricWiki only displays Lyric searching in the correct way And other applications that dependendem that way.

Michael Jacobs wrote:

To me, it seems (as John stated) that it is more a convention, that the servers always transmit [artist - title] in the title field than a reliable rule. After all, for other stream formats (e.g. ogg), there might be a different convention, or there might be sufficiently many meta data fields defined already in the stream s.th. there is no need for information mangling at the server side. To solve that issue, I would rather think of allowing the user to locally define meta-data rewrite patterns that can be applied to specific streams. In that sense, one could think of a default rewrite pattern for MP3 streams that always treats it like [artist - title]. I have not yet thought about that for too long, but that might be an idea. I would think of a meta data rewrite plugin or something similar.

#8 Updated by John Lindgren over 6 years ago

I would be willing to commit a patch implementing this feature as long as it is an option and is disabled by default.

#9 Updated by Carlos Giamante about 6 years ago

John Lindgren wrote:

I would be willing to commit a patch implementing this feature as long as it is an option and is disabled by default.

Very good John, please implement it :).

#10 Updated by John Lindgren about 6 years ago

Carlos Giamante wrote:

Very good John, please implement it :).

You misunderstand. I am not interested in the feature; therefore I am not writing the patch. Someone who is interested in the feature is welcome to write a patch.

I am tired of your entitlement attitude. ("I want something; therefore I am entitled to it, and it is your job to give it to me.")

#11 Updated by Michael Jacobs about 6 years ago

John Lindgren wrote:

Someone who is interested in the feature is welcome to write a patch.

As stated before, I would be interested in a more general thing than just splitting up the "Artist - Title" information from title fields of MP3 streams.
Also for other stream formats there are other cases where strange information mangling in the meta fields is used.
Like for example the ogg stream of kohina. Its title field contains "Radio Station - Artist" and its title field contains "Title - System of Origin".
For such cases I would like to see custom rewrite pattern that can be applied to particular stream urls.
One could also think of applying such rewrite pattern to whole types of streams, like for example MP3 streams.
A default pattern, that could also exist from the start but be disabled by default, could be the feature Carlos is interested in.

I agree with John, that such a thing should be disabled by default.

Just to make it clear, I am only interested in the more general feature. So I am not willing to provide a patch that just adds the exact feature Carlos requested. I guess the more general feature will need some more thinking in order to end up with a flexible concept and a clean and maintainable implementation.

I'd really like to implement the more general feature. But that will take some time and I can currently not estimate when I will have this time.

#12 Updated by John Lindgren over 2 years ago

  • Status changed from New to Rejected

Closing some old requests that no one has had time to implement.

Also available in: Atom PDF