Not possible to merge artists when Roon has no meta-data for one of them?

I also find the jumbling up of composers, choir masters and librettists bewildering as well. It is bad enough that roon routinely makes librettists “composers” of choral and opera works. In the Elgar case roon actually goes one better and makes 4 librettists co-composers of a Cello concerto :confounded:

I hope the solution is not simply to move the librettists from the Cello Concerto to the Choral Work. Better, but as Klaus points out, not really a solution.

Guys, thanks for posting these examples. To my mind, they point up two things: 1) the poor quality of Roon’s own metadata sources, and 2) the black box nature of Roon’s methods of constructing the credits. There’s also the nagging feeling that, even if we elect to use our own metadata, Roon will continue to take the “it knows best” approach.

I added the Elgar album from Tidal to my own collection to see how it would look, and there are differences from the version owned by @Tony_Casey :

Notice how there’s no mention of “Sea Pictures” in the title, and while the LSO is credited for all tracks, it doesn’t appear in the album artist list (which at least manages to just mention Janet and John).

But then Roon screws up the all tracks credit by having a single artist named “John Barbirolli/Jacqueline du Pré/Janet Baker” instead of three separate artists. I can correct that by removing this ersatz artist from the tracks credits, but then I can’t seem to restore du Pré or Baker to the relevant works even though I add them to the track credits. Roon no longer displays artists by the works:

Still playing blind man’s buff here…

I guess the three of us (Geoff, Tony and I) can probably agree that this “black box magic” is the reason of many of our troubles and I would think that this general approach of Roon here is much more to be discussed than any more detailed functions for classical metadata.
But what to do about it? Is it only some nerdy classical music lovers discussing in their ivory tower? I would be interested in a more high-level discussion about this. What do others think about it?
As I said before, I believe the DB framework that Roon offers is a very good one.

2 Likes

I am not that anal about metadata as you guys are, so I’ll not climb and join you on that tower :stuck_out_tongue:

Though I always carefully tag my files the best I can (and care about) and I’m also seeing all the issues you brought up in here. With most of them I can (regretfully, must admit) live with, hoping they’ll be globally fixed someday

But I’d really love it if Roon’s approach to metadata was instead “use my tags, if/when present, and fill the voids”
I’m even willing to adapt, need be, my tags to what Roon expects them to be. But I need a clear reference page to do it, which is so far missing (just small parts scattered here and there across various threads/FAQs)

I’m with everyone on that. It’s all well and good building the case but what to do? My priority would be:

  1. A properly functioning “use my tags when present / use roon tags only when I ask” option
  2. Clear metadadata parsing rules reference page
  3. A more systematic/alternative channel into roon to help build a more classical friendly power product (I would pay more). Is that possible? Is that what you meant Klaus by “higher level”?

I’ll invite @Ludwig into the discussion - he is another user who has experience in wrestling with Roon’s way of dealing with classical metadata. But really we need to hear also from the Roonies themselves - they are the ones who develop the algorithms. Insights from them are sorely needed. I’ve already invited input from @joel and @vova earlier in the thread, but no response from them as yet. I suspect they are still dealing with the aftereffects of the 1.3 release.

I find it slightly ironic that @kevin invites submissions from us on the topic of “Best practices for organizing and navigating a classical music library”. At this point I haven’t got a clue where to start.

1 Like

I’m with you on all your points. As far as higher level is concerned, I meant it not in a Roon hierarchy manner, but more in a sense of looking at the big picture before tackling the details. But of course I’m happy to advocate my case towards anyone :wink:

I am not that anal about metadata as you guys are, so I’ll not climb and join you on that tower :stuck_out_tongue:

Fair enough. Me being anal about it probably comes fromt the time I’d invested in tagging my collection. It’s counted in years…

lol - that would make it necessary to understand what the software is doing…

though I’ll keep promenading thereabout and uphold you the best/as much as I can :wink:

1 Like

Roon is still not getting it I think. Best practice was evolved to work with legacy folder view / relational database products like JRiver and other more specialist ones we have all tried. Roon is a step change but no one knows yet what the new best practice is. On other threads I can see that there are plans to introduce JRiver like folder views and personally I welcome that as it helps ease the pain of the transition process. For the time being all I can see is a very rudimentary “best practice” that collects the few rules of the rules of thumb that are emerging in various corners of the KB. Things like:

a) get rid of your “comma” delimiters
b) null out your artist tags
c) etc. etc.

A lot of this is counter-intuitive and is probably going to render your library unusable in legacy products. So it is quite a commitment. Any further progress needs more commitment from roon to share the underlying logic of how it is really interacting with legacy local libraries.

Thanks @Geoff_Coupe for dragging me in. :slight_smile:

There are two separate issues at work here.

  1. I have no problem “merging artists when Roon has no metadata for one of them” but I always edit the name of the artists to be the same before I merge. I never tried without doing that. I’m not sure whether it should work without changing the names, but I suspect it might not be the design. The feature appears to have been designed to merge two accidentally created artists with the same name (i.e. same name but different data source), rather than to merge equivalent artists, such as two different name forms/languages, which leads me to the second issue:

  2. The “Also known as” field on Allmusic (see below for the Wiener Philharmoniker one) - which presumably comes from Rovi/TiVo appears not to be supported by Roon, despite some indications to the contrary. At least I have never seen it in action, and for the Wiener Philharmoniker have had to edit accordingly. This is something which I hope @joel will have time to get to (and he has a lot on his plate) because it would transform the artists browser.

No doubt it’s more complicated than it seems, as everything in metadata always is :wink:. For example, if the equivalences are based on just strings, there could be non-equivalent artists dragged in by mistake. This kind of thing is multi-layered and we the use can’t always see what layers are behind each bit of metadata in the Roon UI.

Anyway, I hope the artist equivalences which appear to be there in the main metadata source one day get benefitted from.

Just to let you guys know that I am reading this thread. However, as Ludwig points out, it is more complicated than it seems and there is no easy fix here: if there was…

One thing to clarify: we’ll never present equivalent artists as separate in the artist browser; we present non-equivalent artists. Which means that either (a) the “duplicate” is there from your file tags or (b) apparently equivalent Roon artists are actually not equivalent. For example, Rovi has four distinct “Wiener Philharmonikers” :frowning: and our automated system hasn’t equivalenced them all yet. :frowning: :frowning:

We understand that things aren’t perfect now; for many reasons, we’re currently re-thinking equivalence from top to bottom. It will take some time, but we will get there. However, we believe we made great strides with classical in 1.3 and we’re not going to stop there.

2 Likes

Joel, your attention is appreciated. As is your work up to now. And as I said before, we know it’s almost always more complex than it looks.

The Wiener Symphoniker would be a good test artist. Let me know if you need more.

Thanks, Joel. Dealing with metadata is a Herculean task - cleaning out the Aegean stables comes to mind. Good luck in your endeavours.

2 Likes

thanks a lot @joel and @Ludwig for your comments. It is good to hear that Roon guys are reading.

However, please allow me to be nagging a little bit. If it is more complicated than we think why not offer a documentation that explains it properly?

I have no problem “merging artists when Roon has no metadata for one of them” but I always edit the name of the artists to be the same before I merge.

How should anybody know that this is the way to go? Is it the way to go? Or did you just by accident adopted a way of merging that works?
I can select two artists even if they are different in name and click on “merge”, so why shouldn’t the user assume that this is the way to do it? It’s the same way with merging compositions. If they wouldn’t be different in text there would not be the need to merge them.

Working in the IT business myself I am familar with the difficult balance between development speed and documentation requirements but even if I’m very happy with how Roon developed with 1.3 I still have the feeling that there’s lots of guessing involved for the user.

There is so much happening in the background that the need for proper documentation on how the system reacts to primary data fed into it is just so much more important.

Having followed a similar discussion with JRIver in the past years I am absolutely conviced that it is not the right way to ask the user to figure it out by himself or to write How-To’s for a software company (not implying that you are, but you could read the offer to be a writer for Roon in such a manner).
Users can certainly provide input to the documentation and even enhance it with a different style of writing or addtional examples but the documentation on “how it works” should be there first.

Please do not get me wrong: I very much like where Roon heads to DB structure wise and I am very willing to be patient and trusting on the way to “get there”, but I also expect a certain transparency that goes beyond the “it’s more complicated than you think” explanation.

Personally I’d rather live with a lower development speed but with proper documentation on how the wizardry works. If you can’t explain the algorithm to your users how do you want to do the coding for this algorithm? How to you do your tests if the use/test cases are not described properly?

Having said all that I am still aware that I am propably a minority in expressing those wishes and I have no problem with that - just wanted to offer my honest opinion. I think we all want Roon to succeed because it is what lots of us classical music lovers have waited for, so please don’t see that as any kind of “bashing” but as a try to share our user experience in order to make Roon better.

Regards
Klaus

2 Likes

Ah, now I see the disconnect. I don’t want to see equivalents displayed separately either. Makes no sense.

What I had hoped was that it would be possible to make the ‘master’ equivalent configurable. At the moment roon appears to be making a decision during the identification process that all equivalents from this list:

will be catageorised as “Vienna Philharmonic Orchestra”. I would like to have some means of categorising all these equivalents as “Weiner Philharmoniker”. The expectation would be that all references to “Vienna Philharmonic Orchestra” would be bannished from the user experience of my personalised roon.

  1. At the end of the day I seem to be asking for a feature request to make the selection of the ‘master’ equivalent configurable. For example, I would like to be able to banish all references to Vienna Philharmonic Orchestra and replace them (including links) with Wiener Philharmoniker.

  2. roon is proposing to continue setting the ‘master’ equivalent to Vienna Philharmonic Orchestra in background during the identification process but tightening up the ‘equivalence’ matching logic so that searches display all equivalents under a Wiener Philharmoniker Orchestra banner.

  3. roon decides what the ‘master’ artist name is
    But there is some brojn equivalance logic that can be fixed so all

I think what I had in mind was some configurable way of controlling the ‘master’ equivalence

  1. roon’s artist merge is really for the case where there has been an accidental/unintended miss-labeling of an artist. Re-naming one of them before the merge is advised.

  2. the artist equivalence feature is not implemented

  3. This thread has finally established that my case is a consequence of 2) not 1)

It’s disappointing but I can see that my case is essentially a feature request to make the equivalence artist configurable. It seems to be a pre-requisite to resolving all the unintended consequences this thread has flushed out like giving local library album artists links and eliminating all the album artist/primary artist duplication.

I hope this isn’t considered too niche a request. I would see it more as a baseline request for establishing roon as a viable classical library manager.

so… I’d better un-merge, eg, “Wiener/Vienna” and “Alfonso X/Alphonse Le Sage/Alfonso X (El Sabio)”? :confused:

The Holy Grail for me would be a fully localized metadata system where you could choose to have “native” artist names (Wiener Philharmoniker, Серге́й Васи́льевич Рахма́нинов, 馬友友, etc.) or locale-specific aliases.

Obviously, we are completely limited by what our metadata providers provide… Though that may change :slight_smile:

@joel but why is that so? If you have your own DB structure designed in a proper way and open the decision about who is the main artist name to the user it should be ok for most. This all comes back to the basic argument whether the software/metadata provider should decide vs. the user should decide.

It is probably a paradigm change for Roon but I think this really should be adressed when discussing classical music. I have always seen 3rd party metadata as a starting point for my own tagging rather than expecting 100% accuracy. if you download classical music from either labels or resellers like Qobuz, etc. you’ll have different approaches for it already, so if even the musical industry can’t agree why should we let 3rd party metadata suppliers dictate it for us?

There never will be real consensus on how to handle metadata for classical, so what we probably need is a kind of basic agreed structure that we can fill on our own or have it filled with 3rd party data. To my feel how it is done currently it’s like doing the 2nd step before the 1st.

I am confused as well Paolo.

Merging didn’t meet my expectations so I have abandoned it. It turns out I probably have a feature request for configurable equivalents instead. Maybe roon can comment. Does merging when you really want to manually add an equivalent have unintended consequences? The thing that worries me all the time with roon is have I inadvertently hidden a bunch of albums because I didn’t understand the consequences?

I

1 Like