summaryrefslogtreecommitdiffstats
path: root/packaging
diff options
context:
space:
mode:
authorChristophe Besson <cbesson@gmail.com>2026-08-24 20:31:04 +0200
committerChristophe Besson <cbesson@gmail.com>2026-08-24 20:31:04 +0200
commit6c56877675958e40ae526e0965266ab68aae44f2 (patch)
treefaa097bfeb0a20614481ffd071fb2470c2f4eb91 /packaging
parented97f138cfc0aee5ac04e4d12b9e392277cbcc40 (diff)
downloadmeshbay-6c56877675958e40ae526e0965266ab68aae44f2.tar.gz
feat(node): recognize WMA and Musepack as audio, read their real tag keys
A real-library scan turned up 250 .wma and 23 .mpc files that the indexer was silently classifying as "other" — genuinely lost from the Music app, not a consolidation-rule artifact (checked separately: the grouping logic itself drops nothing). Both are now indexed as audio and tagged properly: - WMA has no mutagen "easy" wrapper, so the generic tag reader was reading nothing from it at all. Reads the real ASF keys directly instead (Title/Author/WM-AlbumTitle/WM-TrackNumber), confirmed against a real sample file before writing the mapping. - Musepack's format auto-detection is unreliable enough (misidentified a real .mpc as MP3 in spot checks) that it now always opens by its own class instead of guessing from content. - Filters out another placeholder value found along the way: a French ripping tool's auto-generated "Album inconnu (<timestamp>)". Neither format decodes natively in a browser's <audio> element, so this gets them correctly visible, tagged, and covered — not yet playable in-browser. That would need server-side transcoding, deliberately left out of this change.
Diffstat (limited to 'packaging')
0 files changed, 0 insertions, 0 deletions