Benefit of recording 32-bit audio?

Aloha guys,
Yes yes yes yes!

Here I do mucho local stuff that many times is one
person singing (chanting) or one
solo flute type instrument or
a single slack key guit or uke.

And yes in that context you can hear a diff.
Especially with a single vox with no FX.
And at my age too! :slight_smile:

{‘-’}

Also all busses are at the least 32bit, so this sounds counter intuitive but recording 32bit places less stress on the computer (with the exception of storage subsystems).

As for sound quality you will not really hear a difference, the problem with PCM is that increases in bit and frequency rates give much smaller advances in sound quality than they do with Delta modulation for instance, although increasing sample rates above 50k will increase detail in high frequencies and up the filter like Nyquist behaviour outside of most peoples hearing range. However, 32bit does have a huge advantage if you do signal processing involves a lot of data reduction like noise reduction, click removal, extreme levelling and EQ etc., you simply have bits to spare so to speak, In the archival world people are moving to 64 bit files and processing for this reason, i.e. not the initial sound quality which stays the same effectively but the quality of the end result after large chunks of the original data has been removed in the NR and artefact removal processes.

In the old days there was the benefit that 32bit float would play on old sound blaster 16bit cards. Not that I see many of them anymore :slight_smile:

You are imagining things. In a properly executed blind test you will NOT be able to hear any difference. You are “hearing” a difference because it is a bigger number of bits and you want to hear it due to the psychological bias you have. Also, if you are not doing any offline processing there is ZERO difference between recording 24 bit fixed and 32 bit float.

The only way you will see a difference is to intentionally force errors using offline processing as Soul-Burn described, but if you have anywhere near remotely decent gain-staging habits, 24 bit fixed is more than adequate resolution and the mixer is always floating-point no matter what file type you use.

Last, with modern computers I do not believe you will see any “less processing” load on the computer by recording 32 bit float files. The files are bigger too, and if you record much this can be a penalty (despite what others may claim). I record many tracks every day and back them up after every session. File size is still an issue for me even with today’s large inexpensive drives.

There is less stress on the bus and processor while recording and playback of 32bits because the bus has to perform padding for smaller files while 32bit wide files get pumped straight through, simple really and immaterial if the files are FP or integer, the same can happen with plugins but that actually depends on their design, etc. If the computer is modern or not is of no issue as long as the bus is 32 bits.

Less stress? How do you measure this? Does it actually make a difference in performance?

I’ve tested recording 32 bit/float files versus 24 bit fixed @ 32 sample buffer setting and saw NO difference in performance. You are also writing more data to the hard drive using 32 bit files versus 24 bit fixed, which could be argued is stressing the system more.

In the vast majority of cases there is absolutely no benefit to recording 32 bit/float files in Cubase. Export audio mixdown to a 32 bit float file can be useful at times, but it is not something that is going “improve” your mixes and not really what the OP was talking about.

Yes, a little if the bus is not constrained, a lot if the bus is already constrained (or lane in modern PCI-E Chipsets), it is not a piece of knowledge that should change your life but rather like turning off Hyperthreading on an intel board or turning on the high resolution clock on a AMD board, a useful knowledge to have when diagnosing audio card errors and latencies.

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?