Fix integer overflow during unfolding of the rice residual

[MarkKremer]

Solves #60

Fix found by looking really hard at the reference code:
https://github.com/xiph/flac/blob/8cf7e7fbb536e3968efe1e442922c514ca99f9c0/src/libFLAC/deduplication/bitreader_read_rice_signed_block.c#L91

[ktmf01]

This is additionally documented here: https://www.ietf.org/archive/id/draft-ietf-cellar-flac-12.html#name-rice-coding

When folding (i.e., zig-zag encoding) the residual sample values, no extra bits are needed when the absolute value of each residual sample is first stored in an unsigned data type of the size of the last step, then doubled, and then has one subtracted depending on whether the residual sample was positive or negative. Many implementations, however, choose to require one extra bit of data type size so zig-zag encoding can happen in one step and without a cast instead of the procedure described in the previous sentence.

edit: uhh, I just realize this is for encoding. For decoding it is a little different.

[mewmew]

Wonderful! Thanks @MarkKremer for the fix and @ktmf01 for the docs : )

This is truly open source at its finest!

Cheers,
Robin

[mewmew]

The v1.0.9 release has now been tagged.

Very happy to see that the audio samples of the IETF test cases are now correctly decoded by mewkiz/flac.

Cheerful regards,
Henry & Robin