Hi, I’m new to this forum although I’ve used Audacity happily for over six years.
I’ve just completed the pre-master files for a new album. Throughout the development of each component file in each mix I’ve exported the files as 16-bit (I know Audacity does its internal processing at 32-bit float – which I’ve maintained as the default). As in the past, I sent the final (16-bit) mixes to the mastering service I use, but this time they responded with a request that I send the files as 32-bit – for more effective processing. I pointed out that all my work had been exported as 16-bit, and that I couldn’t see how re-exporting the pre-masters as 32-bit (float) would improve anything. However, the audio guy said it would be better, but I still don’t see how. I’d be grateful for any comments on this issue.
Related to this, it was suggested to me that, in the future, it would be better for me to export everything – from raw recording onwards – as 32-bit float files, and then let the mastering service do the final reduction to 16-bit for the masters. This would mean a lot of extra space being taken up by the component files and, I assume a fair bit more processing power. I’ve always worked with 16-bit exports, so I’m not sure why there’s now a push to have me work with 32-bit exports. My material is typically distributed by streaming services and via CDs.
It won’t make much difference at all, but they are correct that for best possible results, 32-bit float is better.
For 32-bit float format, each sample value is represented as a 32-bit number. When exporting as 16-bit, each sample is rounded to a 16-bit value (a special kind of “rounding” is used that randomises the rounding direction so as to avoid creating harmonic quantization noise - this special kind of rounding is called “dither”.) Thus there is a very small value error (rounding error) to every sample value. The error is so small that in most circumstances it is inaudible.
So now let’s say that you send off your 16-bit mix for mastering. They convert it to 32-bit, but doing so does not correct the rounding error - the rounding error is preserved in the 32-bit representation. They then master the recording and export as 16-bit, which requires rounding back down to 16-bit again. So now you have two lots of rounding errors.
Also, during the mastering process, if any of the audio is amplified, then the errors from your conversion to 16-bit are also amplified.
To keep this in perspective, the “errors” we are talking about amount to a tiny amount of hiss, but to minimise this noise, the audio should be kept in 32-bit format until the final export after mastering.
Yes, the 32-bit float files will require double the amount of disk space as 16-bit files, but exporting actually requires less processing power because the sample values are just being copied to disk - no conversion to 16-bit is required.
One side issue, if you never come down from 32-float, you don’t need dithering noise in the export.
Usually they want the best format you have, or they may request 24/96, etc. And sometimes they may ask that you leave a certain amount of headroom (which isn’t technically-necessary as long as you’re not clipping).
And, it’s usually best to just give them what they want. But more importantly, they should be giving you what you want! …Do you want that modern “loudness war” sound or do you want to retain all (or most) of the dynamic contrast, etc.?
Thanks Steve, your explanation has objectively described what I felt must, at least, be a pointless double conversion. But as you make clear, it’s not only pointless but will introduce a second error component in the mastered 16-bit files. I’m not sure whether, in the past, the mastering service converted my 16-bit pre-masters to 32-bit for processing before the final 16-bit conversion. This time, they asked me to do the initial conversion myself (as described in my original post). I’ve been reasonably happy with the outcome in earlier times, so I’ll keep my fingers crossed for this occasion – I should be able to make an assessment early next week. Regardless, I’m pretty certain I’ll be sticking to 32-bit float exports for everything from now on.
Also, Koz and DVDdoug: your comments were also really helpful – thankyou.