Music File Management

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

So there is the final nail in the coffin of native folder browsing within Roon.

I still hope for the ability to play another app through Roon to gain folder browsing, by using something like BubbleUPnP, and other things like apps for internet radio, Pandora, etc. Played through Roon, volume leveling, DSP, etc., are preserved.

I’m having trouble tracking the tags discussions fully. Another approach would be to have Roon be able to search folder names and display contents. I could follow each of my folder names with characters, say “-z”. In the regular Roon search box, searching for “Jazz Vocal Newer -z” would serve a display of all albums in that folder.

This would just be like another tag without having to embed new tags in tens of thousands of tracks. And it would still work if the folder structure changed.

This seems to provide those of us who want to preserve this ability without compromising the Roon vision.

Roon can filter your library based on partial path matching in the Tracks browser:

This provides another avenue to get “ahold of” tracks in Roon based on where they are located in the filesystem.

Hmm. Thanks, I’ll experiment with this tonight.

I would encourage you not to get dragged into the tagging approach prematurely. Roon has other more direct techniques.

I have been a Roon user since it was first released, and a Sooloos user before that. I have a library of about 3,000 albums, adding about 1,000 per year (mostly Tidal). I listen to mostly jazz. And I have never added any tags to any of my files.

Your example of “recent jazz”: my “home page” is the Album browser sorted by Date Added, so “recent” is automatic. Instead of just sorting, I can Focus on the last month, or year, or whatever. And I can Focus by Genre.

I do add a tag inside Roon every now and then (but not on the file). For example, I sometimes add a few albums that are recommended in this Forum, or by a few specific people with the same taste as mine. But that’s easy in Roon: I add a few albums, they appear in the upper left of the Date Added browser, so its a few clicks to add it.

This doesn’t work well for everybody, depends on your scenarios, but I encourage you to start there.

1 Like

What happens with a 2017 reissue of a 1955 jazz vocal album? Does it show up in “recent” with your method?

It will under date added

That wouldn’t help at all unless I were looking for recent album acquisitions. I wouldn’t want a 1955 recording to show up under “Jazz Vocalists Newer” which is where we started.

Is there a reason storage location paths couldn’t be expandable from here? Then that path location could be displayed with all the Roon operations still available on this subset (search, focus, etc).

1 Like

If you know who the artist is, just type the name into the funnel.

Ah. I have it sorted by recent acquisitions, Date Added.
Roon keeps track of four dates, Originally Recorded, Originally Released, Released (would include the re-release Date), and Added. But you can sort only by Released and Added, and filter only by Released.

Chris took your use of “recent” to mean “Sort by date added”, there are other sorting options including “Sort by date” which can be configured to use Original Release date or Release date in Roon’s settings.

1 Like

Cool, I didn’t know that.
@pstrisik I’m sorry, I was wrong, Roon is even more flexible than I knew.

1 Like

Well well. I’m finding something workable thanks to help here. I configured date to be date recorded in settings. I then focused on Jazz and on Vocal and sorted by date. So far so good, but cumbersome to get there. I then created a bookmark for “Jazz Vocals by Date” and it works for this example.

The only request that comes to mind immediately is to display the date on the album in that full view. Similarly, I notice dates are displayed for “Main Albums” when viewing, say, an artist page. But dates are not displayed when you click to view all albums.

I’ll set up more bookmarks and see how this approach works as a substitute for folder browsing.

1 Like