Re: [PATCH v3 0/2] avcodec, avformat: add Olympus DS2 decoder and demuxer

Hi,

Follow-up on the DSS SP codec stability -- we hit a production issue
that looks relevant to FFmpeg's dss_sp.c decoder as well. This is not a
patch submission, just a report of what we found.

## The symptom

On certain DSS SP files (Olympus DS-7000, recordings longer than a
minute), the LPC synthesis filter goes unstable partway through. On our
reference file it happens at frame 2420 (t = 58.0 s): the RMS jumps
from ~3,000 to ~13,000, the signal clips at +-32768, and the audio
becomes unintelligible. Up to that frame our output correlates at 0.998
with a commercial reference decoder; after it, correlation is zero.
Four of seven files from the same recorder are affected.

## What it is not

Our first hypothesis was accumulated truncation in the Q15 fixed-point
arithmetic -- the >> 13 and >> 15 shifts that dss_sp.c also performs at
every filter stage. Two experiments ruled that out:

  - We extracted the codebook tables from the real Olympus
    DssDecoder.dll (14 x 256 IEEE-754 doubles at VA 0x10050008, in
    non-uniform logarithmic spacing: dense near +-1, sparse near 0)
    and substituted them for ours. Same instability, same frame.

  - We rewrote the whole synthesis path in f64 floating point. Same
    instability, same frame.

So it is not a precision problem. The same input drives the filter into
resonance regardless of the arithmetic it is computed in.

## What it looks like instead

The DLL decodes those same files stably end to end (1,404 s, RMS
staying between 2,300 and 4,400, zero clips). Its synthesis routine at
VA 0x10014230 is labeled "SP lattice filter" in Ghidra, which suggests
a lattice structure rather than the direct-form LPC recursion used in
dss_sp_sf_synthesis(). A lattice is unconditionally stable for
|k_i| < 1; the direct-form filter reconstructed from the same
coefficients is not, and can resonate when the quantised reflection
coefficients land close to the unit circle.

That is our current best explanation rather than a proven one, but if
it holds it applies to dss_sp.c unchanged -- same direct-form
structure, same tables.

## The stopgap we shipped

Until we port the synthesis to a lattice form, we cap subframe energy
straight after synthesis. Against dss_sp.c's 72-sample subframe, the
equivalent C would be roughly:

    int64_t sum_sq = 0;
    for (i = 0; i < 72; i++)
        sum_sq += (int64_t)dst[i] * dst[i];
    int rms = (int)sqrt((double)sum_sq / 72);
    if (rms > 6000) {
        int scale = (6000 << 15) / rms;
        for (i = 0; i < 72; i++)
            dst[i] = ((int64_t)dst[i] * scale) >> 15;
    }

6000 is the top of the DLL's observed output range. sum_sq needs 64
bits: 72 * 32768^2 overflows a 32-bit int.

With that in place all seven files decode stably over their full
duration, up to 23 minutes, zero clips, RMS back in the 2,500-5,500
range. It is deployed in our production pipeline and in our WASM demo.

We are deliberately not proposing this as a patch. It is a limiter, not
a fix, and it perturbs output on files that were never unstable. We are
reporting it because dss_sp.c should reproduce the same failure on the
same input, and because the lattice lead looks worth someone's
attention.

## One aside that may save somebody time

NCH Switch, the other widely used DSS decoder, does not appear to share
an algorithm with the Olympus DLL at all: correlation between their
outputs on the same file is ~0.04, although both are intelligible. It
is not usable as a bit-exactness reference.

Full write-up, with the measurements and the investigation trail:
https://github.com/Guillain-RDCDE/DS2-Anywhere/blob/main/docs/16-the-q15-instability.md

Happy to share the problematic samples with anyone who wants to look --
they are voice dictation, so they need scrubbing first, same as the
FATE sample in the v3 series.

Thanks,
Guillain d'Erceville
_______________________________________________
ffmpeg-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]