Somewhere around post 28
“humans should be fixing it–but to my eye, that data source looks like exactly what you get when you try to employ Humans to do that kind of task”
Seems to imply an opinion against a crowd-cooperative project for this.
Crowd sourcing does not have to be a crowd-cooperative project.
This comment from Brian is probably relevant:
A crowd of experts is somewhat different to a crowd of the hoi-polloi…
Yes, but that post refers to a problem specific to classical music, I think.
That said, I think there are analogous problems of sorts in all genres. It is not just limited to how compositions are treated in classical music, but there are so many different releases of so many titles, and then when you add in needle drops from LPs, rips from SACDs, blu-rays and DVD-audio, downloads, etc., there are soooo many different versions. Then there are bonus tracks, and whether box sets should be treated as box sets or individual releases, etc.
I don’t think Roon or any data source could really fix this, and certainly not to every user’s satisfaction since we all have our preferences. I personally would like box sets of individual releases to be treated as individual releases in the sense that the box set may have the best mastered version and so it needs to be the preferred version of the individual release rather than treated as a different title. That’s not to say it is important that they be surfed as individual releases, but the preferred version issue is the challenge.
My opinion would be that Roon would be best off giving users a set of tools to quickly determine how to represent titles, works, and compositions in any genre according to user preferences rather than try to normalize all the data and then implement this across the board. In other words, create a truly efficient method of recognizing albums, breaking apart or combining into box sets, maybe with some sort of drag and drop capability. Similar comment to the other thread about how much of a PITA it is to move songs up and down one slot in the current album identification wizard - something much faster that supports various user preferences.
When it comes specifically to correcting metadata errors, I think there are more efficient ways we could use our resources than building a crowdsourcing system for that.
I think there are many classes of metadata corrections that could be handled by machines. in my opinion, we should run our options out in that department before risking human effort doing things that machines could have done.
I think the inferences being made are a little bit more absolute than my actual thoughts on this.
We’re not anti-crowdsourcing. We have already used it for the translation system. We are planning to use it for an internet radio directory, and for some other stuff too.
The trouble is using it for, specifically, metadata corrections, and also as a mechanism for adding unknown albums to the system. This seems like a very technical endeavor to me. It would be hard to imagine doing it inside of Roon itself–it would require a very complicated user interface, much more technical than our current editing stuff. And it would require a fair amount of education for people to use it, which I am not sure is practical.
Another problem is that I think the number of people who would participate is fairly small. A few prolific contributors plus a few dozen who participate more rarely. I don’t think we will make major progress on the problem with that size crowd. There are 11 million release entries our system, plus 1000+ new additions per day. It’s a pretty large problem to handle manually in a way that would truly produce transformative change.
A third problem is the lack of instant gratification. I think this is a really big one. If someone is going to put in effort to grooming metadata, they expect to enjoy the results when they finish. Without that serotonin feedback loop, it is pretty unlikely that we will bootstrap a successful population of editors.
The problem there is–Ingesting new/modified metadata into our system is time consuming from a compute perspective. There are some large-scale data processing steps that need to reason globally. For example, an algorithm that mines all of the release data in order to discover + materialize composition entities when they weren’t otherwise present. Our metadata system ingests/rebuilds data on a daily schedule–incompatible with instant gratification.
Crowdsourcing works better for things with less surface area and no “global-scale” reasoning like that. Fanart.tv is one of our data sources–very simple idea. Provide great high-res album/artist artwork. Something that anyone can do in a few minutes with a google images search.
Spotify crowdsources playlists. That works out great too. People know how to make playlists, no education or understanding of complex data models required. Lots of people can participate, not just a narrow set of committed, technical people.
Allowing for the fact that metadata is for a large part subject to personal appreciation, wouldn’t it be a good idea to offer a more intuitive search function that allows users to search and filter on attributes like artist, album and especially song title. Using focus feels unnatural to me. It feels and handles like a clumsy workaround.
Also, it doesn’t really improve search results when I want to use a specific track as a starting point for a few hours of browsing and exploring or when I try to find interesting cover versions of a track.
Have you tried using Filter? Or Search? Or the song pages listing alternative performances?
@Ludwig and @brian, thanks for the pointers but the filter icons either have escaped my attention or didn’t show up. I’ll have a looksee. Song pages listing alternative performances rarely show up. In many cases I the android app doesn’t react when I try to go to the track page, credits are missing more often than not, let alone alternative performances.
It could of course be down to my lack of knowledge. Or the lack of a manual. As an old guy, I prefer a structured manual to a wiki/faq style documentation. I find “knowledge bases” as a sole means of documentation sorely ineffective. But that might just be me.
Wouldn’t it be more intuitive to include a pre-search filter option? It"s a feature I often miss in library/curation software. If I want to search a specific track title I would like to specify this beforehand. To me, this seems basic. Filtering a scattershot result afterwards is tedious and not really what I am looking for.
I don’t know what kind of algorithm Roon uses, but a prefiltered query is generally considered best practice when dealing with data.
The filters may not show up if the device you are using for control is seen as a “mobile”. Not sure of that though…
The mobile apps don’t have the Focus search tools. Have you looked at them with a tablet or computer Control ?
If you click on each tool then added functionality is exposed. The filters can be toggled from + to - to include or exclude.
This KB article describes what can be done with the Focus tools.
The problem with a user manual is that it would have to be continually rewritten as Roon changes. What would you want to see changed with the Knowledge Base and User Guide ?
Ahh, gentlemen, you have clarified a lot… and added a lot to my frustration.
I’m not a big tablet user, I prefer a big screen, a real keyboard and a reliable pointer tool
That said, I use a tablet for controlling Roon. It might well be that somewhere in the obfuscated bowels of android, there is a setting to define a device as mobile or not mobile. I have no idea. I’ll fumble for it in my Lenovo tablet’s limited user interface.
It does seem like a strange distinction to make. I can understand that certain features are disabled on devices with itty-bitty displays like mobile phones, but wouldn’t it make sense to let the app discover screen size and enable/disable these features based on the OS’s reading of the hardware? Enable from - let’s arbitratily suggest - 8" or so?
So, no, I haven’t yet tried a laptop (or my Surface tablet) as a controller. The reason for this is that the controller app loses it’s connection to Roon Server, every time the device goes into power saving mode (black screen). None of the other apps do this (AVR remote app, BlueOS control app), so this is quite annoying.
Luckily my tablet can go for about 10 hours with the display enabled, so the annoyance is relatively minor. A more accomplished device drains lots more power and running a cable to a power outlet while reclining in my easy chair is not my idea of comfort.
Still… Having to whip out a more “robust” device to perform simple tasks does not seem very user friendly to me.
I would like a structured approach. Chapters and Headings by topic, an alfabetical index, a troubleshooting index…
The KB is - like most KB’s - too randomly iterated. There is a search function, but like all full text searches, it returns scattershot results.
There’s a trend developing here, I think
Just press things and see what happens. You can’t break it. That’s how the kids learn so quickly. Global learning as opposed to linear. It’s easy to learn if you just poke around. The old fashions manual is, in 2018, very much a thing of the past.
That’s what it does.
Can you upload a screenshot of your Album view ? That will show whether the Focus tools are present. You will see them on a computer also, not just tablets.
With the KB, there are headings and subheadings in the User Guide. What would you use an index for that the search function doesn’t do dynamically ? Can you give an example of an unsatisfactorily scattershot result ?
Is your Lenovo Tablet one of their Android-based tablets? I suspect it is, because with my Lenovo ThinkPad 10 tablet, it doesn’t lose the connection with the Roon Server when it goes into power saving mode. Neither does my Surface 3 tablet. Both are Atom-based tablets, with Connected Standby (aka InstantGo).
I hear this adage more and more and I’ve got quite a few clients in software development who have been hit very hard by the simple fact that manuals are very much not a thing of the past. One of these clients has seen three deals cancelled due to lack of documentation where the prospective buyers went for lesser performance but better documentation.
I don’t believe it’s a good idea to force older generation customers (i.e. the ones with the cash) to conform to not-really-working-but-hey-the-kids-today-all-do-it-like-this ways of working.
This is an example of both an unsatisfactory and scattershot (albeit only two shots ) result. Somewhere in Roon I believe there is a possibility to ban tracks (or artists or whatever). Until now, I haven’t found it. The hits from a search on the knowledge base are… ehm… less than helpful.
So yes, documentation, documentation, documentation. It’s been a mantra for software developers since back in the days we all learned to program in assembler. I know I’m a living dinosaur, but that doesn’t mean old truths have stopped being truths.
Yes, the Lenovo is an Android-based tablet. Much to my chagrin, but most remote apps for domotics are either Android or IOS. So it makes sense to use an Android device as a control device for Roon.
Otherwise I’ll have the portable device equivalent of a coffee table full of remotes.
Tip for software developers everywhere: develop a true universal control app and you’ll be the richest man/woman/other sex in the world. (But according to the weather report, pigs have been reported flying …)
On banning tracks, it’s the heart button. Hit it once to mark it as a favorite (which to my knowledge is just a standard tag - it does not affect Radio/Shuffle or other selection logic, I don’t think) and hit it twice to ban it (Ghostbusters symbol) which does then stop that track from being selected in Radio/Shuffle or album play, UNLESS that track has been specifically queued up.
I agree I would love more documentation about the specific way that some features work, like the heart button. If the effect is just obvious (immediate, visible, does not affect logic), fine, but sometimes the effect isn’t visible or obvious. For one thing, i didn’t know that Thumbs Down affects more than stopping that track from being queued at that moment – sometimes I just didn’t want to hear that track at that moment, but do not want to affect anything else. But that said, it would be a serious resource drain for Roon to document every feature fully since the software does change substantially with each new version release.
I didn’t start this post with this in mind, but it does occur to me that the heart button is a little weird conceptually - that is, if you favorite something, all that does is allow you to filter a search for favorited tracks; it does not affect Shuffle/Radio etc., but at the same time, the Ban will actually stop a track from being played. So that is a little counter-intuitive as a toggle, kind of like if a knob or lever in your car if turned left starts the air conditioner, but if turned right, starts the turn signal rather than the heater. You can get used to it, but I can see how it would confuse users.