Audacity Forum

Kdmeizk wrote: Why should I edit without “bit-perfect” in mind?

"Bit perfect" is one of those phrases that is easy to grasp, but not really very meaningful.

32-bit -> 8-bit is obviously not bit perfect, right?
but
8-bit -> 32-bit -> 8-bit may be lossless.

24-bit -> 64-bit -> 24-bit -> laptop / iPod / other portable player, is probably less than 16-bit in terms of signal to noise (last time I looked, Apple were quoting "SNR > 90 dB" and "THD+N < -75 dB")

The smallest, non-zero, 32-bit float value is 1.40130×10−45 (about 0.00000000000000000000000000000000000000000000014), but sound cards are 24-bit at best, so that will be converted to zero + noise, where "noise" will be millions of times larger than this tiny value.

steve wrote: 32-bit -> 8-bit is obviously not bit perfect, right?
but
8-bit -> 32-bit -> 8-bit may be lossless.

Yes I understand this.

steve wrote: The smallest, non-zero, 32-bit float value is 1.40130×10−45 (about 0.00000000000000000000000000000000000000000000014), but sound cards are 24-bit at best, so that will be converted to zero + noise, where "noise" will be millions of times larger than this tiny value.

You mean “0.00000000000000000000000000000000000000000000014” is not the maximum exponent and can be for example greater than “0.000000000000000000000000000000000000000000000140000000…”? Or 1.40130×10−45 is the maximum possible exponent?

For loopback recording, I do not use the “Stereo mix” of the sound card because I know it is not “bit-perfect”, I use WASAPI loopback (I could try ALSA and Jack and PulseAudio forwarding under GNU/Linux), which can be “bit-perfect”. But this part is not really related to the subject. I simply want to configure Sample Data Export to export “bit-perfect” sound from Audacity. By the way, I know there is a delay between recording and playback, so I added Silence at the beginning and end of the test files to precisely select the sound. With the same steps as my first post, I have their SHA-512 which are identical (with 50 decimal places, I even tested 200 and I still have 0 as value after the first 15/16 values).

I wasn't sure if Nyquist supported this notation, but it appears that it does: I think this should ensure that enough digits are printed in all cases.

“.100g” means 100 digits will be printed after the dot, right?

Yeah now it is a pretty big number! So as long as I do not have around 100 digits printed after the dot (I assume I can even increase the value if necessary), the exported text file will contain the sound as “bit-perfect”/lossless?

Kdmeizk wrote:“.100g” means 100 digits will be printed after the dot, right?

Not quite.
It means, use the shortest representation: %e or %f, with up to 100 digits, including digits on both sides of the dot.,
where %f is floating point notation, and %e is scientific notation (mantissa/exponent).

32-bit floating point numbers, and hence sample values, may be greater than 1, in fact, very much greater - up to about 340282300000000000000000000000000000000.
By my reckoning, 100 digits should be sufficient to uniquely identify every value and thus give the same 32-bit sample value after the 2 way conversion.
100 digits is more than enough to provide a "bit perfect" decimal representation of any sample value in any format support by Audacity (up to 32-bit float).


*1 One this that we haven't mentioned, though in normal use they should not occur, are inf, -inf and NaN. (positive / negative infinity, and "Not a Number" (https://en.wikipedia.org/wiki/NaN)

*2 I think that far less than 100 digits are required, but the '100' ensures that the number of digits has a limit.

steve wrote: Not quite.
It means, use the shortest representation: %e or %f, with up to 100 digits, including digits on both sides of the dot.,
where %f is floating point notation, and %e is scientific notation (mantissa/exponent).

Hum yes, I used a too big shortcut, sorry.

steve wrote: *1 One this that we haven't mentioned, though in normal use they should not occur, are inf, -inf and NaN. (positive / negative infinity, and "Not a Number" (https://en.wikipedia.org/wiki/NaN)

I will handle this kind of case if I meet him, no problems.

With this last configuration, I just tested by changing the last number of a line in the exported text file. Once imported into Audacity, then exported in a 32 bits RAW file, the SHA-512 of both RAW files are identical, even with a modified value… Does Sample Data Import truncate or round the values when importing? Or Audacity itself? (in Audacity, my project settings are 32 bits 48000 Hz)

Kdmeizk wrote:Does Sample Data Import truncate or round the values when importing? Or Audacity itself?

Converting floating point values to decimal is handled by Nyquist. You would need to dig into the Nyquist programming language code (http://www.cs.cmu.edu/afs/cs.cmu.edu/pr ... tware.html) to find out exactly what happens there.

I tried

sample-data-import.ny, line 183:
replaced by So, in the input file the first line is: and with the "Debug" button before importing, it shows: but if I change the first line, for example to now it shows:
EDIT: But what I do not understand at all is that even if Audacity imports "0.8", if I export this importation, the new exported file will be the same as the original input file.

Try running this with debug: *float-format* sets the format for displaying numbers. It does not affect the actual value.

I tested and even better: You are right, the full value was here.
Back to the file, it contains in multiple times (generated by "Tone" 23000 Hz, 0.8 amplitude) I changed them to Now when I import, I can see :/