What bit depth am I recording at, 16 or 24?

[selig]

My stand is still the same. Reason for me uses 24 bit. If I go from higher to lower I always use dithering and for me 24 is the maximum in reason so I don't use dithering, I agree with you every engineer has different perception about floating point some use dithering some don't I prefer to use going from 32 to 24 and 16.

Just to be clear one more time, Reason uses 32 bit signal path internally for you and for everyone - you can't control this. Your audio card uses 24 bits to create the digital stream. Your audio card can only output 16 or 24 bit audio streams. And you can't dither when going HIGHER, only lower. Well, technically you CAN dither wherever you like if your system supports it (Reason doesn't), but WHY add dither when INCREASING bit depth?

If Reason imports a 24 or 16 bit file/sample, it will pass it on through (padding it with zeros as I understand it) UNTIL you do SOMETHING. This "something" can be as simple as changing levels or summing two signals together. At this point that 16 or 24 bit file will use the extra resolution afforded by the 32 bit internal stream (increasing to a 64 bit stream at the mix bus) until it gets to your audio card, at which point it will output a 24 bit audio stream. Most audio cards will output 24 bit streams, and only down sample when exporting/bouncing (IF you choose to do so).

It is only at this final stage (exporting or bouncing to an external audio file on disk) where ANY decisions about bit depth can happen, other than choosing 16 bit or 24 bit (or 32 bit) audio files from your drive for import (if they exist in those formats).

One major difference to understand between 16/24 bit fixed point depths and 32/64 bit FLOATING point depths is that at 32/64 bit float you CAN have values above zero dBFS whereas with a fixed point system you CANNOT. In other words, a fixed point system can clip, a floating point virtually cannot. This is why it's imperative to reduce all signals that are above zero when exporting, but it's ok to allow them internally.

[Ostermilk]

One major difference to understand between 16/24 bit fixed point depths and 32/64 bit FLOATING point depths is that at 32/64 bit float you CAN have values above zero dBFS whereas with a fixed point system you CANNOT. In other words, a fixed point system can clip, a floating point virtually cannot. This is why it's imperative to reduce all signals that are above zero when exporting, but it's ok to allow them internally.

IIRC the clipping point is around +1500 dBFS for 32 bit floating point arithmetic, so if you can find out how to add more than that amount of gain to a track you could prove that it's 32 bit floating point arithmetic going on because it will have clipped...

[selig]

One major difference to understand between 16/24 bit fixed point depths and 32/64 bit FLOATING point depths is that at 32/64 bit float you CAN have values above zero dBFS whereas with a fixed point system you CANNOT. In other words, a fixed point system can clip, a floating point virtually cannot. This is why it's imperative to reduce all signals that are above zero when exporting, but it's ok to allow them internally.

IIRC the clipping point is around +1500 dBFS for 32 bit floating point arithmetic, so if you can find out how to add more than that amount of gain to a track you could prove that it's 32 bit floating point arithmetic going on because it will have clipped...

I certainly don't know this as fact but always assumed the clipping point was half way (or greater) across the available dynamic range, as the need for low level audio support was as great or greater than high level (above zero). If you only have 1500 dB theoretical dynamic range you can't put ALL of it above the clipping point - that would be "pointless"! (see what I did there?!?)

So that would put the "actual" clipping point at or around +750 dBFS (assuming 32 bit) and double that for the 64 bit mix bus. Either way, it's going to take a LOT of work to run out of headroom.

[mcatalao]

I could be wrong on that though do you have a definite scenario where this occurs, only I don't do much internal sampling with Reason itself (this might be one reason why ) so you may well be right.

If you push "sampling" button at the NNXT you can see recording sound parameters - 16 bit always.
But if using "bounce to disk" option your files might be 24 bit

Ah, I get it.

I always do my sampling for NN-XT, Kong, Redrum etc outside of Reason so I've never come across that yet.

There's something I'll have to try out for myself.

I'm sorry but i just tested that and checked the generated sample in the song samples and it is 24 bit... Unless i'm seeing it wrong?

[ljekio]

How you testng it?

[mcatalao]

I just routed a synth to the sample input, sequenced it, then sampled it into an nn-xt.

When i go to the song samples, and check for the properties of the file in the browser, it says "Sample|Stereo|24 bit|44.1 kHZ".

[ljekio]

Im confused.
You have Mac or Windows system on your machine?
I have Windows and 16 bit when sampling.

[mcatalao]

Windows.

[ljekio]

So why I cann't 24 bit?

Nothing ideas...

[mcatalao]

I don't get it too... I'm sampling a thor, routed it to Sample imput and hit the sample button...
From your post, you say you see the "recording sound parameters - 16 bit always."... Where do you see this?

[ljekio]

16bit.png (408.86 KiB) Viewed 1660 times

[mcatalao]

I get it.
if you edit you edit the file and then save it, it is saved as n 24 bit file.

Before you edit it, it is always at 16 bit

I need to do some more testing out but this is Really odd.

Can you confirm it?
Thank's.

[ljekio]

Yes, I talk about create new files. With editing 24 bit files is all right.

[mcatalao]

Me too. But what i found is that when you edit the 16 bit file, it gets converted to 24 bit.
I still don't get if this is a bug or if i'm missing something else.

According to the manual:
"Whenever you sample in Reason, the resulting audio files are stored in WAV format. The sample rate is determined by the settings on the Audio tab in Preferences (see “Audio settings”). The resolution (bit depth) is defined in the setup application for your specific audio hardware (consult the manual for your audio hardware for information). Actually, Reason is totally agnostic about what sample rate and resolution you use. If you like, you can change audio settings at any time without affecting the pitch, playback speed etc. of your samples. What you have once sampled will always sound the same, regardless of the current audio settings!"

Anyway, i did my tests with the internal audio card in my work laptop and a Microsoft Surface, oddly enough both with Realtek cards. I have to check this at the studio, as i would expect these to be completely 24 bit files there from the start, according to what the manual says...

[ljekio]

24 you can take with direct audio record to audio channel.
My audiocard supported 24 bit, but sampling feature still works only with 16 bit.
It's time to fix it, I think so

[Ostermilk]

One major difference to understand between 16/24 bit fixed point depths and 32/64 bit FLOATING point depths is that at 32/64 bit float you CAN have values above zero dBFS whereas with a fixed point system you CANNOT. In other words, a fixed point system can clip, a floating point virtually cannot. This is why it's imperative to reduce all signals that are above zero when exporting, but it's ok to allow them internally.

IIRC the clipping point is around +1500 dBFS for 32 bit floating point arithmetic, so if you can find out how to add more than that amount of gain to a track you could prove that it's 32 bit floating point arithmetic going on because it will have clipped...

I certainly don't know this as fact but always assumed the clipping point was half way (or greater) across the available dynamic range, as the need for low level audio support was as great or greater than high level (above zero). If you only have 1500 dB theoretical dynamic range you can't put ALL of it above the clipping point - that would be "pointless"! (see what I did there?!?)

So that would put the "actual" clipping point at or around +750 dBFS (assuming 32 bit) and double that for the 64 bit mix bus. Either way, it's going to take a LOT of work to run out of headroom.

Let's just say it's completely mind boggling the amount of headroom you have with 32 bit floating point arithmetic and if one manages to clip in the box they've managed something pretty spectacular...

Another thing I've found when using DAW's that have a 64 bit FP internal setting to choose from is that the only difference I find is the amount of CPU usage goes up (as expected) but I've never come across a project that sounded different (let alone better) by choosing it. So I reckon that the hybrid use of 32 bit FP through the chain and 64 bit FP arithmetic at the master bus at the point where greater precision is a benefit is a great idea.

[Ostermilk]

24 you can take with direct audio record to audio channel.
My audiocard supported 24 bit, but sampling feature still works only with 16 bit.
It's time to fix it, I think so

I agree it does seem like a bit of anamoly.

[ljekio]

Interesting addition: When sampling a new RV7k2 files are written to 24-bit, even with 16-bit audio interface

UPD: I can't reduplicate that success.
I send a request to support.