Playing “Lorena”, a song from 1857, very popular during the American Civil War. The lyrics are on the Wikipedia page. Does Roon have them? No.
Don’t want to pile on, but I might as well chime in – I agree with the above word for word. Roon devs have made it pretty clear they assign no useful weight to “liking” a post here, even if it’s a feature request. Additionally, the barriers for acknowledging a legit usage case seem to keep rising. This even for obviously broken & non-functional (imho, anyway) features or atrophied 1st attempts to enable ‘complete metadata editing’ which…oh, never mind. Why bother? This is why I post so rarely…
2 Likes
For the long term I would agree to some posts where brian stepped in (similar things) explaining what roon is heading for, and that embedded or local metadata is sort of a secondary thing which in case all would work as expected, could be ignored by 100%.
So the simple question which I would expect @brian to answer (since being in charge) is dead easy:
What’s the solution for the users right now, until the whole concept works as described many times?
I really wonder why roon tries to have that much pressure in many similar fields about this’n’that which would simply stop if poeple would not detect they have lost something after having switched to roon.
There’s already lots of additional geeky things in the software, but unfortunately these are bundled with a loss of functionality due to not taking existing data into account.
From scratch I would have expected that local metadata would have been treated like sort of ‘dumb data’ which would get displayed but not being fully useable and it would get replaced by roons data when being found, something I’d then call ‘intelligent data’. In practice this should mean I could stick bio or lyrics to the one currently having gaps. And at any time roon catches up, it could get replaced.
But as long as the ‘intelligent’ data isn’t served, the ‘dumb data’ outperforms the ‘no data’ concept by miles.
2 Likes
That question isn’t “dead easy”. It’s not really a question at all. It’s a demand that we stop working on stuff that touches most of our users and instead focus on an area where we are near the point of diminishing returns to give a relatively small number of people who take a certain view of metadata grooming a solution right now. We would be fools to do that at the expense of larger-scale efforts that grow the product in bigger ways.
These individual requests may seem trivial in isolation, but they aren’t when we are tracking hundreds of them–and there will always be hundreds of feature requests open in a product of this size. Good product is not made or measured by maintaining “inbox zero” on the feature requests forum, or by treating it as “first come, first served”.
Requests do not automatically become more urgent because they first came up 3 years ago, nor are they necessarily illegitimate as use cases because we haven’t gotten to them yet. We are always going to make decisions based on now, the foreseeable future, and the impact we are able to predict from our work.
In terms of selecting smaller work items, we are looking for stuff that touches lots of people, and provides a good return on the effort put in in terms of making peoples’ lives better. As noticed above, grooming/editing features have a harder time hitting that bar now than a few years ago. This is because the product is bigger, our membership is bigger, and this kind of stuff has not grown in importance proportionally.
You should expect us to focus on the things which produce the most impact because we would be fools to do anything else. It isn’t really an indictment of us if something like this doesn’t make it to the top of the pile–it says more about the feature itself + the impact we think it will have on our members.
But–more importantly–the large-scale stuff will never happen if we allow ourselves to be bogged down with hundreds of smaller feature requests. It’s easy to say “I haven’t gotten anything that scratches my metadata grooming itch in a while, progress is super slow”, but when I look back over what we’ve released since our launch…it’s a pretty huge amount of product. Maybe you guys don’t remember how small Roon was as a product in 2015 compared to now, but I do.
There was a comment above that we don’t really look at “likes” in the feature requests forum. This is true–we sort the feature requests forum by views, since that is a better measure of interest. If you sort the feature requests section this way, you will get a different view of how we respond/prioritize/deliver out of that list.
We have spent a lot of time and effort making Roon more usable for people who make editing/grooming their focus. When Roon was launched it supported no editing at all and only 9 or 10 file tags. There was no track browser. There was no “prefer local metadata”, no “library settings”, no genres from file tags. There wasn’t even an album artist field.
Through the course of growing this part of the product, we have learned something discouraging: no matter what we do, the same people are grumbling that Roon is not the ideal metadata grooming platform.
This is a fundamental problem–people who take a comprehensivist view of editing/grooming and place that at the center of the world seem to want Roon to be something that isn’t really consistent with our vision. And that’s a fine point to disagree on–we will occasionally release stuff to relieve pain points when it makes sense, but we don’t intend to compromise the bigger direction we are pointing in.
As for the direct topic in this thread: We are still planning to add support for importing lyrics from file tags. We have some other lyrics-related improvements in the pipeline, too, as well as a couple of more improvements related to sucking data in from file tags that are in our concrete plans, too. And we will continue to balance this stuff against the larger-scale projects that are ultimately consuming most of our resources.
6 Likes
Some of us remember. 
The updates and the changes since launch have been seismic.
4 Likes
@brian, I don’t think people necessarily want to groom metadata (I definitely don’t want to, and I certainly don’t want to have to do it within Roon) but we’re left with little choice when Roon’s metadata is incomplete and results in things not working the way one would anticipate. If the core of Roon’s value proposition is “Music is an experience, and Roon reconnects you with it.” and “What you get is a searchable, surfable magazine about your music.” then, as good and as versatile as it is, and as much as I think it’s a great product, it’s not delivering adequately against that value proposition and I could just as well be using LMS, Squeezelite and iPeng. I know there’s a lot of work underway and I don’t mean to be disrespectful nor to denigrate the product or the team’s efforts. Roon has made great strides and it is a great product, but it could be even better by answering its own call. I’ll continue to look forward to the day it does.
The people on this forum are a tiny proportion of the whole room user base. Of those posting here a small proportion have fundamental problems with the metadata. And reading the forum, a large proportion of those few have obsessively organised their file system, metadata, works to fit with their own perception of the ideal. (Not saying you are such a one, as you said, you want roon to do it )
However, even as a standard user I’m fed up of multiple threads about metadata; so goodness knows how pre-sensitised the team are.
Industry talks a good game…
I do think too much is made of Roon’s metadata feature by the many positive reviews of the software I’ve read, which imply that the metadata will be fairly complete with just about any recording. This of course isn’t true, and in this respect these reviews are unfair and misleading since they set the reader up to expect that the metadata feature will be comprehensive. I like Roon’s metadata feature a lot, but am frustrated sometimes by the lack of metadata with recordings I like. My feeling though is that there’s probably a good reason for said lacks, and I don’t let this comparatively minor (for me) complaint override my overall appreciation and enjoyment of the metadata feature and the metadata that is available. I guess I figure, too, that Roon is well aware of the issue and probably doing what they can as time goes on to improve it. These comments do not refer to previous criticisms or questions about this issue–others are entitled to their views.
Jim Heckman
I’m really too dense to understand why lyrics already existing in the file tags aren’t shown. Room has a lot of remarkable things in it, and the music playing part is great. No complaints on that score. I’ve run software products myself, and I’ve used the “if you knew what we know, the big picture, you’d probably understand why we haven’t prioritized your feature” line as well. So I’m sympathetic to that explanation.
But pulling lyrics from the file tag and adding them to the DB… There’s already a column of tag info in the Album Editor with “prefer Room”/“prefer file”/“prefer this” switches. How hard can it be to add another row to that column, and add a stanza to the file analysis which pulls the lyrics out of the tag and adds them to the DB? Considering this was asked for 3 years ago, and semi-promised two years ago, it seems remarkable (to me, anyway) that it’s still missing. Perhaps it’s a contractual thing? Perhaps Room Labs has signed an agreement with LyricFind to only use their lyrics? Dunno.
1 Like
The Roon notes say, “a stunning brace of poetics and grace”. And, of course, for this 16-year-old album, no lyrics.