PDA 3D Raw Data / LSS Raw Data chromatogram: bit-packed segment payload encoding undecoded

[Nathan-D-R]

PDA 3D Raw Data (UV/PDA detector) and LSS Raw Data (chromatogram) streams in .lcd files use a segment-based encoding that is only partially decoded - see docs/format/04-lcd-chromatogram-pda.md (status: PARTIAL). Neither stream is wired into crates/openszraw at all currently; this is secondary detector/chromatogram data, not core MS spectra, so it doesn't block anything else, but it's a real, documented gap.

What's confirmed

Every segment starts with a 24-byte header, magic RC\x00\x00 (u32[0] == 17234), with u32[2] likely a declared point count and u32[3] the segment's total block size (inclusive of the header) - enough to walk from segment to segment reliably.

What's not decoded: the payload itself

The bytes after the 24-byte header are a bit-packed or variable-length delta encoding, not a plain fixed-width array (segment payload byte counts are often odd, ruling out a simple u16/u32 array). Two hypotheses have been tried and ruled out:

• Plain unsigned LEB128 (7-bit continuation): decoded to 426 values against a segment whose header declared 321 points - wrong count, rejected.
• PDP-endian floats (byte-swapped 16-bit words, 3412 ordering): produces individually plausible-looking float values (e.g. 0.914, 1.782), but the odd payload byte counts mean it can't be a uniform array of these either. Interesting partial signal, not a solution.
• The TTFL MS Raw Data RLE scheme (see IT-TOF (.lcd TTFL): no m/z calibration for the RLE payload's raw time-bin index axis #1 and docs/format/03) does not transfer: tried directly against a real PDA stream and it doesn't decode cleanly - early segments are near-all-zero (a plausible blank/baseline region) and later, clearly-populated segments don't parse as RLE marker words at all (full leftover every time). So this is a genuinely different encoding from the MS payload scheme, not a shared cross-stream compression scheme as originally hoped.

Corpus and prior tooling

Any local .lcd file has these streams. Prior analysis scripts: re/src/analysis/decode_pda_leb128.py, decode_pda_pdp.py, decode_pda_bits.py, pda_rle_test.py - useful starting points, not working decoders.

Priority note

Lower priority than #1 (TTFL m/z calibration): this is a secondary UV/chromatogram stream, not MS spectra, and doesn't block MS-level format parity or openmassspec-io wiring. Worth picking up when there's appetite for genuinely open-ended bit-level reverse engineering with no guaranteed payoff, not before higher-value work.

Constraints

Clean-room only, per CONTRIBUTING.md: no LabSolutions software, no vendor SDK or output as ground truth.

Done means

A documented, evidence-backed payload decode in docs/format/04-lcd-chromatogram-pda.md, plus (if decoded) chromatogram/PDA support wired into crates/openszraw via openmassspec_core's chromatogram-source trait (mirroring how sibling readers like OpenWRaw expose iter_chromatograms).