Files
qbz/crates/qbz-dsd
vicrodh 70defb2e86 fix(dsd): the SACD stereo area is byte-interleaved, not block-per-channel
Reported: a SACD image played as white noise with the music distorted behind
it, identically in all three DSD modes. That the three agreed was the clue —
DoP and native never touch the PCM filter, so the damage had to be upstream of
the delivery choice, in how the bits are pulled out of the image.

THE LAYOUT WAS DECIDED BACKWARDS. The first measurement converted twelve
seconds and looked at where the energy landed: block-per-channel put 23 % above
the audible band, byte-interleaved 0.2 %, and the reasoning was that real DSD64
must carry a large ultrasonic component. That argument does not hold for this
pipeline. DsdPcmConverter low-passes and decimates to 88.2 kHz, so it REMOVES
sigma-delta noise shaping by design — a correct decode has nothing above
24 kHz. The 23 % was aliased garbage from bits read out of order: the symptom
was being read as the proof. The ratio does not discriminate either, since
scrambled bits and shaped noise both put energy up high.

Re-measured with a statistic that can come out differently: decode with the
real converter, then ask whether the audible band has the shape of music and
whether the two channels are a stereo pair at all.

  layout             spectral flatness      L/R correlation
  BlockPerChannel    0.038 … 0.107          -0.17 … -0.06
  ByteInterleaved    0.0036 … 0.0093        +0.24 … +0.48

Tracks 1, 4 and 13 of disc 1 and track 5 of disc 2. A negative correlation
between the channels of an orchestral recording is not a subtle hint, and a
spectrum ten to twenty times flatter is noise.

Two earlier instruments are recorded in the doc as non-discriminating rather
than deleted quietly: the energy ratio, and the variance of the raw stream's
64-bit local mean, which answers the same for clean and scrambled bits because
the local mean of a byte-level mix of two correlated channels is still roughly
the audio.

Also lands a real framing bug found on the way, which was NOT the cause: the
packet descriptors carry a frame_start bit that the reader ignored, and frames
begin 0, 672 or 1344 bytes into a track's payload depending on the track. With
byte interleaving an even offset is harmless, which is why it hid; an odd one
would swap the channels. FrameSync makes the reader hunt for the boundary, and
keeps the unsynced path so a probe can reproduce the broken stream.

cc
2026-08-21 18:56:40 -06:00
..