0108a70131
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>
335 KiB
335 KiB