Just a thought: nbits should never have been an input argument of a
playback function, since the precision of the internal data is much
higher than even 24 bit, the higher bit resolution usually found in
audio playback systems (not to be confused with the internal
representation of many digital signal processors; I mean D/A
converters). By the way, 24 bit means 144 dB signal/noise ratio, much
higher than currently attainable analog performance.
The only situation where that could be of some interest would be to
demonstrate in the classroom the effects of reducing the number of bits
per sample. But as such case is very specific and quite rare, it would
be better just to requantize de original signal getting entire control
of the situation, being able to measure noise and /or distortion, plot
the stair-like waveform and listen to the result.
Federico Miyara
On 02/03/2020 13:03, Samuel Gougeon wrote:
Le 02/03/2020 à 16:45, Perrichon a écrit :
Ok but this is a strange way to handle backward compatibility
I agree. This is why i asked for confirmation to a second reviewer
before removing nbits,
when the first reviewer asked me to remove it.
nbits was never implemented (never actually used in the function),
just present as a dead input.
But it was not disturbing.
Now, i guess that sometimes it's useful to clean the code. I think
that the next input argument "aplay"
after nbits is (very) rarely used (it addresses "only" Linux and MacOS
users (15%), and only if
its default value is not convenient (? 5% of 15% ?). Most often, only
the first 2 arguments are used.
_______________________________________________
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users
_______________________________________________
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users
