Prefer the repo fingerprint matcher in the real-directory song-centric pipeline
Constraint: Improve the current directory-to-feature path using components already present in the repo, without depending on unavailable heavyweight semantic runtimes. Rejected: Keep exact-lane validation on a purely ad-hoc local hash path | It underuses the repo's existing fingerprint extraction capability and weakens evidence for the real pipeline. Confidence: high Scope-risk: narrow Directive: In host-level song-centric pipeline validation, prefer ChromaprintMatcher-backed fingerprints first and use local_wavehash only as fallback. Tested: /usr/local/miniconda3/bin/python acr-engine/scripts/enrich_songcentric_manifest_with_local_features.py on the real wav smoke manifest; imported the enriched manifest into postgres://d2:d2pass@127.0.0.1:5432/d2 schema acr_songcentric_test twice and verified counts stayed media_entity=9, audio_object=22, feature_fact=24, set_membership=9 on rerun; matcher_fingerprint_count=5 and fallback_fingerprint_count=0; git diff --check; /usr/local/miniconda3/bin/python scripts/check_markdown_links.py --root docs returned OK for 11 active markdown files Not-tested: true external chromaprint library integration and semantic-model-backed enrichment on this host
Showing
7 changed files
with
218 additions
and
22 deletions
acr-engine/data/pgvector_eval/music20/songcentric_directory_manifest_with_features_v2.jsonl
0 → 100644
acr-engine/data/pgvector_eval/music20/songcentric_directory_manifest_with_features_v2_report.json
0 → 100644
-
Please register or sign in to post a comment