these come all from identified albums and are all identified compositions.
but there is a contradiction. in fact the last composition “Preludes (24) Op. 11” comprehends all the previous compositions…
I don’t know which should be the correct behavior. I think that there are good reasons to keep all the “No. x” parts separated, and good reasons to collect them in a single composition, and that these reasons could differ for different compositions and different composers.
BUT, in any case, looking at classical compositions in my library, it seems that roon database is quite a mess, and no thought about this topic has been made.
That first issue (Work(s)) intrigued me, so I did some digging in my collection. Filtering on the composition title threw up some examples of the same thing:
i don’t know about this… because in my settings i always prefer file tag title over roon title.
but even if roon title is not displayed… it’s somewhere beneath
No, the tilde is a track title delimiter used by the metadata provider to separate the composition and part names in a track title. Usually, we will parse and edit out the tilde.
Typically, Work(s) means one of two things:
The metadata provider couldn’t match it exactly to a composition in a composer’s work list. Usually this is because there isn’t enough information in the track listing to identify something. E.g. all it says is “Chopin: Waltz”.
The track combines more than one composition by the same composer. For example, a singer performs two separate songs without a break.
We are aware of the issue and there is already a ticket in the system to resolve this. The problem is that, if the metadata provider hasn’t been able to identify the composition unambiguously, we may struggle too and end up equivalencing compositions which aren’t the same. However, at the very least, we will try and clean up these track titles.
Niccolò, nothing could be further from the truth. We have had many internal discussions about how we might move to a hierarchical composition data model (which I think would be the only way of solving this problem).
Do we have a solution for this today? No. Will we have a solution for this within the next 12 months? I don’t know. Do we intend to solve this problem? Yes.
@joel, i’ll investigate in my library. maybe, it’s something that can be solved locally by more precise tagging.
one lesson, though, would be that the composition identification by roon is… not always very satisfying. the “automatic” behavior by roon need a way to be manually corrected. id est, manually un-identify or identify a composition for some tracks.
please, see also this thread of mine:
ok @joel
but we (users) are not in your (staff) mind… so i can only judge what i can see now.
so, i’m glad that there will/should/could be work on this topic
yes, i guess that the hierarchical approach could be a solution.
in a way, add a level between WORK and PART.
one could ask then: what’s the point in this? why cannot we simply collect all these “sub-compositions No. x” in the “big-composition Op. x”?
that would result in this problem: how can i select different performances of a single “sub-composition No. x”?
let’s say that in general… no one has 1000 performances of the same composition… so, once the “big-composition Op. x” is selected… one could chose manually.
another solution would be: as “big composition Op. x” are considered WORK and “small composition No. x” are considered PART, one would only need a PART performances counter/aggregator.
i mean: in the tracks list of an album, there should be a counter/aggregator for the whole composition AND a counter/aggregator for the PART.
this is, maybe, quite heavy on the graphical side of the album (but not very different from the non-classical situation)… but would avoid the hierarchical approach, much more difficult in my opinion.
I’m getting more and more frustrated by classical albums being unidentified even after careful ripping in dbPoweramp or XLD using their metadata pulls.
My hunch is that this is not necessarily a Roon issue but the extremely flawed and, yes, stupid methods and structures for classical music metadata. I don’t think this issues will ever be resolved in the industry. Just too many idiots who think their way is best or a lack of care.
It’s not just an issue in Roon but I waste time in Spotify and TIDAL looking for albums finally finding them with ludicrous tagging.
dbPoweramp and XLD both make use of FreeDB and/or MusicBrainz, which are clearly inadequate for classical music (and CD ripping generally). try itunes, which makes use of the Gracenote DB and should be much better.
actually… i agree with you all: i mean that online DB (ituned, musicbrainz, AND rovi/allmusic) are quite a garbage.
i use them, but i also make an extensive tagging work by myself, trying to create a coherent tagging system. in a way, it’s part of the fun…
and i’ve been quite lucky, because in the end my years-long tagging procedure turned out to be quite similar to roon structure.
some minor differences, that could be solved with semi-automatic mass-tagging procedures.
subject of the post here is (though) when file-tags are ok, but roon output is wrong for some reasons (bad rovi metadata, or roon unable like here to interpret the tags and match them with its DB).
the problem is that we users have a very difficult life in correct these errors, even when it’s possible.
and that’s a pain you know where, expecially when you have spent a lot of time in searching info and tagging files, and … a lot of money in roon licence.
