Menu
▾
▴
1 Attachments
#255 gain -n sometimes causes clipping (?)
"gain -n 0" with no other effects sometimes introduces clippping. Shouldn't this be impossible by definition?
It seems to occur with 2-channel input files (low-volume, with no full-scale samples). Perhaps there is some corner-case or roundoff bug which results in clipping (or, possibly, an erroneous warning).
I will attach a small test file which shows the problem.
Steps to reproduce:
- Download attached file t.wav
- sox t.wav out.wav gain -n 0
sox WARN sox: `out.wav' output clipped 1 samples; decrease volume?
The same thing happens with "gain -e -n 0"
I looked at the output file with audacity and it appears to have a single full-scale sample (expected, since it was normalized to 0db).
Forgot to mention: Using SoX v14.4.1 (as distributed with Ubuntu 13.10)
This is a subtle one...
In the manual section on the 'gain' effect, it does in fact suggest what is going on here: "Output formatting (dithering and bit-depth reduction) also requires headroom" — so the solution, is to add the -h option. (The reason for this is to do with the fact that signed integers are asymmetric about zero and that SoX's internal processing is done at 32-bit, so saving to a 24-bit file represents a bit-reduction.)
Ok. But then the man page should be updated to be more clear:
It says dithering is added "when the output bit-depth is less than 24" but that isn't true if dithering is done automatically in this case, which is 24 bits.
In gain options, it says "Note that unlike -e, -B might cause some clipping." which implies that -e can NOT cause clipping. Which again isn't quite true if this isn't a bug (when is it ever true that -e can't cause clipping?)
In fact, the (very minor) clipping in your command occurs during output formatting (reducing 32-bit integers to 24-bit, done by dividing by 256 then rounding to nearest, but this can yield a number that falls beyond the range of the lower-precision integer), not during dithering—the documentation is correct: there is no dithering in this case—and not within the gain effect itself. That's not to say the documentation couldn't be improved though.
Isn't it normal for gain -n to produce a 0dBFS sample?