Continuing Qobuz metadata integration issues

@support, I have tried reporting this issue numerous times as have many others. When adding an album from Qobuz, almost all metadata is being missed by roon. This information is clearly available using the Qobuz apps but not with roon. This is an easily reproducible general case and affects large numbers of Qobuz albums. It seems to me a very basic issue with the way in which the Qobuz integration was done.

It is difficult for me to understand what the point was in tweaking the search performance in build 416 if roon cannot find an album in the first place if it searched for the age of the universe because there is no basic metadata?

Here is another example (just an example, there are many, many others, it is an extremely common issue). This is how an album looks in Qobuz:

There is composer info, release info and the multi-part compositions have titles and are correctly grouped with identifying (and searchable) catalog numbers.

This is how the same album looks in roon:

Now there are no composer credits, incorrect release info, no composition titles, let alone catalog numbers, and no multi-part grouping. The album is to all intents and purposes invisible to roon on the most common search criteria (composer and/or composition) and unplayable in any other context than playing the album straight through (if you can find it).

In order to fix this, it requires over 30 manual edits and a lot of trial and error grappling with the undocumented way in which roon goes about parsing a multi-part composition title. So in case this helps anyone else, the canonical composition form of the English Suites is this:

English Suite, for keyboard No. 4 in F major, BWV 809 (BC L16): I. Prelude

The basic editing task is to add composer (Johann Sebastian Bach) to every track title instance and prepend the composition to every orphan part name. However, there are two commas before the colon (demarcating TITLE: PART) and roon will break the TITLE/PART on those commas instead of the colon to give:

English Suite
for keyboard No. 4 in F major, BWV 809 (BC L16): I. Prelude

or if you remove the first comma

English Suite for keyboard No. 4 in F major
BWV 809 (BC L16): I. Prelude

so both commas have to be removed in your manual edit after which roon will automatically put the commas back to finally give

English Suite, for keyboard No. 4 in F major, BWV 809 (BC L16)
I. Prelude

To a certain extent I can understand why tweaks to search performance was given priority in build 416. Performance issues actually made me stop using roon altogether for a while and start the process of going back to CD based replay (probably settling on a Luxman D-06u with a USB input so I can have a foot in all camps). But performance is only half a fix. There has to be something for roon to search on in the first place, so these ongoing systemic issues with Quobuz metadata integration really need to be addressed.

1 Like

Hi @Tony_Casey,

Please see my post here addressing this topic:

Thanks Dylan, but I am not seeing an “on occasion” issue. My experience is that it is an “every other download” type of issue. There are a number of similar complaints. Many do not complain as they assume that one or two example complaints is sufficient rather than initiating a class action every time. This appears to have been the case with the performance issue.

If I have understood you correctly when you cannot find an “object” match with your metadata suppliers all you have is some “text” from Qobuz. But is there really no pattern to the text? If that is the case then I get why you are having problems but that just seems extraordinary. I know that there was a time in may industries that mapping between different data formats was non-trivial but this was commoditised years ago? Surely the Qobuz developers know where to look for “Johann Sebastian Bach” in whatever convention Qobuz uses to store its metadata.

I find it best to never assume things like that. :roll_eyes:

Assume things like what?

That intelligent decisions were made regarding data.

That I can believe but I would be incredulous if there were not some minimum structure to the data necessary to predictably build millions of screens.

I think that Qobuz’s meta data model and Roon’s are very different. It is implied that one is purely textually based, while the other is object based. I agree that some type of connective plumbing should be (if not already) there to help with this since, I would guess, most everyone else’s data is also just text. And this would be the 2nd rodeo, so to speak.

It has not been mentioned but it is also possible that use of Qobuz’ meta-data maybe restricted in the licensing agreement to only be used in an identification process and not allowed to be displayed.

Hi Tony,
I’m a new Roon/Qobuz subscriber and this issue is driving me crazy.
I can’t seem to find any information that’s more up to date than this thread.
Do you know any more?

Sorry, no I don’t. Roon has a long-standing principle of not publishing road-maps so even if roon were working on this no one would know. Personally though, I doubt it has much of a priority. There are just too many other library management and metadata loose-ends stretching back years.

Thanks for taking the time to answer. How annoying, when Roon makes such great show of its talent with metadata. Hmm…

Have a good day.

Do we know where Roon is regarding integration of Qobuz metadata? I recently started a trial and while overall I’m liking it a lot, I’m finding that the work/part recognition by Roon is hit or miss.

In most cases, looking at the album through Qobuz’s page will correctly show work/parts, but Roon displays a flat list of tracks. I’ve also seen examples where one or two works are recognized by Roon but others on the same album are not.

I can provide examples if that’s helpful.

Here’s anther example of a recent issue.

Roon and Qobuz need to stick their heads together (virtually) and get this sorted for good. On that example Qobuz clearly f&%§d-up on the tagging, which is why the compositions dont match up.