Inconsistent display of classical tags between PCM and DSD files

[animus]

Outstanding work. Thank you for this elucidation on the mechanics behind the matter!

[guardajoias]

Actually it’s a little bit worse than I thought, but still eminently fixable: for FLAC files, it is indeed the GROUPING tag that Grouping is mapped to, not Work Name! So even a little more inconsistent. But again it can be easily fixed by Audirvana with a simple remapping. Ideally also changing the file name from Grouping to work Name to remove confusion…

[guardajoias]

To make things a bit more confusing, Roon also uses slightly different tags for Works, instead of Work Name, it uses WORK (WORK for FLAC, TXXX:WORK for ID3V2, and ----:com.apple.iTunes:WORK for Apple), and for the Movement Name it uses PART (respectively PART for FLAC, TXXX:PART for ID3V2, and ----:com.apple.iTunes:PART for Apple). This is however compatible with the Work Name and Movement Name tags with respective Apple atoms, as Audirvana can read both schemes and display whichever it finds. It does not do this for now, and uses a mismatch of tags: Grouping for FLAC and DSD, ©wrk for Apple (which corresponds to Work Name), and reads the movement names for Apple (©mvn), but the title (TITLE or TIT2) for FLAC and DSD.

That’s why in many cases Audirvana simply does not display the work and movements.

It can be fixed easily by correctly mapping the fields and corresponding tags in the 3 systems, and using fallbacks: for example for the Work for FLAC: read WORK–NAME (read/write), then WORK (read only), then GROUPING (last resort)…

[guardajoias]

I prepared the following proposed changes with explanations with the help of Claude AI to summarizes what needs to be done to the mapping of fields to tags in the Vorbis, Apple and ID3V2 schemes to cover FLAC, ALAC and DSD files.

Hopefully this will be useful to Audirvana @Antoine .

Updating the Audirvana Classical Metadata Mapping

Observed behaviour in Audirvana, and the changes that would make classical libraries resolve correctly
across all three container formats.

Basis. Two controlled experiments. First, a three-way test on one album, Mozart — Clarinet & Oboe Concertos (Hogwood /
Academy of Ancient Music, Decca 1984), held in the library as ALAC and as FLAC, tagged from the same
source with the same values, plus a third copy of the FLAC with the GROUPING tag removed and nothing
else changed. Audirvana’s display and its own metadata inspector were captured for each; the tag block of
each file was then read byte-level with mutagen.

Second, a sentinel test on a DSF: one track of Ravel — Daphnis et Chloé (LSO / Gergiev, LSO Live) with
a distinct marker string written into each of the five candidate fields, so that whatever Audirvana displays
names its own source.

Because the files differ only in the container and in the tags deliberately changed, every difference in
display is attributable to the mapping and nothing else. Nothing below is inferred from behaviour alone.

The finding in one line. Audirvana already does the right thing on M4A — it loads ©wrk into its
Grouping field and ©mvn into its Title field. On FLAC and ID3 it loads the Grouping and Title tags
instead, ignoring the Work Name, Work and Movement Name fields entirely. The request is that the M4A mapping
be mirrored onto the other two containers.

Legend: correct today · needs changing · open

---

1. The three-way exhibit

All three files carry identical values except where noted. Verified contents of track 1:

	ALAC	FLAC	FLAC (GROUPING removed)
Work Name	©wrk = Clarinet Concerto In A, K 622	WORK--NAME = same	WORK--NAME = same
Work (Roon style)	----:com.apple.iTunes:WORK = same	WORK = same	WORK = same
Grouping	absent	GROUPING = same	absent
Movement Name	©mvn = Allegro	MOVEMENTNAME = Allegro	MOVEMENTNAME = Allegro
Movement No. / Count	©mvi = 1, ©mvc = 3	MOVEMENT = 1, MOVEMENTTOTAL = 3	same
Part	----:…:PART = I. Allegro	PART = I. Allegro	same
Title	©nam = ␣Clarinet Concerto In A, K 622 : 1. Allegro	TITLE = same	same

What Audirvana’s own track metadata inspector shows for that track:

Audirvana field	ALAC	FLAC	FLAC (GROUPING removed)
Grouping	Clarinet Concerto In A, K 622	Clarinet Concerto In A, K 622	empty
Title	Allegro	Clarinet Concerto In A, K 622 : 1. Allegro	Clarinet Concerto In A, K 622 : 1. Allegro

And what the album view renders. ALAC — work as heading, movement alone on the row:

Clarinet Concerto In A, K 622                          ← heading
  1.  Allegro
  2.  Adagio
  3.  Rondo: Allegro
Oboe Concerto In C, K 314                              ← heading
  4.  Allegro Aperto
  5.  Adagio Non Troppo
  6.  Rondo: Allegretto

FLAC — same album, same values in the equivalent fields. The headings are right; every row now repeats
the work name:

Clarinet Concerto In A, K 622                          ← heading
  1.  Clarinet Concerto In A, K 622 : 1. Allegro
  2.  Clarinet Concerto In A, K 622 : 2. Adagio
  3.  Clarinet Concerto In A, K 622 : 3. Rondo: Allegro
Oboe Concerto In C, K 314                              ← heading
  4.  Oboe Concerto In C, K 314 : 1. Allegro Aperto
  5.  Oboe Concerto In C, K 314 : 2. Adagio Non Troppo
  6.  Oboe Concerto In C, K 314 : 3. Rondo: Allegretto

FLAC with the single GROUPING tag deleted, nothing else changed. Both headings are gone and the album
collapses to a flat list of six, although WORK--NAME and WORK are still present and correct:

  1.  Clarinet Concerto In A, K 622 : 1. Allegro
  2.  Clarinet Concerto In A, K 622 : 2. Adagio
  3.  Clarinet Concerto In A, K 622 : 3. Rondo: Allegro
  4.  Oboe Concerto In C, K 314 : 1. Allegro Aperto
  5.  Oboe Concerto In C, K 314 : 2. Adagio Non Troppo
  6.  Oboe Concerto In C, K 314 : 3. Rondo: Allegretto

Row text is shown in full here; in the application the Title column truncates it, so the part a listener
actually loses is the movement — the only part that differs between rows.

Four conclusions follow directly.

1 — On M4A, Grouping is fed by ©wrk. ©grp is absent from the ALAC file, yet the inspector’s Grouping
field holds the work name and the heading renders. Nothing else in the file carries that value except
©wrk and the WORK freeform atom.

2 — On M4A, Title is fed by ©mvn. The inspector shows Allegro, not the file’s actual ©nam
(␣Clarinet Concerto In A, K 622 : 1. Allegro) and not PART (I. Allegro). Audirvana substitutes the
movement name into its Title field. That is the behaviour being asked for on the other containers — the
machinery already exists.

3 — On FLAC, Grouping is fed by GROUPING and by nothing else. Delete that one tag and the Grouping
field goes empty and every work heading disappears, even though WORK--NAME and WORK are still present in
the file with the correct value. This is the decisive result: the two genuine work fields are not read at
all.

4 — On FLAC, Title is fed by TITLE. MOVEMENTNAME = Allegro sits unused in all three FLAC states, as
does PART.

---

1b. The ID3 sentinel exhibit

One track of a DSF, with a distinct marker written into every candidate field. Verified in the file:

Frame	Yate field	Value written
TIT1	Grouping	ZZ-GROUPING
TXXX:Work--Name	Work Name	ZZ-WORKNAME
TXXX:WORK	Work (custom)	ZZ-WORK
MVNM	Movement Name	ZZ-MOVEMENT
TXXX:PART	Part (custom)	ZZ-PART
TIT2	Title	ZZ-TITLE

MVIN was left at 1/10. The file carries no GRP1 frame and no TXXX:YiTG, so Grouping maps to TIT1
in the standard way rather than the Apple-compatibility variant.

What Audirvana showed:

ZZ-GROUPING                                            ← heading
  1.  ZZ-TITLE

and its inspector for that track: Grouping = ZZ-GROUPING, Title = ZZ-TITLE.

On ID3, Grouping is fed by TIT1 and Title by TIT2. ZZ-WORKNAME, ZZ-WORK, ZZ-MOVEMENT and
ZZ-PART appear nowhere — TXXX:Work--Name, TXXX:WORK, MVNM and TXXX:PART are all unread. ID3
therefore behaves exactly as FLAC does, and differs from M4A in exactly the same two places.

---

2. The table

Grouping field (drives the work heading)

Container	Audirvana reads today	Requested
M4A (ALAC / AAC)	©wrk	unchanged; optionally ----:com.apple.iTunes:WORK then ©grp as fallbacks
FLAC (Vorbis)	GROUPING only	WORK--NAME (r/w) → then WORK (r/o) → then GROUPING (last resort)
ID3v2 (DSF / MP3 / AIFF)	TIT1 only	TXXX:Work--Name (r/w) → then TXXX:WORK (r/o) → then TIT1 (last resort)

Title field (drives the track line)

Container	Audirvana reads today	Requested
M4A	©mvn	unchanged
FLAC	TITLE	MOVEMENTNAME (r/w) → then MOVEMENT--NAME (r/o) → then TITLE (fallback)
ID3v2	TIT2	MVNM (r/w) → then TXXX:Movement--Name (r/o) → then TIT2 (fallback)

Supporting fields

Field	FLAC	ID3v2	M4A	Purpose
Movement Number	MOVEMENT	MVIN (holds number/count)	©mvi	an integer, so ordering is reliable and the numeral can be rendered in the host’s own style
Movement Count	MOVEMENTTOTAL	MVIN	©mvc	—
Show Work Name	SHOWMOVEMENT	SHOWMOVEMENT	shwm	an explicit override where present — it should not be a prerequisite. Absent from every file here, including the ALAC that displays correctly.

(r/w) means the field an editor writes when you type into it — read it first, and write it. (r/o) means
read it, do not write it. Read broadly, write narrowly.

---

3. Why these changes

This is a mapping gap, not a missing feature

Audirvana renders the Mozart ALAC exactly right: work as heading, bare movement name as the track line. The
FLAC of the same album, with the same values in the equivalent fields, renders the work name twice — once as
the heading and again at the start of every row, and shows nothing at all once GROUPING is absent. The DSF
sentinel test shows ID3 behaving identically to FLAC. No feature is missing: the same two entries point at
the wrong tags in two of the three mapping tables.

The cost of the current FLAC mapping

Correctly tagged files show nothing. The third test file is the general case for any library tagged to
the Apple or Roon conventions rather than the Grouping convention: WORK--NAME and WORK both populated,
GROUPING empty, and Audirvana shows a flat list with no work structure at all. Three further verified
FLACs in the sample set are in exactly that state — Porgy and Bess, Roméo et Juliette and The Children
of Rosenthal all carry WORK and/or WORK--NAME with no GROUPING.

And the row text is the work name. In a narrow column the prefix is identical on every row and survives
truncation, while the movement — the only part that differs between rows — is what gets cut off.

Please do not derive the movement by trimming the Title

The tempting shortcut does not survive contact with real files. Verified Title values from four albums,
alongside the movement already stored in a dedicated field:

Album	TITLE / TIT2 as stored	Delimiter	Movement Name field
Mozart, Clarinet Concerto	␣Clarinet Concerto In A, K 622 : 1. Allegro	␣:␣ + leading space	Allegro
Gershwin, Porgy and Bess	Porgy and Bess :Act 1: Scene 1: Summertime	␣:	Act 1: Scene 1: Summertime
Gounod, Roméo et Juliette	Roméo et Juliette:Acte I:Ange Adorable…	:	Acte I:Ange Adorable…
Ravel, Daphnis et Chloé (DSF)	Daphnis et Chloé: i. Introduction et Danse Religieuse	:␣	Introduction et Danse Religieuse

Four albums, four delimiter conventions, one with a stray leading space, and two where the delimiter also
occurs inside the movement. Movement numbering appears as 1., I. and i. in the same sample. The
dedicated fields have none of these problems — and Audirvana already reads the M4A one.

The numeral should come from one place

MOVEMENT / MVIN / ©mvi holds the movement number as an integer, and MOVEMENTTOTAL / ©mvc the
count. Movement Name deliberately omits the numeral because Apple stores number and name separately — the
Mozart ALAC carries ©mvn = Allegro with ©mvi = 1 and ©mvc = 3. PART is the field that embeds the
numeral in text (I. Allegro in the same file). Taking a numeral from the row position and from text
embedded in the field yields 1. I. Allegro.

Which fields are genuine work fields

WORK--NAME and TXXX:Work--Name are what Yate — and the Apple-compatible convention generally — writes
for the Work field; ©wrk is its M4A counterpart, which Audirvana already reads. WORK (bare) is the Roon
and MusicBrainz Picard convention for the same concept. GROUPING and TIT1 are the separate user-defined
Grouping field, which merely sits next to Work in most tagging UIs. Trying the work fields before falling
back to Grouping costs nothing on files that carry only Grouping, and fixes files tagged properly.

Why a gap like this can go unreported for a long time. A file with the Work field and the Grouping
field populated with the same value renders correctly under either mapping, and a great many files are in
that state — several tagging applications write both, and users tend to fill in whatever their player
happens to display until something works. The problem only becomes visible on files tagged to the Work
convention alone, which is exactly what the third test file above represents, and what a library tagged
for Apple Music or Roon looks like throughout.

---

4. What is still open

One question remains, and it is minor. ©wrk versus the WORK freeform atom on M4A is not strictly
separated, because both are present with the same value in every ALAC sampled. It is strongly implied
that ©wrk is the source: the equivalent WORK tag is present in the FLAC and in the DSF and is ignored in
both, which makes a freeform WORK reader on M4A unlikely. The distinction has no practical consequence —
©wrk should be read first either way.

The sentinel method settles it in one file if a fully explicit result is wanted: on a single ALAC track set
©wrk = ZZ-WORKNAME, ----:com.apple.iTunes:WORK = ZZ-WORK and ©grp = ZZ-GROUPING, and read the heading.

---

Appendix — verified tag contents

Read with mutagen. These are the files the observations were made against.

The test trio — Mozart: Clarinet & Oboe Concertos, track 1

Field	ALAC	FLAC	FLAC (no GROUPING)
Work Name	©wrk = Clarinet Concerto In A, K 622	work--name = same	same
Work	----:…:WORK = same	work = same	same
Grouping	absent	grouping = same	absent
Movement Name	©mvn = Allegro	movementname = Allegro	Allegro
Movement Number	©mvi = 1	movement = 1	1
Movement Count	©mvc = 3	movementtotal = 3	3
Part	----:…:PART = I. Allegro	part = I. Allegro	I. Allegro
Title	©nam = ␣Clarinet Concerto In A, K 622 : 1. Allegro	title = same	same
Show Work Name	absent	absent	absent

Other FLAC files — all in the “correctly tagged, no GROUPING” state

File	WORK--NAME	WORK	GROUPING	MOVEMENTNAME	TITLE
Gershwin, Porgy and Bess	Porgy and Bess	same	absent	Act 1: Scene 1: Summertime	Porgy and Bess :Act 1: Scene 1: Summertime
Gounod, Roméo et Juliette	Roméo et Juliette	same	absent	Acte I:Ange Adorable…	Roméo et Juliette:Acte I:Ange Adorable…
Desyatnikov, Children of Rosenthal	absent	The Children of Rosenthal	absent	Tableau 1 - A silent night…	Tableau 1 - A silent night…

Other M4A files

File	©wrk	©grp	©mvn	©nam
Prokofiev, Symphony No. 1 (current tagging)	Symphony No.1 in D major, Op.25 'Classical Symphony'	absent	Allegro	Symphony No.1…:I. Allegro
Mozart, Requiem K 626	Requiem In D Minor, K 626	same value	Dies Irae	Requiem In D Minor, K 626 : 2. Dies Irae
Bach, BWV 1064	Concerto In C For 3 Harpsichords, BWV 1064	same value	Allegro	␣Concerto In C For 3 Harpsichords, BWV 1064 : 1. Allegro
Verdi, Nabucco	absent	absent	absent	Nabucco - Va Pensiero

ID3v2

File	TXXX:Work--Name	TXXX:WORK	TIT1	MVNM	MVIN	TIT2
Ravel, Daphnis et Chloé (DSF), as tagged	Daphnis et Chloé	Daphnis et Chloé	Daphnis et Chloé	Introduction et Danse Religieuse	1/10	Daphnis et Chloé: i. Introduction et Danse Religieuse
Ravel, Daphnis et Chloé (DSF), sentinel copy	ZZ-WORKNAME	ZZ-WORK	ZZ-GROUPING	ZZ-MOVEMENT	1/10	ZZ-TITLE

The sentinel copy also carries TXXX:PART = ZZ-PART, and no GRP1 or TXXX:YiTG frame.

[Agoldnear]

I’m wondering if a different approach to managing the sorting of different file formats by employing ‘Smart Playlists’ would be more direct..

How To Sort, Use Filters & Create Smart Playlists in Audirvāna

Playlists