Audacity Forum

Gale:
You're right. This sure is complicated.

Gale Andrews wrote:The original said 32-bit was used internally by default then 16-bit was used for export by default. That's correct. Default quality on a newly initialised Audacity is 32-bit, and default export is 16-bit PCM WAV (or AIFF on Mac, I think). Other inferences could be made than those made here about what happens if you import a 24-bit file at 24-bit quality.

My quibble was with the word "default" in reference to internal processing, and that's what caused my initial confusion. It's true that the default recording quality on a newly initialised Audacity is 32-bit, but regardless of this setting it appears that Audacity still does all internal processing at 32-bit. So I like the new version in the manual.

Gale Andrews wrote:One minor quibble with what Steve said:

1) Create 3 tracks (it does not matter what the default quality settings are)
2) From the track drop down menu (click on the track name), set the first track to 16 bit, the second to 24 bit, and the third to 32 bit.
3) Select all 3 tracks and generate 30 seconds of silence..., [fade in and the 16- and 24- bit tracks will have dither noise]...

That's not true for the case where you had created tracks in 16-bit quality. In that case after both changing the track sample formats and fading in, the tracks are still silent because they can only be upsampled from 16-bit, so no dither is applied.

Well, I tried this. I set the Quality Preferences to 16-bit PCM, created the three tracks (so they were "created" in 16-bit quality), changed the sample format of track 2 to 24-bit and track 3 to 32-bit and generated 10 seconds of silence in each track. Then applied my "do-nothing" Nyquist prompt to the tracks. The same thing happened - tracks 1 and 2 had dither noise, track 3 did not. So the dither appears to be happening when the audio is downsampled from 32-bit after processing and before being returned to the track.

Gale Andrews wrote:All in all, I'm inclined to revert the Manual back to almost what it was, apart from suggesting people read the Quality Preferences page for more detail. I think that's the place to (try and) explain all this.

I like what's in the manual now. I don't think it's too complicated, and I think it's clearer. I'm not sure what to do regarding the statement about what happens during import, since that is so complicated. If people want to know what happens when they import audio, wouldn't they go to the manual page for File > Import > Audio? But you don't want to overload that section with all these details. A quandry.

-- Bill

Gale Andrews wrote:All in all, I'm inclined to revert the Manual back to almost what it was,

I'd forgotten about importing with other importers so I've removed the line;
"Imported audio will retain its original bit depth unless it is lower than the Quality Preferences, in which cases it will be converted to match the Preference settings."

I think the rest of it is clearer than it was, without getting too convoluted.

Gale Andrews wrote:One minor quibble with what Steve said:

1) Create 3 tracks (it does not matter what the default quality settings are)
2) From the track drop down menu (click on the track name), set the first track to 16 bit, the second to 24 bit, and the third to 32 bit.
3) Select all 3 tracks and generate 30 seconds of silence..., [fade in and the 16- and 24- bit tracks will have dither noise]...

That's not true for the case where you had created tracks in 16-bit quality. In that case after both changing the track sample formats and fading in, the tracks are still silent because they can only be upsampled from 16-bit, so no dither is applied.

I don't understand what you mean.

1) If I set the quality settings to 16, 24 or 32 bit and create a 16 bit track (when quality settings are at 16 bit, then the track will automatically be at 16 bit - in the other cases it can be changed to 16 bit from the drop down menu.

2) Generate 10 second of silence - This is created in 16-bit-quality isn't it?

3) Apply Fade - and if you are using triangle or shaped dither, the track will no longer be silent. OK, it's not very noisy, but it is not silent because dither has been applied to it, which I can only assume is because the audio samples were converted to 32 bit for processing, then converted back from 32 bit to 16 bit on being returned to the track.

Am I missing something?

stevethefiddle wrote:

Gale Andrews wrote:All in all, I'm inclined to revert the Manual back to almost what it was,

I'd forgotten about importing with other importers so I've removed the line;
"Imported audio will retain its original bit depth unless it is lower than the Quality Preferences, in which cases it will be converted to match the Preference settings."

I think the rest of it is clearer than it was, without getting too convoluted.

Hi Steve,

I'm afraid I still don't agree, considering the readership level the page is aimed at. You're introducing concepts of different types of sample format conversion which the user cannot see (and at a level they probably cannot understand) without going to the Quality Preferences. You're mentioning playback conversion and recording conversion (rightly ignoring the import conversion due to the complexity), but then that makes it appear there may be no import conversion. I think the level of this page should be kept understandable as far as possible without having to leave it.

We've also lost "This gives you somewhat better quality than audio programs that use purely 16-bit or 24-bit audio samples". That's important for novices to know. Maybe that sentence started people wondering here about whether to record 16-, 24- or 32-bit according to hardware for 16-bit end use, and so helped start the whole thing off. IMO, novices don't really need to consider the fine points of this like we've been discussing here. I think the general weight of opinion is as per the original statement, that recording 32-bit is generally preferable (if you're editing the content, and even if the end output is 16-bit). In fact if we wanted to expand this paragraph, I think that's an important point to make.

I like what we have now less every time I read it, so I'm still thinking it will have to be simplified, but let's consider the other issues first...

billw58 wrote: My quibble was with the word "default" in reference to internal processing, and that's what caused my initial confusion. It's true that the default recording quality on a newly initialised Audacity is 32-bit, but regardless of this setting it appears that Audacity still does all internal processing at 32-bit.

I'm somewhat feeling my way too through this thread, but I'm not sure Audacity *does* do all processing at 32-bit. If it does, I've been under a misapprehension for a long time. Where has anyone seen that all internal processing is 32-bit? See below.

stevethefiddle wrote:

Gale Andrews wrote:One minor quibble with what Steve said:

1) Create 3 tracks (it does not matter what the default quality settings are)
2) From the track drop down menu (click on the track name), set the first track to 16 bit, the second to 24 bit, and the third to 32 bit.
3) Select all 3 tracks and generate 30 seconds of silence..., [fade in and the 16- and 24- bit tracks will have dither noise]...

That's not true for the case where you had created tracks in 16-bit quality. In that case after both changing the track sample formats and fading in, the tracks are still silent because they can only be upsampled from 16-bit, so no dither is applied.

I don't understand what you mean.

1) If I set the quality settings to 16, 24 or 32 bit and create a 16 bit track (when quality settings are at 16 bit, then the track will automatically be at 16 bit - in the other cases it can be changed to 16 bit from the drop down menu.

2) Generate 10 second of silence - This is created in 16-bit-quality isn't it?

3) Apply Fade - and if you are using triangle or shaped dither, the track will no longer be silent. OK, it's not very noisy, but it is not silent because dither has been applied to it, which I can only assume is because the audio samples were converted to 32 bit for processing, then converted back from 32 bit to 16 bit on being returned to the track.

Am I missing something?

Well, I've complicated things as I realise now by turning dither off at one stage, getting interrupted and forgetting it was off! Apologies for that, but I've been told (as I understood it) by other developers that dither is only ever applied if downsampling to a lower bit format. I've also understood on similar authority that Audacity only does 32-bit processing when in 32-bit float quality setting. Those two separate beliefs led me to think I was correctly seeing no dither when (I thought) dither was on.

Here is what I see with shaped dither turned on again, 16-bit Quality setting, 44100 Hz project rate.

1) Generate 1 minute of mono 16-bit silence, and don't change the format. Open Amplify and note "Amplification (dB)" is 0.0 and "New Peak Amplitude" is -Infinity. Either apply amplify at 0.0, or fade in, then re-open Amplify and you see "50.0" in Amplification dB and "New Peak Amplitude" is -21.2. But if you now look at the data that has been created in the temp. folder as a result of the fade or amplify, it's only 5 MB of PCM data, exactly the expected size for 16-bit data. That *cannot* be 32-bit data as far as I understand it - if it was, it would be 10 MB in size. How does Audacity process that 16-bit data in 32-bit when you edit it, without increasing the size of the data?

2) Clear to a new project, generate the 1 minute mono 16-bit silent track, and change it to 32-bit format via the dropdown menu. That creates 10 MB (not 5 MB) of data. Opening Amplify shows "New Peak Amplitude" of -Infinity, and applying Amplify at 0.0, or a fade, produces no noise as you'd expect.

3) Change the Preferences to 32-bit quality, clear to a new project and generate 1 minute of 32-bit silence. Change to 16-bit format in the dropdown. That creates 5 MB (not 10 MB) of data. Open amplify and you will see 50.0 in "Amplification dB" and a New Peak Amplitude of -21, so as expected dither has already been applied because we have downsampled.

Now, I'm most definitely not an expert in signal processing, so someone may be able to explain to me, but:

* Those three scenarios suggest to me Audacity is not doing all processing in 32-bit

* If that's true, why are we adding dither in scenario 1) when there is no downsampling? This has the potential for adding noise to any 16-bit project with white space between clips as soon as you render or export, and as soon as you apply any Nyquist effect, which currently convert white space to silence (or for 16-bit audio, to dither noise). It also means you can't use "Detach at Silences" to get your white space back after running a Nyquist effect.


Gale

Gale Andrews wrote:
Here is what I see with shaped dither turned on again, 16-bit Quality setting, 44100 Hz project rate.

1) Generate 1 minute of mono 16-bit silence, and don't change the format. Open Amplify and note "Amplification (dB)" is 0.0 and "New Peak Amplitude" is -Infinity. Either apply amplify at 0.0, or fade in, then re-open Amplify and you see "50.0" in Amplification dB and "New Peak Amplitude" is -21.2. But if you now look at the data that has been created in the temp. folder as a result of the fade or amplify, it's only 5 MB of PCM data, exactly the expected size for 16-bit data. That *cannot* be 32-bit data as far as I understand it - if it was, it would be 10 MB in size. How does Audacity process that 16-bit data in 32-bit when you edit it, without increasing the size of the data?

[snip]

* Those three scenarios suggest to me Audacity is not doing all processing in 32-bit

* If that's true, why are we adding dither in scenario 1) when there is no downsampling? This has the potential for adding noise to any 16-bit project with white space between clips as soon as you render or export, and as soon as you apply any Nyquist effect, which currently convert white space to silence (or for 16-bit audio, to dither noise). It also means you can't use "Detach at Silences" to get your white space back after running a Nyquist effect.

Gale:
It depends on exactly *when* Audacity writes those files. If you save and name the project then the temp directory is not used (at least, not on a Mac). Instead the files will show up in the _data folder. This implies that what you can see in the temp directory is not a result of Audacity writing out intermediate results - i.e. 32-bit data before it is returned to the 16-bit track. If the developers assert that dither is only ever applied when downsampling, then I believe these experiments go a long way to proving that all internal processing happens at 32-bit.

I agree that this issue (at least at this level of detail) is of interest to very few users, and that the manual should be useful and understandable to novices. But at the same time these kinds of details should be available to those (like us) who are interested. As I said, a quandry. Writing really good manuals is a very difficult task and I appreciate the time and thought you have put in to a couple of sentences to get them right.

-- Bill

billw58 wrote: It depends on exactly *when* Audacity writes those files. If you save and name the project then the temp directory is not used (at least, not on a Mac). Instead the files will show up in the _data folder. This implies that what you can see in the temp directory is not a result of Audacity writing out intermediate results - i.e. 32-bit data before it is returned to the 16-bit track. If the developers assert that dither is only ever applied when downsampling, then I believe these experiments go a long way to proving that all internal processing happens at 32-bit.

Bill, data writing behaviour in the temp. folder is identical to that in a project _data folder. I've seen the apparent assertion that 32-bit processing is only done in 32-bit quality mode several times, and still don't see how Audacity can 32-bit process 16-bit data while the size of the data corresponds to 16-bit. If there's no further comments here, I'll see what more I can find out. But if it is correct that 32-bit processing is only done in 32-bit quality mode, I think that removes your main objection to the original wording (the use of "default" for 32-bit processing implying that lower bit format processing can occur).

billw58 wrote: I agree that this issue (at least at this level of detail) is of interest to very few users, and that the manual should be useful and understandable to novices. But at the same time these kinds of details should be available to those (like us) who are interested.

Agreed, but I think the Quality Preferences page and (if we ever get it written) the "Your First Recording" tutorial are the right places to expand on these issues, not the Digital Audio page.


Gale

Gale Andrews wrote:I've seen the apparent assertion that 32-bit processing is only done in 32-bit quality mode several times, and still don't see how Audacity can 32-bit process 16-bit data while the size of the data corresponds to 16-bit. If there's no further comments here, I'll see what more I can find out. But if it is correct that 32-bit processing is only done in 32-bit quality mode, I think that removes your main objection to the original wording (the use of "default" for 32-bit processing implying that lower bit format processing can occur).

Gale:
I'm not saying that 32-bit processing is done only in the 32-bit quality preference (QP) setting. I'm saying that 32-bit processing is *always* done regardless of the QP setting or the track setting. So, if a track is in 16-bit mode the data returned to the track after processing will be 16-bit, and the data sizes you're seeing are appropriate. The data sizes do not correspond to the bit-depth at which the processing was done, they correspond to the bit-depth setting of the track. The fact that a silent track (with QP setting of 16-bit, and track bit-depth of 16-bit) shows dither noise after a do-nothing process (such as amplifying by 0 db) is what implies to me that internal processing is always done at 32-bit.

The QP setting seems to affect: 1) the bit-depth of new recordings, and 2) the default bit-depth of new tracks.

It is certainly true that recording at 32-bit float will result in the highest quality throughout the editing process. If one is recording through the built-in 16-bit sound card on one's computer, recording at 32-bit versus 16-bit will not result in a higher-quality *recording*. But it will result in higher-quality *in the end* (after all the effects have been applied), since no rounding errors will occur during processing and no dither will be applied before the result of each effect is returned to the track.

Perhaps the manual needs a "for digital audio geeks only" section

-- Bill

I think this may require some information from someone who understands the relevant bit of Audacity code to get a definitive answer on this, but my reasoning is as follows:

Gale Andrews wrote:dither is only ever applied if downsampling to a lower bit format

Yes, that is my understanding.

Gale Andrews wrote:I've also understood on similar authority that Audacity only does 32-bit processing when in 32-bit float quality setting.

I don't see how that can be the case - if I were to stick my neck out, I'd say that was incorrect.

This leads us to the point in question in the manual.

Gale Andrews wrote:if it is correct that 32-bit processing is only done in 32-bit quality mode, I think that removes your main objection to the original wording

Conversely, if it's not correct, then the original wording is misleading.

The question about "why do the temporary files not double when processing 16 bit audio.

I seem to remember reading that Audacity processes data in blocks. Certainly it would not make sense for the entire track to be loaded into memory in one go, and we know that Audacity can handle tracks far in excess of the available memory.

So Audacity reads a block of data into memory, does some mathematical calculations on it, and writes the results back to disk, then moves onto the next block of data. It doesn't matter for the sake of the argument if these blocks of data are individual .AU files or not. What is important is the precision with which the calculations are performed. If the calculations are done using 32 bit precision, then although the original data was only 16 bit, the result is a 32 bit result and needs to be converted back down to a 16 bit number before it can be written to disk.
This gives you somewhat better quality than audio programs that use purely 16-bit or 24-bit audio samples.

If processing (the mathematical calculations) were only done at 16 bit for 16 bit samples, then the precision (hence the quality) would be significantly lower.

Although a 16 bit audio track never exists on disk as 32 bit data, the processing should be done in 32 bit rather than 16 bit and the evidence indicates that this is what happens. Digital audio processing is after all just number crunching.

Gale Andrews wrote:This has the potential for adding noise to any 16-bit project with white space between clips as soon as you render or export, and as soon as you apply any Nyquist effect, which currently convert white space to silence.... It also means you can't use "Detach at Silences" to get your white space back after running a Nyquist effect.

I seem to remember the point about exporting being raised some time ago and yes it does apply dither when Exporting 16 bit audio.
In my opinion this is a bug . When Exporting 16 bit audio to a 16 bit file, why is there any need to do anything to it in 32 bit? Either dither noise is being added even though there is no dithering to be done, or it is being converted from 16 bit to 32 bit and back to 16 bit when it is Exported.
Exporting 16 bit data to a 16 bit file should all be done with 16 bit integers and no noise.

Noise IS added to any 16 bit project with white space between clips as soon as you apply any Nyquist effect.
This may be avoidable (certainly retaining white space, as is being considered, would avoid it) but I would not call it a bug.
Processing audio with Nyquist is just number crunching in the same way as any other processing within Audacity, and doing it with 32 bit precision will still give you "somewhat better quality" than processing with 16 bit maths, even though dither is applied. The exception to the rule is when processing absolute silence (which is how Nyquist interprets white space). To avoid producing dither noise on silence, either a different algorithm for dither needs to be used, or Audacity needs to be able to somehow switch off dither when it encounters silence.

Interestingly there IS an algorithm that does NOT add noise to silence and that is the "Rectangle" dither. Unfortunately it works less well on non-silence than other types of dither.

In the audio world there is some argument about whether dither should be applied during processing at all. Advocates of "no dither during processing" maintain that applying dither on Export is sufficient and avoids the cumulative effects of dither noise at every stage. Certainly tests can be devised to support this stance, but it depends very much on what kind of processing is being done, how much processing is being done, and what kind of data is being processed. If VERY quiet audio is a significant part of the data and a LOT of processing is being done, then the case becomes stronger. An extreme example being if you apply fade-in (or "no effect") to silence several hundred times, the noise floor will gradually creep up. With real world audio examples and only a little processing I would favour dither whenever converting to a lower bit depth.

What can not be argued about is that best results will always be achieved by using high bit depths throughout and only converting to 16 bit (with dither) if required for the final export format.

Getting a bit carried away there, and almost forgot:

Gale Andrews wrote:It also means you can't use "Detach at Silences" to get your white space back after running a Nyquist effect.

Not necessarily.
a) the silences could be marked before passing the audio to Nyquist. In fact, before the data is read. The AUP file contains a "map" of where audio starts and ends, so I presume that data exists somewhere while an Audacity project is open.
b) the silence could be detected during processing and before converting back to 16/24 bit for writing to disk.
c) "silence" could allow for dither noise - that is, it could interpret a very low level as being silence.

Refering to "retaining white space", then a) would need to be the answer otherwise "real" silence (zero samples) will be converted to white space (null samples) which is not what is required. Ideally silence should remain as silence , and white space remain as white space.

Gale Andrews wrote:I think the level of this page should be kept understandable as far as possible without having to leave it.

Yes I fully agree and agree that it needs improvement. But it also needs to be accurate, and it is the "default" bit that I, like Bill, am having trouble with.

A definitive answer about what Audacity does internally may help us come up with some wording that is both easy to understand and accurate. No easy task for such a complex thing.

stevethefiddle wrote: I seem to remember the point about exporting being raised some time ago and yes it does apply dither when Exporting 16 bit audio.
In my opinion this is a bug . When Exporting 16 bit audio to a 16 bit file, why is there any need to do anything to it in 32 bit? Either dither noise is being added even though there is no dithering to be done, or it is being converted from 16 bit to 32 bit and back to 16 bit when it is Exported.
Exporting 16 bit data to a 16 bit file should all be done with 16 bit integers and no noise.

Steve:
This can be (possibly) verified experimentally.
Set the Quality Preferences to 16-bit and generate 10 seconds of silence. Export it as WAV or AIFF. Import the exported WAV. Bring up the Amplify dialog on the imported track and note the "new peak amplitude".
The result? The imported track has dither. Was the dither added on export or import? Hard to tell, but we are assured that dither is *not* applied when importing a 16-bit track into a 16-bit file.

Delete the existing tracks.
Set the Quality Preferences to 32-bit.
Generate 60 minutes of tone. Export it as WAV or AIFF and note how long it takes.

Delete the existing track.
Set the Quality Preferences to 16-bit.
Generate 60 minutes of tone. Export as WAV or AIFF and note how long it takes.

The result? It takes a little bit longer to export the 16-bit track! (23 seconds versus 19 seconds on my machine)
This last result implies that some extra computing is done when exporting a 16-bit track to a 16-bit file. Converting 16-bit to 32-bit?

Now, this actually makes sense. It seems that Audacity's behaviour has been optimized for the case of exporting a multi-track project. Some of the tracks in that project may have volume envelopes or volume/pan settings which are applied on-the-fly. Or different tracks may be at different depths. So, during export, *everything* is converted to 32-bit, volume and pan changes are applied in 32-bit, the tracks are mixed in 32-bit, and the result is exported in 16-bit with dither. This results in the most accurate mix.

The only case where you wouldn't want this to happen is if the project consists of nothing but a 16-bit stereo track with no envelope, volume or pan changes. That's a *very* special case. Programmers hate special cases. And I'm not sure that we, as users, need Audacity to recognize this special case and change its behaviour.

So, I respectfully disagree. Adding dither when exporting a 16-bit project to a 16-bit file is not a bug, it's a feature!

-- Bill

billw58 wrote:This can be (possibly) verified experimentally.

I did that before I posted

billw58 wrote:Was the dither added on export or import? Hard to tell,

Not at all difficult.

1) Generate 10 seconds of silence and export as a 16 bit WAV file called "dither.wav"
2) Switch of dither in Preferences.
3) Export the same 10 seconds of silence as a 16 bit WAV file called "no-dither.wav"
4) Turn dither back on in Preferences
5) Import BOTH tracks back into Audacity.
6) Test.

Result - dither is applied on Export (no-dither.wav is silent).

billw58 wrote:The only case where you wouldn't want this to happen is if the project consists of nothing but a 16-bit stereo track with no envelope, volume or pan changes. That's a *very* special case.

Not so special really. I would guess (with absolutely no evidence or research to back this up ) that such recordings account for at least 50% of all projects done with Audacity. Why so high? Because of the enormous number of people that do very basic projects such as transfering music to CD, or making podcasts without using the envelope tool, or trimming recordings made from YouTube.

billw58 wrote:Programmers hate special cases.

That's true - and I must admit that I'd overlooked Pan and Envelopes so I'll agree that it is a feature rather than a bug.

However, it is possibly such a common case scenario that it may justify special treatment.

On the other hand, how much difference does it actually make in those "special cases"? Extremely little (insignificant?), so is it worth the time and effort? Probably not.