Music File Management

But surely that’s one of the positive aspects of databases like Discogs?

As long as the editing rights are not abused, you - anyone - can go in & make an update and suggest other changes.
There’s potentially an infinite source of like-minded enthusiasts…resources which no Record Label could call on.

I’ve noticed errors & made / suggested amendments, and I’ve also added a couple of rarities myself - which others have later picked-up on & improved / added-to.

However it is clear that there are (other) weaknesses - particularly when it comes to Classical…

1 Like

As an isolated database perhaps, but not if you have to code around it.

1 Like

I meant a perfect example of “how” they work in practice not that they work perfectly. Thought I was clear on that. It is a perfect example of how it works with all the pro’s and cons. I know the pros and cons, that’s inherent to a system like this. The only thing I was referring is that I don’t see a Roon user based crowsed sourced tagging to become any different

1 Like

Got a hammer in your hand and everything looks like a nail :joy:


That’s a great Gretchen Peters Lyric

1 Like

Not seeing it, and…never gonna happen. It would ruin the product.

We will of course keep making incremental improvements…the “can’t be done” isn’t the same as admitting that it’s impossible to move forward. Just that some of the obvious paths aren’t the clear-cut winners that they are made out to be.

Think about where we were with regards to metadata/editing/classical/file management 2.5 years ago:

  • No Library/Import settings
  • No file paths in the tracks browser
  • No “prefer local metadata”
  • Composer catalog system that was so dumb that it did more harm than good
  • No awareness of “classical” or filtering of “classical” content in the compositions/composer browsers
  • No “browse this composition on TIDAL” links
  • No editing in Roon, at all. If Roon got it wrong, you were out of luck.
  • Metadata pulled from file tags was extremely limited. No LIVE LABEL RECORDINGDATE LOCATION WORK PART COMPOSITION CREDITS PART MOVEMENT CONDUCTOR or dozens of others.
  • No support for using user-provided genres
  • No support for merging albums
  • No support for disabling/controlling work/part grouping
  • No support for custom delimiters in file tags

I’m sure I’m missing a lot…this is just what came to mind quickly. The point is–while there are still pain points, we are consistently shrinking them. The feedback we were hearing on these topics a couple of years ago was far noisier and more concerning than the issues we are dealing with today (and back then, our user base was a small fraction of the size that it is today).

The fundamental problems with classical are:

  • The music is published poorly
  • The people who listen to it have different opinions about how to organize it
  • There is a big gap between how the music is published/sold and how it is consumed when compared to other genres.

For example, in this thread, someone was complaining about composer names in the album artist field. The problem is–record labels often put composer names into the artist field. I understand why people groom those away, but it’s really not a clear-cut call whether we should do that in cases where it is actually the most accurate artist name according to the publisher.

The most acute improvements we will likely make for Classical are probably less about data and more about navigation/presentation. There are obvious missing navigational links from Composers -> Albums/Performances. There are also some faults in how we order/present data on the Composer/Composition screens–they do not do a good job of pushing the most important stuff towards the top of the list. This is being worked on as well.

1 Like

Is there a definitive list of these somewhere?

Thanks for the suggestions. Now, if only the programs were for Windows.:grin:

Completely and fundamentally agree.

Thanks for having the character to state that.

Unfortunately, that stake in the ground won’t stop further ongoing requests.


At least we are not left wondering your intentions!

And why should it? The request is still reasonable, even if there is a cultish stance against it.

My solution to this is to continue to use the software I was using before using Roon. I have used jriver since v17, now on v22. If I have metadata issues in Rooni fix them using jriver (and very occasionally using mp3tag). I also discovered one issue with my files that was stopping room from importing 100%. I had artist folders like “The XX” and “The xx”, room only looks inside one and ignores the other. So I used jriver’s powerful facility to correct the artist name so they matched, and the move & rename option to tidy up the album’s into one folder. Same with bjork Vs Bjork and other uppercase/lowercase discrepancies. Roon is still showing about 100 files fewer than jriver so another anomaly to be solved, but I have closed the gap. Because roon uses its own database and doesn’t touch the file embedded metadata, I think it’s necessary to use another piece of software.

1 Like

James, you know I’m sympathetic. But the answer to your question is, “because it ain’t gonna happen.” For better or worse, that’s not a direction Roon is going to go. That sort of clarity is helpful–and very much appreciated. Helps the rest of us make our decisions. (FWIW, I’ll stick with Roon anyway, and not only because I just re-upped for a year.)


I know. It’s their software and they can make whatever decisions they want with it, and live with whatever results, positive and negative, come of those decisions, and I think there are probably both.

I am starting to see a wider view of this, being that I think the Roon team may have adopted an anti-inter-operability stance. That I think is unfortunate. It means a much bigger challenge and amount of work to re-create custom curating done outside of Roon within Roon. Limited ability to import outside organizational work into Roon.

1 Like

You’re well ahead of (beyond) me on this. Other than iTunes, I’d never previously used server software. I built my library in Roon. My frustrations have been about trying to get Roon to recognize and properly display a few difficult albums and sets (which I eventually solved by learning to use mp3tag)–that and the fact that about 7% of my library remains unidentified. (I’m thinking 1% would be a better goal.) So, while I’m not totally happy–and I too have had my frustrations with Roon’s direction (such as the destructive queue, which I think they finally fixed) I haven’t experienced your frustrations. Good luck.

My take is I would rather (1) solve any recognition problems and (2) build in any library customizations, like track and album ratings, outside of Roon, then have a quick way to import them into Roon. I have some concerns about investing time doing that within Roon in a way that isn’t exportable. But I’ve been a broken record about that since I first implemented Roon. I thought broken records weren’t supposed to happen with digital! :grin:

1 Like

you are assuming that “the publisher”, or whoever was hired by him knows what he’s doing… :wink:

I always thought the reason for all this confusion was historical. The original ID3v1 standard goes back a long way to 1997. It was very simple, there was no composer tag or much else for that matter so a convention for classical arose of putting the composer in the artist tag. I remember doing that myself. ID3v2 changed all that, there were a lot more tags including a composer tag (TCOM) but it took a long time for tag editors and longer for players with fuller capabilities supporting composer and other ID3v2 tags to arrive. By then the die had been cast so there is a lot of legacy metadata out there and legacy best practice where it is still common to see composers in artist tags. I believe ID3v2 is still an “informal” standard and that cannot help much either. Maybe that has changed.

MusicBrainz is a good example of a metadata publisher reinforcing this pattern. Their classical style guide actually recommends putting the composer in what they call an track artist tag

and the performer in what they call a recording artist tag

But they are not recommending mixing them up and sometimes putting composers in the artist field and sometimes putting performers in there. It is very unfortunate, their choice of labels, as it’s so confusing. I can imagine this adding another layer of confusion to mappings between MusicBrainz / ID3v2 behind the scenes. It’s probably similar with all the publishers because of this lack of standards.

But surely the real issue is not what the others are doing, it’s more how to deal with the messy reality in a way that improves the roon experience. The pattern I often see is that in otherwise quite well tagged classical files when the composer is in the artist field, the composer field ends up empty and the performers are found in the album artist field. So I just swap everything around. Maybe it’s placebo but it seems to improve composition identification and has knock on effects with radio experience for example. It would be nice if roon could automate some of this.

1 Like

If we were anti-interoperability, why would we spend the majority of our technical resources working on interoperability?

We generally have 5-7 interoperability projects in flight at a time, not counting Roon Ready + Roon Tested certifications (which are also interoperability!). We released interoperability with three new families of audio products last year (Sonos, Devialet, KEF). We just totally re-built our volume controls to make them interoperate better with the hardware products that our users have. We are currently working on interoperability with two home automation systems, MQA files, and another family of audio devices that we are not ready to announce yet.

In the library management area, we made two serious iterations to the product last year that improved our interoperability with file tags and file-based organization. We added support for over a dozen new file tags, for controlling work/part structure via files, and for pulling liner notes + PDFs from folders. Then, we through our export feature to make sure that as much data as possible was being exported back into file tags at export time.

I think the problem is–you are defining interoperability selectively. The wider view is: we are working on interoperability constantly, but not prioritizing the things that are personally important to you.

This one folder browsing feature is a sticking point for you–as are a couple of library management topics, and I understand that. You made a list of a few things in another thread…let me address a few.

  • folder view - This is against the philosophical purpose of the product and the presence of this feature creates rigidity that will be harmful as we evolve the product. Our decision making about this has nothing to do with interoperability.
  • capability to search and sort by custom embedded metadata - We have no fundamental problem with this, but we do not totally understand the use case where it’s required and no other solution would do. I had a conversation with an alpha tester a while back asking for this, and it turned out that what he really needed was support for performance location and a couple of other fields, so instead of building a generic escape hatch and guaranteeing him grooming work for the rest of his life, we enhanced support for performance location (and related stuff like dates) and made sure that we could gather that information from file tags, integrate the same from our metadata sources, sort by it properly, etc etc. In other words–we addressed his real need instead of the literal feature request that let him do it the way he used to in the last software he used.
  • compatibility with/ability to import track ratings - Track ratings are simply a feature we choose not to have. This is a user experience choice, not in the interoperability domain. If we had support for track ratings in the product + failed to import them, you’d have an argument that we were failing to interoperate. Nonetheless, we tried prototyping a solution to this last year (converting track ratings into tags like ★★★, ★★★★★), and found some issues in the user experience that caused us to pull the feature back.
  • importing user tags - This is something that we would like to address. We also prototyped support for this last year, but ran into a set of experience issues that caused us to pull it back (same as the track ratings). We will likely re-consider both next time we do an iteration on the tags feature.

In general, with library management we are not over-eager to do stuff quickly/badly and make mistakes. It is nearly impossible to go back on these kinds of decisions (and in many cases ,they severely impact our possibilities for future architecture shifts–mobile products, cloud access to content, etc–these products would be substantially easier to build if we did less complex stuff in the library management sphere).

Our approach to library management involves re-thinking the ways things have been done in the past. That means that our stuff will sometimes work differently, or not translate 100% 1-1. It’s pretty obvious that there are some serious benefits to that approach, and also some tradeoffs. We try to minimize the tradeoffs, but sometimes it is better to push forwards.


Hi Brian. I appreciate the long and thoughtful response. I should have been more precise in my choice of words, as I was referring specifically to inter-operability in library management as you picked up on. Really, library organizing.

Specifically I feel that media management software should minimize how proprietary… [STOPPED TYPING WENT TO READ THIS:]

If this works, I will totally retract my comment on inter-operability. I had not thought of using a playlist to select files, and that I can export playlists from media managers that handle custom metatags or other attributes. I will see where that takes me before I get back on my high horse, if I do at all. Thanks Brian.

1 Like

6 posts were merged into an existing topic: Browse by folder structure