fix(rockbox-wasm): duration, seek, and HE-AAC routing for progressive M4A; bump to 0.1.9
Three fixes to the progressive M4A/AAC (ADTS re-framing) path:
- Duration always 00:00: updateLiveMeta() hard-coded duration_ms:0 and
live:true, clobbering the real duration playMp4 parsed from the moov on the
first decoded segment. Now it preserves a known duration and reports the real
live flag. Genuine live/ICY streams are unaffected (they start at 0/true).
- Seek support: the streaming path has no whole-file rawPtr to reposition, but
the container's sample table maps time -> AAC frame (1024 samples) -> byte
offset. seek() now maps the target time to a byte offset, issues an HTTP Range
request from there, seeds a fresh demux at that sample, and resumes re-framing.
Captured for both the network (playMp4) and gapless-prefetch (playAdtsBuffer)
entry points; falls back to skip-forward if the server ignores Range (200).
- HE-AAC stutter: backward-compatible HE-AAC signals objType=2 (LC) with a
trailing SBR extension that doubles output to 2048 samples/frame. The
progressive path's primer trim assumes 1024/frame and dropped ~half of every
segment. mp4ParseEsds now rejects any ASC longer than the 2-byte plain-LC
config (catches backward-compat SBR/PS), routing it to the whole-file decoder
which handles SBR correctly and is seekable.
Verified against real Navidrome tracks: duration reports correctly, seeks land
frame-accurate and decode cleanly (server returns 206), and HE-AAC decodes
full-length at 44.1 kHz with no dropped segments.