SongKong Jaikoz

SongKong and Jaikoz Music Tagger Community Forum

Support for Lyrion (LMS) tagging profile

#39

That should not happen, I have checked the code

If matches to a MusicBrainz Release then no issue since all artists on a MusicBrainz release have artist ids and we add artist/artists/artistsids and releaseartist/releaseartists/releaseartistids at the same time.

If matches to Discogs no issue we do not overwrite fields if already matched to MusicBrainz, if not already matched to MusicBrainz then when we add artists and releaseartists there is no attempt to match to MusicBrainz artists and add artistids.

If matches to Bandcamp then Bandcamp only supports a single artist, we try to match that artist to MusicBrainz and if match found we add artisid/rteleaseartistid if not we dont, but there is only ever one artist/release artist added. Does not overwrite fields if already matched to MusicBrainz.

If matches to Acoustid Album (which means matching a group of songs by Acoustid that do not link to MusicBrainz and finding common album metadata for all the songs on Acoustid) then Acoutid Albums only support a single albumartist/artist and we therefore we only ever add one artist and possibly one artistid, same for track artists. However, there does seem to be one bug we dont need to modify the artists or albumartists fields in this case although this should not cause you an issue since you don’t use these fields.

Then at save time there is one addtional tidy up where we try and improve the artist data for songs that have not been matched. This makes artist and artists fields consistent and trys to match the artists to MusicBrainz artists. If matches are found it can add artistids, but already it only does this if all artists on song could be matched to MusicBrainz artist

So I’m not aware of any issue, if you see an issue let me know.

#40

Does that mean if I have artist=a;artist=b and Musicbrainz matches the album and track and Musicbrainz for whatever reason only has artist=a or artist=b, then SK will remove the other entry and overwrite it with what MusicBrainz has?

#41

I believe the discrepancies between the artist list and the MBID lists arose in my case, as a result of manual editing (using Jaikoz, but it might equally be done in SongKong manual edit).

Your account suggests that SongKong “Fix Songs” task will always put that right. Would that be a correct understanding?

#42

And now I will find out whether there’s an issue tracker for Lyrion Music Server and submit some reports as there are at least two bugs or fragilities which have arisen from this discussion.

#43

By default yes, when we we match an album to MusicBrainz for any fields that MusicBrainz has data for SongKong will overwrite existing data, but you can modify this with Never modify or add these fields and Only Modify the fields If empty options.

Yes, as long as SongKong actually matches your songs to a MusicBrainz album and you have not configured some fields so they cannot be modified.

#44

Did you manage to do this?

New versionn now available with fixes for some of the Classical issues

#45

I have been testing the 12.2 SongKong release on a variety of albums. Many of the issues I had seems to be fixed, and the new Lyrion profile is working for me.

However there is an anomaly - I think a new one - with one of the albums I have looked at before. “Fix Songs” is detecting an Opera type work and creating GROUPING tags when it shouldn’t - just for one of the two works on the album. I can’t see anything at all which might be responsible for this so I would be grateful if you could take a look. I already submitted the support files for this.

#46

Hmm, I’m wondering - the songs already have MinimServer field set to Concerto for Violin and Orchestra no. 1 in D major, op. 35 and I wonder if that had confused SongKong.

Can you try running MetaGrater task and delete the following fields

  • MinimServer Group
  • Work
  • MB Work
  • Grouping

Then rerun Fix Songs and see if that resolves it.

#47

No, still the same behaviour. Support files sent.

#48

Okay, are you able to send me the files for testing that is going to be the easiest way to solvce it.

Did you manage to raise those issues on the Lyrion site?

#49

Okay its a bug, the check for multi level (Opera) works is not robust, raised issue

#50

Hi, now fixed and available

#51

Thank you. I have tested this and the “opera” works detection now appears to be functioning correctly. I appreciate the quick bugfix, There’s still an issue with artist names being rendered in Russian/Cyrillic script which I have posted in that other thread.

Regarding the Lyrion tagging issues, I have been postponing action on this until (a) Lyrion released version 9.1 - no point in reporting against an old release and (b) until I understood the issue well enough to create a sensible bug report, which required further testing. But at least I think I now understand the issue. There are two relevant variables:
a) Whether LMS treats the album as a compilation. This can be forced by the IS_COMPILATION tag should its default detection algorithm make a mistake in any case.
b) Whether the ALBUMARTIST tags are set or not. What I get from testing is

(“MA;NM” => “Martha Argerich;;;Nathan Milstein”; TRACK_ARTIST is what LMS derives from of either the ARTIST or ALBUMARTIST tags for its internal representation)

  1. IS_COMPILATION=F; ALBUM_ARTIST=MA;NM
    a. Both NM and MA displayed on both works as track artists
    in work/artist/composer listing. TRACK_ARTIST=just the correct one.
    b. All soloists, conductors, composer displayed under Album.

  2. IS_COMPILATION=T; ALBUM_ARTIST=MA;NM
    a. Both NM and MA displayed on both works as track artists
    in work/artist/composer listing. TRACK_ARTIST=both soloists+orchestras
    b. Just MA displayed under Album.

  3. IS_COMPILATION=T; ALBUM_ARTIST=null
    a. Only correct soloist displayed on either work as track artist
    in work/artist/composer listing. ARTIST=both soloists+orchestras
    b. “Various Artists” displayed under Album.

  4. IS_COMPILATION=F; ALBUM_ARTIST=null
    a. Only correct soloist displayed on either work as track artist
    in work/artist/composer listing. ARTIST=both soloists+orchestras
    b. “Various Artists” displayed under Album.

So in case (2) - a compilation with multiple ALBUMARTIST’s LMS just displays only the first ALBUMARTIST as in the above screenshot. If not flagged as a compilation [case (1)] the artist list gathered from other tags is used, which is a perfectly viable option. But in cases (3) and (4) with no ALBUMARTIST specified the album is displayed, sensibly, as “Various Artists”. Only case (2) strikes me as being suboptimal, though now I have the behaviour mapped it is easily avoidable.

I think this is a consequence of the failure of the popular music tagging schema of ARTIST/ALBUMARTIST to capture the finer distinctions and roles. Some posters to the LMS forums declare that they use neither for classical albums. I would not go that far, as ALBUMARTIST is often, but not always useful. The MA/NM/Tchaikovsky album is actually a good exemplar of a great many classical albums in my collection. We may quibble about whether or not to call them “Compilations”, but either way, there is no satisfactory ALBUMARTIST tag and it all works much better (with LMS at least) to omit this tag entirely for these. I would be curious to know whether other music servers really need this tag, and how they cope in its absence. I may have to set something up and explore…

#52

The obvious risk of having no Album Artist field is how do you distinguish between two albums with the same name.

The Lyrion logic is unclear to me,I don’t see why the IsComplilation field should effect how album artist and artist is are used, for a start a single artist best of album can be considered a compilation.

#53

Within the classical domain, we would distinguish by composer, performer, orchestra or conductor. Album names are not unique - I wonder how man are simply called " Symphonies" for example.

One thing that could be relied on with well-tagged MusicBrainz classical at least is that any Album Artists will also appear additionally in the more specific fields of conductor, performer, orchestra or composer.

Mind you, completely disambiguating albums will be a near impossiple task. For example, von Karajan recorded the entire set of Beethoven symphonies four times with the Berlin Philharmonic over his career and these have probably appeared on hundreds of separate releases! So even all artists + recording year would be insufficient to uniquely identify the album. Rather belatedly I understand why MusicBrainz insist on a perfect match for cover art, as this may be the best shot at it!

I agree that compilations can either be same artist or various artists, and also agree that this can be confusing. I would suggest that a rigorous definition of a compilation would be simply that all tracks/works appeared previously and separately. Actually I have seen LMS developers treat “Compilations” and “Various Artist” albums as separate concepts, but agree with you that the way this is handled, or at least documented is unclear.

#54

Yes you may do that, but what does Lyrion do. If you go to an Albums view will two albums with no value for Album Artist and same value of Album does it merge both albums into one album ? - I think that is what MinimServer would do.

#55

I suspect not. According to the tagging documentation at [https://lyrion.org/reference/getting-the-most-out-of-metadata-in-lyrion](https://lyrion.org/reference/getting-the-most-out-of-metadata-in-lyrion it will use MUSICBRAINZ_ALBUM_ID as a UUID.

It definitely uses MUSICBRAINZ_ARTIST_ID/MUSICBRAINZ_ALBUMARTIST_ID as a unique ID for artist naming, hence the importance of keeping multiple-valued artist name tags perfectly synchronized.

(It never actually consults MB - just uses the tags as UUIDs).

But the question warrants experimentation rather than speculation. I will test it.

#56

Sounds like you are probably correct for Lyrion, if both albums have a MusicBrainz Id of course.

But in the general sense when using other software this is an issue.

If Lyrion understand MusicBrainz then they should also understand that an artist being listed as an Album Artist should not mean they are automatically added as a track artist, The Album Artist field should only be used as track artist if the Artist field is empty.

#57

I have established a little more clarity on Lyrion’s treatment of compilations.

  1. It attempts to automatically determine whether an album is a compilation or not by assessing whether all tracks have an ARTIST or ALBUM_ARTIST tagged in common.
  2. The automatic detecttion of a compilation may be overridden in either direction by a COMPILATION tag in the files.
  3. Only tracks within the same directory are considered for this.
  4. Lyrion does not distinguish between a “Various Artists” album and a compilation of previously released recordings by the same artist. So the latter should be handled as “not-a–compilation”, ie the COMPILATION tag should be absent or “0”, and ARTIST or ALBUM_ARTIST tags used.

It’s a shame that there seems to be no generality of tagging scheme strategies across different server software. But hopefully I can address this using the scripter to prune the ALBUM_ARTIST and related tags as long as it can detect a “Various Artists” album.

[Of course this isn’t quite as simple as that - I have an example of an album with one soloist performing with different orchestras and conductors, in which case I need to remove the ARTISTS who are not present in every track, but leave the soloist who is! Does the scripter have hooks to operate on the “Album”, not just individual tracks?]

#58

No, unfortunately not - I can see this might be helpful but cannot quite visualize a sensible way to present this to user.