One of the things we shied away from in 1.1 was building a control panel of “library settings” that let you tweak/tune this stuff. We did one screen–the genre mappings editor–and we made everything else (file tag genres vs roon genres display) a display setting.
In part, it was because we really don’t like the idea of settings that take a long time to apply. A lot of this stuff requires going back to the tags in the files to re-evaluate what that data means globally, then distributing the results of that re-evaulation to hundreds of thousands of impacted records in the database. This is roughly equivalent to the work done during “updating databases due to software update”–which can take several minutes or more, depending on library size.
So the settings that we did expose in 1.1 were settings that could be applied instantly–so even though they have global effect, they can be flipped off as quickly as you flipped them on with no ill effect and a very smooth user experience.
We have become less afraid of building features like this over time. Yeah, it’s annoying that clicking “save” on the library settings screen will take a few minutes, but that’s probably an inconvenience that will be tolerated in return for more fine-grained control. And since these settings are largely there for power users, the undesirable UX is something that most people won’t be faced with anyways.
I think we are going to revisit that “library settings” idea again and make it easier to make high-level choices about how files are handled.
Some of this will just be about changing the global defaults for existing features (genre display settings, prefer-local-metadata, import date handling preferences).
Other things will likely be small ways to satisfy common requests. For example, some people find AllMusic’s editorial data (Rating, Review, and/or Picks) offensive. I’d rather say “you can turn it off over there” than have to have the argument every single time about why our default behavior is sane. We effectively did this for genres in 1.1, but we could go further with the idea.
We also, sorely, need to support a mechanism for merging artists. This is a complex problem–because in Roon, references to artists can arise automatically, and are extremely numerous and spread out in all kinds of places you might not think of immediately. In iTunes, you can “rename” an artist by editing all of the file tags that name that artist. That doesn’t really work in Roon, since updated metadata can arrive on-the-fly from our servers at any time, and all it takes is one reference to the artist you “merged” to bring it back from the dead. We have a solution mostly worked out, but it took a lot of thought to get there.
We’ve had requests to support custom delimiters in file tags (despite the horror show that can result from using “,”, a character that can show up legitimately within artist names like “Crosby, Stills, and Nash”, some people really want to have Roon split their ARTIST tags on “,”). This could fit into the same set of preferences–it requires re-parsing all of the tags in all of the files to re-split them, so it takes some time, but there’s nothing technically difficult about splitting on a different character once you have the infrastructure in place to re-evaluate all of the tags + rebuild the library.
More towards your issue: another thing that we did in 1.1: populating many more fields in our data model based on file tags. We more than doubled the set of supported tags with that release, but we didn’t cross the line and start inventing tagging conventions on our own. I think it’s time to cross that line.
For example, for your Album Version situation, we could support an ALBUMVERSION tag that, when present, overrides all of the path-based logic and just directly populates that field.
Likewise, there are some people who struggle with getting import dates the way they want them to be. They could use an IMPORTDATE tag and manage import dates externally to Roon if they don’t like the built-in options.
Others have requested a file tag that just turns off automatic metadata handling for some tracks. Or ways to represent classical work/part structure, or album reviews, or …
File tags are an open mechanism–accessible to everyone, and there are good existing tools for manipulating them, scripting those manipulations, etc. We shouldn’t stand in between people and their ability to do that. And it seems like we don’t have to–we can expose a lot more control/power without impacting the out-of-box “Roon cleans up my messy pile of files!” experience for casual users at all. It will never rise to the expressive power of our data model, but for many, many use cases–particularly for power users–it is a very sane approach.
And of course, there are people who don’t like the idea of burying their data inside of a proprietary database, or who worry about data corruption, or don’t want to depend on our long-term viability as a business. Other people just have pre-existing workflows surrounding file tags that they don’t want to re-invent. They all have reasons to mostly-or-completely avoid Roon’s in-app editing features.
This mindset will also facilitate easier migration of data from other systems. I have 6 years of import dates buried in a Sooloos database that still aren’t in Roon. A lot of people have similar stuff with iTunes, or in other places. It’s a lot easier for us to support reading that data from tags, document the details, and let people handle getting the data from where it is into the tags, than it is to support each of those previous systems one by one. It means that anyone sufficiently motivated would be able to solve their own problems.
I know things have been quiet on the metadata/library management front for a while. It’s not because we aren’t thinking about it–it’s because we’re a small team and we can only focus on so many things at a time. Right now, we are deep into planning what the next major release(s) are going to look like, so a lot of this stuff is being woken up discussed again…
(@evand, @VirusKiller, @ncpl, @ludwig)