Autotag: identify tracks by audio fingerprint (Chromaprint + AcoustID) #96
Notifications
Due Date
No due date set.
Blocks
#277 Downloads: verify a grab by audio fingerprint before import
yonlu/yellowjacket
Reference: yonlu/yellowjacket#96
Reference in new issue
Block a user
Identify a track by what it sounds like rather than by what its tags claim. Chromaprint generates a fingerprint, AcoustID maps that to MusicBrainz recording MBIDs, and the existing autotag machinery takes it from there.
Salvaged from section 5.2 of
docs/dev/roadmap.md, which is deleted — every other part of its MusicBrainz phase has shipped.Why it is worth having
The autotagger currently matches on metadata: normalized titles, track counts, durations. That works well on a library whose tags are approximately right and not at all on the case that most needs help — a folder of
track01.mp3with no tags at all, where there is nothing to match on. Fingerprinting is the only thing that answers those, and they are exactly the albums a user cannot fix by hand.It also raises confidence on the ambiguous cases the scorer refuses to auto-accept: a bonus-track edition and its plain pressing have the same titles and nearly the same durations, and different recordings.
The seam already exists
#91 proposes
type Identifier interface { Identify(path) ([]Candidate, error) }withMetadataIdentifieras the v1 implementation, explicitly so that anAcoustIDIdentifieris a new implementation rather than a rewrite of the call sites. This issue is the reason that seam is worth building — the argument in #91 says the interface is speculative generality unless fingerprinting is actually wanted. If this is wanted, it is not.The cost to weigh first
Chromaprint is a C library. This project has spent real effort staying off cgo —
cmd/indexbuildandcmd/indexexportbuild withCGO_ENABLED=0so they need no GTK, and the SQLite driver is modernc's pure-Go one. The options are bundling thefpcalcbinary and calling it (which keeps that property, at the cost of shipping a binary per platform and a packaging change in four recipes), or cgo bindings (which do not).fpcalcis what Picard itself ships.An AcoustID API key is also required, and it is per-application.
Done when
A folder of untagged files can be identified and tagged, and the autotag confidence for an ambiguous edition improves rather than merely being another opinion.
Research done, with measurements rather than reading. Full plan:
.planning/plans/active/022-audio-fingerprinting.md(written locally; lands with the first branch).Short version — the two costs this issue worried about are both gone.
Chromaprint in pure Go: no cgo, no binary.
alexgorbatchev/gochromaprintreproduces referencefpcalcoutput essentially bit-for-bit when fed PCM from our ownmetadata.DecodeFile: 948/948 subfingerprints identical on a FLAC, 615/616 on an MP3 (decoder rounding, not algorithm), ~500× realtime for the fingerprint stage.CGO_ENABLED=0survives, Android included, and there is no fifth packaging recipe. One caveat: the published v1.6.0 failsgo getwith a sumdb checksum mismatch — the tag was rewritten after publication — so it gets vendored (MIT, zero deps, ~2k LOC + tests) behind a conformance test against systemfpcalc.It works on our own music. 19 files sampled from
test_data/mb-tag/: 19/19 matched, and all 8 files carrying aMUSICBRAINZ_TRACKIDcame back with that exact MBID, scores 0.950–1.000.meta=recordingids releasegroupsreturns the recording and the release-group MBID, so candidates can be built from the local release-group cache with no MusicBrainz search call.Three protocol facts that would each have cost a day, all measured:
durationmust be the whole file's duration. Tolerance is ±7 s: 129→match, +5 s→match, +8 s→zero results. A 120 s fingerprint window is fine — identical results to a full-file fingerprint on a 315 s track — as long as the duration is real, whichaudio_files.length_millisecondsalready is.batch=1. Without it the server silently answers only the first query. Up to 20 per request (annotated "temporary, decrease to 10 or less later"), which makes an album one request — so the 3 req/s guideline is not the constraint it looked like.metais whitespace-separated, not+.Decode is the only real cost: fingerprint ~500× realtime, MP3 decode ~30–55×, FLAC ~120–210× through beep. The scan never decodes today (header-only duration parsers), so this is new work — ~3 s per file with the 120 s window, so it wants to be an opt-in, pausable job plus on-demand analysis of one album, not a scan step.
What I'd build, in order:
"fingerprint"step in the existing candidate cascade behind #91'sIdentifierseam, resolved through the local release-group cache. That is thetrack01.mp3case, which nothing else can serve, and it can break ties where the scorer is torn.StateVerifyingwindow (backend/download/manager.go:1124), fingerprinting staged files and checking them againstdl.Expected— needs aRecordingMBIDonExpectedTrack, whichexplore.MBTrack.MBIDalready carries. Advisory only: it records and flags, never blocks an import, and it is also the full-decode integrity check the pipeline has never had.Two corrections to this issue's framing. The fingerprint resolves the recording, not the release: a remaster and the original pressing fingerprint the same, so it will not choose between a bonus-track edition and a plain pressing — that stays with the length/date/release-meta signals. And what it fixes outright is the untagged/mislabeled file, which is the case the scorer cannot touch at all.
Download verification and the quality diagnostics have no issue yet; say the word and I'll open them.
Claiming. Branch
feat/96-audio-fingerprint(Phase 2, #277, will land on the same batch branch).Plan 022 was checked against the code before starting and revised — see its new "Revisions to the first draft" section. The substantive changes:
sql/migrations/(schema is one description; new tables only);release_groupscache exists, so the candidate comes from AcoustID's nested release ids (meta=recordingids releasegroupids releaseids), voted locally → at most two MB lookups per group;audio_files.recording_mbid(tag-projected, Owned); it is stored evidence, and the MBID reaches the file only via Apply;acoustid_matches, Cache + Cascade);Also opened #277 (download verification) and #278 (quality diagnostics), both depending on this.
Needs from a maintainer: an AcoustID application key registered at acoustid.org/new-application. Until it exists the feature reports "no key" and sends nothing; everything is tested against a stub server.