Commit graph

1 commit

Author SHA1 Message Date
Admin
62d6732504 Vorbis: mono decodes sample-exact (115/160 files exact, was 0)
Two root causes, both found by building an oracle rather than guessing.

1. Amplitude ~75x low: the IMDCT applied a 2/n normalisation the encoder's
   forward transform had already carried. Because 2/n varies with block size
   it produced DIFFERENT errors on 256- vs 2048-sample blocks — exactly the
   reported symptom. Removing it gives fit scale 1.0000.

2. Leading trim, the real remaining defect. The first audio packet produces NO
   output (its window only primes the overlap-add) but we emitted from the
   first block's centre, injecting half a priming window of garbage and
   shifting everything early. And Vorbis carries encoder delay in the GRANULE
   POSITION, which varies per file — afinfo confirms 128 / 1103 / 960 frames
   on three samples — while our Ogg reader kept only last_granule and
   discarded per-page granules, making it unrecoverable. Added per-page
   granule tracking: the first page reporting a granule pins priming as
   centre - granule, and valid audio starts at priming + blocksize_0/2. That
   reproduces afinfo's numbers exactly on all three.

A premise in the brief was also wrong and worth recording: our output length
was already correct. afinfo reports valid frames matching OUR output — it is
afconvert that trims a further 128. The reference WAV was short, not us.

  mono    47 files  mean corr 1.00000 (min 1.00000)  47/47 exact
  stereo 107 files  mean corr 0.826                  68/107 exact

Decode cost 5.13 ms/file average; 11.5 MB compressed expands to 143.3 MB of
f32 PCM, which is why the sample bank's LRU cap matters.

Honest remaining defect: ~39 stereo files decode wrongly and it is NOT
alignment — a full lag sweep peaks at 0.40-0.89 with fit scales 0.40-1.87, so
specific blocks have wrong amplitude. Mono being 47/47 rules out floor,
residue 0/1, MDCT, windowing and priming; coupling matches the spec's
square-polar mapping including reverse order; floor 0 is rejected rather than
mis-decoded; and both channels are identical in the failing files, so it is
not a swap. The failing set is transient-heavy impact/footstep sounds, so the
lead is residue type 2 partition counting on short blocks.

reference_decode.rs is no longer #[ignore]d: 3 real tests asserting mono
correlation > 0.999 and length == granule, plus a 3000-mutation fuzz that must
never panic, all skipping cleanly without fixtures.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-03 09:26:27 +02:00