A bouquet of flowers to the Roon development team

Feedback Feature Suggestions
1

I’ve decided to use dramatic titles to get more attention. :blush:

Since I’ve started using Roon, I’ve had no problems spending enjoyable time configuring Roon to my network topography and in adapting my network to Roon. Indeed I built a new computer to serve as the core. At 2 houses.

But I’ve felt funny about grooming my media collection to work with Roon – a little queasy doing things like choosing the preferred release version, identifying albums, applying tags, and otherwise grooming the media collection to work best within Roon, which is far more time consuming than software and hardware config. I couldn’t identify why I felt like that. Until today.

I’m uneasy because if Roon goes away or I go away from Roon, there is absolutely no preservable value from my work within Roon on my media collection. Choosing preferred versions, creating tags, identifying albums, it means nought to any other media player or system. Outside of Roon, these don’t exist.

Foobar and JRiver, among a host of others, don’t work this way. Grooming the media collection is done by organizational techniques outside of the player itself - mainly metatags, images in the media folder, file and path name. Organizing via these techniques makes the media collection portable from software-to-software in a way that Roon disrupts. It’s all in a proprietary database that only Roon understands.

So, Roon is brilliant for creating this Venus Flytrap. But we’re onto you.

To the point: I believe that any collection grooming work needs to be exportable with the media. There are limited options for this, and the obvious one to me is creating custom metatag fields that can hold multiple values - “Tags” is the obvious one, but there is actually quite a substantial amount of media information that the user has to correct/input to get Roon working perfectly, and the vast majority could easily be stored in custom metadata embedded in the media files. To validate this investment of time, we have to be able to take it with us if we need to.

I’d love Roon’s own metadata in there too - lyrics, band bios, album reviews, but certainly that is just icing on the cake. But we definitely need the cake - we need to be able to export the user configured media data that we input into Roon. I’m not talking about genres and things that already export - but rather the deep stuff that takes time and effort on an album by album basis, and sometimes track by track.

Roon could fail as a business (I hope not - I really love it). Tidal could fail as a business or de-integrate. Roon could be bought and the model integrated to a service we don’t want to use. There are many reasons we cannot assume that Roon will manage our collections indefinitely. I thought I would use Foobar forever.

So please, help us dedicate our time to Roon by not making it a sunk investment.

10 Likes
2

I maybe be incorrect but.

Allot of the metadata you talk about isn’t ours to own and take. We rent it from Roon’s metadata providers and that’s where part of our subscription fees go.

3

I agree with this. That’s why I do most of my grooming in an external metadata editor and keep my in-Roon grooming to a minimum.

I’m fortunate in that the developer of my preferred metadata editor (Yate) is trying his best to incorporate Roon-friendly custom tags that are, as you suggest, embedded in the track files. This is at a very early stage, but so far, so good, and I’m hopeful that the situation will improve over time. You might encourage the developer of your favorite tag editor to make a similar effort.

Besides all that, the Roon team have let it be known that they’re working hard to improve Roon’s metadata-related capabilities, so I’m likewise hopeful those efforts will bear fruit.

5 Likes
4

I’d love to get that metadata too, but as I mention above, that would just be the icing on the cake. The metadata I’m referring to is all the information we input into Roon relative to our media collections. Tags, album identification, likes, preferred releases, etc. We input quite a bit of that information to get our collections working well.

1 Like
5

Ive taken to accepting Roon at face value, and not even going down the route of “deep personalisation”, not so much for the reason you cited (valid though it is), but more a couple of more reasons:

  1. Primarily…I can’t easily and consistently see a way of integrating a backup of a HDD of music into (a personalised) Roon and maintaining those personalisations. I have even renamed a HDD to the original and told the pc to use the same drive letter; the files came up in Roon but it kept crashing while reindexing. I gave up trying in the end.

  2. The method of modifying the data within roon is quite tiresome, involving multiple clicks in various places, with inconsistent results. There are many ways in which this could be streamlined, (and as you say, an option to write basic data mods back to meta-tags would be a major asset).

I absolutely LOVE roon. This personalisation aspect, for me, pales into insignificance alongside the basic encyclopedic premise and the fact that I have been able to make much more sense of a v large collection of red book flacs and hd files.

The Roon team is doing a very fine job and I expect to see many more improvements over the months/years. Some seemingly simple ergonomic improvements I look out for at each build with bated breath include:

Like you say… ability to write back the mods to metatags

Much better implementation of the Identify function (I’d love to see the ability for example to simply identify the albums with the album reviews and credits, and album art, but ignore the track listing options profferred, because unidentified albums are usually unidentified for track listing discrepancies despite our file data being correct)

Better handling of albums art handling eg… long press on any piece of art view to give option to make album cover; ability to rotate art when viewing

Ability to add to (ie modify locally) the bios supplied for albums and artists

Just these (seemingly) simply mods would be so cool.

5 Likes
6

I agree - one great thing about Roon is how compelling its core functions are but yet there is so much room for growth.

1 Like
7

I have JRiver and a lot of the ‘grooming’ lives only in the JRiver library. No JRiver - no library - no ‘grooming’, At least as I understand your point. JRiver lets one create customized fields and specify acceptable values, etc., but these are only intelligible within the JRiver cosmos.

8

I use Yate as well, and I agree - the addition of Roon-specific or “Roon-friendly” tags is progressing well. I don’t have any expectation that all the metadata that Roon retrieves for me can be written back into the files (although it would be nice). But I do want to make sure that any metadata I add, either to assist Roon or to augment what Roon can find, is not just contained in a proprietary Roon database.

1 Like
9

Some time ago I did something I never thought I’d do. Actually use itunes. But wait, not for playing music, nor for downloading music. I use it because it’s a standard (and free) product that integrates with many 3rd party products. Why might I want to do that you may ask?

Well, because I got sick of managing my external media file naming and locations, as well as internal music metadata. So step 1 that was a bonus for me was that iTunes has a default option that names the files based on your metadata. That’s one edit less than before. Further, it organises it’s own directory structure based on the metadata, that’s another painful step done with. Step 3, a 3rd party integration allows me to look up the same data source that I expect roon uses, and set the metadata based on that, which in turn updates the files in step 1 and 2.

Of course there is one compromise that some people just don’t want to swallow. Apple enforces an apple file format. However, since everything I use read’s this fine, it’s only a container and I can easy batch convert it out again if I really wanted to, I swallowed this one as it was better than the alternative.

That was all BEFORE Roon. I was using a mixture of tools, Squeezebox and Plex being primary ones, each of these scanned the itunes music folder with ease (and still do simultaneously to Roon) and have never had an issue. Roon of course picks this up equally well and again, I’ve not had to worry about it.

So that’s one option I can offer, if you can bite the apple Pill. :slight_smile:

In case you’re interested I used tuneup to fix my metadata (but don’t do it all in one hit) http://www.tuneupmedia.com:8080/

I agree it would be cool if this could be integrated into Roon, the fact that TuneUp bought the data and did it, seems to suggest Roon ‘could’ do it if they chose to. Another feature for Roon, it cleans your music library! :smiley:

1 Like
10

I definitely agree with the overall thrust of this but be aware - file tagging is a thorny issue.

This becomes even thornier (!) when considering the richness of Roon’s schema. Not only are many fields not supported in existing file tagging schemas but, worse in some ways, some music players disagree in the way these tags should be interpreted.

So while a given approach might be good for one piece of software, you might come into problems with others, and the overall control and management of your library will still be a task you must do yourself.

11

No real argument with the overall post, but just a note that if we’re talking about Apple Lossless (ALAC) here, it’s been an open format since 2011. I’m not especially advocating for ALAC, but if someone doesn’t like the format because it’s proprietary, they can cross that objection off their list.

1 Like
12

ALAC doesn’t offer any way to detect corruption of the audio stream, whereas FLAC does.

1 Like
13

One of the design principles of Roon is that, with few exceptions, it doesn’t alter our music files. There used to be organised folders and they were discarded, which was a good call imo. Now the only way Roon affects files that I can think of is deleting local tracks from storage.

One of the benefits of designing Roon so that it never writes anything to music files is an absolute inability to stuff up said files. Changing that is a big step with scary potential consequences. Apart from potential bugs causing problems to user libraries, user error raises its head.

I can see the desirability of accessing or exporting the user information in the database in a useful way, but I’d be cautious about having Roon automatically write it into tags in music files. An export procedure sounds safer.

2 Likes
14

That is really what I had in mind. Whether Roon adds its information to the original file or exports a new file is, to me, just a matter of storage space. I’d be fine with having new files exported and then, if and when I stopped using Roon, having an extended period of testing the exported files before deleting the originals (if ever).

The point, really, is that it takes significant media grooming to make Roon work well, and the Roon team clearly agrees given the substantial attention paid to processes like Identify Album and the Tagging feature. I just don’t want to lose that if for any reason I cease using Roon. This potential loss keeps me from investing my full time into Roon.

To be clear, I said it would be great if the full Roon metadata went with such an export, but I’m not really asking for or expecting that - I understand it is licensed for a specific use. What I am directly talking about being able to take from Roon is the information we have to input to make Roon work smoothly with our collections.

1 Like
15

I suppose it is a matter of semantics regarding what “grooming” is. I look at what you are talking about as configuring JRiver. Plus there is no risk of loss of JRiver like there is with Roon. JRiver will always work locally for someone like it does today. If Roon (the company) ceased to exist, if the software still worked at all, which is an open question, it certainly would suck to have all new music acquired be void of metadata - Roon would not work well at all if the source of metadata ceased…

16

At least with Foobar, it works with any custom metatag you want to create, and from what I have seen with JRiver and MediaMonkey, those work with custom tags as well.

Foobar’s plugin Columns UI has a filter feature that is, IMHO, still more powerful than Roon’s Tags and Focus features, and works with any custom metatag you create, although it is generally not as pretty and doesn’t read like a music magazine. I’m not saying that Foobar is overall better than Roon or any such thing, simply that there definitely are ways to effectively utilize the information I would like to see Roon capable of exporting.

(Sorry for three posts in a row…)

1 Like
17

I’m not talking about customizing the way the app works. I’m talking about custom tags and/or new fields one might devise to categorize one’s music, metadata in other words. These live only in JRiver’s propitiatory library structure, unreadable by any other app. The only thing that is in a file in the same directory as the music files is cover art. Cover art can also be placed as a tag in the file, but really who cares about that? Cover art can always be recovered from the internet.

As far a worrying about a software company going belly up, that fear is true for everything. If JRiver went belly up, it would still work until it didn’t.

18

JRiver may be capable of media customizations within the JRiver library, but in my experience in using JRiver it is not nearly as necessary to implement media grooming with JRiver in ways that are not portable, relative to the extent such work is necessary in Roon. Still, my point was not to debate what JRiver does. It’s a nice program but Roon is much more fun to use.

If JRiver went belly-up, its software would work just like it does today on any device configured as it is today. Operating systems might eventually move on, but the user experience would not be an iota different the day after JRiver ceased to exist.

There’s no way the same can be said of Roon – it would be substantially unusable if the source of metadata stopped, except with a number of onerous workarounds and sacrifices. That is, if it even worked at all.

This is not meant to be critical of Roon. It’s simply a desire to assure that if I put in the time necessary to really get Roon to understand the full of my media collection, I won’t lose that effort 5, 10, or 20 years from now. I still leverage efforts I put in 10-20 years ago and expect to be able to continue to do so.

1 Like
19

Not true. Roon is perfectly capable of reading your tags and preferring them over other metadata sources.

1 Like
20

Maybe I am in the minority about what I see as the primary value propositions of Roon. I do like the playback/transport chain, and that is not metadata dependent.

BUT, would most people migrate to Roon if the transport function was all Roon offered over other players? I mean, if it didn’t come with the rich metadata and (1) Roon’s method of navigating one’s library based on that rich metadata, and (2) Roon’s method of shuffle and radio based on this metadata, would people still use the software without the Roon-provided content?

I do not think so. So, back to the original point - if Roon the company ceases to exist, I believe Roon the software loses a lot of its compelling value, IF it even still runs at all.

Thus, we need our work grooming our collections within Roon to be reasonably portable. I’m not sure why any user who has spent years grooming their audio collections would NOT want that capability.