Mosaic Android app - Qobuz Track List

Support
14

@PAR It has all to do with Mosaic.

For classical music Qobuz delivers two levels of metadata through their API that local players can leverage. AFAIK Lyrion is the only player I know of that does this correctly. Lyrion displays both levels consistently. Mosaic could also do this, but it takes some effort to understand the documentation and to implement the retrieval and display of the two levels correctly.

I had previously raised this same topic, unfortunately it has never been addressed.

Qobuz Metadata and Mosaic - dCS Products / Feature Requests - dCS Community

Mosaic Android app - Qobuz Track List - Support - dCS Community

When I posted this deficit originally, I was hoping dCS would take the initiative and fix this, but unfortunately this has not happened so far.

This has nothing to do with the tagging of locally stored music. Been there and spent hundreds of hours tagging my own collection.

Luckily Qobuz Connect is available now, so we don’t really need Mosaic to play Qobuz anymore.

PS. This is what Gemini has to say about the two levels of metadata as Qobuz uses them. YMMV

In the Qobuz API (specifically the album/get and track/get endpoints), the fields corresponding to the hierarchical “Work” and “Movement” metadata are not named as intuitively as they appear in the user interface.

Based on technical audits of the Qobuz JSON responses, the two levels you are looking for are generally mapped as follows:

1. The Work Title (MP3Tag: WORK)

In the Qobuz API, this is typically represented by the work field (where available) or, more reliably for older integrations, the work_title.

  • API Field Name: work

  • Context: This is often a top-level attribute within a track object. However, it is important to note that Qobuz’s implementation of this field is inconsistent. For many albums, the “Work” isn’t a dedicated tag but is instead parsed from a specific track type.

  • The “Group” Failure Mode: In the JSON response for an album, tracks that belong to the same work often share an identical work string, allowing players to group them.

2. The Movement Title (MP3Tag: PART)

The title of the movement itself—the specific “Andante” or “Allegro”—is stored in the standard title field at the track level.

  • API Field Name: title

  • The Logic: Qobuz distinguishes between the Display Title (what you see in the list) and the Work Title. In a classical context:

    • The work field contains: Symphony No. 5 in C minor, Op. 67

    • The title field contains: II. Andante con moto

3. Structural Comparison

To give you the “architectural” view of how this looks in a raw JSON response:

MP3Tag Element Qobuz API Field Example Value
WORK work “Symphony No. 9 in D Minor, Op. 125 ‘Choral’”
PART title “IV. Presto - Allegro assai”
COMPOSER composer “Ludwig van Beethoven”

Critical Insights & Fragility Flags

Since you value robustness and understanding failure modes, there are three key “architectural” quirks in Qobuz’s classical metadata you should be aware of:

  1. The is_classical Boolean: Qobuz uses an internal flag called is_classical. When this is false, the work field is almost always null, even if the music is technically neoclassical or crossover.

  2. Concatenation Risk: Many third-party apps that use the Qobuz API (like older versions of Roon or dCS Mosaic) fail to see the work tag separately because Qobuz sometimes provides a “pre-rendered” title. In these cases, the API returns a title field that has already concatenated the work and movement (e.g., "Symphony No. 5: II. Andante"). A robust system cannot rely on the work field being populated for 100% of the classical catalog.

  3. The “Work” Object vs. String: Unlike the Apple Music Classical API, which uses a dedicated Work object with its own unique ID, Qobuz primarily treats “Work” as a string-based metadata attribute attached to a track. This makes “grouping by work” fragile because minor typos in the string across different tracks in the same album will break the grouping.