I don’t want to get too far off topic since this is about Tag and Bookmark functionality and how Genres might be leveraged, but I guess to the extent users are using their own Tags as a way to correct faulty Rovi data then it is relevant. (But still, I would hope that the Community will continue to chime in as to how they are using these features to enhance their Roon experience rather than have this simply be a debate about Rovi data).
So my response to the above quote is: I do think Roon cares about the accuracy of the data. They understand it isn’t just an annoyance, but that it really has a direct impact on the ability to use Roon as it is designed – the relationships between objects can only be exploited (enjoyed?) if the objects are correctly identified/defined.
Where I suspect the Roon team may differ is that they don’t want a crowd-sourced solution. They’ve probably seen its limits and challenges, and that it may fix one problem and create two. And, oh gosh, if it went to the level of people debating applicable genres, it could be a complete mess. Even with it correcting problems without creating others, it’s also just a different business than software development, and the infrastructure and staffing required to do this would not be trivial. There are also concerns about IP (intellectual property) rights. Translations of an interface are one thing (unlikely to be considered an infringement since it is a derivative of Roon-owned content) but crowd-sourced metadata could easily be infringing the same way you cannot simply copy a phone book even though each individual entry in the phone book is not any one person’s IP. How does Roon detect if someone just uploaded a Discogs item of data, and take it back out, before they get a nastygram from Discogs?
My suspicion is that Roon intends to do something similar to the relationship between credit reporting agencies and other large consumer data sources: Let’s say Experian has my current address and Equifax has my current employment information. They compare databases and each fixes the inaccuracy or stale information of the other (“you complete me”). So if Roon were to obtain music metadata from 2,3,4 different sources and employ the same Big Data strategy, there would clearly be some notable upgrade in the accuracy of this information, even if there are still some inaccuracies.
And there will always be inaccuracies in data like this – the music world has no clearly defined boundaries; the plethora of artists, albums, etc. has no stopping point. And in some cases there just won’t be a way to reconcile differences, even if there is a human looking at them.
What I’d like to suggest is that in this thread we discuss how Tags can help address some of those problems in addition to other types of experience enhancements. The objective is to, I hope, help the Roon team explore how best to enhance these tools into something powerful but usable.
Tag and Bookmark functionality is very important, indeed critical, to some users. Maybe there is a contrary sentiment within Roon, but I don’t feel that developing a direct function to address a specific use case is necessarily the same as enabling multiple user-customized use cases by developing robust logical search and sort capabilities out of these tools. In other words, I would like to use the potential power of these tools to build out my own use cases rather than to see only specific use cases supported directly as a limited feature.
Yes, Roon might eventually be able to tell me what albums or tracks are overplayed and which are more obscure, and thus serve up what I desire relative to those attributes without my having to use Tags to do something similar. BUT, Roon won’t ever, and no software ever, will supplant all of my ideas about how I want to mix and match my library because some of those are simply too personal, or too obscure, for there to be embedded support. For those items, I just want some robust logic and flexible configuration capabilities.