Artists scraped/grouped/presented differently than XBMC, want old behavior back
#16
Too late for Jarvis now I think, unless a very simple fix can be produced (to turn off reading of MB ID's for example) otherwise you run the risk of causing other regressions as we've all too easily with other changes to do music in this release cycle.
Reply
#17
(2016-01-15, 12:07)jjd-uk Wrote: Too late for Jarvis now I think, unless a very simple fix can be produced (to turn off reading of MB ID's for example) otherwise you run the risk of causing other regressions as we've all too easily with other changes to do music in this release cycle.

Fair enough, I won't put the effort in then, but what I had in mind was'n't complex. I thought that we simply test if the numbers of names and MB IDs match, and if not then check for "AAA feat. BBB" and extract the artists as if they were in and ARTISTS tag. It would fix many of the user issues.

You are right there is some risk involved, but I was almost brave enough to try Smile
Reply
#18
I have no idea how kodi handles the stuff internally(apart from what I read here now) nor do I know how those MB IDs work exactly BUT I always expected the listing/grouping of e.g. Artists to be decided by either picking the Artist (TPE1 for id3) or Album Artist (TPE2 for id3)

Staying with the initial 2pac example you'd have (for each individual track of one album) the Artist set to "2pac featuring ThisGuy" while Album Artist is set to "2pac"
Than you'd have a clean listing (as long as your tags are properly maintained)

For Elector-Mixes (e.g. Dream Dance etc.) you'd have the Artist set to whatever the artist is and the Album Artist to "Various Artists". Therefore
you'd have a clean listing again.

I've no idea how other formats (like voribs etc.) work but I always thought that "Artist" and "Album Artist" are a pretty standard thing ^^
(please correct me if I'm wrong)
Reply
#19
I think mainly what has happened is many users are relying on the Musicbrainz database as the "best" source of music meta-data. Musicbrainz has changed some meanings of the entities in their database. In particular, Musicbrainz now defines something called "artist credit" and "album artist credit":

"Artist credits indicate who is the main credited artist (or artists) for releases, release groups, tracks and recordings, and how they are credited. They consist of artists, with (optionally) their names as credited in the specific release, track, etc., and join phrases between them."

Key thing is that an artist credit is tied to a "release" and to one or more "artists".

The problem is how to capture that in the actual meta-data tags. At least as implemented in Musicbrainz Picard, they use TPE1 (ID3) or ARTIST (vorbis comment, APE, etc) as the artist credit. I guess in theory a tag reader could parse the artist credit and extract the performing artists out of it. But because there are so many stylistic differences in how artist credits are displayed on a medium, that's kind of problematic. So the solution that Musicbrainz has implemented in Picard is to create a new tag (in ID3, using the TXXX= tag frame which is extensible) that has the key-name ARTISTS (with the S). In Musicbrainz, the values in ARTISTS key are entries in the database for the artist(s).

Now the problem for Kodi, is that some users may use the Musicbrainz definitions, but others use the conventional definitions. (Still others may use something else, for example for classical music.) And of course there could be a mix of music if the user doesn't run everything through a tagging software. So how does Kodi "decide" which tag definitions are in use in any music file? The answer is to look for the existence of Musicbrainz IDs for artist or album artist. The assumption is that if Musicbrainz ID tags are in the file tags, then the Musicbrainz database semantics are used. In this case the ARTIST/TPE1 tag frame is stored as a string value that is displayed as the song artist or album artist in Kodi music views. The ARTISTS/TXXX=ARTISTS tag frame (along with Musicbrainz IDs) is used to relate songs and albums to artists (and to add new artists to the music database).

scott s.
.
maintainer of skin  Aeon MQ5 mods for post-Gotham Kodi releases:
Matrix see: Aeon MQ5 Mod Matrix release thread
Nexus see: Aeon MQ5 Mod Nexus release thread
Aeon MQ 5 skin and addon repo 11.1.0
Reply
#20
OK I have raised a PR against Krypton that will alleviate some of the problem especially when for files without ARTISTS or ALUMARTISTS tags. https://github.com/xbmc/xbmc/pull/8904

My thought is that if Kodi finds it has a mis-match in musicbrainz artist ids to artist names than it looks to see if the name it has is "artist1 feat. artist2" or "compser; conductor, orchestra, soloist" - both standard output from Picard - and trys to match them up to the musicbrainz ids. It also logs the mis-mtach in the debug log, not easy for the user to see, but at least not totally quiet.

Perhaps you will check this out Scott or JJD? It will save the OP doing the server hack he proposes when he gets to that version of Kodi.
Reply
#21
(2016-01-18, 17:41)DaveBlake Wrote: OK I have raised a PR against Krypton that will alleviate some of the problem especially when for files without ARTISTS or ALUMARTISTS tags. https://github.com/xbmc/xbmc/pull/8904

My thought is that if Kodi finds it has a mis-match in musicbrainz artist ids to artist names than it looks to see if the name it has is "artist1 feat. artist2" or "compser; conductor, orchestra, soloist" - both standard output from Picard - and trys to match them up to the musicbrainz ids. It also logs the mis-mtach in the debug log, not easy for the user to see, but at least not totally quiet.

Perhaps you will check this out Scott or JJD? It will save the OP doing the server hack he proposes when he gets to that version of Kodi.

I'm going to have to take a closer look. I like the idea of adding some logging, tough I don't know what Kodi policy is on adding stuff to the logs. I'm not so sure about trying to parse the artist tag. I do think we have to accept that not every artist will have an MBID assigned, and have a way to deal with the case. IIUC there currently are 3 legal ways to tag artists:

1. Use ARTIST tag without MBID. Artist(s) are extracted from the single tag using Kodi separator semantics

2. Use ARTIST tag with MBID. Artist(s) are extracted from the single tag using Kodi separator semantics and then MBID is applied in order. Mismatch in sizeof could be logged, but legal. All Artist(s) are kept regardless.

3. Use ARTIST tag with MBID and ARTISTS tag. Artist tag is used just as a display string. Artist(s) are extracted from the ARTISTS tag using Kodi separator semantics. Mismatch in sizeof ARTISTS and MBID is logged and treated as an error.


BTW I ran my whole library through Kodi 16 B5 and the results were really good. Every problem I found so far was due to tag errors, not Kodi. I do have some question about how to properly clean up the library after fixing tags, but need to look at it more closely.

scott s.
.
maintainer of skin  Aeon MQ5 mods for post-Gotham Kodi releases:
Matrix see: Aeon MQ5 Mod Matrix release thread
Nexus see: Aeon MQ5 Mod Nexus release thread
Aeon MQ 5 skin and addon repo 11.1.0
Reply
#22
Scott, let's see if I can convince you that a little bit of limited artist tag parsing is worthwhile.

The current situation is as you describe, without the logging or raising an error. And I can keep telling users to sort out their tagging, but they find that hard and see it as Kodi's fault. It is made worse by the fact that Kodi does not handle some of the default tagging produced by Picard. Now I do not advocate we are tagging software specific, but equally from a user perspective they tag with Picard (as we often suggest), other players work fine but because Kodi is "musicbrainz id enabled" it messes up, then Kodi just looks silly.

Picard outputs as standard some artist tags like this "Artist1 feat. Artist2" with 2 mb ids or "Composer; Conductor, Orchestra, Soloist" with 4 mb ids (and variations on that). There are also v2.3 files with ARTISTS = artist1/artist2 (no space).

I think the policy should be that if you have musicbrainz tags present then Kodi uses ARTISTS tag, then artist tag to name the artist, and if that fails it trys the above layouts to see if it can repair the situation. Fundamentally if a file contains mb ids then all the artists in that song, not more not less, need to have an mb id.

What is to lose by this parsing? I know that you have the need for artist alias name support, and that is something I want to work on, but I don't think this parsing should have bad results with the way your files are currently tagged.

So do take a closer look and tell me what are your reservations are if any.

Good news about the 16 B5 testing, had a look at Krypton yet? Still pre-alpha but major music tag additions, love you to take it for a spin.
Reply
#23
(2016-01-19, 15:18)DaveBlake Wrote: Scott, let's see if I can convince you that a little bit of limited artist tag parsing is worthwhile.

The current situation is as you describe, without the logging or raising an error. And I can keep telling users to sort out their tagging, but they find that hard and see it as Kodi's fault. It is made worse by the fact that Kodi does not handle some of the default tagging produced by Picard. Now I do not advocate we are tagging software specific, but equally from a user perspective they tag with Picard (as we often suggest), other players work fine but because Kodi is "musicbrainz id enabled" it messes up, then Kodi just looks silly.

Picard outputs as standard some artist tags like this "Artist1 feat. Artist2" with 2 mb ids or "Composer; Conductor, Orchestra, Soloist" with 4 mb ids (and variations on that). There are also v2.3 files with ARTISTS = artist1/artist2 (no space).

I think the policy should be that if you have musicbrainz tags present then Kodi uses ARTISTS tag, then artist tag to name the artist, and if that fails it trys the above layouts to see if it can repair the situation. Fundamentally if a file contains mb ids then all the artists in that song, not more not less, need to have an mb id.

What is to lose by this parsing? I know that you have the need for artist alias name support, and that is something I want to work on, but I don't think this parsing should have bad results with the way your files are currently tagged.

So do take a closer look and tell me what are your reservations are if any.

Good news about the 16 B5 testing, had a look at Krypton yet? Still pre-alpha but major music tag additions, love you to take it for a spin.
maintainer of skin  Aeon MQ5 mods for post-Gotham Kodi releases:
Matrix see: Aeon MQ5 Mod Matrix release thread
Nexus see: Aeon MQ5 Mod Nexus release thread
Aeon MQ 5 skin and addon repo 11.1.0
Reply
#24
I have nothing against parsing, just that getting it right seems quite a challenge. It seems like at the end of the day, you have to specify what unicode strings will serve as separators, and users will have to conform to that via their tagging so from a "user effort" POV, it still means work without a "kodi certified" tagger.

For Krypton, I recently got a hopefully solid Jarvis version of my skin mod out, and so far have only gotten as far as to get all the Krypton-compatibility skin changes made (up to current PR status). I just finished looking at all my real music library in 16 B5 with good results so now I can start looking at Krypton.

The one thing I found in Jarvis, is that if I get a wrong artist / MBID pair in the database, the only real way to fix it is to remove the affected files from the source, perform a library update/clean cycle, then replace the fixed files in the source and update again. Probably this has always been the case, but with the new handling of song artist "stuck" MBIDs are more obvious.

scott s.
.
maintainer of skin  Aeon MQ5 mods for post-Gotham Kodi releases:
Matrix see: Aeon MQ5 Mod Matrix release thread
Nexus see: Aeon MQ5 Mod Nexus release thread
Aeon MQ 5 skin and addon repo 11.1.0
Reply
#25
Getting parsing right can be tricky, hence my idea of keeping it simple. I think there can be big users gains for a small code addition.

Good news re your skin. I have added a bunch of info labels in 17 for my artist role work, so there will be plenty to do Smile

Quote:The one thing I found in Jarvis, is that if I get a wrong artist / MBID pair in the database, the only real way to fix it is to remove the affected files from the source, perform a library update/clean cycle, then replace the fixed files in the source and update again. Probably this has always been the case, but with the new handling of song artist "stuck" MBIDs are more obvious.

Yes that is the methodology, and it has always been the case. I think the silent handling of MBID count mis-match has been a real nuisence there. Do you think we should make that different somehow? And if so what? Or is it just a matter of documenting what to do?
Reply
#26
(2016-01-19, 15:18)DaveBlake Wrote: And I can keep telling users to sort out their tagging, but they find that hard and see it as Kodi's fault. It is made worse by the fact that Kodi does not handle some of the default tagging produced by Picard. Now I do not advocate we are tagging software specific, but equally from a user perspective they tag with Picard (as we often suggest), other players work fine but because Kodi is "musicbrainz id enabled" it messes up, then Kodi just looks silly.

Picard outputs as standard some artist tags like this "Artist1 feat. Artist2" with 2 mb ids or "Composer; Conductor, Orchestra, Soloist" with 4 mb ids (and variations on that). There are also v2.3 files with ARTISTS = artist1/artist2 (no space).

For one, it's not that I consider it "Kodi's fault." It's that it's hard, and that's it. It can also require huge changes to procedures we've created/learned over a long time. This is just one example: one of the things I do when I get new music that might contain duplicates is to load the new folder AND the existing "sorted" artist folder into picard. I then save /all/ of them, which creates some files ending in (1), and then I delete *(1).mp3 to kill the dupes. Yes, there are other ways to achieve that, but this one is a habit. It's also only an example. Some things that people (including myself) do are not so easily replaced.

So for you to tell me "change your tags" is easy, but DOING SO is not.

The only, one and only, reason I started using XBMC was that it was relatively universal. I could point it at a folder full of ANY media files and within an hour or so (I have a lot of media) it would all be presented in a uniform, user-friendly manner, regardless of filetype or origin. The current behavior is not universal. Picard provides a rather easy way to make sure files containing ID3 entries of "2pac," "Tupac", and "Tupac Shakur" get forced into the same place, but files tagged automatically with Picard, at least with its default settings, are unusable in Kodi.

This whole discussion seems to be about, "do we get the artist data from the MB tags, or the artist/albumartist tags?" and it seems to me that the entire feature that's currently forced on me is to read the MB data and "automatically" get the correct artist/albumartist data -- but here's the thing: if the file HAS musicbrainz tags, then the user (or somebody) MOST LIKELY ran it through Picard -- and that means at the ARTIST and ALBUMARTIST tags are *also* set by musicbrainz. There is no need for Kodi to redo what picard already did. The act of fetching the artist/albumartist data from the musicbrainz database has already been done.

And going back to that difficulty and user-friendliness thing: suppose a user, who does not have/use picard his/herself, gets ahold of some files with musicbrainz tags, and they are sorted improperly. Your answer is "fix your tags," which they do (or attempt to) by loading the files up in their favorite media player (winamp, itunes, heck Windows Media Player) and attempt to edit the data. Their changes are written to the standard ID3 tags. Kodi continues to ignore them. This user just wants their awesome new user-friendly media center program (Kodi) to do its job, but now the only way for that to happen is to go install and learn yet another not-as-friendly program. (picard, mp3tag, etc)

Are Kodi and MusicBrainz even connected as projects? Cooperating? If Kodi is going to ignore the industry standard ID3 tags in favor of data provided by another project/organization, what is in place to ensure there isn't a complete disaster if the musicbrainz people suddenly decide to change something? It seems to me that your assertion throughout all of this is "it's picard's fault" (you surely aren't blaming *ME* personally for running an automated program and expecting it to do what it professes to do...) so if we somehow managed to beat picard into submission, how do you ensure that a newer version of picard doesn't start "misbehaving" in a different way next week?

Your program is one I wish to use, for what it's always been good at: providing a user-friendly control interface for an otherwise-unwieldy media library. Being able to manage that library en masse is critical, and picard is the best tool available for that. The data you insist upon fetching from musicbrainz tags is already present in an industry-standard spot that is supported (and used) by literally every single other media-related program out there. I (and other users, apparently) simply want the option for Kodi to present the same data I see in the file everywhere else, and it seems the only reason I'm being denied this option is because somebody on the dev team thought forced MB integration would be a good idea and refuses to let go of that.

Adding a "feature" that isn't necessary and doesn't work, then forcing users to use it anyway... that sounds a lot like Microsoft.
Reply
#27
^I think emolatur makes a lot of sense. Let the user choose Picard or whatever other means to update the standard tags, and use the standard tags for KODI sorting/display/playback. I do understand how MBIDs can assist scraping, but maybe it would be best to give up on that benefit for greater simplicity and predictability.
Reply
#28
I understand your frustration, and I am working to aliviate it. There is no blame to be alloted to any party, Kodi, Picard, you or me.

But when I first read your post I felt quite irritated. There is no "forcing", Kodi does not ignore standard ID3 tags, and processing musicbrainz IDs (extracted from the ID3 tag along with everything else) are a feature that is effective and useful for many people. It sounds awefully like you do feel it is Kodi's fault! But there are things that can be done to improve the user (your) experience, make Kodi more flexible and robust, and I will try to do those.

Best I say no more and instead spend my time improving Kodi and making this issue vanish.
Reply
#29
Yep I've often wondered if the problem is in the complexity of trying to resolve the conflicts between tags and MB ID's, and that we might be better off simplifying things by allowing the user to specify where they want the metadata to come from.

For example we could allow user to specify where they want to load data from when adding the Source, so work flow would be something like:

1) Add Source
2) Select the folder to be used
3) Select metadata provider (ID3 tags, Musicbrainz, etc)
4) Select scraper for additional information such are artwork from online sources (current artist/album scrapers)

Then depending on what's selected in 3) then a different set of rules could be applied.
Reply
#30
(2016-01-21, 18:10)jjd-uk Wrote: Yep I've often wondered if the problem is in the complexity of trying to resolve the conflicts between tags and MB ID's, and that we might be better off simplifying things by allowing the user to specify where they want the metadata to come from.

For example we could allow user to specify where they want to load data from when adding the Source, so work flow would be something like:

1) Add Source
2) Select the folder to be used
3) Select metadata provider (ID3 tags, Musicbrainz, etc)
4) Select scraper for additional information such are artwork from online sources (current artist/album scrapers)

Then depending on what's selected in 3) then a different set of rules could be applied.

Maybe the best place to choose how MBID tags are used would be in the scraper settings? Then there would be future flexibility with different scraper choices.
Reply

Logout Mark Read Team Forum Stats Members Help
Artists scraped/grouped/presented differently than XBMC, want old behavior back0