# Known bugs & rough edges Behaviour that is unspecified, awkward, or known-imperfect — as distinct from outright breakage. Each entry says what happens, why, and what a real fix would need to decide. --- ## Large WAVs in the browser: text corruption and a long hang **Status:** open. Reproduces on the web build only; desktop is unaffected. Loading a large capture through the web UI (drag-drop or the Open file button) produces garbled glyphs in menu titles, tooltips and axis labels, and the page stops responding for a long stretch. Small files load and render correctly, and the corruption appears *after* the load rather than at startup — so it is triggered by the size of the work, not by the build being broken. The hang is understood and partly by design: the web build computes its entire STFT in one synchronous pass (see the `__EMSCRIPTEN__` branch in the main loop), because the desktop's incremental fill depends on idle main-loop frames the browser doesn't hand back the same way. A DOM overlay now warns before it starts, but the page genuinely is frozen until it finishes. A real fix means chunking that work across frames or moving it to a Web Worker. The **corruption** is the unexplained part. The leading theory is heap growth: the build links with `ALLOW_MEMORY_GROWTH=1`, and a large file forces the wasm heap to grow mid-load. Growth reallocates the backing `ArrayBuffer`, which invalidates every cached view and raw pointer held across that moment — so anything retaining a `char*` or a texture-side pointer from before the growth would read garbage afterwards. Font glyph data reached through raylib's atlas is a plausible casualty, which fits the symptom being *text* specifically. Worth checking first: - Whether `INITIAL_MEMORY` large enough to avoid growth entirely makes it go away. That would confirm the theory cheaply, at the cost of a bigger initial allocation. - Whether the font atlas survives a deliberate `sbrk`-forced growth. - SAFE_HEAP + ASSERTIONS=2 (`build_web.sh` debug path) to catch the first bad access rather than the downstream symptom. **Testing note:** always serve the web build with `serve_web.py`, never `python3 -m http.server`. Browsers cache `.wasm` hard enough that a plain reload runs a stale module, which makes rebuilds look like no-ops and has already burned significant time chasing bugs that were fixed. --- ## Playhead vs. a selection edited mid-playback **Status:** partially addressed; underlying semantics still undefined. Playback hands a *snapshot* of the selected region to the audio device — the samples are copied, bandpassed, and normalised up front, so the sound coming out of the speakers is fixed the moment **Space** is pressed. The selection box, however, stays live and editable while that audio plays. Previously the playhead marker was drawn against the *live* `app.sel`, so moving or resizing the selection during playback made the marker jump, run off the end, or scale to a region that had nothing to do with what was audible. The playhead is now measured against `playSelStart` / `playSelEnd` / `playDuration`, captured at `PlaySelectedRegion()` time, so it tracks the audio that is actually playing. What remains undefined is the *product* question, not the drawing math: - If the user drags the selection somewhere else mid-playback, should the audio follow (restart / re-seek against the new region), or should playback keep going with the old buffer and the marker stay where it is (current behaviour)? - Should editing the selection during playback simply stop playback? - Should the playhead remain visible when the region it refers to is scrolled off-screen, or has been replaced by a selection elsewhere in the file? Current behaviour is the conservative reading: **the sound wins**. The marker always describes real audio, and a mid-playback edit is treated as staging the *next* thing to play rather than modifying the current one. That is defensible but was never explicitly chosen, and the UI gives no feedback that the box on screen and the audio in flight have diverged. Related: a sub-threshold click *inside* an existing selection deliberately does not clear it (`hoverInsideSelection` in `spectrogram.c`), because silently clearing changes what **Space** would play. A click on empty space still resets to full range. **Touches:** `audio.c` (`PlaySelectedRegion`), `spectrogram.c` (playhead advance, scope cursor), `render.c` (`DrawPlayhead`), `spectrogram_types.h` (`playSelStart` / `playSelEnd` / `playDuration`). --- ## Long-file zoom sharpness lags the zoom gesture **Status:** working as designed, but reads as a bug. `ComputeSkipFactor()` (`stft.c`) strides the initial STFT pass for long files — every 8th segment past 10 minutes — so the overview loads promptly. The missing segments are filled at full resolution afterwards: the visible range first, then a background sweep of the whole file. The practical effect is that a hard zoom into a 30-minute file can look blocky for a moment before the foreground fill catches up and it sharpens. The fill is gated on `view.end - view.start <= 0.25f`, so it only runs once reasonably zoomed in. If a view stays blocky indefinitely, the fill is not reaching that range and that *is* a real bug worth chasing. --- ## Load time on long files is unbounded and unreported A 30-minute 48 kHz file spends a long time in `Processing…` before the UI is usable, and the percentage indicator advances non-linearly (the strided overview completes fast, the high-res fill does not). There is no cancel. Headless/scripted runs must wait this out; see `AGENTS.md`.