I can look into that. Where do you want these? Here, Redmine, email? And each album individually? (Just do a search in the metadata server for Album Artist = Beethoven, and you’ll find thousands…)
One ticket in redmine, with examples added as you run across them, will be most helpful. That way Jeremiah has plenty of meat to work with once he reaches that point in his queue.
As far as I can see we are now getting many if not all of our file tags displayed alongside the Roon server tags. Have you outlined the reasoning for this new handling anywhere elsewhere? If not can you do so now? It’s causing me chaos but I’m sure you’ve done it for a good reason even if I can’t perceive it just now. What’s the thinking?
We described what was done in the 1.1 release notes, but not to a huge extent why.
The rationale is all about supporting people with well-groomed collections or good pre-existing tag data. It provided a good answer to many, many questions like “JRiver/whatever shows , how do I see it in Roon?” A large amount of content is poorly covered by our English-centric metadata sources, and supporting as many tags as possible allows people with clean collections to have a fairly rich experience.
Personally, I think I’m in the same boat as you: I’ve been ignoring my tags for years and using Sooloos/Roon style approaches that completely re-invent the metadata since 2007, so my tags are junk and I don’t really care about them anymore.
In most cases, when data is available from our metadata services, it overrides the data from the tags by default. In some cases where our data was sparse (particularly with track credits), this will cause data to be added. In other cases (release catalog#, country, label) we decided that tag data is probably more reliable than whatever our automatic identification comes up with, so it should be preferred by default.
What kind of chaos are you seeing from the 1.1 changes? I’m guessing that it’s mostly related to track credits, but maybe I’m wrong. The way we merge local/Roon track credits right now is pretty crude–I think we can do better.
With your best metadata and good file tags, Roon works very well with classical already. But having got this far already at 1.x it’s going to be amazing at 1.3…
A few of the big things we accomplish next time we iterate on this stuff are:
One is work-level identification. Instead of doing dumb text munging in Roon, we’re going to try to match works against Rovi’s database. Right now we only perform identification at the album level. This would add a second layer of identification at the work level that could afford to be much fuzzier about text.
Rovi has a very good list of works for the most significant composers, and they generally have well-structured data for new releases. They have very, very poor coverage of box sets. I don’t think it will be hard to use their work data to identify when works appear within, say, a large box set. This requires more smarts than text matching–we can rely on composer’s name, catalog number, number of movements, etc. to narrow down candidates. This requires a lot of domain-specific work for classical, but it’s worth doing. Our current work munging happens in the app, without the benefit of this master work list. It must be moved to the cloud (big work) in order to do this.
Another we need to do is to figure out how to represent non-classical works in this system without polluting the classical browsing experience. I know that a lot of people will want to keep classical separate and clean. I think this is right from a UX perspective, but wrong from a data modeling perspective.
I’m loathe to create two systems for this because the core idea is the same: someone authored a piece of music and some number of people performed it. This is a universal idea, not specific to classical. I think the solutions to this will be focused on filtering/navigation, not creating a separate cathedral for classical music sitting alongside the rest of the system.
As much of a mess as the munging stuff we are doing makes in a large classical collection, it nails use cases like this to an extent that even the best metadata sources (Rovi, Discogs) have not approached (or attempted to…):
JVH is a significant composer that didn’t really record albums or perform. In most music software he’s completely invisible. Obviously I have some bias as a serious Jazz collector, and our product shows it, but it’s important to preserve good results like this while improving our handling of large classical collections.