# 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.

---

## 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`.