diff options
| author | Christophe Besson <cbesson@gmail.com> | 2026-08-24 21:08:34 +0200 |
|---|---|---|
| committer | Christophe Besson <cbesson@gmail.com> | 2026-08-24 21:08:34 +0200 |
| commit | f4ed927fa873133c5fed73fb7dd60e7747fc3dc2 (patch) | |
| tree | d126c5e505c342ee6b02aadc1e46b1a026c2a027 /man | |
| parent | 75d1f8b93dfa0bffda3a59a6d143b06dcc3ca67f (diff) | |
| download | meshbay-f4ed927fa873133c5fed73fb7dd60e7747fc3dc2.tar.gz | |
feat(music): transcode WMA/Musepack to AAC so they actually play
Tagging and covers for these two formats landed already, but neither one
decodes in any mainstream browser's <audio> element at all — a real
library scan turned up 273 such files that would show up correctly in the
Music app and then simply fail on click. This closes that gap: the node
transcodes to AAC/M4A on request (a one-shot whole-file conversion, not
live-piped like video's fMP4 segments — an audio file is small enough that
streaming it buys nothing), caches the result under its own content hash
the same way a TMDB poster or a MusicBrainz cover is cached, and serves it
back through the ordinary file_req/chunk path. That path used to assume
anything in the media cache was thumbnail-sized (single chunk, always);
generalized it to slice a cached blob the same way a real file on disk
gets sliced, since a transcoded track can be several MB.
New MNP pair (`audio_transcode_req`/`_resp`, version bump to 0.9), shares
its concurrency cap with video's transcode pool rather than getting its
own — both are real ffmpeg processes on the same node. Every other audio
format is untouched: this only fires for .wma/.mpc, the two extensions
that need it.
Diffstat (limited to 'man')
0 files changed, 0 insertions, 0 deletions