I’m still very new to this community but I have been loving the experience. Today I have been learning a lot about metadata, matching albums, etc. I am one of those people who meticulously maintained their file tags since other applications heavily relied on them. It’s actually a relief that Roon takes a different approach… when it works. So far my results have been fairly good though I’ve only reviewed about 1/10th my collection.
To my problem — @support — I was adding an artist to a few songs today. She’s very well know — Sheryl Crow. But after clicking add credit, when I type her name into the search field, she does not show up at all. I can add her name, but there is no information to back her up aside from just that her name. If this were some obscure artist, I probably wouldn’t have thought about it at all. But since it is a very well known performer, I expected Roon to find her in the database. Now I do not own nor have any Sheryl Crow anywhere else in my library. Maybe that’s the trouble? But there has to be some way around that? Right? Maybe something isn’t set up correctly with my account? Or preferences? Some library setting somewhere?
It is indeed. I stumbled over this for quite a while before realising. Add a Sheryl Crow album, do your metadata edit, Sheryl will now be there, finally delete Sheryl.
I think Roon is supposed to automagically re-link your dumb link to a real link later if Sheryl turns up after the fact, but that didn’t seem to work for me.
Wow @BrianW that’s such strange behavior. Has this been reported as a bug or as simply “undesirable behavior anywhere?” Is @support aware?
Here’s another thing I’d like to try but can’t within the trial — what if you have a Tidal account? Does that increase the available metadata range? Or do you have to add a Tidal album to your database before adding the performer to the album in question?
This alone is frustrating enough that I might decide to go back to JRiver or one of the other player solutions out there and stick to my file tags. I already have Sheryl added in my file tags and other players have been able to do some of the cross-linking for which I wanted to get onboard with Roon in the first place.
Hey Richard – thanks for the feedback, and please let us know how you get on once you’ve read the post linked below (thanks @BrianW.)
The big issue here, as you’ll see, is that performers in Roon are not just pieces of text – they’re full-fledged “objects” in the data model, with credits, influences, birthdays, etc – the words Sheryl Crow are not, in and of themselves, enough to make a match. I get why that seems frustrating in this particular case, but what you’re really bumping up against here is the power of Roon’s data model to really understand the performers and composers in your collection.
That power is the same reason why Roon can track two different Jazz musicians named Bill Evans, or 20-odd spellings of Tchaikovsky. The system is designed to make assumptions when it’s safe, but it also plays things a bit more conservative when we don’t have any information to go on.
Other apps may make an assumption about which Sheryl Crow you’re talking about, and for her that that may be a safe assumption. But because our system aims for a higher standard, we really try to avoid false positives and conflation of artists with the same name, as you can see from this thread.
Once you’re accustomed to the system, I think you’ll see why it works this way, but any questions, just ask.
First — thanks to this community and support for all the input. It’s refreshing to see an active community of passionate users and developers.
@mike — I found Roon and decided to try it for this exact reason! I love the fact that Roon takes the approach of artists as intelligent objects. This model is superior in every way. My frustration comes from the fact that I went looking for an (obvious/discoverable) way of telling Roon which artist object to link to the track I’m tagging. Given what I had experienced up to that point using Roon, I expected something like the “contacts” feature in a modern mobile OS where you type someone’s name and you see a dynamically searched list populate with names and photos (along with most common email address, etc.) So I typed “Sheryl Crow” and expected to see a photo of her face show up next to her name in the list but instead I got nothing.
Now that was totally different for John Mayer. I had just gone through this exact process with a compilation album that happened to have John Mayer appear on some of the tracks. I own several John Mayer albums and he showed up just as expected. To be clear, this isn’t a compilation album. I want to add Sheryl (or John or whomever) to a track where I know she/he performed on it along side someone else. In the case of John Mayer, this worked perfectly! That’s why I expected it to work for Sheryl. But as I describe above it failed.
I looked at the links @BrianW sent and I do not see a workaround. There are a few more links to follow. I am hoping I am missing something obvious and I do not have to add some Sheryl Crow originals just to get her into the set of matchable artist objects. Nothing against Sheryl! I just don’t own any of her music right now. That’s also a major shortcoming and odd workaround should that be the case.
We need a single piece of identified music, then the right person will exist in your library and show up in that list for you to select.
It could be an album, or a track on a compilation, a credit, etc, but we need something in your library to match a person before we start attaching unidentified content to a known person.
I understand this, and your rationale for it. However, sometimes it takes a bit of sleuthing to get it right. I spent an evening adding composers to the tracks of a Duke Ellington album, and trying to find a suitably identified track from Tidal can take a long time. Just typing a little known composer’s name into the search doesn’t always work (although the standalone Tidal App is better in this regard). I usually type a track name , then laboriously load each putative album and see if composers are credited (and as an individual, not a group - e.g Duke Ellington&Irving Mills&Manny Kurtz is no good)
When trying to identify an album, Roon will offer up alternatives from its database; it would be nice if for credits something similar could be used. For example, I type Manny Kurtz and Roon offers me a list (or two) of people from both my library and Roon’s. I could then click and see if the biography looks right for my required artist.
Hello, I have started this thread because I have experienced exactly the same pain as Richard. I would expect a search approach as a directory look up picking prospect entries from all of roon’s contributing sources. I am not asking roon to decide automatically without certainty of doing the right choice. But showing options, picked from tidal and/or allmusic.com entries, and letting the user establish the right link would be functional. It is impractical instead, to be obliged to add the artists on a compilation, one by one as favorites, before being allowed to create a link. Some artists in a compilation are not even worth to become favorites, and I have to add them from tidal, establish the link, and remove the favorite flag after that. I recommend to open up the search to all the sources, and let the user isolate the right link among the options.
@simoneratti — as you’d expect I completely agree with you. I would like to see this addressed in one of the next Roon releases.
@mike —I could see how existing functionality could remain the default behavior with this added either within the search results itself or via a checkbox that says “include artists from outside library/favorites.” This could be a very user-driven process with the obligation of confirming the match is correct using a photo and some basic data such as birth/death dates and country of origin. I do see how it would be very challenging to automate this process, but since we are trying to add artists manually anyway, there should be a provision for doing this completely. Any way we can get this added to the feature request list?
You said this in Feb, and I just ran across it. To play devil’s advocate, what does Roon care if it “incorrectly” links a strange new artist to one that’s close? Its just my library, isn’t it? Are you trying to protect us from ourselves? I really don’t quite get that statement, but you’d have to know the programming logic to really understand.
A lot of the linkages seem to be more of educated guesses rather than sure things.
Well, we need to make a decision about when to guess, and so we opt to only do that when it’s an educated guess. If your point is that we won’t be blamed for guessing incorrectly… we will have to disagree on that
The Bill Evans example I mentioned here is a good one to keep in mind. As soon as something in your collection matches our metadata, we assume that unidentified Sheryl Crow is the same person as the one in our metadata model. Just remember that in lots of cases it’s less clear – our system tracks two different Nancy Wilsons, two different Steve Wilsons, 5 different people for both Steve Davis and “Moss”, 6 different people for “Nicole”, and so on.
This stuff can get messy even when we’re relatively conservative about guessing, so this is the current designed behavior. Just remember that nothing is preventing you from clicking “Create Artist” to create a new performer in your library. This is about when that performer is linked to someone in our database.
Sheryl Crow seems like an obvious example but we need to consider the full spectrum of cases, and the current behavior is designed to prevent errors that can arise when we take an unknown person and link them to our data without sufficient confidence.
Like many metadata issues in Roon, my advice would be to spend your time matching your content to our model when possible (which will sidestep these issues and automatically link content to the appropriate people), as opposed to manually entering data by hand.
But we’re not asking you to guess; we would like to be presented with options so we can choose the correct artist. As I said above, options are presented when trying to identify an album manually, so why not when adding an artist manually?
True, but the trouble with this is that in my ignorance I may create a new performer Fred Bloggs, not realising that Roon really knew about him all along. Later the real Fred Bloggs gets incorporated into my library via an import. I now have two Fred Bloggs and merging two non-primary artists is not straighforward (assuming I have realised it has happened - finding duplicates in non-primary artists is close to impossible)
Mike, there is certainly nothing wrong per se with a triangulation approach to establishing links to the metadata. But there is a serious flaw in your model: it is the abiding presumption that the metadata are accurate. That presumption may work in 85% of tracks, but it doesn’t work well for boxsets, LPs, certain multi-track compositions, or compilations.
In these and similar metadata problem areas, the user is virtually helpless to correct her library. She can report the DB inaccuracy, but since neither Roon or Rovi are set up or incentivized to make such corrections, the glitches persist. She may try to override the mistake and either coax or force recognition of the album/artist/composition, but the workflow for doing so is murky and the chances of success minimal. Since Roon won’t disclose the IDing logic of its software, the user is left to her intuition and persistence to come up with a solution.
One brief example follows that typifies my frustrations. I have eight performances of “Bolero”: two are orphans, unlinked to the rest and likely to be forever ignored as a result. Why are these two not IDed I ask? Beats me, and I’ve gotten skilled at this stuff.
In the case of the first orphan, the album is identified but Bolero is not. Bolero is the only track not identified and linked. The second orphan is on an unidentified LP with lots of “linkable but unlinked” compositions. Since the second LP won’t ID, maybe I should give up any attempt to link its other tracks? Or maybe, I ponder, I should alter the title to conform with others in my library? Or maybe I should tinker with the punctuation? Maybe I should make Rovi or Roon aware of the snafu?
Well, I’ve tried all of the above “maybes”, and nothing has worked. The problem persists without any path to improvement or a fix visible to me.
So I then ask, “why can’t Roon take track titles, an opus number, and a composer, and ID a composition independent of its associated album?” This remains a mystery.
Roon has created a pretty good but very black metadata box. It treats its metadata source as “truth”. It hasn’t a visible process to improve the quality and scope of the database. It does not allow users to say, “this is Ravel’s Bolero, dammit, recognize it as such!” And (TMK) Roon has never publicly declared this problem to be “on its roadmap” or, for that matter, even a priority.
That this flawed metadata process persists in the midst of otherwise excellent and improving processes is vexing to me.
I’m curious as to why you think exposing the guts would help. I’m generally OK with being open about details, but I’m not sure the technical explanation is any better than the high level explanation that you seem to understand already (and specification-lawyering around processes that are understood to not work at 100% accuracy/precision is often less than fruitful and time consuming).
Do you have specific questions we can help with?
Roon is capable of linking up composition metadata on unidentified albums. It took me a second to find an example in my library, but it seems to be doing the right thing here:
I’ll admit, it can be tricky to give the system enough evidence to make the link confidently. Generally a composer credit on each of the tracks, classical genre at the album level, and parse-able catalog number is the viable set of ingredients for getting things to look right.
That said, I don’t think the focus should be on making the editing/grooming process more crisp+predictable. We could polish that turd (and miss the point) forever without reaching very many people with the resulting product.
The point we’d be missing: most people aren’t willing to groom their metadata. Most of our members don’t edit at all. Most of the potential members we can acquire in the future won’t be interested in editing.
That doesn’t mean that solving the classical collector’s problems is a bad idea–the group of classical collectors not willing to engage in manual metadata grooming is a much larger group. I just don’t see the point in incentivizing grooming.
The viable way forward that I can see is to figure out how to improve the quality and completeness of the data in the “black box”…which leads me to the next point.
This statement deserves a broader scope. The world as a whole has chosen to ignore the problem of generating and managing clean and complete metadata for musical releases.
So in this area–content that is poorly documented on Earth–we’re starting with a much harder problem. Recovering that information is a data mining project. Different problem domain than the stuff we do currently, but something I would like us to tackle.
I think it’s more likely that we talk about this topic differently because we view it differently, so you’re not seeing us communicate about it in the language of feature requests.
Our metadata systems are the most research-focused area of the product, and the slowest to make progress. With a lot of the other areas in the product, the roadmap is relatively clear and getting it done is a pure resources/scheduling matter.
With metadata-related topics, it takes a lot longer to figure out what to do and steer the ship, since we’re in unknown territory without much precedent to learn from or garner inspiration.
Anyways–the core value proposition in our metadata offering (and the way that the vast majority of our users experience it) is: throw your messy folder of files at it, we’ll figure it out, present it nice, and you don’t have to ever worry about it again.
I’d much rather focus on bringing that core value proposition to classical collectors and making Roon work for them out of the box than sinking effort into the manual-grooming escape hatch that only benefits a small subset of people who are willing to “do it by hand”.
Agreed. It’s taking too long to make meaningful improvements in this area.
Sorry I took so long to react. I didn’t know how to respond for a while.
You don’t really mean that do you? I should write Roon and ask why my two Boleros won’t link up?! And, I’ve got about 300 unidentified albums with about 3000 unidentified compositions. Should I start feeding those to you? Actually, I have asked Roon several specific questions about this topic, and while people have been courteous, my issues remain unfixed.
To say Roon is “OK with being open about the details” is disingenuous: Roon is anything but OK with being open about the logic. To answer your question “why expose the guts”, I would think that would be obvious to you.
But anyway, there are a good number of things the user can do to help the IDing and grouping process. Knowing what is required to ID an album or composition helps to us to add and fetch what’s missing, such as a missing opus or catalog number. Knowing how tracks are grouped helps users to discern if tracktitles are correctly specified. The user can add WORK and PART tags if that would help. And knowing “the guts” helps determine why particular IDs did not happen, which may give insights into improvements. And finally, I want to know about “the guts” because I grow tired and frustrated at the many missed links.
I confess that you lost me at the parenthetical.
Well, on that at least we can agree.
If you mean by this, “why should we enable the user to achieve the metadata links we sold to him,” then we have differing opinions about quality.
If only…
I think most of metadata research was done in 2015-16 when you came up with munging and IDing protocols that worked for most people, and the classical genre was a time suck. So, Roon has moved on to more lucrative areas like MQA. Solving or even denting the remaining metadata issues won’t get done, because as you said, there’s no value proposition in it. Except you really meant value for Roon. Fixing metadata is destined to be eternally deferred, pushed down in the stack for flashier stuff.
You asked how things work. I said “be more specific”–because it would take hundreds of pages to describe how our metadata systems work end to end and no-one has the time to write or read that. Ask me a specific question about how a specific thing works and I’ll do my best.
Explaining how things work does not equate to fixing every issue. Especially in the domain of data products which are not, can not, and will not be 100% accurate or complete ever. If you just want to rant about what’s not right with your library, that’s cool, but there isn’t much of a place for me in that discussion.
The thousands of hours that @danny, @mike, and I have spent on this site explaining guts of various parts of Roon disagree with you.
People have portrayed this as obvious truth to me before. They were wrong, too–when and how to expose internals is a complex and nuanced topic–but is an argument about how best to make and evolve software products really what you’re after here?
The poor value proposition is: We have a certain amount of resources available to focus on the metadata area. Do we focus on things that make the metadata experience better for 100% of our users or the <<5% who are interested in editing by hand?
“Fixing metadata” is not a binary thing. It’s 100 small projects that focus on various sub-prolems. If your litmus test for fixing metadata is “everything is 100% perfect”, you’re correct–we will never get there. It’s just not the kind of problem that can be solved in such a black+white way.
Roon focuses on album/release level identification for sound technical/architectural reasons. This will always be the focus of our matching systems–so if content lacks album-level data out there in the world, it’s always going to suffer to an extent. We sold you the data that we have, not the data which we do not have. Just about anything else we can work on is easier than conjuring missing album/release data from nothing.
We will continue to make progress. I already agreed that it should be moving faster…not sure what more you’re looking for here.
If you allow me to jump in here, i would like to point out that, among this “5% group of users”, there are incredebly knowledgeable experts who I am sure would be more that happy to contribute their expertise, time and patience to improve on Roon metadata for those troublesome cases, and all that for free. Should’nt Roon team start to involve those people by “opening up” a bit and giving them the proper tools to do so ? This could increase the limited “amount of resources” about which Roon frequently complains when it comes to metadata, especially in classical music.
I think this conversation has already been had… And as has been said elsewhere in the forum in the last couple of days: “would that it were so simple…”
Well, actually it’s already possible to add metadata to the roon data set for unidentified albums: musicbrainz.org; one might want to argue it’s not a proper tool - especially for classical albums the process using the musicbrainz site directly is a bit tedious or so I think. I believe there was a discussion about a tagging tool which helps, but anyway: it works.
There’s no clear statement about how roon actually imports musicbrainz data (and what get’s used and what not) and from what I’ve read it’s a work in progress. What seems to be missing is a way to correct or enrich existing metadata the musicbrainz way. For example I’ve a question open regarding release versions (which is important for my use case):
The nice thing about entering data into musicbrainz btw is: one does something for the so called greater good.
