Three ~28s tracks Karti generated, re-encoded from 160kbps to 96kbps and
pulled from -15 LUFS to -26. They were mastered at foreground level; the
failure mode of background music in a tool someone has open for eight hours
is not "too quiet". Playback volume is a further 0.14 on top.
AUTOPLAY DOES NOT MEAN AUTOPLAY. Every current browser refuses audio with
sound until the page has had a real user gesture — Chrome sometimes relents
for a site with a high Media Engagement Index, Safari essentially never does
on a first visit. So `play()` rejects on mount, and the naive version of this
looks like a bug: the control says playing and nothing is audible. This tries
immediately, and on refusal arms a one-shot listener and starts on the first
click or keypress. Verified in Chrome: paused on load, playing 2.2s after the
first click. That also happens to be the kind behaviour for someone who opened
six tabs at once.
Mounted in Shell, NOT in App. The anonymous Learn page renders outside Shell,
and a share-code visitor opening a link someone sent them should not get
unexpected audio — that is the one context where it reads as a fault rather
than as character. Asserted by there being no <audio> element on that page at
all.
Preference is localStorage and deliberately not mirrored to the server, on the
same reasoning as the sidebar: whether you want music depends on whether you
are wearing headphones, not on who you are.
Also pauses on tab hide, because music from a tab nobody is looking at is the
thing people hunt through twenty tabs to kill.
The element is rendered rather than `new Audio()` so it is inspectable in
devtools and in a test; `preload="none"` means a user who mutes it never
downloads a track.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
karti
0108a70131