Here’s a code snippet that returns the bit depth of the selected track.
(Defun bit-depth (s)
(let ((s (if (arrayp s) (sim (aref s 0) (aref s 1))s))
(test-values '(10 11 20 23 29 31)))
(dolist (bits test-values )
(if (= (snd-maxsamp (integrate (diff s (quantize s
(truncate (power 2 bits)))))) 0)
)); end bit-depth
(print (case (bit-depth s)
(10 "8 bit unsigned")
('20 "16-bit integer")
(23 "24 bit integer")
(29 "30 bit compressed (mp3 etc.)")
(31 "32-bit integer")
(t"32 bit float")))
If you create a 32 bit float tone 32 bit will be returned.
Changing the format to 16 bit PCM returns 16 bit.
If you change back to 32 bit, 16 bit is still returned.
The tale’s morality: Be careful, when changing the bit depth unless you’re already deaf,
in which case it doesn’t matter, how much went thru the shredder…
Thank you Steve for re-formatting the code (and removing the apostrophe before 20).
Its maybe worth mentioning that you don’t have to analyse the whole sound, 1100 samples should be enough. Just look that you don’t catch a silenced part. However, it can also work with silence, given that the sound was downsampled and dithering is on. Otherwise, “8-bit” will be returned.
It’s also interesting that imported mp3 sounds return 29, what would indicate a 30 bit Bit depth But mp3s do not have a constant bit depth. Thusthe the average seems to lie at (2^) 14.5.
The function snd-maxsamp should probably be replaced with the function peak as the Nyquist manual states that snd-maxsamp "will probably be removed in a future version (http://www.cs.cmu.edu/~rbd/doc/nyquist/part8.html#index264). The function “peak” must take a maxlen parameter, so that can be set to 1100 samples or whatever.
Well, “snd-maxsamp” has survived the last 10 years among other functions that should have been removed ever since.
therefore, I don’t have any qualms in using these functions. However, for the code above “peak” is preferable, since we can limit the calculation, if this is not already done by passing only a part of the sound.
“DEFMACRO” is just a LISP expression, not related to Audacity itself. In its simplest form, the name of the macro is during runtime replaced by the code within the block below it.
It would certainly be interesting to be able to define or alter Audacity macros from within Nyquist.
However, the developers are worried about such structures that could potentially call themselves.
A “trick” that occasionally comes in useful: You can redefine any of Nyquist’s built-in macros and functions locally, so that they behave differently from the standard version. Again, this remains local to the specific script that is running.
A silly example,
The limitation that Nyquist can’t call itself still exists, but Audacity now handles the limitation better. If a Nyquist macro command attempts to call a Nyquist plug-in, the command is skipped / ignored.
Related to this, you might be interested in looking at my “Macro Step Through” plug-in. The most recent version: https://forum.audacityteam.org/t/enhancement-for-macros/59223/33
That override of Nyquist’s GATE function was because Nyquist had been updated, and the updated version limited the “floor” parameter to a minimum of 0.001 (-60 dB), which was too high for this effect. The Nyquist version of GATE has now been updated so that it supports values down to 0.00001 (-100 dB) so the override has now been removed from Audacity’s Noise Gate effect.