Still important problems in build 234 with COMPOSITION handling

[Andre_Gosselin]

Release notes for build 234 clearly say (at least in my comprehension) that multi-part compositions are fully user-definable by setting COMPOSITION(WORK)/MOVEMENT(PART) tags inside tracks. Unfortunately, I still have serious problems with this announced feature.

As an example, I will take Mahler Symphony No.1 by Haitink on Philips (rec. 1987, rel. 1988)

) :

Without any COMPOSITIOB/MOVEMENT tags, the album shows as follows once identified :

Take note on this screenshot of the composition title, with (“Titan”) at the end,especially the bracketing double quotes.

To test what was announced in the release notes, I went to Mp3tag and entered the following COMPOSITION/MOVEMENT tag values for the four album tracks :

Now Roon displays album contents as follows :

Values of the MOVEMENT tags are correctly shown,but certainly not the value of the COMPOSITION tag, as we can easily see that the (“Titan”) suffix is altogether missing at the right of the composition name. The full composition name is however clearly shown with (“Titan”) at the right when we go to View File info > File tags :

I repeated the experiment, this time moving the (“Titan”) substring to the left inside the COMPOSITION tag value, after “Symphony No.1” . I set In Mp3tag :

Now I get this in Roon :

Note that substring (Titan) nows shows after Symphony No.1, but the bracketing double quotes are missing. View File info > File Tags shows that the COMPOSITION tag value is there, but has not been fully honoured in Roon display :

Finally, if we activate the composition editor we get for the first example above :

and for the second one :

In both cases, Roon declares that “Roon data is being used because your file does not have this data” whereas I think we are in the opposite situation because the composition title (even if only partially honoured in Roon displays), comes from the file metadata and not from Roon database.

Those examples are the easiest I could come up with.I have cases where Roon will simply refuse to honour the COMPOSITION tag values applied to tracks, always sticking to the original “canonical” work names, altough I note that the MOVEMENT tags are always correctly handled.

All the above results are carefully presented after numerous attempts a identifying/unidentifying the albums, and checking that preference has been given to “File” metadata.

I may completely miss something important here. If so, please tell me. But my understanding is that if the COMPOSITION tag says that the composition should be named “xyz something” and I requested that preference be given to my choice of composition titles, then this is what Roon should use, even if this is not “politically” correct and does not agree with the Rovi/Tivo/AllMusic “canonical” names.

I appreciate the immense value of the new Roon release, but I fear that Roon is still applying some sort of undocumented wizardry behind the curtains. I fully understand that many (most?) users who do not want to invest hundreds of hours grooming their metadata prefer that. But there are exceptions, and I would not like to apologize for being among those.

Please rest assured that I greatly appreciate the work done by the Roon team.

Regards

[vova]

Hey @Andre_Gosselin,

Thanks for the report. We are investigating the issue. We’ll let you know how the progress goes.

[mike (Mike Fass)]

Hey @Andre_Gosselin – thanks for the feedback and question. The behavior here can be bit confusing, so I want to give you a little background on how Roon’s handles compositions and why.

The recent changes were focused on giving people more flexibility with regards to multi-part grouping, so users would have more control of which parts were included within a given multi-part work.

The new implementation expects that users hoping for more control of composition grouping will have consistent tags for the composer, composition, and movement/work names, within a given album. The new controls will allow those tags to drive the grouping of tracks on that album into compositions.

So, while the new controls allow for file tags to drive composition grouping, they don’t take precedence over some of the larger goals of Roon’s Composition browsing, namely that all performances of a given composition are linked to each other, and to additional performances of that work in the wider world (ie TIDAL).

We also don’t assume that just because composition tags within an album are consistent that file tags referencing that particular composition will always be consistent across your library. Roon is still going to try to correct inconsistencies and link up all the performances of that composition in your library. Roon can prefer text from your file tags for text-based fields like track names, but compositions are more like performers, in that many features in Roon can only really work when they are modeled consistently in the database.

So, a few things are happening in your screenshots above: first, because the composition tag doesn’t include a catalog number and doesn’t match the “canonical” composition names we get from our providers, Roon is not able to match the composition tags to our metadata. You can see in the first screenshot that Roon has found 5 local performances and 85 performances on TIDAL of the Mahler composition. In the later screenshot, that link has been lost.

When Roon isn’t able to directly identify a composition, the composition name is normalized as it’s added to the database as a fallback attempt to match it up to Roon’s metadata. This is why your composition name isn’t coming through exactly as it appears in your tags. I think if your file tags are closer to what Roon is looking for, or include a catalog number, you’ll be able to control the grouping and preserve the link.

None of this is to say that you can’t edit the composition name in Roon. Like performers and composers, compositions in Roon are richly modeled objects, so editing a text string in some files isn’t really how you want to rename it in Roon – you’ll want to edit the composition in Roon directly, using the editing functionality.

Hope that helps!

[Andre_Gosselin]

@mike
Your answer sure helps a lot! In fact, it is immensely helpful in helping me, and others I am sure, to clearly understand how Roon proceeds to identify compositions. I would suggest that your explanations be included in bold in the Roon knowledge base.

If you let me rephrase your comments in a parlance I am used to after having spent many years designing relational database models, I would say :
1- When identifying a group of tracks associated with a common WORK/COMPOSITION tag value, Roon works very hard to identify an entry somewhere inside its data providers databases (Rovi eg.) identifying this work. This is what is usually called a key or id in database terminology.
2- When such a key is found, Roon will forever stick with it, and all other performances of this work inside your library will be linked to the same key. This is because of integrity constraints : you cannot have two performances of the same work linked to two different ids. Two different ids mean two different works. In other words, if you have more than one performance of the same work, they will all be identified similarly.
3. The name displayed by default by Roon for a work identified by such a key (the so-called canonical name) will be the one linked to this key inside the provider database (likely contained in a column inside a table).
4. No matter the details you change inside the WORK/COMPOSITION tag, this cannot affect the default work name displayed for this work. The WORK/COMPOSITION tag only helps to find the id, but the data provider fully controls the contents of the name linked to this id.
5. You can however locally change the name associated with a work id by going to the composition editor,and typing a value inside the name edit box. All performances of this work will be changed accordingly.

I personally spent many hours trying to fix the work name assigned by Roon to all my instances of Dvorak’s 9th Symphony :

Symphony No. 9 in E minor (“From the New World”), B. 178 (Op. 95) (first published as No. 5)

I just cannot stand this silly (first published as No. 5) tacked to the end of the work name (even my gand-grandfather could not remember the day when the 9th was numberd as the 5th). No matter what I could set in the WORK/COMPOSITION tag, the work name reported by Roon would remain the same.The only logical explanation seemed that Roon was assigning a unique id to all instances, and getting the name for this id from somewhere else, probably the data provider database over which I have no control. The post by @mike clearly confirms my guess.

As a final note, I really think it would help if the source and value of the key/id assigned by Roon to composition would be reported in the composition editor window. For one, this would make clear where the composition name comes from. Second, it would surely help precisely reporting problems about suspected bad work identifications.

Regards,

[Fernando_Pereira]

I too feel that some of the Rovi canonical names are a bit silly. The ideal solution for this would be to support a “library local” display name for a composition. The canonical (Rovi?) name would still be available for database reconciliation, but users could provide their favored composition display name.

[joel]

@Andre_Gosselin Andre, you pretty much nailed it in your last post. We do need to think about supportability here.

@Fernando_Pereira Fernando, with the new metadata system we’re working on, we will have flexibility to depart from Rovi where we wish to do so.

[Fernando_Pereira]

Fernando, with the new metadata system we’re working on, we will have flexibility to depart from Rovi where we wish to do so.

Great news, thank you!

[Ludwig (Ludwig van Marbach)]

I just cannot stand this silly (first published as No. 5) tacked to the end of the work name (even my gand-grandfather could not remember the day when the 9th was numberd as the 5th). No matter what I could set in the WORK/COMPOSITION tag, the work name reported by Roon would remain the same.

This back-end magic regarding work titles is hugely useful generally, I have to say. That it matches up our tags to their database is really cool. The problem only comes when we don’t agree with the database.

You can edit the canonic work name. That solves the problems you are concerned about, as far as I can tell (you can remove the “first published as No. 5”, for example). My only question is what happens if you then subsequently import a further performance of the work. I haven’t tried this because my collection is already to a large proportion imported, and so I am not doing much importing right now (although I am editing composition titles from time to time).

Let me know what I am missing.

[Ludwig (Ludwig van Marbach)]

@vova says he’s looking into this, but I’m not sure exactly which part, or all of it, or what.

Note that substring (Titan) nows shows after Symphony No.1, but the bracketing double quotes are missing. View File info > File Tags shows that the COMPOSITION tag value is there, but has not been fully honoured in Roon display

I’ve not seen this, but I’ve only started scraping the surface of WORK/PART. It looks decidedly fishy. I don’t see why Roon would knowingly remove part of your tags like this.

In both cases, Roon declares that “Roon data is being used because your file does not have this data” whereas I think we are in the opposite situation because the composition title (even if only partially honoured in Roon displays), comes from the file metadata and not from Roon database.

I’ve also seen this. It seems to me that some of those screen have the switches set to the exact opposite of what I think Roon is doing. It’s suspicious IMO, but I am not familiar enough with these metadata preference screens to be able to scream “bug” just now…

I fear that Roon is still applying some sort of undocumented wizardry behind the curtains.

I suspect the two specific examples above aren’t just wizardry.

[joel]

I don’t see why Roon would knowingly remove part of your tags like this.

Mike explained why above. Roon makes an attempt to normalize composition titles, in order to help future matching.

[Fernando_Pereira]

Roon makes an attempt to normalize composition titles, in order to help future matching.

I’ve worked on record reconciliation in my day job, this makes a lot of sense to me. Name normalization is as you say critical for robust record matching. But normalized names are often not users expect. That’s why separating display names from normalized names (database keys) used for record matching can be so helpful. For instance, if a user imports an album with a WORK tag “Grand Symphony” and that gets normalized to “Tragic (“Grand”) Symphony Op. 99”, it would be helpful if the display name in the user’s library would still be “Grand Symphony”, even if the underlying work key is “Tragic (“Grand”) Symphony Op. 99” (or a uniquely derived function of that).

[Ludwig (Ludwig van Marbach)]

Name normalization is as you say critical for robust record matching. But normalized names are often not users expect. That’s why separating display names from normalized names (database keys) used for record matching can be so helpful. For instance, if a user imports an album with a WORK tag “Grand Symphony” and that gets normalized to “Tragic (“Grand”) Symphony Op. 99”, it would be helpful if the display name in the user’s library would still be “Grand Symphony”, even if the underlying work key is “Tragic (“Grand”) Symphony Op. 99” (or a uniquely derived function of that).

As I said above, I haven’t actually had a problem with Roon normalising the WORK tag that I thought I told Roon to use instead of its own tags. This is because when I bother to use WORK/PART I make the effort to use the composition name from Allmusic. So my composition names already match the canonical names.

Still @Fernando_Pereira seems to be on to something here. Reading all this makes me very insecure about putting in the hours editing my tags if even forcing Roon to use them results in normalised titles (not necessarily the contents of my tags) being displayed.

I’m also curious (only that) whether removing “Titan” actually helps Roon match the work in the Mahler case from the OP, and if so why.

This all plays into my natural insecurity.

[joel]

But normalized names are often not users expect

No, and this could be unintended.

[Esskay]

But normalized names are often not users expect

No, and this could be unintended.

@Joel,

The issue of track titles disagreeing with user input (through tags in the file or through typing a different title in the “edit” field) arose before the composition/movement structure was introduced (or exposed?). See https://community.roonlabs.com/t/mysterious-composition-substitution among others.

There are many reasons a user might want to display a composition name different from Roon’s internal name. I’m sure that’s what most of us thought the “edit” field was for. Among the reasons are:

1. Roon’s database inevitably contains errors such as the one described in the “mysterious substitution” thread.
2. Roon’s composition names are sometimes quirky (Dvorak 9th/5th Symphony).
3. Roon’s composition names are often very long, causing problems on endpoints that display the track name and on portable devices playing exported files.
4. Users have their own preferences, especially for compositions with multiple versions. Some may want to identify different versions in the composition name. Others may want all versions of the same composition to display identically. Example: Appalachian Spring exists in at least 4 versions of one basic composition (chamber orchestra or full orchestra, suite or full score).

Thanks for working to accommodate us obsessive classical listeners.

-SK

[Niccolo_Terzi (Niccolò Terzi)]

i reply here, somehow offtopic.
what about tracks that do not have a composition?
i’ve got … tons of them. they are not linked to corresponding track with correct composition… so they are like motherless childs…
note: they are also in identified albums.
i’ve posted repeatedly about this topic, with no answer.

thansks

[Fernando_Pereira]

I’m not sure that these will always work, but I’d explore the following two approaches:

1. Make sure that track file tags are set correctly, both WORK (the composition) and PART.
2. Re-identify the album, making sure that all tracks are correctly paired with their metadata, even if duration does not quite agree.

One problem I’ve seen is mismatches between what Roon’s metadata sources have as tracks (PARTs) in a recording and the actual track files, because for some compositions, especially 20th century classical, the division into “movements” is not an objective decision, and different (re)masterings of the same recording might have different track splits.

[Ludwig (Ludwig van Marbach)]

Are you talking about tracks which are classical compositions but not linked to compositions in the Roon metadata database?

Or tracks which really aren’t compositions, like applause?