Good question! It turns out that 64 bit arithmetic does not overflow (I explain this in a comment in the source code [1]) up to the shift. The shift amount must then be large enough to fit the result in 32 (or actually, 24 or usually 16) bits. For a valid FLAC file this will be the case. For an invalid FLAC file it might truncate, but an invalid file cannot be decoded properly anyway. The shift amount is a 5 bit signed number [2], so it is never possible to shift by the integer width or more.

[1]: https://github.com/ruuda/claxon/blob/91b6af9/src/subframe.rs... [2]: https://github.com/ruuda/claxon/blob/91b6af9/src/subframe.rs...

I think the shift at the end (>> qlp_shift) takes care of this. The multiplication and sum are done in 64-bit, and then the sum is presumably shifted enough so as to fit in 32-bits.

My assumption would be that the assumption was that 64-bit arithmetic is somehow more time efficient and 32-bit is more memory efficient while still large enough to hold the results.