An album artist is read from a key upstream does not read #42

New issue

Closed

opened 2026-08-03 19:31:04 +02:00 by Claude · 1 comment

Claude commented

2026-08-03 19:31:04 +02:00

Collaborator

A track's album artist is read from a key upstream's own reader does not read.

lofty maps the non-standard Vorbis key ALBUM ARTIST — with a space — to the
album artist (lofty/src/tag/item.rs); ATL maps only ALBUMARTIST. So this
server reads a name where upstream reads none, and prefers the spaced key's
value where a file carries both.

Measured on the reference library, after #39:

44 tracks whose AlbumArtists column differs from upstream, every one of
them this — Grimes + d'Eon|Grimes here against upstream's Grimes.
67 PeopleBaseItemMap rows more than upstream, every one an AlbumArtist,
32 of them files whose only album-artist key is the spaced one.
It reaches the album summarised above them: 5 album rows differ the same way.

Two shapes to decide between: refuse the keys upstream's reader does not map,
which means keeping a list of what ATL reads per format; or read the tag blocks
directly rather than through the generic key table, where the raw key name is
visible.

Not a splitting question — the value is one string either way.

A track's album artist is read from a key upstream's own reader does not read. `lofty` maps the non-standard Vorbis key `ALBUM ARTIST` — with a space — to the album artist (`lofty/src/tag/item.rs`); ATL maps only `ALBUMARTIST`. So this server reads a name where upstream reads none, and prefers the spaced key's value where a file carries both. Measured on the reference library, after #39: - 44 tracks whose `AlbumArtists` column differs from upstream, every one of them this — `Grimes + d'Eon|Grimes` here against upstream's `Grimes`. - 67 `PeopleBaseItemMap` rows more than upstream, every one an `AlbumArtist`, 32 of them files whose only album-artist key is the spaced one. - It reaches the album summarised above them: 5 album rows differ the same way. Two shapes to decide between: refuse the keys upstream's reader does not map, which means keeping a list of what ATL reads per format; or read the tag blocks directly rather than through the generic key table, where the raw key name is visible. Not a splitting question — the value is one string either way.

Claude referenced this issue

2026-08-03 20:14:19 +02:00

An ID3v2 genre frame is split where upstream keeps it whole #44

Claude commented

2026-08-03 20:54:25 +02:00

Author

Collaborator

The tag reader mapped keys upstream's does not, so a file spelling its album
artist one way was billed for a person upstream never credits.

Upstream reads tags with ATL, this port with lofty, and the two disagree about
which key names which field. ATL at the pinned version maps ALBUMARTIST only
in a Vorbis comment, TP2/TPE2 only in an ID3v2 tag (a user-defined TXXX
frame goes to additional fields, never to the album artist), both ALBUMARTIST
and ALBUM ARTIST in an APE tag, and aART only in MP4. lofty additionally
maps a spaced ALBUM ARTIST comment and a TXXX frame named for the field.

Tag blocks are now read directly, with the keys upstream's reader does not map
removed before lofty's table runs. lofty's generic view discards the raw key, so
filtering after the fact is not possible.

A second defect fell out of it: the fallback to the prober's own tags was per
key, so where the reader was made to answer "no album artist", ffprobe's
ALBUM ARTIST supplied it again. A reader that opened a file now answers every
key it reads, empty where the file names none — an empty answer is the file
saying nothing, and is the whole answer. A file no reader can open still keeps
what the prober made of it.

Measured over 5387 tracks against upstream's own database:

	before	after
tracks whose `AlbumArtists` differ	44	0
albums whose row differs	5	0
`PeopleBaseItemMap` rows	9218	9151

The people table is now row-for-row identical to upstream — EXCEPT in both
directions over path, name, role and both orderings is empty. Five artist values
this port carried and upstream did not are gone.

The review checked the mapping table against ATL's own source at the version
Directory.Packages.props pins, rather than against this description of it, and
found one more over-read on the way: lofty maps RIFF's IMUS to a composer
where upstream's WAV reader maps no composer at all. Fixed here too, though no
file in either library is a .wav.

Genres are untouched by this and still differ on 4 tracks, which is #44.

The tag reader mapped keys upstream's does not, so a file spelling its album artist one way was billed for a person upstream never credits. Upstream reads tags with ATL, this port with lofty, and the two disagree about which key names which field. ATL at the pinned version maps `ALBUMARTIST` only in a Vorbis comment, `TP2`/`TPE2` only in an `ID3v2` tag (a user-defined `TXXX` frame goes to additional fields, never to the album artist), both `ALBUMARTIST` and `ALBUM ARTIST` in an APE tag, and `aART` only in MP4. lofty additionally maps a spaced `ALBUM ARTIST` comment and a `TXXX` frame named for the field. Tag blocks are now read directly, with the keys upstream's reader does not map removed before lofty's table runs. lofty's generic view discards the raw key, so filtering after the fact is not possible. A second defect fell out of it: the fallback to the prober's own tags was per key, so where the reader was made to answer "no album artist", ffprobe's `ALBUM ARTIST` supplied it again. A reader that opened a file now answers every key it reads, empty where the file names none — an empty answer is the file saying nothing, and is the whole answer. A file no reader can open still keeps what the prober made of it. Measured over 5387 tracks against upstream's own database: | | before | after | |---|---|---| | tracks whose `AlbumArtists` differ | 44 | **0** | | albums whose row differs | 5 | **0** | | `PeopleBaseItemMap` rows | 9218 | **9151** | The people table is now row-for-row identical to upstream — `EXCEPT` in both directions over path, name, role and both orderings is empty. Five artist values this port carried and upstream did not are gone. The review checked the mapping table against ATL's own source at the version `Directory.Packages.props` pins, rather than against this description of it, and found one more over-read on the way: lofty maps RIFF's `IMUS` to a composer where upstream's WAV reader maps no composer at all. Fixed here too, though no file in either library is a `.wav`. Genres are untouched by this and still differ on 4 tracks, which is #44.

Claude closed this issue

2026-08-03 20:54:25 +02:00