If they left it where it always was, it’s Preferences > Quality > Sampling.
However. You may not want to work natively in your import format. Audacity converts to 32-float because it doesn’t overload. You can apply whatever effects, filters, or corrections you wish, it will always be possible to gently bring the show back to normal volume ranges no matter where it went.
For example, in Audiobook Mastering, the first step, Equalization, always reduces volume, but the middle step, Loudness, could very easily create tips and peaks that go over 100%, giving you ticks and pops in the performance. The third step, Limiter, gently corrects those peaks back down to Audiobook Standard — Maximum -3dB.
That only works if you’re in 32-float. If you’re in any of the fixed formats, the distortion is permanent. Once something goes over 100%, no matter how it got there, you’re stuck.
While you’re messing with this, it pays handsomely to keep a clean backup copy of the original work somewhere. Once you realize you permanently messed up the governor’s interview is a bad time to not find your backup.
By the way, that’s a terrific reason to do critical work on a stand-alone recorder. Automatic safety backup.
Audicity appears to not know what it wants to be. If importing a file means it is automatically converted to 32-bit, yet it is possible to set the project to 24-bit, which does rather go against what you said.
I am aware of the ‘theoretical’ reason for the automatic conversion of imported files, but it is of no use if your using a project set at 24-bit.
Looks like either a bad bug, or somebody hasn’t thought it out (shades of Reaper here).
I don’t what the chances of this issue being sorted if i put it down as an issue to be dealt with, but i guess i can tey, if nothing else.
The way I understand it, if the show and the bit rate match at 24, Audacity either doesn’t convert, or converts from 24 to 24. Similarly on Export. It’s possible the new version no longer does that. Which Audacity version number do you have? I do need a number.
when i import a 24-bit mono file into the program it is immediately converted to 32-bit
How do you know it’s doing that? What damage did you discover?
Are you really objecting to the dither signal that Audacity adds to the export? Early versions of Audacity had serious problems with that. Now much less so. You can set dither—or even turn it off.
DSP is easer & better in floating-point so if you apply any effects I’d bet that Audacity is converting to floating-point, even if it converts back before you know it.
DSP? Sorry but i can’t see how that deals with a problem with Audacity itself.
However. You may not want to work natively in your import format. Audacity converts to 32-float because it doesn’t overload. You can apply whatever effects, filters, or corrections you wish, it will always be possible to gently bring the show back to normal volume ranges no matter where it went. The conversion is lossless and mathematically reversable.
If the program gives the option to work in another way to the standard 32-bit, ie; 24 & 16-bit, then it is to be expected that options like “import” should work to that standard and not just universally convert the (say) 24-bit file being imported to 32-bit which then requires to be converted back to 24-bit, which is NOT transparent
I think it could be argued that this is a “very minor bug”.
The workaround is very simple:
After importing the file, click on the track name, and from the dropdown menu: “Format > 24-bit PCM”
However, I would highly recommend that you don’t do that.
There is one, and only one benefit to working in 24-bit rather than 32-bit float, which is that it potentially saves up to 25% disk space.
There are multiple down-sides to using 24-bit rather than 32-bit float, including:
Going over 0 dB at any point during processing / mixing will permanently clip the audio.
Internally, Audacity works in 32-bit float, so there will be two conversions, 24-bit > 32-bit float > 24-bit, every time you apply an effect (unnecessarily reducing the audio quality).
Processing is a bit slower.
CPU usage is slightly increased.
Processing will either introduce quantization errors or add dither noise (depending on conversion settings). This is unavoidable.
Unless disk space is an overriding issue, I would highly recommend working in 32-bit float.
Conversion from 24-bit integer to 32-bit float is transparent and “bit perfect”.
Conversion from 32-bit float to 24-bit integer may or may not be “bit perfect”, but is “transparent” in the audio sense, which is “perceptually lossless”.
Repeated conversion between 32-bit float → 24-bit integer → 32-bit float → … may create audible loss in quality (ie. not transparent).
Conversion from 32-bit float to 24-bit integer is bit perfect if:
The sample values can be represented exactly in 24-bit
“Dither” is turned off.
Note that processing audio will almost always produce sample values that fall between 24-bit integer values.
Many thanks for taking the time to reply, but i feel we are going around in circles with everyone giving information that doesn’t really help with the issue, and therecs no reason given why the program allows it to be set to 24 or 16-bit, butat least one area, so far, doesnct seem to be aware of the settings.
It is NOT an option i feel that should be accepted to have a 24-bit file automatically converted to 32-bit (in a 24-bit project!!) and having to reconvert it to 24-bit. Very sloppy and poor programming.
So why is the option to chose 32/24/16-bit in the project settings there at all if the program makes such an option pointles?
For information: The 24-bit files to be imported have previously been recorded in 32-bit and finally saved in 24-bit format. They’ve been through enough!!!
I gave the reason: “There is one, and only one benefit to working in 24-bit rather than 32-bit float, which is that it potentially saves up to 25% disk space.”
(for 16-bit, there’s a potential saving of up to 50% disk space).
If it had been my decision, the 16 / 24 bit options would no longer exist. They’re a legacy from 20 years ago when disk space was expensive. Now that even cheap hard drives are often a million times bigger than was affordable 20 years ago, there’s very little justification for retaining these options.