mirror of
https://github.com/storytold/effectcraft.git
synced 2026-11-01 05:58:19 -06:00
Kristian MyramandClaude Sonnet 5.5
620d340d15
Two findings from the review of #1423. RF64 (WAVs over 4 GB): a chunk too big for 32 bits has a size field of 0xFFFFFFFF and its real size in the file's `ds64` chunk. The reader took the field literally, so it stopped at the `data` chunk and never reached the `cue ` and `_PMX` chunks that follow it. It now resolves such sizes through `ds64` (the `data` size, and a table of other chunks, capped at 1,024 entries), with checked arithmetic, and leaves the field as it was when there is no usable `ds64`. The `adtl` list: every `labl` record scanned the growing list of names, which is quadratic in the number of records, and nothing bounded how many were kept. The cue points are now read first, names and lengths are kept only for those ids in hash maps, and at most 40,000 `adtl` sub-chunks are looked at. The duplicate check between the cue and XMP markers uses a set instead of a scan. What a file yields is unchanged for any file within the bounds: a `labl` still wins over a `note`, and the first `ltxt` still gives the length. Tests: an RF64 file whose markers follow a sentinel-sized `data` chunk, sizes taken from the `ds64` table (and not taken when the table has no entry), hostile `ds64` sizes and tables and every truncation of an RF64 file, and a 100,000-record `adtl` list that is read in linear time, with the cap applied. The RF64 tests fail with the previous reader. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>