Running “Fix Songs” on
Beethoven: Moonlight Sonata, Pathétique Sonata, Appassionata Sonata
results in adding CONDUCTOR tags for no reason I can discern. There is certainly no mention of a conductor in the MB entry.
Songkong adds "conductor" tags where none in MB
Hi, okay the logic goes like this:
At track level if release is identified as a Classical release AND no one has been identified as a Conductor on MusicBrainz then for if the track artist is listed in our Classical Conductor List then give them role conductor.
This is done to try an improve the metadata for classical releases with poor metadata. Unfortunely in this case because Daniel Barenboim does gets credits not only as pianist but also as conductor on some releases for he is listed in the SongKong Classical Conductor list and that is why he gets added
If you go to Preferences:Classical
And select Edit the Classical Conductor List
And delete the line containing Daniel Barenboim and select OK this will not happen again, and negative consequences will be minimal (SongKong now just has one less metric with which to identify classical releases by Daniel Barenboim). If you manually delete the conductor and conductor sort field (or use MetaGrater) and then rerun Fix Songs they should not get re-added.
This SongKong feature usually works well, but maybe I need to finesse it slightly perhaps by only adding conductors for Classical releases with no conductor roles and no other classical roles defined, or by only allowing Conductor role if the identified person has no other role ?
I had suspected as much. Of course there are many classical musicians who perform an instrument as well as conducting, (In fact I am still working on the tagging of a full box set of all the Mozart piano concertos by Barenboim. In those he is both conductor and pianist at the same time.). And when you take composing into account, there will be many cases where, for example Benjamin Britten or karl Jenjins are both conductor and composer.
I would be inclined to restrict this fix to cases where there is also a named orchestra or choir to be conducted.
There is a second problem/issue with this same album. SK gets confused about what is the “Work”, choosing the work as
-
Two Piano Sonatas, op. 27
not the intended - Sonata for Piano no. 14 in C‐sharp minor, op. 27 no. 2 “Moonlight”
This actually happens for several releases with different performers, so clearly there’s some heuristic logic which is choosing to match to the “overall work” (ie the Two Sonatas) rather than the individual sonatas. But I can’t figure out exactly what is triggering this.
So performing on a track as an instrumentalist doesnt prevent being conductor at same time then making my only allowing Conductor role if the identified person has no other role idea invalid, I will consider your idea further.
So accoridng MusicBrainz Two Piano Sonatas op.27 comprises the two two works on this album, therefore this is a multilevel work like an Opera.
So the Opera format comes into play which you have set to Roon (Section/Work), so the work you are looking for is stored in field Section and the overall Work is stored in Work
But nobody familiar with classical music would ever think of it that way. The two sonatas were published together as Op. 27, but are not performed together.
The concept of a “work” is of a single, or a set of movements performed together and in sequence. A sonata is pretty much always a work, as are a symphony, concerto, suite, ballet, oratorio or opera. It is the subdivision into “Acts”, “Parts” etc which mark out ballets, operas etc. But I’m not sure how or even whether Musicbrainz encodes that information at all. A tricky one. Even operas are sometimes part of a collection, eg Tosca is
part of: Giacomo Puccini: Catalogue of the Works (“SC”) (number: SC 69) (order: 7)
Perhaps the way to decide is from the MB “Work Type”, which has a restricted set of possible values. Ballet, Opera, Oratorio, Mass, Requiem are clearly multi-level “Opera”-style works while symphony, concerto, suite are not. It should be fairly straightforward to partition the list.
So in this case you dont want Two Piano Sonatas op.27 stored anywhere?
In your Puccino example you show a relationship between a *catague and a work, we currently ignore catalogues. But in the original example it is listed as a work so the relationship is between a work and a work that is why we show it. If we restricted to particular work types then there will bound to be cases where no work type even though there is a multilevel work is correctly set preventing the overall work.being set. Also you are coming at this very much from a Classical pov, but multilevel works are not restricted to classical music.
So in this case you dont want Two Piano Sonatas op.27 stored anywhere?
That’s correct. In an physical album Two Piano Sonatas op.27 would only show up in the booklet (or LP cover) notes if at all.
If we restricted to particular work types then there will bound to be cases where no work type even though there is a multilevel work is correctly set preventing the overall work.being set.
Yes, but that can be attributed to incomplete data in MB - and rectified at that level.
My suggestion for an algorithm is to follow the chain of MB “is part of” links upwards from the track recording until you reach an entity on one of a list of classical “top level” work types - opera, symphony, sonata, mass, overture, suite etc, and terminate the search there if you find one.
If that search fails, then other criteria or algorithms could be invoked, exactly as they are now. This would not interfere in any way with non-classical multilevel works (though I am struggling to think of good examples).
Incomplete data is always an issue with MusicBrainz but we try to fill in the gaps, if we relied on only MusicBrainz data then would not even be able to set the is classical flag since that is not data provided by MusicBrainz . Note most SongKong customers do not edit MusicBrainz itself.
You idea at stopping for certain work types may work but what I want to explore is what type should this Moonlight Sonatas work actually be since it currently has no Work Type. Or should it not actually be a work but something else such as a collection or series - in which case would the issue be fixed by changing the MusicBrainz data?
Looking at
Musicbrainz -Moonlight sonata shows Work type: sonata (upper right), which is one of the top level work types. Do you see something different?
(It also shows, by the way, part of: * Two piano sonatas, op. 27 (part of collection)*. The attribute part of collection is another flag that we are at the level of a classical “work”. By contrast Tosca act I shows neither of these flags.
That is an untyped work, whose parts (the sonatas) are “part of a collection”, implying that it is a collection. It seems to be a lacuna in MB’s types that there appears to be no explicit “collection” type.
This is exactly the level for which no metadata tags are needed, as it is irrelevant for player software and music library organization. That level of information is of relevance only to music historians and cataloguers. But it does illustrate how Opus numbers (assignes by the compser) are unreliable data for work identification purposes!
Okay Two Piano Sonatas, op. 27 has been added as a Work and the two actual Works have a part of relationship with with the addtional part of collection attribute enabled
In MusicBrainz as well as Works they also have Series, and Series can have type such as Catalogue. So Two Piano Sonatas, op. 27 is part of Works of Ludwig van Beethoven by opus number, and this is a collection of type Catalogue which is a subtype of Work Series
I was wondering if Two Piano Sonatas, op. 27 should be a series instead of a work but since it has the Opus number I guess it needs to be a Work.
So i think that simply not including works that have part of collection attribute set (and possibly not including number, not sure what that attribute is for) would work without causing issues for works that dont fit into your traditional classical work type categories.
However, currently we don’t make use of the attribute info and Albunack does not provide it so to fix this will have to make some changes to Albunack rather than SongKong, raised issue.
Thank you for your response. This seems to be just what is needed.
Ig you look at the pull-down menu for “Type” on that edit page, there are just 27 possibilities. Most or all of the classically-relevant subset of these are exactly what ought to be rendered as a “Work” for player purposes. As the MB guidelines are explicit that a “movement” should not have a work type, so a very good criterion for a top-level work will be “any non-null work type”, which might be more robust than the “part of a collection” criterion.
I am aware that I seem to be creating a fair bit of work for you, but hopefully the result will be worth it for a wider userbase of classical music listeners.
I looked at this again, I only actually call this if have single track artist for track artist credit, and first we try and match to a composer if that fails we try to match to a conductor. Since for classical the track artist (not the recording artist) should be set to composer, and if not we would expect to see multiple artists if there was a conductor and a orchestra. So if only have a single artist little point assuming this is conductor so I am going to remove the code, raised issue.
Fixed in 12.2