v0.16.0: the file already told you

Two real failures from the first hour of round 45, both fixed by treating
the file itself as evidence.

"B. Clem - Zuuso [1025657891]" fingerprinted fine and matched nothing.
Checked before building: AcoustID returns zero results, a MusicBrainz text
search for "Zuuso" returns zero, iTunes returns zero. The track is in no
metadata service on earth, so no smarter lookup could have answered it —
but its filename said exactly what it was. New filename_tags.py reads that,
validated against all 474 files in the untagged folder rather than invented
examples: it strips yt-dlp ids, drops "(Official Video)" noise, splits
Artist - Title, reads a leading 1-04, and falls back to the iTunes tree.
It is careful about what it removes — an 11-char trailing token counts as a
YouTube id only if it carries a digit, an underscore or flipping case, or
"Cold Draft-Underground" loses a word, and a hyphen only splits when it has
spaces around it so Jay-Z survives.

A guess says it is one: candidates carry a source, and the dialog quotes a
confidence only for real fingerprint matches.

The file now ranks lookup results too, which fixes the Alhambra case: token
overlap (words double, bare numbers single), a duration bucket against the
recording lengths AcoustID returns, and a filename year that predates what
the database knows. Live also stops counting as a demerit — it was lumped in
with Compilation and buried a live album for a file whose name said "Live At
The Alhambra". That track now proposes the right album with year 1961
instead of a compilation with 2002.

The year genuinely needed the filename: MusicBrainz's own first-release-date
for "Ahmad Jamal's Alhambra" is 2002, because its three original 1961
pressings are stored undated. The obvious fix of a second MusicBrainz call
returns the same wrong answer.

Not done on purpose: trav rejected "never propose a shorter title" —
truncating is wanted, since the garbage is usually the part being dropped.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NsiFHdyVg1UhBSxDJfTNRm

TASKS.md

@@ -9,6 +9,32 @@ When a round closes, move its finished items to `tasks-done.md`.
 
 - [ ] archive the done tasks in here to another file, this is crufty....
 
+## Round 46 (2026-09-02) — The file already told you: done, see tasks-done.md
+
+Filename-derived proposals when no database knows the song, plus using the
+file's own tags/name/duration to rank real lookup results. Left on the table:
+
+- [ ] **Submit fingerprints back to AcoustID.** The Zuuso case is unfixable by
+      lookup because nobody ever submitted it — and LinTunes is holding a good
+      fingerprint plus (after an identify) confirmed tags. `/v2/submit` takes
+      exactly that. It would make the library better for everyone and fix
+      trav's own second machine. Needs a user API key (not just the app key)
+      and must be explicitly opt-in — never submit tags the user hasn't
+      confirmed.
+- [ ] **An LLM pass for the genuinely ambiguous ones.** Raised by trav
+      2026-09-02. Worth being precise about where it helps: *not* the Zuuso
+      case (no data exists to reason over) and *not* the Alhambra year (1961
+      isn't in the response either). It helps where there are many plausible
+      candidates and the signal is semantic — an odd filename convention, or
+      deciding whether a number is a performance year or a release year. Would
+      be the app's first LLM dependency; keep it behind the same
+      "nothing is written until accepted" gate.
+- [ ] **A "clean up this filename" action independent of identify.** Half of
+      what round 46 built is useful with no network at all: 474 files in
+      Unknown Artist/Unknown Album could have artist/title/track filled from
+      their names in one pass. Wants the worker+progress split, not a dialog
+      per track.
+
 ## Round 45 (2026-09-02) — Ask the song what it is: done, see tasks-done.md
 
 Right-click → Identify Track…: Chromaprint fingerprint + AcoustID lookup, a