feat(enrichment): alias-aware scoring — auto-confirm non-Latin-primary artists - #772
Conversation
…ists)
The MB text search used a strict field-phrase query
(`recording:"<title>" AND artist:"<artist>"`). A field phrase only matches
MusicBrainz's *primary* artist/title — it never searches ALIASES — so a
recording stored under a non-Latin primary name (大橋純子) whose romanized
form ("Junko Ohashi") is only an alias returns ZERO results, even though MB
has it. Whole swaths of a community library (e.g. romanized J-pop / city-pop
charts) were unsearchable.
- `build_recording_query(..., loose=True)` drops the field scoping + phrases
for plain AND-ed term groups (`(telephone number) AND (junko ohashi)`),
which searches the whole document incl. aliases.
- `_mb_search_recordings` runs the strict query first (unchanged, high
precision) and only on an EMPTY result retries once with the loose query —
so mainstream matches are untouched and the extra throttled request is spent
only on a miss. Results are re-scored by rank_candidates, so recall goes up
without lowering match quality (auto-accept still needs the per-field floors).
Verified live: "Junko Ohashi / Telephone Number" and "Anri / Windy Summer"
(both 0 under the strict query) now surface the real records; "AC/DC /
Highway to Hell" still hits strict at score 1.0 with no loose retry.
Follow-up (separate): alias-aware SCORING so these can auto-confirm, not just
appear as manual candidates.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
… artists)
Builds on the loose-search fallback: that surfaces a recording stored under a
Japanese primary name (大橋純子) via its romanized alias, but the SCORER still
compared the reference ("Junko Ohashi") against the primary only → artist
similarity 0 → below the auto floor, so it could only ever be a manual
candidate, never an auto-fill.
- mb_match: `cand_artist_sim` takes the best similarity over the candidate's
primary name AND its `artist_aliases`; score_candidate + classify use it.
- server: `_mb_artist_aliases(id)` fetches an artist's aliases (one throttled
lookup, process-cached — a one-artist discography costs ONE request) and
`_alias_enrich` attaches them ONLY to promising near-misses (title agrees,
primary artist doesn't) so a normal pass spends zero extra requests. Wired
into both the auto-matcher (_enrich_one) and the manual search proxy.
Verified live: "Junko Ohashi / Telephone Number" → 大橋純子 candidate goes from
score 0.5 (loose-only) to 1.0 (auto-confirmable), ranked #1; "AC/DC / Highway
to Hell" unchanged at 1.0 with no alias lookup.
Stacks on #771 (feat/mb-loose-search-fallback).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthroughAdds alias-aware artist similarity scoring, alias fetching and attachment in MusicBrainz enrichment/search flows, and tests covering alias-based matching and cache behavior. ChangesAlias-aware artist matching
Estimated code review effort: 3 (Moderate) | ~25 minutes ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
…fallback # Conflicts: # lib/mb_match.py # server.py
…nto feat/mb-alias-scoring # Conflicts: # server.py
|
Review + fix pass (Claude Code) — stacked on #771. Logic is correct: Fixed (integration): synced the updated #771 base (which now carries merged #758 + #764) and resolved the server.py conflicts — routing |
The loose fallback dropped the strict path's -secondarytype:Live filter, so a studio chart whose strict query missed could fall back to — and, since score_candidate doesn't penalize live takes, auto-confirm — a live-only recording. Apply the same live gate to the loose query (skipped only when the source title is itself a live take). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…nto feat/mb-alias-scoring
# Conflicts: # tests/test_mb_enrichment.py # tests/test_mb_match.py
Stacks on #771 (base =
feat/mb-loose-search-fallback; retarget tomainonce #771 merges).Problem
The loose-search fallback (#771) makes a recording stored under a Japanese primary name (大橋純子) findable via its romanized alias. But the scorer still compared the reference ("Junko Ohashi") against the candidate's primary name only → artist similarity
0→ belowAUTO_ARTIST_MIN, so these could only ever appear as manual candidates (score ~0.5), never auto-fill on the Refresh pass.Fix
mb_match.cand_artist_sim— best similarity over the candidate's primary name and itsartist_aliases(romanized/alternate names).score_candidateandclassifyboth use it, so an alias match clears the per-field artist floor._mb_artist_aliases(id)— fetches an artist's aliases via/ws/2/artist/{id}?inc=aliases, process-cached (a one-artist discography costs a single request). Raises on transport failure so a pass pauses cleanly (nothing cached on failure)._alias_enrich— attaches aliases only to promising near-misses (title already agrees, primary artist doesn't), bounded by_ALIAS_ENRICH_MAX=3. A normal pass (artist already matches, or no ref artist) spends zero extra requests. Wired into both the auto-matcher (_enrich_one) and the manual search proxy (ranking).Verified live
Tests
cand_artist_simuses aliases; an alias lifts a title-matching candidate from non-auto toauto;_mb_artist_aliasesfetches + caches (+ rejects a non-UUID id without fetching); and an end-to-end_background_enrichauto-matches a Japanese-primary candidate through the alias.Note / possible follow-up
The stored canonical artist is MB's primary (大橋純子). If preferring the romanized display is wanted, a small display-precedence tweak (prefer a romanized alias / the pack's own value) can follow — the match + album/year/art/MBID all resolve correctly regardless.
🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Bug Fixes