Roon metadata vs file tags = hell

Support Metadata
21

I understand that you could solve a bootlegs use case using this method…but…we have a field called “Is Bootleg” in our metadata model already.

Currently, there is no supported file tag that populates this field–mainly because there is no well-defined consistently-agreed-upon standard for how to represent bootlegs in file tags (as with many things involving file tags…). But that could be rectified easily and incrementally without creating a whole new mechanism.

This bootleg flag is also populated by some of our metadata sources–so getting the tag-derived information into the same place is more powerful than just putting this stuff in a user-defined tag ghetto.

This is the problem we have run into in the past with the “custom tags” proposal–every time someone provides an example, it feels like there is a better, first-class solution out there where we enhance support for it in the main data model.

What I’m looking for is: a compelling use case that can only be accomplished with custom tags and this level of flexibility. It has to be something that we would never put in the main data model. Not saying it doesn’t exist–just saying, I’ve posed this question half a dozen times and never had a “hit”.

If we build something super generic, it will only be for people willing to groom their metadata and populate the data–a small minority. And if the fields that they are using it for are applicable to a wider audience (like bootleg, or the performance date/location stuff I described to you a few days ago), then we have failed by creating an escape hatch instead of solving the problem broadly.

As I said in the other thread…we are totally open to doing this if the right use case pops up. Custom tags was in the “maybe” list for 1.3…and then all of the use cases we found during our research ended up solved in the main data model instead.

I’ve seen some of this vitriol and I agree that it is not productive. Internally, we’ve been on board with the idea of a non-consuming queue for a long time…it was mostly just a matter of finding the block of time do it, which took a while. I am 1000% happier with the new design.

I understand that there are some “Roon Fans” who will always defend the current state of the product…but they don’t represent the company or its attitude towards change/improvement.

Yes, sometimes we reply with a “hard no” to some features, but we try to take the time to explain ourselves and do it politely.

The primary constraint on our end is time. It’s really tempting to spend all of our time doing incremental improvements and missing the large-scale stuff Roon needs–like a solution for listening to music outside of the home, or a radio implementation that goes outside of the library.

1 Like
22

Isn’t the ability to add Roon Tags as I described in another post just that? If it wasn’t clear from that post the idea was to have Roon define a single tagname whose content will become a Roon Tag inside Roon if that tagname is encountered inside a file.

23

No…that’s an example of something that fits into our data model, but is missing support on the import side.

I mentioned this case in one of my previous responses to him as something we played around with in the lead-up to 1.3, but couldn’t make “right”. The problem was–tagging solely at the track level was losing information, and the UX of a tag full of tracks was pretty poor. In real life, a lot of these tags are really album level, and we couldn’t figure out how to determine that or handle it.

What @James_I is proposing is user defined file tags outside of the data model that can be filtered using focus + boolean queries.

1 Like
24

Thanks @brain. It seemed to me it would work pretty well insofar as tracks that are assigned a Roon Tag are treated no differently to tracks currently assigned a Roon Tag. Where all tracks in an album carry the tag then the album carries the tag, otherwise define a track level and an album level file tag people could use and then there’s zero ambiguity.

25

I always appreciate the thoughtful responses of the Roon team.

This was just an example. And whether “Bootleg” is in the metadata model already, the real point is to be able to import this information from within embedded file tags. And as mentioned, “Bootleg” is just an example. You don’t have in your data model, for example “tunes suggested by Ian” or “songs I listened to in the summer of 1991.” (And please, no need to mention that I can sort by date - not the point). Yes, your tags support designating objects in that fashion, but we want to dynamically import that information into Roon tags from our existing schema. And many of us want to KEEP designating such information in the files, so as to preserve this investment of time and energy beyond Roon alone.

One man’s trash is another man’s treasure. Brian, by producing Roon you have asked users to think outside the box of their prior media applications and adopt something different and in many ways better. Now I will ask you to think outside of the current Roon box: no matter what you build into your current data model, there will always be users that want to push beyond that; or to push it in their own way. You’ll never develop your standard data model faster than my Sunday afternoon ideas that I want to try as soon as I think of them, by leveraging my customized object-by-object data in connection with Roon Tags, Bookmarks, etc.

But I cannot invest in trying those ideas if the core object-by-object work is locked in a proprietary database. That investment from the past exists embedded in custom fields in my media files, and so should future investment be put there (my opinion). I want to implement my own album ratings; my own artist groupings, my own track-level criteria. I want to slice and dice my music however I want. Your standard data fields won’t keep up with it, nor should I be expecting it to. If and when your standard data does support a given designation, then maybe I’d import from my “tag ghetto” into your standard feature, but in the meantime, I don’t want to wait for it. And it may never do what I can do with the information I’ve embedded.

Core users, IMHO, are not necessarily the ones that simply adopt what the standard application can do. I’m sure many do, but many core users want to take it farther, faster, add their own gloss, make it work like they want it to work. Those users form part of the core of the community. You’ll never be able to develop fast enough or far enough to satisfy the tweakers. We just want to be unleashed to try things our own way. If you eventually adopt something similar or solve a problem your own way, great, but for now, using Roon Tags, bookmarks, etc., we want to put own own gloss on top of what the Roon team can build. Extensions are great for some of that. But we also need to be able to leverage the tremendous investment we already have in our file schemes.

What we are asking for is a way to apply our own tweaks as we have with every media app we’ve ever used. To do so, we are asking to be able to dynamically import embedded information into Roon tags. That, in and of itself, is a “hit.” There is no need to justify this request with a specific use case – some specific designation, field, or characterization that is currently not supported that you would consider building into the standard data model. That’s not the point. The point is always to be a step ahead, or a step to the side, whatever. Much of that is based on how we have organized our collections already. Please help support that with some basic import functions that support custom embedded information. The information is already in your database - you just have to set it free!

1 Like
26

Ok, so I think you’ve identified two things:

  • Adding support for pulling “bootleg” from tags.
  • Some way to create/populate Roon tags based on tags in files

These are both reasonable ideas, but neither are fundamental changes–they are just more file tags that we could recognize + merge with our model, since we already have bootleg + user-tags in Roon–this is the same kind of incremental stuff we have been doing every 6 months or so since the beginning.

They are not what we have thought of as a “custom tags” feature in the past. To us, “custom tags” is about defining custom fields that can be displayed somewhere in the Roon UI and then deciding which file tags will populate them and how. Some other software supports this kind of thing. This is the “tag ghetto” I was referring to, and the area where I am having trouble with use cases to justify it…but that is distinct from the thing you’re asking for above.

I’m never going to respond positively to “just expose all of the power and let the users figure it out”. That is how you make product that is better for the 1% of users willing to figure it out and worse for the 99% who don’t care.

There is cost to complexity and a cost to releasing product that misunderstands the needs. Understanding the use cases is critical to making good product. You could make the argument that some of our “misses” in this area of the product happened because we didn’t understand the use cases.

2 Likes
27

Thanks for the quick response, Brian. The use case referring to bootlegs is not a major concern of mine. I was just trying to come up with a usable example of something that may be designated in embedded file data that could be imported into Roon and then potentially even imported right into your bootlegs field.

But yes, the second bullet, huge for me. And I assume for some subset of intense collection curators. This information might also fit into your conception of custom tags, but that isn’t where I was heading with it. I just want a way to have these tags dynamically create Roon tags.

The second part of this is to make Roon tags a bit more powerful with some Boolean logic. That is what helps tags then be used as filters.

If you’ve ever seen the Foobar Filters function (in Columns UI) in action, you’ll have some idea of what I’m getting at. Foobar doesn’t present this in a graphically appealing way - yes it is in lists and columns – but the feature is mega powerful. It can be used to sort through almost any set of media very quickly and efficiently to then be able to play or shuffle almost any combination. I think this could be done in Roon in a graphically appealing way, through a combination of tags brought together with Boolean logic.

Main goal, being able to perform object-by-object characterizations or classifications of any sort while storing that information in a location that can be repeatedly leveraged, rather than to have it only locked in the Roon database.

Please don’t take that as I want an exit from Roon. Far from it - I have really committed to Roon in many a way from a hardware perspective. But I have to think 20 years out, and the hundreds of hours that one puts in when one does object-by-object work has to be reusable.

You would definitely know better than I. My only take is that the 1% probably makes up more than 1% of the core that gives life to the Roon community, and so I would hope that our use cases can be enabled at least to some degree, as above. It sounds like you don’t disagree and that doing something like the ROONTAG-ALBUM idea then populating tags on albums within Roon is not a radical concept.

Thanks again for the reply.

1 Like
28

I understand the desire for a more flexible file import like matching file embedded tags to existing fields in roon (including creating roon tags). No one like to do work twice if the information already exist. I also agree with more functionality using the given tag system: I dare say a possibility of grouping tags could be a way to give more hierarchical structure for those who have a lot of tags. To take the example further, ““tunes suggested by Ian”… Dave … Lucy can be grouped to “recommendations from friends”. UI presented in the way like the genres (parent tag - album/track highlights - child tags)… how about that?

But in my opinion filtering should be done with the given focus feature, not with a script-driven query-tool. In some cases focus doesn’t behave like I expected: if I filter artists by genre ‘fusion’ I get maybe Miles Davis with 4 albums as result. Indeed, I have 4 albums of this artist but none has the genre fusion. The filter stops at level artists. Or: an artist is tagged with Pop/Rock and Keybord. Setting a filter ‘Excluding Classic’ the artist disapeares, because Keyboard is a subgenre of classic. But it’s also Pop/Rock. So the focus has room for further gains.

1 Like
29

Is “folder.jpg” a folder or a file?

30

This would be helpful. The way I do it now is by using 2-level tags; for example “Admin: Lossy Compression,” “Group: Chicago Bands” and “Group: MQA” and “Mood: Mellow.” This helps me organize them but a hierarchical display, even cooler with custom graphics rather than the mosaic of member objects, would be nice. I also think you can tag tags, for what it’s worth, so you could do some hierarchy there.

Regarding Focus and filtering, I agree a script would stick out like crazy relative to Roon’s workflows - definitely not what I’m looking for. If you’ve ever used Foobar’s Filter feature in Columns UI, that is a great example of how to very quickly zoom into a chosen group of content; graphically it could use improvement, and I don’t think it needs to be columns or as textual as it is often represented. Focus works alright - I think we need to control the logic better to make it as powerful as it could be.

31

Folder.jpg is a file.

32

This is sounding a bit like the discussion in another thread

Allowing Composition/Work and Movement/Part to be set externally and honoured on import of rescan. My Compositon tag is a custom tag managed in JRiver and is pretty well 100% populated but Roon I assume doesn’t look at it . I can’t see a way of “Prefer File” to force it

Mike

33

Already easily done using Roon Tags, the only thing missing is the ability to have Roon import these tags from the underlying files.

34

Kind of. You can tag tags I think and that would allow grouping of tags. But AFAIK all tags are still displayed together so you cannot group them and then surf them hierachically - i.e. the group tag and the base tags are displayed together, but not in some sort of way that allows drill-down.

Yes exactly. I would like to keep the dialog going on this point. I think there are a lot of users that would benefit from this, albeit some may not realize how powerful this could be.

35

Not sure why you’d need to see them heirachically

Something can for e.g. be assigned to Roon Tag One, Two and Three. Some items can have all 3 tags assigned, others 2 of them, others only one and others 0.

Browsing each of those tags will yield the outcomes relevant to those tags, so hierarchies are implicitly catered for if your Roon Tags are defined appropriately.

36

Why can’t Roon do what many other players can do – show individual cover art for albums in box sets. I have been asking for this feature since Roon first started, and am starting to feel this will never happen.

I doubt there will ever be a metadata source that would cover this adequately (especially for classical albums). Surely, this can’t be that difficult!!

2 Likes
37

By that I mean group tags within another tag and have them display at different levels in a drill down fashion. E.g. top level tag displays would be “Friend recommendations,” “Moods,”: “Formats” etc. and then when you click on “Friend Recommendations” you’d see the next page displaying “Bill,” “Amy,” Bob," etc.

It is not high on my list of Roon needs although I think it would be nice. I was responding to some post above that implied to me that is what someone was looking for.

38

It’s all set theory, all those browses can already be achieved if you apply Roon tags to the stuff.

39

Oy, I’m not explaining this well, or something. Anyway, nevermind.

40

I wish it was possible.

I think what @James_I is trying to explain is that you can drill down to lower levels of terms.

Friend Recommendations is the highest level and the names of friends are lower levels. You narrow the results by tag filtering.