Box Sets Confusion

[brian (Brian Luczkiewicz)]

Presumably hand-in-hand goes the ability to group tracks which do not have the same date/venue into performances in some way? (Also allowing us to fix Rovi when they have screwed this up.)

Yes

By the way, Live not being de-duped looks like an anomaly. When a complete performance is live, we don’t need to be told on every track line and on the main heading.

Agreed.

[Klaus_Kammerer1 (Klaus)]

OK - I was simplifying.

In general @Ludwig and @brian I would aree with your statements under the basic paradigm of automated metadata assignment. Forgive me when I am looking at this from a more manual mindset. Wouldn’t identifying a unique performance not being similar to assigning a WORKID tag to differentiate between different instances onf the same work on an album?

Performers: what about operas where the metadata reasonably has different performers for each track?
Work: what about excerpts, orcomplete performances plus encore (cf. all concertos in the Richter complete Melodiya)?

This is true if you’d list the performers on track level. For Opera this is a thing I personally dislike and I would not want to see it differ track by track. For me an opera (or an oratorio) has a “cast” which applies to the performance of the work - admittedly we are now back at the discussion about what defines a performance. But again, if third party metadata is providing these kind o finformation on a trackl level and you want to fill it, then you certainly have this problem.
I’d rather prefer metadata providers to focus on assigning roles to artists as far as opera is concerned

Recording date/place: what about those performances where each movement is recorded separately (cf. Horowitz Beethoven Sonatas, Zimerman/Rattle Brahms Concerto, etc…)

true - but the point here again is to identify what I would call a unique “peromance id” for a group of tracks. For an automated process this is a problem. For a manual process this is just setting the ID or am I missing someting?

To me it sounds as the biggest challenge is to deal with more than one content source in the first place.

[Ludwig (Ludwig van Marbach)]

This is true if you’d list the performers on track level. For Opera this is a thing I personally dislike and I would not want to see it differ track by track. For me an opera (or an oratorio) has a “cast” which applies to the performance of the work - admittedly we are now back at the discussion about what defines a performance. But again, if third party metadata is providing these kind o finformation on a track level and you want to fill it, then you certainly have this problem. I’d rather prefer metadata providers to focus on assigning roles to artists as far as opera is concerned

I totally agree with all of that (particularly the last point!), but it’s just a fact that third-party metadata sometimes works in a more granular but less useful way, listing only the names of the performers for each track (with no roles).

the point here again is to identify what I would call a unique “peromance id” for a group of tracks. For an automated process this is a problem. For a manual process this is just setting the ID or am I missing someting?

For me what you are missing is something in “just setting the ID”. For my collection that should be “just setting the ID 140,000 times”… I simply don’t have the time or inclination to do that much work when Roon can work it out automatically (by various means - both involving third party metadata and from my already existing tags).

[Klaus_Kammerer1 (Klaus)]

For me what you are missing is something in “just setting the ID”. For my collection that should be “just setting the ID 140,000 times”… I simply don’t have the time or inclination to do that much work when Roon can work it out automatically (by various means - both involving third party metadata and from my already existing tags).

fair point. I was thinking more based on a posibility to set or modiffy the “ID” manually for already identified perfromances like it should be possible with the WORKID tag. I have to admit, thought, that I did not use the WORKID tag, yet.

[brian (Brian Luczkiewicz)]

This is true if you’d list the performers on track level. For Opera this is a thing I personally dislike and I would not want to see it differ track by track. For me an opera (or an oratorio) has a “cast” which applies to the performance of the work

There is a subtlety worth pointing out here.

There are two possible definitions of the word performance:

• The performance “on earth”–i.e. humans playing in a concert hall at a time/date
• A performance “in your library”–i.e. an instance of a performance in your library, represented by a set of tracks.

The first definition isn’t actually very useful for software oriented towards cataloging media–it’s best left to encyclopedias.

So when I (and @Ludwig) talk about performances, we are using the second definition (in fact, from Roon 1.2->1.3 we changed from using the first definition to the second).

It’s a perfectly valid thing to aspire to cataloging performances “on earth”–and some of the comments you’ve made seem oriented towards this goal–but that is not our goal with this product right now.

The main problem with cataloging performances “on earth” is that we lose the ability to represent multiple instances of the same performance in your library. For example, if you have multiple masterings of the same recording, things get confused. Roon 1.0-1.2 were littered with edge cases where this mis-modeling of the data leaked through.

For example: one of the bugs we used to have before changing definitions was: if you have 2 masterings of the same CD, and you tap the composition header to play a symphony on one of them, you end up hearing each movement twice. Why? Because all of those tracks ended up associated with the same “performance” entity, and that’s what was being played when you clicked the header.

Likewise, in a world where we define “performance” as “performance on earth”, you would not be able to tag a recording of a symphony precisely, or favorite it, if you had multiple masterings in your library–since these tracks would be linked to the same “performance” without a clear way to separate them.

It became clear that we needed to be able to have a separate identity for each instance, not just one identity for the performance “on earth”.

There are practical concerns, too: No metadata source that we are aware of currently catalogs performances “on earth”. They all use this same, instanced, definition. So trying to reconstruct performances “on earth” becomes an error-prone data mining exercise.

The same goes for file tags–there is no guarantee that two instances of the same performance “on earth” will have the same metadata. If they didn’t, and we were using the “on earth” definition, we’d be left to resolve conflicts in the data. Generally, conflict resolution within the file tags for a single album goes pretty well, but it’s a disaster when attempted across albums. We’ve learned not to do this–it surprises people too often, and fixing the problems that it causes requires making potentially hundreds or thousands of tags perfectly consistent. Again, easy to do within an album, but not easy to do across a whole library.

This same distinction between “on earth” and “in your library” applies to more than performances. Albums and Tracks also use an “in your library” definition, too–this allows you to have duplicate copies of the same CD without having a single “album” that has two of each track. Performers/Composers/Artists, and Compositions are handled in the encyclopedic way–so they have a single identity “on earth”.

Not easy data modeling stuff, and there is almost no precedent for us to look towards in making these choices so there is strong “research” aspect to this project. This is why we iterate and see how people are living with our choices BEFORE opening up editing functionality

[Klaus_Kammerer1 (Klaus)]

Thanks a lot @brian for giving us an insight in your rationale. It gave me a lot of food for thought. Very much appreciated!

For example: one of the bugs we used to have before changing definitions was: if you have 2 masterings of the same CD, and you tap the composition header to play a symphony on one of them, you end up hearing each movement twice. Why? Because all of those tracks ended up associated with the same “performance” entity, and that’s what was being played when you clicked the header.

Interesting point. I initially would have thought that the “album” is a central part ot Roon’s data model and therefore would keep the two performances separated, But even in my simple thinking of Work/Performer/Venue key for a performance this would have been a duplicate

I didn’t think about different remasterings because I have to admit that I normally don’t keep older “versions” of my recordings in my library.

I just hope that the complexity of the topic does not discourage you to continue on your path, especially since we are a minority of your customer base. As I’ve said several times in this forum: I for my part are willing to be patient and I am very happy that you guys are fairly transparent as far as your rationale and strategy is concerned.

[Ludwig (Ludwig van Marbach)]

I didn’t think about different remasterings because I have to admit that I normally don’t keep older “versions” of my recordings in my library.

Remasterings bring me to another related topic: dealing with multiple remasterings and/or multiple instances of the same remastering of one performance on earth. I mean, when the same actual musical performance comes twice in the list of performances on a work details page, representing probably two physical media (a single CD; and a collected box, for example) carrying the same tracks.

We need to be able to merge them, and chose a Primary version, while at the same time retaining the best metadata (date, venue etc.) for the performance on earth.

Here’s an example.

The 4th and 5th items are the same performance on earth (and in this case the same mastering). I need them merged into one entry. Moreover, I want the venue from the 4th item (which is the correct one) even though it might have been the 5th item which is the preferred remastering.

As an ambition, Roon should IMO to learn these “stackings” from me and make them automatic for users with the same material in their library.

@brian this is a flag for ticket #13730.

[Mike_O_Neill]

I sort of started this and ran away, I just came across it.

The truth is that this was an insurmountable issue for me and Roon so I baled out.

I handle this with Custom tags in JRiver. Each box has a Name tag separate from an album name. Each disc has a name , summarizing the disc content.

It’s manual but works just fine.

The primary issue to me is the lack of user defined views in Roon.

I JRiver I can define a box set view which makes navigation so simple. Adding this feature would allow users to set up a personal navigation method.

I really miss Roon and I am far from DeRoonified as my wife calls it but adding navigation frustration isn’t the name of the game.

One day classical metadata will be standardized, bit at 67 I may well not see it

Mike