I have several voice files in 32bit 44100 wav format. I’m finding that I can’t always do all my editing (eq, noise removal, normalize, etc) in one session. I’m also trying to work out a way to use chains to automate some of the work.
What I want to do:
Use chains on a directory of files to automate as many steps as possible and keep 32bit format until the very end.
Except I can’t keep 32 bit if I save or export from within a chain (I think).
Even if doing manual editing, I can’t export a 32 bit file.
What I think I can do:
Save as an Audacity project seems to keep the 32 bit format. However this changes my directory structure and I no longer have a single wav file in case I have to do some steps in another software package.
I can also do manual editing, noise removal, etc. on the project.
I guess this all boils down to a new feature to export 32 bit wav from the interface and the corresponding chain command.
In your particular case, you should be able to Save the Project in your extended format and use chains to open that up instead of stand-alone music files.
I’m gritting my teeth as I say this because we’re constantly harping that people need to Export “real” sound files often in the face of failures or crashes. Projects can be brittle.
Hokay, of course I found “Other Uncompressed Formats” immediately after I posted. Welcome new user!!
I do prefer to keep just the wav file. So I’ll pare my new feature request down to having a chain command to export 32 bit wav files.
Now I think I’ll just run my chain (low cut, high cut, normalize) manually instead of on a series of files followed by noise removal. I think that will take care of 90% of what I need. Some of these have furnace fan rumble and all of them have some level of tape hiss. I’m still learning/experimenting with eq settings for spoken voice restoration.
OK I’ll add your vote so (@ Peter) you need not add the vote at the end of the month.
@Rich_O If you are on Windows 2000 or later and want a build that has experimental support for ExportUncompressed in Chains, I can send you a link to one.
It may be a moot for me right now. I’m having to learn all about digital audio as I tackle these restorations.
I believe it would be extremely rare to have 32 bit sound built into a laptop so my recordings are surely 16 bit. However the software allows me to select 32 bit. I think it really does save the file as 32 bit wav (the file size is correct for 44100, 32 bit) but maybe some space is wasted.
That is each sample in 32 bit has 4,294,967,296 levels of resolution but since the actual data is 16bit, only 65,536 levels are being used and the rest are just sitting there empty. Do I have the right impression about this?
So, bottom line as far as this thread is concerned is that “exportwav” would probably do everything I need if I were to use chains. I probably won’t use chains soon since I’m having to experiment with Eq settings look at spectrum charts and listen carefully to make sure I know what I’m doing.
That’s a close enough description until you do any audio processing.
Let’s take for example a simple “fade in” effect. The final sample of the fade will remain at its original volume, while the first sample will be reduced to zero. The sample in the middle will be reduced to half of its original volume, and in like fashion each other sample will be reduced proportionally according to its position in the fade. Where the problem comes is that some sample values will not scale exactly. For example if the middle sample has a numerical value of 121 (on a scale of −32,768 to +32,767) then the scaled value should be 60.5, but in 16-bit data that value does not exist. What we would need to do is to approximate the value by rounding. This type of error is called a “quantise error”. Unfortunately a nasty feature of quantise errors is that they tend to fall into regular patterns, similar to the effect of looking at a striped shirt on a television, or the patterns that are formed when looking through two layers of netting. One way round this problem is to use “dithering” to smooth out the “steps” (similar to the use of “dither” in printing), but this has the downside that it introduces noise, and worse still the effect is cumulative. With each process that is applied to the audio, whatever measure are taken to combat it, the errors increase and lower the sound quality.
The solution is to do all of the processing with much higher precision -preferably a floating point format such as 32-bit float. In 32 bit float the value equivalent to 60.5 can be accurately represented so there is no rounding error. In fact 32-bit float is so precise that you can apply hundreds of processes with virtually no loss of accuracy. The only problem comes when you come to export at 16 bit for your final mix down, and at that point there will be some rounding errors, or a little bit of noise if dither is used to smooth the steps. The point about this is that this rounding or dither only occurs once - when you export - it does not occur repeatedly with every processes that you apply.
So the short version is that if you only record, cut, paste and delete and do no processing at all, then you are as well to stick to 16 bit throughout. However, if you do any processing at all, then working in 32-bit float wins out for sound quality (applying only one process it is probably a draw).
Now back to using Chains:
If you are using Chains for intermediate processing of a batch of files (the processed files are not the final product) then I agree that it would be beneficial to export in 32-bit float format (and I’ll be adding my vote to this). The good news is that even though you currently have to export in 16 bit (at best), the losses due to rounding/dither are small. In most cases “dither noise” will be considerably lower than the background noise of the source material. Unfortunately though it does mean that for the very highest quality work you should not use Chain Export as an intermediate step as it forces you to drop down to 16 bit. Of course if the output of the chain is the finished product (which you will probably want in 16 bit format) then this limitation does not matter.
I’ve added my vote to “Export Other uncompressed”, but of these I think that Exporting as 32-bit (float) is the most important (though not specifically listed on the Feature Requests page of the wiki).
I have some technical background, but of necessity, I’m going at this from the outside-in…from a software users point of view.
So, I have Audacity set to 32-bit float and I import a 16-bit file. Now I really do have 32-bit data…by interpolation?
And it really is beneficial to work in 32-bit float until I make the final 16-bit file for CD or MP3 for computer.
The processing I anticipate is 2 or 3 passes of EQ, one pass of Noise Removal, and normalize. And I could use chains to combine the Eq steps, for example, during a session where I would manually export the 32-bit file.
Unfortunately the answer is not quite that simple.
If you import an uncompressed audio file (WAV, AIFF or Flac) then Audacity can either make a copy of all of the data straight away or it can copy the data as needed. This depends on a setting in “Edit menu > Preferences > Import Export”. Make a copy … (safer)
Read uncompressed audio files directly … (faster)
The default is “Make a copy”, in which case you will really will have 32-bit data as soon as you import.
If you change the setting to “Read uncompressed audio files directly” (not generally recommended) then you will have real 32-bit data as soon as you need to process it, but this setting does not copy the data until it is actually required.
If you import a compressed file (such as MP3) then it is always copied.
If you import a compressed file that requires FFMpeg for importing (such as WMA) then the file will be copied in, but it does not get converted to 32-bit (automatic conversion of files imported with FFMpeg is not yet supported).
Rather than trying to remember exactly which formats are converted to 32-bit and which are not, just check the track information on the left end of the track - it tells you whether it is 16, 24 or 32 bit float.
if needed you can easily and quickly convert a 16 or 24 bit track to 32-bit float by clicking on the track name, then in “Select sample format” select “32-bit float”.
Converting from 16 (or 24) bit to 32-bit float is 100% lossless. Each 16 (or 24) bit value has an exact equivalent in 32-bit float format.
Converting from 32 bit float to 16 (or 24) bit is not totally lossless because 16 and 24 bit formats can only represent integer values, so any fractional values must be rounded. Basically there are a lot more discrete values that a sample can take in 32 bit format than in 16 or 24 bit, so any in-between values must be fudged in one way or another.
I’ve got a lovely little experiment that demonstrates this:
Import or record a bit of audio
Make a duplicate of the track (Select the track then Ctrl+D)
Apply “Normalize” to bring both tracks up to a peak of -1 dB
Set one track as 16 bit and the other track as 32 bit float (they both sound identical, though the 32-bit track will now use 32-bit values).
Apply the Amplify effect with the Amplification amount set to -40 dB (minus 40). Both tracks go very quiet.
Repeat step 5 to make the tracks a further 40 dB quieter (or just press Ctrl+R to repeat the last effect)
Now Normalize both tracks back up to -1 dB.
The 32-bit track should sound virtually unchanged by the processing. The 16 bit track shows extreme deterioration.
The experiment was quite illuminating.
In summary I can now say that even though I digitized at 16-bit, it’s still worthwhile to convert to 32-bit float for any processing. That’s worth knowing.
Welcome new user!!