For a 24-bit PCM audio file, Sample Data Export creates a list of positive and negative sample values consisting of zero followed by five decimal digits after the decimal point. My question is, do those decimal numbers represent the 24-bit PCM binary sample values exactly? Is there any rounding or approximation that occurs when the binary sample values are converted to the decimal numbers in the text file?
The values are rounded to 5 decimal places.
If my maths is correct, to represent normalized signed 24-bit numbers accurate to the least significant bit, you will need 9 decimal places.
For greater precision:
- Find the “sample-data-export.ny” file.
- Make a backup copy of the file somewhere convenient.
- Open “sample-data-export.ny” in a plain text editor (such as NotePad++)
- Find the line:
(setq *float-format* "%1.5f") ; 5 decimal places
- For 9 decimal places, change that to:
(setq *float-format* "%1.9f") ; 9 decimal places
Note that for real-world recordings, anything beyond about 5 decimal places is likely to be just random noise.
Thanks for your helpful reply. Your point that anything beyond 5 decimal places is likely to be just random noise is well taken, but I am interested in the exact values in the context of random number generation. Having designed and built an analog white noise generator that utilizes the random voltage fluctuations that occur across a reverse-biased semiconductor junction, and having recorded that noise in Audacity, I am interested in obtaining exact audio sample values. I shall implement the modification to the ny file you suggested.
Let me know how you get on.
Provided that you use a plain text editor, and don’t change the file extension of the plug-in “.ny” file, it should be an easy and straightforward change.
I decided that the default 5 decimal places would be plenty for 99.9% of use cases, but there were sure to be a few use cases where greater precision would be required. That is why I put that line near the top of the file (just below the controls) so that it could be easily modified by end users when required.
I think you’re the first person to ask for more precision, so although it’s been 11 years since I wrote that plug-in, I’m pleased to see that someone wants to make use of that little feature 
The modified ny file worked as expected. As an experiment, I increased the number of decimal places to 16 and was suprised to see non-zero digits beyond 9 decimal places, for many samples. I changed it back to 9 and used that.
A nice feature would be an option to display the actual binary numbers, all the way out to least significant bit, in the text file.
It isn’t possible to get the 24-bit binary values directly. The actual values in Audacity are 32-bit float in the range +/- 1.0, so you would need to convert the (IEEE 754) 32-bit float values to 24-bit signed integer.
Binary is “tough” (for humans), especially with more than 8-bits… You have to start counting the bits…
Programmers often use hexadecimal because every group of 4 bytes (every nybble) converts exactly to one hex digit and you can easily learn to convert numbers of any size between hex and binary in your head.
For example, 11 binary is 3 in or hex (or decimal). So a pattern like 0011001100110011 converts to 3333 in hex and I can do that in my head. (Using the Windows Calculator in programmer mode… it’s 13,107 in decimal.)
Most of the time when programmers are looking at hex or binary they are interested in the “bit pattern” or the state a particular bit, rather than the numerical value.
Either binary or hex would work for me, as I’m a programmer. 
Binary numbers are not hard to read if they appear in groups of four, as in Windows Calculator in programmer mode.
This topic was automatically closed after 30 days. New replies are no longer allowed.