Off by one samples count

[eliggett]

Corrects an issue where the adpcm decoder reports one additional sample decoded than the actual count.

[dbry]

Hi, and thanks for the patch!

Unfortunately, I don't think it's correct. You see, the sample count starts at one because there's always one more sample than the decoded samples. It's stored verbatim in the header and copied just a few lines after the samples = 1 assignment.

Also, when I tried this change, the command-line program immediately failed with "adpcm_decode_block_ex() did not return expected value!" because it knows how many samples to expect. Of course, they could both be wrong, but in this case they're not. Were you having a specific problem with the library? I suspect that something else is going on.

BTW, that's cool you work at NASA/JPL! Can you get me a job... 😃

[eliggett]

Ok, that makes sense. The first two bytes do indeed constitute a sample. I had not considered that. I'm using it as a library to decode a stream from a ham radio on ethernet. We receive 164 bytes per RTP chunk, the first 4 bytes being the predictor (two bytes, equals the prior decoded sample), the step index (one byte) and an unused byte (generally 0x00). And after running the adpcm decoder function, we receive 320 16-bit LE samples. But the return value is 321! That is what surprised us.

Your decoder works great, from what I have been told, it is better than the OEM software (windows only).

[dbry]

So I've never been able to test the decoder with RTP packets, and there is an old issue (#7) where someone had trouble with that. You might want to look at a branch I created recently that has some decoding options:

https://github.com/dbry/adpcm-xq/tree/new-formats

Specifically it has options for variations where the nibble order is reversed (which is called DVI4 and may be the case with RTP based on that issue) and formats that do not contain headers (which sounds like it's not the case here because you describe the header).

But I have seen documentation (maybe RTP-related) where that sample in the header might not count. If it is actually the final sample in the previous block, then counting it as a sample would result in a duplicate sample every 320 samples. That would not sound terrible, but would be audible. If that's the case then throwing out either the first sample of each block, or the last sample of each block (which might be a little better in terms of quality).

I would be interested in your results if you get this working with RTP packets.

In theory, ADPCM decoders should all generate the identical output, and the choice should simply be what's easiest to integrate. That said, FFmpeg's decoder takes some shortcuts that can affect the output in a negative way, and so I don't recommend it. The reason I created this library, however, was for the quality of the encoder, which produces results measurably superior to anything else.