64 Bit FP Audio Engine?

[ThomasHelzle]

Ah - I thought you mean input recording from an interface, sorry. You can already export to 32 Bit Floating point.
What exactly is missing for you?

Cheers,

Tom

[dom@bitwig]

Exactly... and good posts already right at the very begining of a thread!

TL;DR: 32 bit offers sufficient headroom and the cons of 64bit (speed) likely make it not worth it to have more (inaudible) headroom.

+1

Actually after some reading, it seems that using double precision floating points is pretty common in audio these days! I stand corrected!

So why the heck is that?

So while some of the latest DAWs touts 64-bit audio paths throughout, I don't see that at a serious improvement, but more of a marketing gimmick. And in the end, it's going to be output to a 24-bit DAC, and your hardware and your ears can't even resolve that much. I don't see enough error accumulating to matter.

3 very valid points!

Cheers,
Dom

[billcarroll]

Ah - I thought you mean input recording from an interface, sorry. You can already export to 32 Bit Floating point.
What exactly is missing for you?

Cheers,

Tom

Unless I am mistaken, when you bounce in place this is done at 24-bit. It would be useful to have bounce in place operate at 32-bit floating point.

To be clear, I'm not advocating at 64-bit FP audio engine, I was just asking for clarification on that point, which Tom was kind enough to give.

[dom@bitwig]

Ah - I thought you mean input recording from an interface, sorry. You can already export to 32 Bit Floating point.
What exactly is missing for you?

Cheers,

Tom

Unless I am mistaken, when you bounce in place this is done at 24-bit. It would be useful to have bounce in place operate at 32-bit floating point.

All audio gets calculated by the engine at 32bit. That's when you actually benefit from 32bit resolution, during the processing, only the file export then writes a 24bit file.

[ThomasHelzle]

Ah - I thought you mean input recording from an interface, sorry. You can already export to 32 Bit Floating point.
What exactly is missing for you?

Cheers,

Tom

Unless I am mistaken, when you bounce in place this is done at 24-bit. It would be useful to have bounce in place operate at 32-bit floating point.

To be clear, I'm not advocating at 64-bit FP audio engine, I was just asking for clarification on that point, which Tom was kind enough to give.

Yeah, true, that would make sense as a preference.
Mail to Tech-Support or hoping that Dom is still reading

Cheers,

Tom

[ThomasHelzle]

All audio gets calculated by the engine at 32bit. That's when you actually benefit from 32bit resolution, during the processing, only the file export then writes a 24bit file.

Yeah, but Bill is right: if you use the 32 Bit headroom in your track, bouncing in 32 Bit would make sense, since you then wouldn't have to worry about clipping, especially since it's 32 Bit internally anyway.
I would make that a preference.

Cheers,

Tom

[billcarroll]

Ah - I thought you mean input recording from an interface, sorry. You can already export to 32 Bit Floating point.
What exactly is missing for you?

Cheers,

Tom

Unless I am mistaken, when you bounce in place this is done at 24-bit. It would be useful to have bounce in place operate at 32-bit floating point.

All audio gets calculated by the engine at 32bit. That's when you actually benefit from 32bit resolution, during the processing, only the file export then writes a 24bit file.

Dom and Tom, I really appreciate y'all discussing this topic.

If we are going from 32-bit floating to 24-bit then there should be dithering, which I prefer to avoid by staying in 32-bit until I want to output a final file. I certainly don't want to go from 32-bit float to 24-bit every time I process and bounce a file.

My preference would be to work at 32-bit float, and keep all files in 32-bit float, until I'm ready to export.

[dom@bitwig]

If and when dithering from 32bit to 24bit makes sense or not is also an interesting and much discussed topic... the bits that get truncated will not ever reach your converters anyway, as you only write the result of a finer calculation to a file, so not changing the signal further by dithering it should be avoided, but this is pretty dumbed down and a lot more involved and it is too late over here to dive into that today.

[Eta Carinae]

https://www.youtube.com/watch?v=Qt-EJhDDHUI

This is the tip of the iceberg. The more processing you do on a file, the more useful 32-bit floating point becomes.

But if you just set your gains to sensible levels, then there's no need to render in 32bit. All it does is take up extra disk space. 24 bit easily has enough dynamic range for modern productions.

[u-u-u]

My preference would be to work at 32-bit float, and keep all files in 32-bit float, until I'm ready to export.

Sounds reasonable, so why not? +1
Of course that probably slows down bouncing time and so on but if it's practicable somehow -> always +1 for optimum in sound quality. (EDIT: of course, i meant when you use the bounced files for further editing/processing - not that a 24bit file sounds worse when you leave it as it is.)

Another point(just to be a wisenheimer):
Of course the differences between 32bit floating point and 24bit are not audible in a rendered audio file -> Although for processing and editing 32bit is better.
You never know what crazy algorithms will get applied to the signal or how much you want to increase the volume of a recording whose level is too low (even a DAW internal recording from, say, a stochastical sound generator which never plays stuff twice and you just found the one perfect sound ).
Same thing with the sample rate: you never can get enough -> for a normal playback of an audio file 44,1 kHz might be enough but for processing you'll sometime need much more. (extreme time stretching; just pitching down high sounds: e.g. 16 kHz to 100 Hz; recording HF electromagnetic waves and pitching down the result to make it hearable (don't know whether that will bring good results but again: you never know ))

[billcarroll]

https://www.youtube.com/watch?v=Qt-EJhDDHUI

This is the tip of the iceberg. The more processing you do on a file, the more useful 32-bit floating point becomes.

But if you just set your gains to sensible levels, then there's no need to render in 32bit. All it does is take up extra disk space. 24 bit easily has enough dynamic range for modern productions.

This assumption is incorrect. Processing audio within a DAW will benefit from 32-bit floating point in many situations.

[Eta Carinae]

https://www.youtube.com/watch?v=Qt-EJhDDHUI

This is the tip of the iceberg. The more processing you do on a file, the more useful 32-bit floating point becomes.

But if you just set your gains to sensible levels, then there's no need to render in 32bit. All it does is take up extra disk space. 24 bit easily has enough dynamic range for modern productions.

This assumption is incorrect. Processing audio within a DAW will benefit from 32-bit floating point in many situations.

No, your post is incorrect. I'm not talking about internal DAW processing, I'm talking about the video that you posted, which clearly shows an export to 32bit.

If you learn gain staging then you don't need to worry about clipping. Just don't export things so loud.

[billcarroll]

https://www.youtube.com/watch?v=Qt-EJhDDHUI

This is the tip of the iceberg. The more processing you do on a file, the more useful 32-bit floating point becomes.

But if you just set your gains to sensible levels, then there's no need to render in 32bit. All it does is take up extra disk space. 24 bit easily has enough dynamic range for modern productions.

This assumption is incorrect. Processing audio within a DAW will benefit from 32-bit floating point in many situations.

No, your post is incorrect. I'm not talking about internal DAW processing, I'm talking about the video that you posted, which clearly shows an export to 32bit.

If you learn gain staging then you don't need to worry about clipping. Just don't export things so loud.

Once again, your assumption is incorrect. You might want to read up on 32-bit floating point and the related benefits before making a claim that all you need in place of 32-bit floating point is proper gain staging.

[billcarroll]

If and when dithering from 32bit to 24bit makes sense or not is also an interesting and much discussed topic... the bits that get truncated will not ever reach your converters anyway, as you only write the result of a finer calculation to a file, so not changing the signal further by dithering it should be avoided, but this is pretty dumbed down and a lot more involved and it is too late over here to dive into that today.

Dom,

If bounce in place creates a 24-bit file and the audio engine is 32-bit floating point, is Bitwig upsampling on the fly to deal with 24-bit audio files? How does bitwig handle files that are lower than 32-bit floating point?

Would it make sense to give us the option to bounce in place at 32-bit, and also the option to upsample files as they are imported into a Bitwig project? Wouldn't this option reduce resource overhead?

edit ... As for dithering when going from 32-bit float to 24-bit, I believe the general consensus is overwhelmingly for dithering when downsampling. Is this not true? In any case I'd prefer not to go from 32-bit float to 24-bit when using bounce in place.

Thanks again for your time.

[Eta Carinae]

https://www.youtube.com/watch?v=Qt-EJhDDHUI

This is the tip of the iceberg. The more processing you do on a file, the more useful 32-bit floating point becomes.

But if you just set your gains to sensible levels, then there's no need to render in 32bit. All it does is take up extra disk space. 24 bit easily has enough dynamic range for modern productions.

This assumption is incorrect. Processing audio within a DAW will benefit from 32-bit floating point in many situations.

No, your post is incorrect. I'm not talking about internal DAW processing, I'm talking about the video that you posted, which clearly shows an export to 32bit.

If you learn gain staging then you don't need to worry about clipping. Just don't export things so loud.

Once again, your assumption is incorrect. You might want to read up on 32-bit floating point and the related benefits before making a claim that all you need in place of 32-bit floating point is proper gain staging.

I have, and I've also read about gain staging.

From what I understand, DAWs already process internally at 32bit, and some plugins process at 64bit internally. But the only advantage to EXPORTING in 32bit is that you have unlimited headroom.

That's fine if you're a novice who doesn't know how to set your levels correctly. But as 24bit already provides more dynamic range than the human ear can hear, there really is no need to export things that loud.

But if there are other uses, perhaps you can share them with me? Because right now, it seems like you've been misinformed.