• 1
  • 2(current)
  • 3
  • 4
  • 5
  • 23
Music Development
#16
I don't think there is such a thing as "perfect tags". The closest to an actual tagging spec is the ID3 spec, but that spec is widely abused by use of TXXX frames in ways that aren't part of a spec. Other tag formats largely have "de-facto" specs based primarily on the market position of entities using them (for example Apple iTunes). In general there is no agreement on how various tag formats are harmonized.

I get that there is a group of Musicbrainz users who prefer Musicbrainz's tag definitions. I don't have a particular problem with Musicbrainz tag definitions, but I see an interoperability problem with other tag systems. Currently there doesn't seem to be a process or method in Kodi development to deal with interoperability in a formal way. What I see is a continued application of "band-aides".

As far as the "multi-artist fix" in Kodi Jarvis, it seems to work as designed. The design is limited.

scott s.
.
Reply
#17
I agree that there are no perfect tags and even the MBZ Picard tags are not ideal. Having said this, the behaviour I am describing in my opening post is clearly a bug and I understand from evilhamster that it has been patched for Kodi 16.

@evilhamster, thanks a ton for helping check my two releases. Let me upgrade my clients to Kodi 16 and give it a try. If that's what it takes to fix my music library, I am more than happy to do so. Do you have any ALAC (m4a) files in your library and do they work for you. It looks like there are some problems with the artists tag for these files. Any thoughts? http://tickets.musicbrainz.org/browse/PICARD-376
Server: Asus Sabertooth Z77 | Intel Core i5 3.4 GHz | 16 GB DDR3 | 128 GB SSD, 82 TB (9 x 6 TB, 7 x 4 TB)
HTPC 1: Raspberry Pi 2 | HTPC 2: Raspberry Pi 2 | HTPC 3: Raspberry Pi
Reply
#18
I found another work-around, which does not require me to update and also does not require the use of the artists tag. I am removing MBZ-IDs from my tags and everything works perfectly.

I will now retag my libray to remove the MBZIDs, which will solve my issue and will show clean artists and albums in Kodi.

As a feature request, we may want to consider an option for Kodi to ignore MBZIDs (maybe through advancedsettings?):
Server: Asus Sabertooth Z77 | Intel Core i5 3.4 GHz | 16 GB DDR3 | 128 GB SSD, 82 TB (9 x 6 TB, 7 x 4 TB)
HTPC 1: Raspberry Pi 2 | HTPC 2: Raspberry Pi 2 | HTPC 3: Raspberry Pi
Reply
#19
(2015-08-15, 00:55)scott967 Wrote: I get that there is a group of Musicbrainz users who prefer Musicbrainz's tag definitions. I don't have a particular problem with Musicbrainz tag definitions, but I see an interoperability problem with other tag systems. Currently there doesn't seem to be a process or method in Kodi development to deal with interoperability in a formal way. What I see is a continued application of "band-aides".

As far as the "multi-artist fix" in Kodi Jarvis, it seems to work as designed. The design is limited.

My mix of pop and classical music has also shown me the limitations of the current design (loving Kodi, but it could be even better). Any suggestions for how a redesign of tag handling could work? What are the interoperability issues?

The difficulty, of course, with any improvements is that it has to be backwards compatible with how users have already tagged their music (including all the odd fixes). I am new to Kodi but willing contribute in this area with the aim of improved music browsing.

Steve, not sure deleting MBIDs is the best solution, having universal unique artist and album IDs as provided by Musicbrainz is useful in a large library. Being able to ignore them in Kodi rather than delete them from the files would be useful I guess. Wouldn't getting Kodi to understand that "feat." and "&" were artist separators be another way, oh and a scan comparing names and MB id's to check that the order had not caused a mix up.
Reply
#20
scott967:
I know you had some comments on my first pr for the artists tag (7281) but if you have any comments on the functionality of the second one (7486), it would be great if you could list them and I could try to improve it.

steve1977:
I have not touched the mp4 part of the tag code in any of my commits, so that is still not working. I have a local copy where I added support for the artists tag to the mp4 code and it seems to be working, but I haven't had time to test it properly.

It would be easy to implement a setting that ignores all mbrainz tags when reading files, but not sure that it is a good idea. If that settings is enabled after already having some music added with mbrainz idConfused in the database, it could be a kind of ugly situation.

Dave:
The problem with using for example & as a artist separator is that some band have a & in their name and should not be split.

Do you have any ideas for how the tag handling could be changed to better work with classical music? Don't have any classical music in my library so haven't been able to see the problems.
Reply
#21
Thanks, this sounds good. Would it even be possible to support MP4s artists tag? I would have thought that it is a bug with Picard/Mutagen?

Agree that ignoring MBZIDs should not be a default setting. That's why I was thinking of advancedsettigns.xml or maybe an expert settign?
Server: Asus Sabertooth Z77 | Intel Core i5 3.4 GHz | 16 GB DDR3 | 128 GB SSD, 82 TB (9 x 6 TB, 7 x 4 TB)
HTPC 1: Raspberry Pi 2 | HTPC 2: Raspberry Pi 2 | HTPC 3: Raspberry Pi
Reply
#22
(2015-08-15, 12:29)evilhamster Wrote: It would be easy to implement a setting that ignores all mbrainz tags when reading files, but not sure that it is a good idea. If that settings is enabled after already having some music added with mbrainz idConfused in the database, it could be a kind of ugly situation.

Do we really want to be dependant on MBIDs? It is not really a standard, and seems to be part of a system originally intended to get the other tags right, not as a primary reference.
Reply
#23
(2015-08-15, 12:29)evilhamster Wrote: The problem with using for example & as a artist separator is that some band have a & in their name and should not be split.

Do you have any ideas for how the tag handling could be changed to better work with classical music? Don't have any classical music in my library so haven't been able to see the problems.

You are absolutely right about "&", but "feat." does seem unlikely as part of a name. But perhaps it is better, and reasonable, to require that music files are tagged with a single and consistent artist separator. Converting "feat." (or whatever language equivalent) to say " / " is easily done at within tagging. And if your music files are using a different separator because that what is used by another player then the Kodi setting can be changed in advancedsettings.xml can't it.

I have lots of ideas for classical music improvements Smile
Maybe a thread with the title "Music Library" is a good place to discuss it (sorry for the hijack). I am sure that there are users outhere that are interested, they just aren't watching the forums. Unfortunately I think it will need more than just handling additional (but standard) tags to do something worthwhile, but tag handling certainly has a part to play.

To give you some understanding of the issues the main selection criteria for playing classical music is composer rather than performer (although sometimes you want that). So a lot of classical music listeners have worked around things by putting composer in ALBUMARTIST/TPE2, but that is a misuse of the tags really since the standards include COMPOSER/TCOM tags (and TPE2 was intended to be orchestra if you read the IDE spec). However album and composer are not always enough to uniquely identify a recording/release/CD e.g. your music collection could easily contain different conductors/orchestras playing the same Beethoven symphony, so you add those to the ALBUMARTIST,or you have them in ARTIST and enable the library to show song artists. Either way it has unwanted consequences: the artist list becomes a jumble of composers, conductors, soloists, orchestras as well as non classical performers; and the song title string becomes too long to be readable from the player display.

The other way you may want to access classical music is by work e.g. show me all my albums with the 1812 overture on. There are standard tags for that too GROUPING/TIT1, SUBTITLE/TIT3, WORK/TOAL, and it would be useful if Kodi scanned them from the files and then have a UI that supported music selection using them.

I will have a look at your PRs, but I think I probably have to let you finish and then try and com up with more changes on top. For now I am messing about on my own system, and will try to keep track of what you submit. However I am reluctant to comment on the PR thread less I am accused of Spam like Steve was!!

As for Musicbrainz, I too would not want to be dependant on it although I do see it as useful. It does know about works and composers (although it does not flag classical music per se), so could be useful in that way too.
Reply
#24
Here is my general understanding. Kodi relies on a GPL library, TagLib, for pulling supported metadata from supported file types.

Each supported metadata has its own specification for metadata, which in general terms is defined as a Key:value pair. Some metadata standards allow multiple instances of Key while other use a single instance with multiple values. In the later case the specification may (or may not) provide a mechanism for determining when multiple values are present, typically through the use of a unique separator character.

In every specification there is a Key which is interpreted as "artist".

MusicBrainz database has redefined this "artist" Key to mean something they call "artist credit".

Musicbrainz database has also defined new Keys (not part of any standard) that contain Musicbrainz-assigned unique identifiers. These identifiers are designed to disambiguate text string identifiers and are used for querying online data sources (aka "scraping", though they actually use published apis).

Because Musicbrainz has changed the meaning of "artist" Key they needed a new Key to replace it, which they call "artists".

There should be a one-to-one correspondence between "artists" and "musicbrainz artist ID" Key:value pairs. However, since every artist may not be in the Musicbrainz database, that can't be guaranteed. (This creates a requirement issue, should Kodi accept or reject these tags?) The presence of "musicbrainz artist ID" Key without an "artists" Key might be considered a tagging error.

A similar problem may exist with the "album artist" Key.

Note that in the musicbrainz scheme, each song (work) can only have a single "artist credit" and hence, for musicbrainz tags there can only be a single "artist" Key:value pair. Kodi would need to define what to do in the case where multiple "artist" Key:value pairs are found (assuming for example that existence of the "artists" key is interpreted to mean that musicbrainz semantics are being used).

For classical things are complex because I don't think there is any real standard. "title" can be ambiguous but usually a composition is uniquely defined by a composer + catalog pair. "artist" of course is not that useful. ID3 has defined something called "involved people list" which is a collection of values in a role:name format.

scott s.
.
Reply
#25
Thank you Scott.

(2015-08-15, 21:35)scott967 Wrote: There should be a one-to-one correspondence between "artists" and "musicbrainz artist ID" Key:value pairs. However, since every artist may not be in the Musicbrainz database, that can't be guaranteed. (This creates a requirement issue, should Kodi accept or reject these tags?) The presence of "musicbrainz artist ID" Key without an "artists" Key might be considered a tagging error.
Given that Picard has not always added "artists" key, and that not all MB fetching scripts in other tag tools populate "artists" I suspect that there will be plenty of tagged files out there with "musicbrainz artist ID"s but "artists" missing completely. Should Kodi reject 1-to-1 mismatches, but still accept total absence of "artists" for legacy reasons?

scott967 Wrote: Note that in the musicbrainz scheme, each song (work) can only have a single "artist credit" and hence, for musicbrainz tags there can only be a single "artist" Key:value pair. Kodi would need to define what to do in the case where multiple "artist" Key:value pairs are found (assuming for example that existence of the "artists" key is interpreted to mean that musicbrainz semantics are being used).

Yes, we need to note that although "artist" is a single string value in ID3 it can be multiple in Vorbis/Xiph comments so no guarentee there is only one of them. I assume that is what you mean? The single value often contains the names of multiple performers (separated by " / ") doesn't it.

scott967 Wrote: Because Musicbrainz has changed the meaning of "artist" Key they needed a new Key to replace it, which they call "artists".
Shame they didn't call is "MusicbrainzArtists", I'm sure that in the past "artists" has been used as an alternative to "artist" so again legacy tagged files could throw up a problem.

scott967 Wrote: For classical things are complex because I don't think there is any real standard. "title" can be ambiguous but usually a composition is uniquely defined by a composer + catalog pair. "artist" of course is not that useful. ID3 has defined something called "involved people list" which is a collection of values in a role:name format.

Although there is a lack of consistency for recording composition title, I for one would be happy to make my library consistent within itself, if only Kodi could make use of the data. We need to start somewhere, and tagging of classical music is still a largely manual exercise (with support from internet resources) anyway.

With the patch Evilhamster proposes the "artist" tag becomes just a track label, this suits classical music too as the list of performers, composer etc. (currently stuffed into artist) becomes too long. The "albumartist" is also similarly problematic.

The ID3 "involved people list" could be included, along with TCOM and TPE3, hence my thoughts that role could be usefully added to Kodi's song_artist and album_artist tables and used when filtering or sorting artists.
Reply
#26
First of all, big thanks to Dave for picking up development for the music library. This is great news and (from what I can tell from this thread), there are actually quite a few more folks excited about it. It may also just be chicken&egg phenomenon and - once the library is improved - the group of Kodi music users may increase.

Let me summarize a few things that I see require development and invite others to comment and obviously Dave to judge what he is passionate about and has time to cover.

1) Support for classical music
* I know Dave is passionate about, which is great :-)
* I am actually quite happy how it is currently done, so personally see less need. But of course also happy to see whatever improvement possible and happy to test

2) Multi-artist tag (artist / artists and albumartist / albumartists)
* I know this is a huge point of debate, but hope we can find some alignment in this thread. The current tagging process in Picard is "artists 1 & artist 2" (artist) and "artist 1 / artists 2" (artists). I know that some people believe that the Picard treatment of "artist" is not ID3 compliant, but this way has developed into common practice (Picard, Itunes, MP3Tag, Mediamonkey), so I hope we can also support this from the Kodi way
* "Artists" tag (when available) is now available in the latest development built, which is great (@Dave, thanks!). It would be great if there is a way that "artist" could still be used for display (i.e., artist view includes artist 1 and artist 2 as taken from "artists"; track view with artist 1 & artist 2 as taken from "artist"
* Would this make sense?

3) Option not to read MBZID tags
* Currently, there is an issue when the artist(s) tag does not match the MBIDartist tag. If there are two MBIDartist IDs and just one artist, it shows the artist twice. Typically, artist and MBIDartist should match, so this is a rare issue, but with manual over-writes of artist tags, this can happen
* My work-around now is to $unset the MBIDs in Picard when tagging, but this is not preferred. My suggestion would be either not to rely on MBID for Kodi or give an option not to read from it

4) Support to read artists / albumartists tag from M4A files
* There is currently some issue how Picard / Mutagen tags M4A files, which is not supported by Kodi
* I saw some development, so this may already be addressed?

5) Support of "albumartists" tag
* Artists is now supported, would also love to see support for albumartists tag (the one with "s")

6) Library analogue to video library
* The video library got an update that you no longer have to switch between library mode. No clue how much work it is (and whether even feasible) to adapt same way with music


Thanks in advance. Unfortunately, not capable of coding, but happy to help with testing or brainstorming about use cases. Thanks!!!
Server: Asus Sabertooth Z77 | Intel Core i5 3.4 GHz | 16 GB DDR3 | 128 GB SSD, 82 TB (9 x 6 TB, 7 x 4 TB)
HTPC 1: Raspberry Pi 2 | HTPC 2: Raspberry Pi 2 | HTPC 3: Raspberry Pi
Reply
#27
Add me to the list Wink I'm a team member and run TheAudioDB site which is where the extra metadata comes from.

I'm not involved in the Kodi coding but feel free to ask any questions as I follow the Github music PR's and helped with the original Musicbrainz support.
Reply
#28
Steve you should be thanking Evilhamster, not me, for the work that has been done so far on the ARTISTS and ALBUMARTISTS tag. If we don't clutter up the Github/PR lists with additional chatter I hope that his work will get merged sometime soon.

I have a tiny PR in there too #7938 that reinstates the appearence of "Various artists" in the list of album artists. Zag as a team member with a music interest perhaps you could give it a nudge towards merge.
Reply
#29
Looks like we have all the Kodi music fans on this thread now. Wasn't aware that you (Zag) are the master behind TheAudioDB, very cool initiative and a brilliant source for music art and beyond. Somwhow thought that it was created by the creator of headphones? That's also you?

Wasn't aware that all the "s" related work was done by evilhamster. So, thanks to him and let's see whether he may join this discussion here as well ;-)

And yes yes, no emails from me on github. Will wait for the merge and then do some testing and report back here on the forum instead...
Server: Asus Sabertooth Z77 | Intel Core i5 3.4 GHz | 16 GB DDR3 | 128 GB SSD, 82 TB (9 x 6 TB, 7 x 4 TB)
HTPC 1: Raspberry Pi 2 | HTPC 2: Raspberry Pi 2 | HTPC 3: Raspberry Pi
Reply
#30
Can I just weigh in with a couple of thoughts:

Firstly on Steve's original problem that started this thread, which he subsequently identified was solved by removing the MBID, this isn't a problem in the first place for those of us using mp3tag - as that doesn't add the MBID to the tags in the first place. I could scan the 2 albums on Isengard with no problem. So. I'm not sure if this is a Picard specific issue, but I'm a little wary of things being changed to fit with Picard that may break set-ups that others of us have using other taggers. I know that's not what people are proposing here, but it should be borne in mind if a significant overhaul of the music set up is proposed.

Secondly, as regards classical music I think many of us tend to have very personal ways of organising our collections. Some people may want their Mozart collection organised by K number, others by soloist or conductor or whoever's on the front of the album cover. So many classical albums are combinations of composers, a Stravinsky concerto with a Dvorak quartet or something. I think it would be really difficult to shoe-horn a specified way of tagging that would satisfy everyone. To me the bigger problem is the limitation on available tags that are imported to Kodi and particularly the inavailability of those tags to create playlists and sort. Seriously, this goes back years and has been resurrected loads of times: http://forum.kodi.tv/showthread.php?tid=10528. If there were greater flexibility in the use of tags within Kodi it wouldn't be necessary to try and get everyone to tag consistently beforehand.

Finally, totally agree with Dave on bringing back Various Artists to the library listing - don't know why that was changed..
Reply
  • 1
  • 2(current)
  • 3
  • 4
  • 5
  • 23

Logout Mark Read Team Forum Stats Members Help
Music Development0