#317 sox cannot handle true 32 bit

[Viktor Polak]

SOX can never output true 32 bit because it will just internally convert it into 24 bit first.
Attached a.raw contains a sequence of 32 bit floats.
Bellow is a minimal example to show that the output contains 24 bit values converted to 32 bit (data lossed).
Can do other things to increase percieved usefulness of command eg: trim
sox -r 4000 -b 32 -L -e floating-point -c 1 a.raw -r 4000 -b 32 -L -e floating-point b.raw
I load the files with Numpy to validate them. Result is very close to what it would look like if it were converted to a 16 bit array with slightly more precision (24 bit makes sense but Numpy has no 3 byte datatype).

[Mans Rullgard]

Fixed, as much as possible. Sox uses 32-bit integer format internally. This means some floating-point values have to be rounded when read from an input. Some 32-bit integer values also cannot be represented exactly as float.

[Martin Guy]

sox-14.4.2 and sox.sf.net head give me b.raw identical to a.raw
However, 32-bit floating point has a precision of 25 bits (24-bit mantissa
plus the sign bit) so I think this is a moot point.