A track's release id is missing where the prober does not report it #40

New issue

Closed

opened 2026-08-03 16:46:21 +02:00 by Claude · 1 comment

Claude commented

2026-08-03 16:46:21 +02:00

Collaborator

MusicBrainzTrack holds 3041 rows upstream and 2939 here — 102 short. Unlike
the recording (#29) this is not a frame the prober refuses to report: the
release track id is a plain text tag, and ffprobe surfaces it as
MusicBrainz Release Track Id.

Three candidates, in the order they are worth testing:

The prober reads the container's format tags. Matroska keeps its tags per
track, which land in ffprobe's stream metadata instead — and upstream has an
explicit fallback key for exactly that shape
(AudioFileProber.cs:654-680, track.musicbrainz_release_track_id).
Any file where ffprobe reports nothing and a tag library reads it: APEv2 on
an mp3, ID3v2 on a flac.
A value ffprobe joined that nothing splits the same way.

Now that a track is read a second time (#27), the experiment is cheap: add
ItemKey::MusicBrainzTrackId to read_tags and compare what it finds against
what the prober reported, across the library. If the second reader answers for
roughly the missing hundred, this is the same family as #29.

Separately and not a count: first_music_brainz_id splits on / alone, while
ffprobe joins repeated values with ;. A tag holding two ids is stored whole
here and as the first of them upstream — a wrong value rather than a missing
row.

`MusicBrainzTrack` holds 3041 rows upstream and 2939 here — 102 short. Unlike the recording (#29) this is not a frame the prober refuses to report: the release track id is a plain text tag, and ffprobe surfaces it as `MusicBrainz Release Track Id`. Three candidates, in the order they are worth testing: - The prober reads the container's **format** tags. Matroska keeps its tags per track, which land in ffprobe's stream metadata instead — and upstream has an explicit fallback key for exactly that shape (`AudioFileProber.cs:654-680`, `track.musicbrainz_release_track_id`). - Any file where ffprobe reports nothing and a tag library reads it: APEv2 on an mp3, ID3v2 on a flac. - A value ffprobe joined that nothing splits the same way. Now that a track is read a second time (#27), the experiment is cheap: add `ItemKey::MusicBrainzTrackId` to `read_tags` and compare what it finds against what the prober reported, across the library. If the second reader answers for roughly the missing hundred, this is the same family as #29. Separately and not a count: `first_music_brainz_id` splits on `/` alone, while ffprobe joins repeated values with `;`. A tag holding two ids is stored whole here and as the first of them upstream — a wrong value rather than a missing row.

Claude referenced this issue

2026-08-03 16:50:43 +02:00

An mp3's recording id is in a frame ffprobe does not report #29

Claude commented

2026-08-03 19:30:41 +02:00

Author

Collaborator

Fixed and merged.

Two things were needed. ItemKey::MusicBrainzTrackId is one of the keys the
file's own reading answers — and, the larger one, that reading now asks every
block of tags a file carries rather than only the one its format calls primary.
The 102 files were flacs written with an ID3v2 block in front of their
comments, which nothing had been looking at.

A block in front answers for a field both of them name, which is upstream's own
order rather than the format's: of the 59 tracks whose genres still differed
after #27, 55 were this.

MusicBrainzTrack: 2939 → 3041, against upstream's 3041, with no path where
the value differs.

Fixed and merged. Two things were needed. `ItemKey::MusicBrainzTrackId` is one of the keys the file's own reading answers — and, the larger one, that reading now asks every block of tags a file carries rather than only the one its format calls primary. The 102 files were flacs written with an `ID3v2` block in front of their comments, which nothing had been looking at. A block in front answers for a field both of them name, which is upstream's own order rather than the format's: of the 59 tracks whose genres still differed after #27, 55 were this. `MusicBrainzTrack`: 2939 → **3041**, against upstream's 3041, with no path where the value differs.

Claude closed this issue

2026-08-03 19:30:42 +02:00