clamp samples to prevent corrupt FLAC files

[kroll-j]

Samples out of range -1..1 will create corrupt FLAC files.

[swh]

Thanks for the patch, but the number -0.999 and +0.999 are a bit aggressive, and will lead to legitimate signals being clipped.

The clipping could be better done by the FLAC encoder, as only it knows what it's internal threshold is.

[kroll-j]

If the FLAC encoder would do the encoding that would be optimal. The WAV encoder seems to clamp, but FLAC does not, resulting in broken encoding. It is not a simple integer wrap-around issue either; out-of-range samples seem to confuse the compression algorithm. I can upload such a file somewhere, you should also be able to reproduce it yourself using an out-of-range audio signal.

Clipping to this range is correct according to my tests. -1 to +1 refers to 0dB full-scale. I added a .001 margin to prevent possible wrap-around in edge cases due to rounding errors.

But it's true, in the long run, fixing he FLAC encoder would be better than this workaround.

[swh]

0.001 is way too much, you’re clipping perfectly OK signal. The real limit is something like [-1, 1-2*epsilon]. It really needs to be done by the encoder, or the library that’s calling it to be done properly. - Steve

…

On 2017-08-19, at 13:18, j. kroll ***@***.*** ***@***.***>> wrote: If the FLAC encoder would do the encoding that would be optimal. The WAV encoder seems to clamp, but FLAC does not, resulting in broken encoding. It is not a simple integer wrap-around issue either; out-of-range samples seem to confuse the compression algorithm itself. I can upload such a file somewhere, you should also be able to reproduce it yourself with. Clipping to this range is correct according to my tests. -1 to +1 refers to 0dB full-scale. I added a .001 margin to prevent possible wrap-around in edge cases due to rounding errors. But it's true, in the long run, fixing he FLAC encoder would be better than this workaround. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACRYRSS56keKgtOyoY41-zFkTMy1UTjks5sZtKxgaJpZM4O8Myq>. <https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png> <https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png> <https://github.com/swh/timemachine> <#4 (comment)>

[kroll-j]

Whether .1% of the range of a signal that's already at 0dBfs is too much, I don't know... Clamping when writing to floating-point formats that can reproduce signals >0dB perfectly fine is not nice, I agree on that much :)

I re-checked and the same wrapping issue happens with WAV with an integer format such as SF_FORMAT_PCM_16, only the compression issues are specific to FLAC. I'm opening an issue with libsndfile.