Benefit of recording 32-bit audio?

Notwithstanding a discussion on proper gain staging, I can think of 3:

  1. You want to preserve any transients that exceed the 0dB TPL.

  2. You print a final mix but might want to add processing at a later time.

  3. You exchange stems with others using 32 bit FP systems.

One can also argue about the S/N quantization being less audible in a 32 bit environment or that the amount of data available for dithering or in-line processing contributes to a “fuller” sounding product but those are discussions based more subjective than empirical.

First of all - where is the proof of the performance benefit Reiknir? Turning off Hyper-threading actually makes a difference in performance, recording @ 32 float versus 24 fixed does not - at least in my testing. Simply stating that it makes a difference does not make it so. Also, recording at 32 float requires conversion at the time of recording (converters are fixed point) and we are also writing more data to the drive than fixed point. My system is most stressed when recording at low latencies - there is no evidence that using 32 float files improves this. One could argue that the system is MORE stressed doing the 32 float conversion when recording. The reality is that there is no noticeable difference - just bigger files.

Sooooo true. :slight_smile:
{‘-’}

Wrong. The mixer is floating point and you are not in danger of losing any transients. If you are talking about printing a mix to a 32 float file - that is a different subject and not what the OP was asking about. I mention that this had some potential benefit in an earlier post.


Again, this is about PRINTING a mix to a 32 float file. The OP asked about tracking to 32 bit files. Also, as long as there are no ‘overs’ and the peak level is at least -20 dBfs or so, it should not make any audible difference anyway.

So? Print your stems @ 32 float (not that you should hear any difference versus 24 fixed, assuming your gain-staging is anywhere near decent). You still have no need to record at 32 float when tracking, and again, you are talking about printing mixes, not tracking.

The quantization distortion you speak of (32 float to 24 fixed) is well, well below the limits of human hearing, not to mention the ability of the gear to reproduce it. Dithering, while the technically correct thing to do, will not make an audible difference in this case either. Blind tests will prove this, though some are not interested in the truth.

Don´t ask for proof when you are not offering some yourself

I never mentioned float, you did, I specifically mentioned that as far as the bus is concerned it sees no difference between float and integer, it is the bit width that matters to it and that you think that there is more data involved binary transfers of float than integer shows that you do not even understand the basics of computing, a 32bit set of data is 32bits wide regardless of what it represents. File sizes are a different matter altogether.

A bit width is a similar concept to a lane on a motorway, if the road in question has 8 lanes it can handle a maximum of 8 cars in parallel at any given point regardless of how many cars are there in total, how fast they are driving or if they are big or small. The latter three all affect the throughput or efficiency of the motorway, but have no effect on the basic parallel capacity of the road. At any given stage of processing the computer only sees the point rather than the motorway as a whole, so if a bus presented with 4 cars at one specific point it fills it up with 4 imaginary cars and processes the next point, the CPU or northbridge/hub then has to sort out which cars sent to it by the southbridge are imaginary and which are real.

And turning off hyper threading is not a question of performance but rather you disable hyper threading so that the fake core does not interfere with the RT subsystem by assigning timing sensitive data out of order in the processing stream of the real core, if that happens you can get latencies and hiccups because the real core has to react to an out of order event that does not exist on a non-HT processor or one with HT turned off. Although the reasons are different this is a similar end result to the problems people sometime experience with motherboards that have built in graphics cards that share memory with the processor, the processor occasionally hiccups due to timing errors induced by the processor/northbridge having to wait for the graphics/southbridge to complete a memory access on the same clock cycle, these are so small that you do not notice them while browsing the web but a piece of software that relies on RT response like cubase and the audio driver will get “confused” for a millisecond, this is the reason the cubase manual asks you to place a “real” graphics card on such a machine.

All that hyper threading does is rearrange a virtual thread to a real core, can be useful in some cases for a highly threaded application like a multi user database system or a massive Prolog program, poison to RT applications

Cubase and Nuendo doesn’t support HT, so… But if you are multitasking with other apps that do…

Just opened the second can of worms :wink:

There is more headroom.done

Before the final stereo mix, the only advantage of 32-bit audio files/recording is if you use a great amount of Offline Processing.

Internally it is the 32-bit floating point calculations that make a “crazy high” headroom (in plain mixing/recording), no matter what bit size your files have.

But to try to use that “internal headroom” is a very BAD BAD BAD way of learning proper gain staging…

… Remember, more and more of the plugins today actually emulates the real analog equipment down to the very behaviour of proper gain staging (the way we had to do it in the old analog days).
So if you want to use those plugins properly (without adding crazy distortion/artifacts), you better start learning about proper GAIN STAGING today
If so, no need for the 32-bit added internal headroom as you have to pass your final mixbus/converter on your way out of your computer sometime anyway (again, bad bad Gain Staging).

If you do a crazy amount of offline processing, go ahead and use 32-bit audio files/recording. Happy messing with the source files :wink:

That is not the real problem, major audio apps like Cubendo are aware of HT and “disable its use” or probably rather make sure that any cores they utilise are real ones, it is apps and even drivers that pre-date HT or are not aware of the problem that are presented with the HT “tread” as a real processor core (should not happen with drivers, all drivers should operate on the first core only, but some offload some tasks to user space and use threaded libraries, old sampler card drivers come to mind)

Hi,

Where is this AMD tweak?

The 32bit floating files have a 24bit signed mantissa (value) and an 8bit signed exponent (scaling factor)

A 24bit mantissa means that 32bit float has the same accuracy as 24bit integer.

The advantage of floating point is that it is unlikely to ever overload, as you would have to overdrive them by approximately 128 x 6dB, which is more than 700dB!

As Cubase supposedly works internally with 32bit floating, the only difference your setting has is how the data is stored. With an integer setting (24 or 16bit), if you do not establish proper gain staging so that any channel NEVER exceeds 0dB, then some clipping will occur in the file for that channel. Actually the file doesn’t know its clipped, because it just has a bunch of maximum values in a row, but you will hear it when playing it back, in or outside Cubase.

Regardless of how the files are stored, any channel directly connected to a DAC will be clipped when the signal at the DAC goes over 0dB. If using 32bit floating for files, the values stored for such channels will still have the correct (non-overloaded) values.

Of course 24bit integer files will be 3/4 the size of 32bit float files.

The same gain staging considerations will apply when saving 24bit integer files after editing outside Cubase.

^^^
What he said.

I read that 32 bit float reduces rounding errors caused by plugins and reduces noise from dithering? If you have enough storage, hard drives are cheap, then why not use 32 bit?

Having the same number of bits of precision as 24bit integers means that there is essentially no difference.

Real time plugin processing is executed in the internal 32-bit floating point realm no matter the bit rate on your source files.
Again, what you say only applies when doing a lot of offline processing.

Dithering is only used as the last step (once), when reducing the bit rate to the intended format (ie 24 bit to 16 bit for CD).
Said that, some old plugins/plugin technology has dithering on by default. Which only try cover up bad (or once good, but old) plugin beaviour/programming.

If it was just 32 then yes, but when it’s float? More headroom, less errors?

Doesn’t the plugin have to covert the file to 32 then back to 24 bits? I’m a little confused about this.

Same rounding errors, which are principally controlled by the bit depth, which is 24.

Float offers less chance of catastrophic errors, that is overload, due to the 8 bit signed exponent handling the scaling.

This is what they say on the Pro Tools website (don’t shoot me lol).

"So having your 24 bit recordings in 32 bit floating point format will not change the quality of the initial recordings themselves, but creating audio files in this format before they are processed by plug-ins will help you avoid the following:

Clipping during AudioSuite rendering
Unnecessary noise introduced by AudioSuite dithering
Rounding errors during signal processing

These issues then are mostly caused by the fact that with either 16 or 24 bit audio the data requires conversion at the point of processing."

http://www.askaudiomag.com/articles/pro-tools-10-the-benefits-of-32-bit-floating-point-audio

So 24 bit files are up sampled to 32 and then back to 24 in a 32 bit plugin? That is where rounding errors etc are caused? Doesn’t it effect the file when you do an audio mixdown?

As already discussed.

Possibly because the dithering will be avoided.

If signal processing is any more complicated than simple addition or subtraction, there is no simple generic explanation. Signal processing may involve conversion between time and frequency domains and sample rate changes, which are non-trivial in execution and explanation.

That is, conversion from input ADCs and to output DACs.

Upsampling refers to sample rate changes, which may be done in a plugin (most UAD plugins internally upsample to 192k for their calculations, and downsample at their output).

Remembering that 32 bit float and 24 bit integer have the same value bit depth, then the more the 32 bit values are above 0dB, the more least significant bits are lost when converting to 24 bit.