<feed xmlns='http://www.w3.org/2005/Atom'>
<title>meshbay.git/docs/musicbay.md, branch v0.9.0</title>
<subtitle>MeshBay — read-only public mirror</subtitle>
<id>https://git.meshbay.org/meshbay.git/atom?h=v0.9.0</id>
<link rel='self' href='https://git.meshbay.org/meshbay.git/atom?h=v0.9.0'/>
<link rel='alternate' type='text/html' href='https://git.meshbay.org/meshbay.git/'/>
<updated>2026-08-24T20:45:07Z</updated>
<entry>
<title>docs(musicbay): note the audio_root amendment in the design doc</title>
<updated>2026-08-24T20:45:07Z</updated>
<author>
<name>Christophe Besson</name>
<email>cbesson@gmail.com</email>
</author>
<published>2026-08-24T20:45:07Z</published>
<link rel='alternate' type='text/html' href='https://git.meshbay.org/meshbay.git/commit/?id=5b41de6a972ef5f6ec93849fab337414733bdd57'/>
<id>urn:sha1:5b41de6a972ef5f6ec93849fab337414733bdd57</id>
<content type='text'>
Records why the original no-root call was wrong (mixing, not cost) and
points at the new §4.3b protocol section — same treatment already given
to the WMA/Musepack transcode amendment above it.
</content>
</entry>
<entry>
<title>feat(music): transcode WMA/Musepack to AAC so they actually play</title>
<updated>2026-08-24T19:08:34Z</updated>
<author>
<name>Christophe Besson</name>
<email>cbesson@gmail.com</email>
</author>
<published>2026-08-24T19:08:34Z</published>
<link rel='alternate' type='text/html' href='https://git.meshbay.org/meshbay.git/commit/?id=f4ed927fa873133c5fed73fb7dd60e7747fc3dc2'/>
<id>urn:sha1:f4ed927fa873133c5fed73fb7dd60e7747fc3dc2</id>
<content type='text'>
Tagging and covers for these two formats landed already, but neither one
decodes in any mainstream browser's &lt;audio&gt; 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.
</content>
</entry>
<entry>
<title>docs: plan the Music group app (musicbay.md)</title>
<updated>2026-08-24T14:43:18Z</updated>
<author>
<name>Christophe Besson</name>
<email>cbesson@gmail.com</email>
</author>
<published>2026-08-24T14:43:18Z</published>
<link rel='alternate' type='text/html' href='https://git.meshbay.org/meshbay.git/commit/?id=16bc07acf053d7d14f8182f5523da1d179154a15'/>
<id>urn:sha1:16bc07acf053d7d14f8182f5523da1d179154a15</id>
<content type='text'>
Proposal only, not implemented. Same plug-in mechanism as Videos
(apps.md), but no new streaming path — a track is downloaded and
decrypted like any other file, not transcoded/remuxed like a film.
Metadata: local tags first (mutagen), MusicBrainz/Cover Art Archive
as node-side fallback enrichment, no API key needed (unlike TMDB) —
just a rate-limited, self-identifying client. Player state (queue,
shuffle, repeat) moves up into the group-page shell so playback
survives a tab switch, mirroring how the video/preview modal is
already shell-owned.
</content>
</entry>
</feed>
