dither on export (bug 22)

[steve]

http://bugzilla.audacityteam.org/show_bug.cgi?id=22

It has long been known that due to a bug in Audacity, when exporting a 16 bit track to a 16 bit uncompressed file format, if "dither" is enabled in Preferences, dither will be applied to the exported data.

bgravato recently mentioned that he tried something similar with 24 bit integer audio and dither was not applied.
I've started this topic so that we can investigate exactly when dither is applied and when not to clarify the actual situation regarding bug 22.

Test 1
New Audacity Project - dither enabled in Preferences - default Quality 32 bit float. (Copy or read directly does not appear to affect the outcome.)

Open a 16 bit wav file.
Export as 16 bit wav.
The two files are different.

Test 2
As for Test 1, but using 24 bit instead of 16 bit.
The two files are identical.


How to test for identical audio data:
With "Preferences > Quality" set for 32 bit float;
Import both files.
Invert one of the tracks.
Select both tracks and "Mix and Render".
Select the "silent" track and call up the "Amplify" effect. If the track has absolute silence, the "New peak amplitude" will show as "-Infinity".


Question: Is Audacity "doing the right thing" with 24 bit files by not-dithering, or is something else occurring?
I suspect that Audacity is not doing the right thing and bgravato has discovered another bug.... more tests to follow.

[steve]

Exporting 32-bit float sine wave as a 24 bit integer file.

The expected result would be for dither to be applied (assuming that it is set in Preferences).

With dither set to "shaped":

• Generate a sine tone.
• Duplicate the track.
• Invert track 2
• Ctrl+shift+M (Mix and Render to new track)
• Apply Amplify to the mixed track > "-Infinity".

This is as expected.

• Generate a sine tone.
• Duplicate the track.
• Invert track 2
• Set track 1 to 24 bit.
• Ctrl+shift+M (Mix and Render to new track)
• Apply Amplify to the mixed track > "-68.5".

This is to be expected because dither will have been applied when converting the first track to 24 bit.
Amplify this mix track by 100 dB (apply Amplify with +50 dB twice), then plot the spectrum. The characteristic "shaped dither" shows clearly.

shaped-dither.png (40.26 KiB) Viewed 2913 times

• Generate a sine tone.
• Export the track as "Other uncompressed files > 24 bit integer"
• Re-Import the exported track.
• Invert track 2
• Ctrl+shift+M (Mix and Render to new track)
• Apply Amplify to the mixed track > "-88.6".

Dither should have been applied when exporting to 24 bit, but we would then expect to see noise at -118.5 dB (the Amplify effect should show "-68.5" as in the previous test).
Amplify this mix track by 100 dB then plot the spectrum. This is NOT dither noise.

not-dither.png (43.74 KiB) Viewed 2913 times

The peak at 880 Hz (double the original tone frequency).
If the mix track is normalized it will be seen that the noise is all positive going (the exported track has been inverted).
This suggests to me that the sample values are being truncated and not dithered.

[billw58]

Steve:
You an I went 'round and 'round on a similar topic over two years ago http://forum.audacityteam.org/viewtopic ... =10#p49864

Test 1 is, I believe, wrong.
When quality prefs (QP) is set to 32-bit float, a 16-bit WAV or AIF will be converted to 32-bit float when imported (the track shows 32-bit float quality). In order to get a 16-bit track from a 16-bit import the QP needs to be set to 16-bit.

So starting with QP set to 16-bit PCM ....
Import AIF 16-bit PCM into 16-bit PCM track
Export as AIF 16-bit PCM
Close project
Set QP to 32-bit float
New project
Import original AIF
Import exported AIF
Invert one track then Mix and Render
The two files are different.

Close project
Set QP to 24-bit PCM
New Project
Import 24-bit WAV
For me, this imports as 32-bit float! Is this not a known bug in and of itself? 24-bit PCM imports as 32-bit float when QP is set to 24-bit PCM?

So I don't see any way of testing Bruno's scenario.

-- Bill

[billw58]

Exporting 32-bit float sine wave as a 24 bit integer file.

FWIW confirmed results on Mac with 2.0.0 latest rc.

-- Bill

[bgravato]

This is the test I did (for testing something else not this...):

Audacity Version: 2.0.0rc4 on MacOS-X 10.6.8
Conditions: Audacity Quality preferences set to 44100Hz, 24-bit, Dither Triangle, Interface set to -145dB view mode

1) Imported a 24-bit wav file (containing valid audio)
2) Silenced some part of the file
3) Exported as other uncompressed format: 24-bit WAV (Windows)
4) Started new project and imported both tracks mentioned in 1) and 3)
5) Inverted one of the tracks and mixed and rendered both tracks

Outcome:
- graphically there's still silence in the silenced part of the exported track
- after step 5) the sum of the inverted parts was not pure silence, there was some noise visible just below 138dB, which I think indicates dither in the non-silence parts

I can later try the same with Audacity set to 32-bit float and post back.

[billw58]

Bruno:
When you import the 24-bit file into Audacity set for 24-bit PCM, what does it say on the Track Control Panel?

- Bill

[bgravato]

Bruno:
When you import the 24-bit file into Audacity set for 24-bit PCM, what does it say on the Track Control Panel?

- Bill

Oddly it says Stereo, 44100Hz, 32-bit float

Since I have nothing set to 32-bit float in Audacity that sounds very wrong...

Edit: the file's headers say 24-bit:

Code: Select all

macbookpro:audacity-tests bruno$ file 24bit.wav 
24bit.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 24 bit, stereo 44100 Hz

[billw58]

Back in the old thread I referenced earlier, Gale posted this table from the source code:

Code: Select all

    Quality setting    File Format      Imports as         
    16                      16                   16
    16                      24                   32 (24)
    16                      32                   32

    24                      16                   24                   
    24                      24                   32 (24)
    24                      32                   32

    32                      16                   32
    32                      24                   32
    32                      32                   32

So there seems to be some ambiguity about how 24-bit PCM files are imported when Audacity is set to 16-bit or 24-bit PCM quality. What does "32 (24)" mean?

Based on our limited tests it seems that 24-bit PCM files are always imported as 32-bit float regardless of the quality setting.

-- Bill

[Gale Andrews]

What does "32 (24)" mean?

Based on our limited tests it seems that 24-bit PCM files are always imported as 32-bit float regardless of the quality setting.

Yes. The table is not from the source code but one I made by testing a while ago. "(24)" in "32 (24)" means that 24 is expected (by me), but not what happens.

From ImportPCM.cpp:

Code: Select all

// In general, go with the user's preferences.  However, if
// the file is higher-quality, go with a format which preserves
// the quality of the original file.

   if (mFormat != floatSample &&
       sf_subtype_more_than_16_bits(mInfo.format))
      mFormat = floatSample;

So Audacity is behaving as intended, but you can preserve the quality of 24-bit files by importing at 24-bit, so without forcing a dither down from 32-bit (if that actually happened). But no, on Windows too if I export 32-bit silence as 24-bit PCM WAV, with shaped dither on, there is no dither added to the WAV. If I export the same silence as 16-bit PCM WAV, there is dither added.

I happened to discuss upsampling on import with Michael Chinen a couple of years ago while discussing something else, and he gave no indication he felt the above code was bad behaviour.


Gale

[steve]

From ImportPCM.cpp:

Code: Select all

// In general, go with the user's preferences.  However, if
// the file is higher-quality, go with a format which preserves
// the quality of the original file.

   if (mFormat != floatSample &&
       sf_subtype_more_than_16_bits(mInfo.format))
      mFormat = floatSample;

It looks like that was written at a time when there was no 24 bit option. Has there ever been such a time?

I happened to discuss upsampling on import with Michael Chinen a couple of years ago while discussing something else, and he gave no indication he felt the above code was bad behaviour.

I think there is now.
It looks to me like 24 bit files are converted to 32 bit float (surprising perhaps, but perhaps not a "bad" thing), but then on Export to 24 bit, the sample values are truncated to 24 bit. Export should properly convert to 24 bit (with dither if enabled) and not just truncated to 24 bit.

@Gale - I vaguely recall some fuss a long time ago about something in the manual that said that converting from 32 bit float to 24 bit integer was done by truncating. Do you remember that? Does it relate to this issue?