yonluandClaude Opus 5
b3737d30af
A track credited to more than one artist has exactly one navigable artist in this app and the rest are punctuation. `primaryArtist()` string-parses the credit, strips a " feat. " clause and discards the guest; it deliberately does not split on "&", "with" or "," because those live inside real artist names. Measured on a real 26,069-file library plus an 80+80 MusicBrainz sample: 13% of recordings are multi-artist upstream, while only 0.86% of files carry any structured multi-artist tag — mp3 carries zero files with multiple MUSICBRAINZ_ARTISTID across 19,840. Of 1,286 files saying "feat.", 90% have nothing structured behind it, and a sample of 80 such files was multi-artist in MB 80 times out of 80. CLAUDE.md justified plan 013's removal of the credit tables with "3 credits of 2,823 listed more than one artist". That measured our own *writer* — cachedLinkArtist was called once per credit, so a collaboration could never have been recorded. Dropping the join table was still right on cost; the evidence for "multi-artist is rare" was not. A credit is ordered parts and the credit string is derived from them, so join phrases are assembly instructions, not disassembly ones. Nothing here reconstructs a credit by searching a name inside a credit string: the stored text may come from tags while the parts come from the catalog, and those disagree for ~1 in 3 multi-artist credits. Where it comes from, after two dead ends: the canonical dump CI already streams has no join phrases and no as-credited names, and the JSON dumps cover 153,691 recordings of ~35M with *zero* overlap against a real library. So mbdump.tar.bz2 — 7.1 GB, ~13.7 min in pure-Go bzip2, whose members are alphabetical, which is what lets one pass resolve an entity's credit without buffering 35M recordings. - artist_credit_part / artist_credit_ref, multi-artist credits only: a single-artist credit is already explore_index's own artist_name. - Column layouts verified against the real 20260815 export; ErrDumpShape makes a wrong guess a failed build, not a wrong catalog. - The pass runs on every mode, not just a build. The job picks its mode from the index's own state, and a complete import means "refresh", which never enters the importer — so credits could otherwise only arrive via a rebuild that re-downloads ~205 GB. It reports whether it populated anything, which is what flips `changed` and republishes. - The importer asks whether an artifact carries the tables, on the writer where `core` is attached, so the artifact already published still imports. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AfVYUVExXsx1nSWrXN8mAh
57 lines
2.6 KiB
SQL
57 lines
2.6 KiB
SQL
-- The decomposition of a multi-artist credit, from the MusicBrainz
|
|
-- dump. One row per credited artist, in credit order.
|
|
--
|
|
-- A credit is ordered parts, and the credit *string* is derived from
|
|
-- them -- MusicBrainz's own `artist_credit.name` is a cached render and
|
|
-- nothing more. Rendering is a concatenation:
|
|
--
|
|
-- for each part in position order:
|
|
-- emit link(credited_name -> artist_mbid)
|
|
-- emit text(join_phrase)
|
|
--
|
|
-- so the link boundaries are known by construction. That is the whole
|
|
-- reason this table exists, and it is why nothing may reconstruct a
|
|
-- credit by *searching* for a name inside a credit string: the stored
|
|
-- string may have come from a file's tags while the parts come from the
|
|
-- catalog, and measured on a real library those disagree for about one
|
|
-- in three multi-artist credits ("Skrillex feat. Swae Lee" tagged
|
|
-- against "Skrillex & Swae Lee" upstream). A search would miss, or
|
|
-- match the wrong span.
|
|
--
|
|
-- `credited_name` is the name *as credited*, which is not the artist's
|
|
-- canonical name: MusicBrainz credits "Snoop Dogg" on a track by the
|
|
-- artist whose name is "Snoop Doggy Dogg". It is stored per row rather
|
|
-- than joined from an artist table for exactly that reason.
|
|
--
|
|
-- Only *multi-artist* credits are stored. A single-artist credit is
|
|
-- (name, "") and is already fully described by explore_index's
|
|
-- artist_name and artist_mbid; storing those would roughly triple the
|
|
-- table to say nothing new.
|
|
--
|
|
-- Credits are shared: an album's twelve tracks by one artist reference
|
|
-- one credit_id. That is the opposite of the local library's verdict
|
|
-- in plan 013, and correctly so -- credit sharing is 1:1 in one
|
|
-- person's files and genuinely many-to-one across a 2M-row catalog.
|
|
--
|
|
-- MBIDs are the same 16 raw bytes explore_index stores, for the same
|
|
-- size reason and with the same CHECK, so a stringly write fails at the
|
|
-- insert that made it rather than reading back as no rows at all. See
|
|
-- backend/explore/mbid.go.
|
|
CREATE TABLE IF NOT EXISTS artist_credit_part (
|
|
credit_id INTEGER NOT NULL,
|
|
position INTEGER NOT NULL,
|
|
artist_mbid BLOB NOT NULL CHECK(length(artist_mbid) = 16),
|
|
|
|
-- The name as credited on this release, which may differ from the
|
|
-- artist's canonical name. Display uses this; navigation uses the
|
|
-- MBID above.
|
|
credited_name TEXT NOT NULL,
|
|
|
|
-- The literal connector that follows this part -- " feat. ", " & ",
|
|
-- ", ", or "" on the last part. Rendered as plain text between two
|
|
-- links.
|
|
join_phrase TEXT NOT NULL DEFAULT '',
|
|
|
|
PRIMARY KEY (credit_id, position)
|
|
) WITHOUT ROWID;
|