Difference between 32-bit fixed integer and 32-bit floating point

I had some recordings in 24-bit, 48000 sample rate, but now have the setup using 44100 to save CPU load. When I played them back in the media player, those were all distorted unless I changed my audio card back to 48000.

While sleuthing that out, as I knew that wasn’t supposed to be the case, I enabled Double Precision (64-bit) Audio processing. I also set Sample Rate Conversion Quality to “High”. The problem with re-sampling went away.

While I was in there, in the Recording options I changed my bit depth from 24 to 32-bit floating point, as I was used to that from my DAWs. I know it helps prevent overloading the recordings, so that’s a good thing.

However, I noticed that 32-bit integer format was also offered, and wondered what the difference between the two are, and when you would use one over the other?

Also, wondered if there is any benefit to using 64-bit floating point, other than to make it impossible to overload ever again no matter what I throw at this thing?

(I know, I know… but 11 isn’t loud enough anymore now that I’m getting older!) :smile:

Terry

Hi Terry,

What kind of media file? wave, mp3, flac? Let me know and I’ll check it out. Also, when you say distorted - do you just mean the pitch is wrong - or is it actually distorted/glitching/etc… Perhaps if you email be small section of one of your files I’ll see if I can repro it.

Hrm… weird, not sure why that would affect that.

Any floating point format will help prevent overloading - so long as it’s scaled down again before being sent to the sound card.

32-bit integer is offered because not all other audio software supports 32-bit float. It’s just about providing more compatibility with other software. Float is better for large dynamic ranges, integer is probably more precise if you don’t clip.

To explain float vs integer a little more, an integer number represents a non-fractional number between two unmovable ranges.

eg: 16-bit integers range from about -32768 to 32767.

Floating point numbers are defined as a sign (positive/negative), a fractional part (somewhere between 0 and 1) and an exponent part. Think of this as a certain number of significant digits with a second number that controls where the decimal point goes.

eg: 0.0000000000000012345678 or 1234.5678 or 123456780000000000000000.0 are all within range of a typical floating point number but notice the loss of precision at each end.

For audio the integer range defines the limits of the dynamic range - the maximum amplitude of the signal. If you exceed the range the numbers will either clip or wrap around and your signal will be fairly messed up. eg: apply a 2x gain to 16-bit value of value of 30,000 and you’ll get either 32767 (clipped) or it might wrap around to a negative number.

For this reason most audio applications don’t do integer math - rather they use floating point and convert to integer only when sending to the sound card - and then they typically clip rather than wrap.

For floating point audio the signal as defined as -1.0 to 1.0, but since floating point numbers can go much larger this is where the additional head room comes from - but if you go too far you’ll lose precision in the fractional part of the number.

64-bit float is not really about providing more head room - it’s more about providing better precision - or in math terms more significant digits. Generally it’s not required (especially for live work) but can be useful if you have long effect chains where the signal is being processed many times over - the extra precision can help with accumulated rounding errors.

Make sense?

Yes, that all makes perfect sense. Thank you!

The recordings in question were done using Cantabile. It was a continuous clipping-style distortion with stuttering. I changed my sound card’s buffer upwards but it changed nothing. Only messing around in the audio options cured it.

They play fine in WMP and VLC. If you want I’ll email you a file or two (they are short).

Terry

Yes, please do and include details on which audio settings cause problems.

Brad,

I will attempt to reproduce the problem first. For all we know, my changing settings only forced a clean and uncorrupted ini file somewhere to be generated. I’ll let you know if I can return settings to a point where the distortion returns.

Terry

Hi @brad ,

I know I know… Sorry to resurrect a very old thread but I have just encountered this issue (like really nasty aliasing distortion) and don’t see any reference to a resolution here.

As @terrybritton mentioned I have my sample rate in Cantabile set as 44.1k to keep resources under control as much as possible, and “Double Precision” set as off (so default setting after installation - not that I’m sure what this actually does). Most of my backing tracks are 44.1/16bit so haven’t experienced this until today when I just loaded a new mix of something which happens to be 48k/24Bit (my preference for rendering before mastering).

Here is a short edit of just the intro of the original 48k/24bit file (I hope Dropbox is ok here)

Here is the recording of how it sounds when left at the default settings described above (recorded in Cantabile). Nasty aliasing/distortion!

Here is the same playback with Audio Engine in Cantabile set to 48k (playback as expected)

Here is the same playback but with Audio Engine back at 44.1 BUT with “Double Precision” option ticked (playback as expected)

Now As I want to leave the Cantabile sample rate as 44.1kHz I guess I can leave Double Precision ticked but as I don’t know what it does I’m not sure if I’ll be getting a heavy hit on resources somewhere else.

So I have a work around (either of the options above; set sample rate as 48k which also is fine for 44.1k source media, or select Double Precision) but would be good to;
a) understand if this is a resolvable issue
b) understand what impact Double Precision being ticked as default may have on resources etc

Again, sorry for the resurrection but thought it better to continue the thread where this was raised - happy to start a new thread if preferred.