This means that the bit-deapth of full scale white noise produced in Audacity depends on the specific implementation of the C++ “rand()” function for the system it is running on.
Very interesting, did not know that.
So basically depending on system, the white noise generated can be anywhere between 16 and 32 bits.
This is different when using Nyquist’s white noise generator, which produces random 32-bit float samples (implemented in C rather than C++).
Confirmed, here the result of white noise at -24dB generated by Nyquist:
and at 0dB:
I wanted to check the bit depth of some clips, and thought I would use the Plugin created by Robert.
(Haven’t added the headers to create a plugin, for now just tested in the Nyquist Prompt).
;;; mix to mono if stereo
(defun mono (sig)
(if (arrayp sig)
(sim (aref sig 0) (aref sig 1))
sig))
;;; test against powers of 2
(defun bit-test (sig bits)
(snd-maxsamp
(integrate
(diff sig
(quantize sig (truncate (power 2 bits)))))))
;;; find the bit depth
(defun bit-depth (sig)
(let ((sig (mono sig))
(test-values '(10 11 20 23 29 31)))
(dolist (bits test-values)
(if (= (bit-test sig bits) 0)
(return bits)))))
;; run the test
(case (bit-depth s)
(10 "8 bit unsigned")
(11 "12-bit")
(20 "16-bit integer")
(23 "24 bit integer")
(29 "30 bit compressed (mp3 etc.)")
(31 "32-bit integer")
(t "32 bit float"))
As can be seen from my previous post, have used this before, in version 2.3.1
However, in Audacity 2.4.2, I get this error:
Thinking it was an old syntax problem, changed the line:
(case (bit-depth s)
to:
(case (bit-depth track)
But the problem persists.
Thanks for testing Steve, but still a problem on my side.
Tried with mono and stereo tracks as well, no luck.
I wonder if OS has something to do with it?
When I last used the code, I was using Audacity 2.3.1 on MacOS.
I’m assuming you are using the latest version on Ubuntu.
I’m currently testing with Audacity version 2.4.2 (32 bit) on W10 (64 bit).
After some experimenting, here is something interesting:
The top most track, is an mp3, the plugin works and shows bit depth as 30.
The middle track, was originally an mp3 that was converted to wav, the plugin works and shows the bit depth
as 30, which is correct as the lost bits are gone forever and converting to wav is not going to bring them back.
Now the interesting one, it’s a wav (32 bit float) and was created from wav samples and was never converted to anything else.
In this situation, the plugin throws the above mentioned error.
Another interesting thing, if the end part of the mp3 (where it fades to to almost nothing) is selected,
this is what is returned:
Is that normal due to the variable compression used by the mp3 codec?
It detects very little audio data and thus switches to the lowest possible bits?
Could you make that file available to me so that I can check what’s going on?
I’m not an expert in the internals of MP3, but I’d guess it’s something like that, but I expect it’s more complicated.
I’ve just tested the tail end of an MP3 and it is showing “30 bits”.
Just for interest, here’s a sine wave fading in from silence, and greatly magnified:
I unfortunately can’t supply the original wav file as it belongs to the studio, but I have attached another
wav (1 KHz tone, 0.99 amplitude, stereo, 32 bit float), that creates exactly the same error.
It has tone for the first 2.5 secs, then fades out by 3 secs, then has about 75 milliseconds of silence.
Also attached it as mp3 (320Kb/s CBR) and that is fine, shows 30 bits.
The silent part also returns 30 bits and not 8 bits as shown with the other mp3.
So, either there is a bug in Nyquist or the code or, the previous mp3 was malformed.
