A bouquet of flowers to the Roon development team

I don’t think anyone on this thread has any intention of bashing Roon. If we weren’t heavy Roon users we wouldn’t care. The concern that caused me to start this thread is that the more I like Roon, the more I want to invest time in making my collection work with it, and making it work with my collection. That, however, is a big time investment, and I would like to find a way to leverage my existing time investment or be able to get that information back out to use with other applications.

Roon says that their goal is to make it so that I don’t have to invest that time. I just feel that’s a long-shot. Some of us, by our nature, have our own ways we want our music to come to us and are willing to put in that effort. I just don’t want to lose the effort.

4 Likes

Well said James_I

1 Like

Not quite true: I recently recovered some code I wrote at university in 1981 from a 1/2 track DEC tape. I’d run it if I could find a free PL/I compiler… That code was originally written on punch cards and run on an IBM System/360. To my dismay, the music catalog program I wrote, and the metadata I put on punch cards, was not on this tape. If it was, I could honestly say that the music metadata I started to capture in 1979 or so was still available and usable today in its original form. In fact I still have it, as I’ve migrated that data from punch cards to a hierarchical database to a flat file manager to Oracle to Access and on.

On the other hand, the work the OP put into his metadata stands a much better chance of existing in a usable form 20 years from now than my stuff did nearly 40 years ago. As roon takes on new corporate form in the future, his data will live on in some AWS S3 backup such even after he’s gone too.

Like some others, I would like to preserve work I do in roon outside roon as far as possible. If tags are insufficiently expressive, roon could export non-licensed data to sidecar files at the album or group or some higher level. Or they could publish their datastore specs or provide an API to developers to extract it and migrate it. But as @brian said in his first post, export needs to be more complete. In his second post, he argued for getting this right as opposed to doing it soon. As he noted, most users do extremely little metadata editing. And those that do find it cumbersome, as I have. My strategy so far has been to go back to other tools to fix data at the source if roon can’t figure something out and then re-import. If only the editing wasn’t buried behind so many clicks. At this point in the product’s life, it shows that these are secondary considerations. If roon ever provides full and efficient metadata editing, the product will need a different UI for it. Expert mode? Arg, please shoot me for saying that.

Thanks,

  • Eric

I have come to believe that the best and easiest path is not that Roon needs to export metadata we configure, but rather Roon would be greatly improved if more capable on IMPORTING. (Although both would be great.)

The short of it is, Roon’s database has all my custom embedded metadata. I can see it in the file info view. It just doesn’t have any feature to do anything with it. If Roon’s Focus features included non-standard fields and the ability to Focus on a given value in a given field, that would go a long way to being able to then apply a Roon tag as a functional equivalent.

Then Roon just needs to add the ability to make its tags work more like filters if desired - I.e. Use tags to find the intersection of 2 subsets rather than adding subsets from tags together, although the minus symbol offers similar logic.

By way of explanation, the focus of my original post on exporting was due to my assumption I’d need to redo and repeat my file grooming within Roon. I didn’t want to lose all that work if I or Roon ever moved on.

Roon not having great tools for this (which is fine, plenty of apps for this exist) I’ve since decided it is better to use more standard file metadata tools to maintain the library and then to hope Roon someday soon supports more robust importing as above.

5 posts were merged into an existing topic: Musings on Ancient Computing

A post was split to a new topic: Musings on Ancient Computing