[SOLVED] Multiple Genres Bug?

[TheOldPresbyope]

@Atair

Late-breaking news.

I should have been more skeptical. It turns out that even mid3v2 (which is based on mutagen) lies about the actual content of the ID3 text frames (the official name of those T... fields).

Recall in my previous post I showed the mid3v2 output for your MP3 file was

Code:

TCON=Rock-Italienisch / Italien / Rock

Quite literally this is not so!

Dumping the strings from the MP3 file, I discovered that it actually contains three TCON frames. Schematically they are

Code:

TCON Rock-Italienisch
<APIC cover art>
TCON Italien
TCON Rock

Here I've not shown the messy binary information which is intermingled with each in a file. 

APIC is the frame type for a picture and is followed by many binary bytes of the JPEG image before the occurrence of the second TCON frame.

So, mid3v2, mediainfo, and MPD's plugins are apparently aggregating the information contained in these three TCON frames, albeit in different ways.

This multiplicity of frames is explicitly in violation of the ID3v2.3 spec, which says in part

The text information frames are the most important frames, containing information like artist, album and more. There may only be one text information frame of its kind in an tag.

Remember that in ID3, as in many metadata schemes, the word "tag" refers to the entire block of metadata associated with a file while in ID3 the word "frame" refers to a single piece of metadata---what we users and the MPD developers loosely call a "tag".

The plot thickens, as the saying goes. My "legal" MP3 files will always be interpreted as having a single genre even if I use creative concatenations with various separators, while your "illegal" MP3 files will be interpreted in various ways by various softwares. 

Regards,
Kent

[Tim Curtis]

@Atair  You are correct, only the last occurrence of a given tag is stored in the $flat array and "track info" does query the MPD database using the MPD command - lsinfo "path_to_the_track".

The Library also has a client-side component which is in /var/www/js/scripts-library.js. This is where sorting, grouping, filtering rendering, UI event processing, etc happens.

[Atair]

@Atair

Late-breaking news.

I should have been more skeptical. It turns out that even mid3v2 (which is based on mutagen) lies about the actual content of the ID3 text frames (the official name of those T... fields).

Recall in my previous post I showed the mid3v2 output for your MP3 file was

Code:

TCON=Rock-Italienisch / Italien / Rock

Quite literally this is not so!

Dumping the strings from the MP3 file, I discovered that it actually contains three TCON frames. Schematically they are

Code:

TCON Rock-Italienisch
<APIC cover art>
TCON Italien
TCON Rock

Here I've not shown the messy binary information which is intermingled with each in a file. 

APIC is the frame type for a picture and is followed by many binary bytes of the JPEG image before the occurrence of the second TCON frame.

So, mid3v2, mediainfo, and MPD's plugins are apparently aggregating the information contained in these three TCON frames, albeit in different ways.

This multiplicity of frames is explicitly in violation of the ID3v2.3 spec, which says in part

The text information frames are the most important frames, containing information like artist, album and more. There may only be one text information frame of its kind in an tag.

Remember that in ID3, as in many metadata schemes, the word "tag" refers to the entire block of metadata associated with a file while in ID3 the word "frame" refers to a single piece of metadata---what we users and the MPD developers loosely call a "tag".

The plot thickens, as the saying goes. My "legal" MP3 files will always be interpreted as having a single genre even if I use creative concatenations with various separators, while your "illegal" MP3 files will be interpreted in various ways by various softwares. 

Regards,
Kent

This is interesting and shows that a couple of tag editors and music databases seem to be programmed "defensively" so they can handle non-standard fram usage.

[Atair]

@Atair  You are correct, only the last occurrence of a given tag is stored in the $flat array and "track info" does query the MPD database using the MPD command - lsinfo "path_to_the_track".

The Library also has a client-side component which is in /var/www/js/scripts-library.js. This is where sorting, grouping, filtering rendering, UI event processing, etc happens.

Now that we came to the heart of the matter I think we can end the discussion.

I am considering whether I can contribute to the code, if it is not too complicated for me.

Tim, maybe you can give me some more hints by PM where to look and which parts may be involved.

Thank you both for your patience!

Regards
Walther

[TheOldPresbyope]

@Atair

Back when the TCP suite of protocols was in early development, Jon Postel accidentally became a legend when he wrote in RFC 760 that, for the sake of robustness, "an implementation should be conservative in its sending behavior, and liberal in its receiving behavior". Various wordings of this statement have become known as Postel's Law or Postel's Principle.

I admire software which can deal with malformed input liberally, but I abhor software which generates malformed output. I especially abhor software which does it apparently on purpose but doesn't bother to document its behavior. No one should have to spend time examining binary files byte-by-byte to understand what's been done.

As for contributing to the moOde codebase, that would be great. Everything is in the github repo and Tim has always considered carefully the code changes proposed by others.

Regards,
Kent

[Tim Curtis]

Thanks to @Atair for a nice code contribution that adds support to the Library for tracks tagged with multiple genres :-)

The commit "@ atair contrib: Add support for multiple genres in the Library" can be viewed in the repo.
https://github.com/moode-player/moode/commits/develop

-Tim

[dwlacroix]

Great addition.

Because giving children candy only results in request for more - could this be easily applied to multiple artist? (I never can remember if Chick Corea or Bela Fleck received first billing)

<Feel free to tell me to be quiet and enjoy what I have>

[Tim Curtis]

That would prolly break the key (album@artist) thats used to uniquely identify an album in the Library but in any case what's the scenario where there would be multiple artist tags?

[dwlacroix]

but in any case what's the scenario where there would be multiple artist tags?

I am thinking about Albums by artist that don't normally record together. Examples would be: 

The Together albums by Julian Bream and John Williams
The Enchantment by Chick Corea and Bela Fleck (actually there are multiple Bela Fleck albums that would fall under this category)
 
It could possible also help with classical recordings - I could tag it Van Cliburn and Tchaikovsky

[Tim Curtis]

I have both the Bream/Williams duet albums. In my case the Artist tag is set to "Julian Bream, John Williams". I have also seen these other formats:

"Artist1 & Artist2"
"Artiust1 and Artist2"

MusicBrainZ lists the Artist for The Enchantment as "Chick Corea & Béla Fleck" but it also lists the Album under each artist individually.

I suppose there is a case to be made for handling multiple artist tags. I can add to the TODO list for investigation.