Question about 32bit or 64bit floating point.

Whats the difference?

I have tech question about 32bit or 64bit floating point mix down.

Taken from the contents in n-Track.

“The format of the input or output (16 or 24 bit) has no influence on the precision with which the program does its internal signal processing calculations. The program always uses 32 bit (or 64 bits if the option is selected) floating point signals for optimum sound quality and dynamic range.”

-------
Is their a difference in sound quality if I mix down in 64bit floating point instead of 32bit floating point? Is one better than the other?

PACO

A darn good question - I sure don’t know. Now that you have brought it up, does the 64 bit float point put a neavier demand on the computer processing, or is it a memory thing.
Basically, what are the advantages and disadvantages?
Bax

Don’t know if it’s relevant but this guy seems to be in favour of 32bit float.

http://stackoverflow.com/questio…ormance

Okay, Tony. I read it three times and I am still not sure of the guys conclusion. Did he say 64 bit float Might better because it could work with more information/a longer number stream?

Uuurrrm!? Yeah. That seems to be the drift. I’m waiting for a couple of wizards to get back to me on this one. I’m useless, but interested:-)

Due to limitations of which I’m not sure of, the maximum I can do is 24bit@96000hz. Anything rendered beyond this won’t burn to disk or convert to MP3. I know that 32bit floating and 64 bit floating virtually eliminated floor noise, (I saw a video on it). I did test my MP3’s 24bit vs/ 16 bit @ 96000hz and I could tell a difference so that’s a plus. I guess you could say your MP3’s are only as good as it’s source.

This begs many questions.
What’s the point of rendering at 32 or 64 bit floating if I can’t do a conversion? Do I need an interface that supports 32 or 64 floating point? Because, my Toneport UX2 doesn’t. Then there’s the dithering factor as well to 16 bit for CD compatibility. At least I’m able to render to the proper dithering value first while still being able to keep a 24bit@96000hz rendered output. WOW this is a big can of worms to which I have no idea but regardless, it smells expensive if I want to go higher.

PACO

On the download page for n_Track 64 bit Flavio states that there is no 32 or 64 bit interface available.
What I am now writing may sound like statements, but I welcome anyone who finds error in my statements because most of this stuff is based on something I was told or read somewhere, and I am not a scientist. Just a guy who like to play, sing, and record music.
So anyhow
I kind of doubt that there is much need for a 64 bit sound card. Most people can’t see the difference in 720 and 1080HD, and I doubt that many can hear the difference in 64 bit sound (maybe?) The idea of recording at a higher bit rate is the head room - much harder to get digital clips, and 96000hz, more information in each sample, a finer “texture” to the sound so that the string bass and the violin can both be heard clearly. I wondering if that is the advantage of 64 bit float IF is has anything to do with it at all . . .
So, where are you tech guys? Fill us in? What can you tell us Flavio?
Bax

From a friend.

“Because the 64bit floating point number itself will have both: a larger Mantissa and a larger exponent, it will offer both a greater range and greater accuracy (rather than using as many following zeros, which loses accuracy the further you move the radix point). So I wonder whether the software can actually make any use of this or whether the extra range is redundant?”

Mixing down to a float (32 or 64 bit) format is only useful when you want to reimport the mixdown file for further processing, with n-Track or a 3rd party app. Even though the final quality of the recording will be 16 bit/44100 (CD) or at most 24 bit / 192 khz (when sending the output to an audio device) using an higher quality (i.e. 32 or 64 bit) intermediate format guarantees the optimal quality of the final file.
n-Track can work with 32 or 64 bit internal precision, as set in the Settings -> 64 bit mixing menu.
Mixing down in 64 bit format when the internal precision is set to 32 bits makes little sense (may only be useful if you need to use the file with something that requires a 64 bit format).
When the internal precision is set to 64 bits, a 64 bit mixdown has the very same information/quality that runs inside n-Track, while mixing down to 32 bits when the internal format is 64 bits very slightly degrades quality. That said the practical difference between 32 and 64 bit float is not noticeable by most human hears.

Flavio.

So I was thinking how can I make use of 64bit floating point. Well here’s what I did.
I rendered a song at 64bit floating point at 96000hz (Creates a pretty big wave file). Then I restarted n-track and inserted the file on a track, then I rendered it to 24@96000hz, which is the the highest I can go if I want to convert to MP3 or burn to disk.

So the two files I compared were the one file created at 24bit@96000hz no floating point directly out of n-track (all my songs are currently rendered this way but not for long) and compared it to the one I rendered down from the 64bit floating point file. Both files are the same size and are 24bit@96000hz.

The floating point rendered file sounds better to me. So that’s what I’m going to do. Master it out to 64bit floating point @ 96000hz file, re insert it and render it down to 24bit@96000hz instead of just rendering it to 24Bit@96000hz without any floating point stuff.

Point of interest, I noticed during the testing a distinct difference in one section of a song where I can hear the toms clearly. I noticed the non floating point rendered file sounds almost grainy for lack of a better term and the floating point rendered version sounded more consistent clean and full. Although the difference is only slight I could after listening to it over and over again hear that indeed there is a difference yet it be so humble. With that said, I’ll take it!

I’ll update all MP3’s today. Edit, all MP3 files are updated, Soundclick and Dropbox

Oh ya, I just wanted to mention a video I saw on floating point yesterday. In this video he shows the noise non floating point files make. This is the same type of noise, buried as it was, I heard in my non floating point file. Here’s a link to it.

http://www.youtube.com/watch?v=92CJdNJen9E


Hope this helps,

PACO

Quote: (Paco572 @ May 11 2012, 9:32 AM)

Master it out to 64bit floating point @ 96000hz file, re insert it and render it down to 24bit@96000hz instead of just rendering it to 24Bit@96000hz without any floating point stuff.

This will give you identical results. Don't believe me... do a null test. I would almost bet an MD5 or SHA hash would be identical assuming no sample rate conversion.

Also, to some of the above confusion, there will never be a floating point sound card. There is no point. Floating point is simply a way to represent really big and really small numbers efficiently at the cost of absolute accuracy due to the limitation of the mantissa.

The main reason floating point internal math is used for DAWs is that it is efficient and eliminates concerns of clipping in the internal mix bus due to the giagantic dynamic range (>700db at 32 bit FP). You will ALWAYS
have to go to a fixed bit format for play back. So while you may THINK you are getting this extra quality, the DAC must truncate to a fixed point value (24 or 16 bit or less) for play back no matter what. That said, there is almost no use for dither when rendering from a floating point stream to 24 bit fixed.
Quote: (Bubbagump @ May 11 2012, 2:29 PM)

Quote: (Paco572 @ May 11 2012, 9:32 AM)

Master it out to 64bit floating point @ 96000hz file, re insert it and render it down to 24bit@96000hz instead of just rendering it to 24Bit@96000hz without any floating point stuff.

This will give you identical results. Don't believe me... do a null test. I would almost bet an MD5 or SHA hash would be identical assuming no sample rate conversion.

Also, to some of the above confusion, there will never be a floating point sound card. There is no point. Floating point is simply a way to represent really big and really small numbers efficiently at the cost of absolute accuracy due to the limitation of the mantissa.

The main reason floating point internal math is used for DAWs is that it is efficient and eliminates concerns of clipping in the internal mix bus due to the giagantic dynamic range (>700db at 32 bit FP). You will ALWAYS have to go to a fixed bit format for play back. So while you may THINK you are getting this extra quality, the DAC must truncate to a fixed point value (24 or 16 bit or less) for play back no matter what. That said, there is almost no use for dither when rendering from a floating point stream to 24 bit fixed.

That's a very detailed explanation and very informative. If it is identical then why is it I can hear a difference? Please explain it, since you have a such a good grasp and technical know how on the subject. Did you check out the video link? The noise I heard on the video was similar to that in my rendered file and I can't hear it anymore. It's undeniable.

Between the floating point, the MD5, the SHA, the really big and really small numbers, internal mix bus, mantissa, fixed bit format, gigantic dynamic range, sample rate conversion, DAC, floating point stream, truncate, dither, internal math or what kind of Bar-B-Q sauce to put on my steak, the whole idea is nothing more than mass confusion. Although your very detailed explanation sheds light on the subject it goes well beyond my experience or my absence of being a certified sound engineer to which I'm not. In some ways I'm a bit insulted, somewhat, your explanation is better understood by a qualified sound engineer and you know that I'm not, but on the other hand, I'm thankful you took the time to explain it. One thing is for certain, I will find a sample rate for my Bar-B-Q sauce and I will trust my ears and anybody reading this post should too.

Thanks again for taking the time to explain it.

PACO
Quote: (Paco572 @ May 11 2012, 4:08 PM)


That's a very detailed explanation and very informative. If it is identical then why is it I can hear a difference? Please explain it, since you have a such a good grasp and technical know how on the subject. Did you check out the video link? The noise I heard on the video was similar to that in my rendered file and I can't hear it anymore. It's undeniable.

Between the floating point, the MD5, the SHA, the really big and really small numbers, internal mix bus, mantissa, fixed bit format, gigantic dynamic range, sample rate conversion, DAC, floating point stream, truncate, dither, internal math or what kind of Bar-B-Q sauce to put on my steak, the whole idea is nothing more than mass confusion. Although your very detailed explanation sheds light on the subject it goes well beyond my experience or my absence of being a certified sound engineer to which I'm not. In some ways I'm a bit insulted, somewhat, your explanation is better understood by a qualified sound engineer and you know that I'm not, but on the other hand, I'm thankful you took the time to explain it. One thing is for certain, I will find a sample rate for my Bar-B-Q sauce and I will trust my ears and anybody reading this post should too.

Thanks again for taking the time to explain it.

PACO

Do a null test. If it nulls... you only THINK you can hear a difference. If it doesn't null, then you are on to something.
Quote: (Bubbagump @ May 14 2012, 12:16 PM)

Quote: (Paco572 @ May 11 2012, 4:08 PM)


That's a very detailed explanation and very informative. If it is identical then why is it I can hear a difference? Please explain it, since you have a such a good grasp and technical know how on the subject. Did you check out the video link? The noise I heard on the video was similar to that in my rendered file and I can't hear it anymore. It's undeniable.

Between the floating point, the MD5, the SHA, the really big and really small numbers, internal mix bus, mantissa, fixed bit format, gigantic dynamic range, sample rate conversion, DAC, floating point stream, truncate, dither, internal math or what kind of Bar-B-Q sauce to put on my steak, the whole idea is nothing more than mass confusion. Although your very detailed explanation sheds light on the subject it goes well beyond my experience or my absence of being a certified sound engineer to which I'm not. In some ways I'm a bit insulted, somewhat, your explanation is better understood by a qualified sound engineer and you know that I'm not, but on the other hand, I'm thankful you took the time to explain it. One thing is for certain, I will find a sample rate for my Bar-B-Q sauce and I will trust my ears and anybody reading this post should too.

Thanks again for taking the time to explain it.

PACO

Do a null test. If it nulls... you only THINK you can hear a difference. If it doesn't null, then you are on to something.

Well I had to figure out what a null test was but that wasn't too hard to do. Here are my results of the null test. I am correct, and just to show just how good my ear is here's a screen shot to prove it. Truly, if both files were identical as you suggest then the null test would be negative, meaning they are identical, there would be no difference between the two of them. In the video he shows that there is a difference and at first he couldn't hear it, same thing happened to me, but then he opened up a spectrum graph and sure enough it was there in the corner. Same thing here. It's also visible on the Master meters as well. Here's the screen shot.

The 2 files used.
1. Rendered directly out of n-Track 24bit@96000hz
2. Rendered out of n-Track 64bit@96000hz, re-inserted into n-Track rendered to 24bit@96000hz



Uploaded with ImageShack.us

PACO

Did you dither anywhere along the line or change sample rate (either up or down)? It should be identical… but that assumes all other things being equal. So something is changing things somewhere, especially with remaining noise around -60 dbFS. I am not doubting what you hear, just stating how the math should work. YOu may want to use something like SPAN for measurement too as there may be purposeful distortion added to the N compressor, aka, make sure what you are using for metering is not also adding something.

Quote: (Bubbagump @ May 15 2012, 11:32 AM)

Did you dither anywhere along the line or change sample rate (either up or down)? It should be identical... but that assumes all other things being equal. So something is changing things somewhere, especially with remaining noise around -60 dbFS. I am not doubting what you hear, just stating how the math should work. YOu may want to use something like SPAN for measurement too as there may be purposeful distortion added to the N compressor, aka, make sure what you are using for metering is not also adding something.

Sample rates remained the same, didn't add or remove anything, just mixed the two down fresh for the test. The only difference is one file was rendered with 64bit floating point. No vst's, effects ect ect..Just to add, I did remaster my whole album this way and after reviewing all the songs I did notice improvements to varying degrees in certain parts. Some nuances seemed better than before. I'm glad I found this little gem because any improvement even as slight as this might be is still an improvement nonetheless.

Thank you for your comments.


PACO

What happens in Reaper? Really, what you did shouldn’t make a difference… so I am curious where the break down is.

Quote: (Bubbagump @ May 17 2012, 2:00 PM)

What happens in Reaper? Really, what you did shouldn't make a difference... so I am curious where the break down is.

The link to the video test is in this thread and that test was done in Reaper. I had the same results in n-Track as the video had in Reaper. Although your considering this as a breakdown or fault because the math doesn't add up and you have good reason to suspect it, given your expertise in this area, I find it difficult to agree with you since I felt even before I did the test myself that my sound was better, although only slightly. In addition, further scrutiny of my own music also convinced me, this was indeed an improvement, fault or no fault.

That being said, this subject for me is now moot. Given the testing, the intense scrutiny and all the information provided, my ear told me it was better, the testing proved this so I'm certainly convinced this was an improvement, so it would be very very difficult to convince me otherwise. I think you'd have to drive a truck load of money up to my house to get me to change my mind.

Thank you again for your comments.

PACO

The video agrees with me completely. The only difference in your case is that you are truncating to 24 bit in a separate step. A 64 bit FP file should be identical to the 64 bit FP stream in the mix bus. You pulling it back in and rendering again to 24 bit should be no different than truncating the 64 FP stream in a render (setting the mix down format to 24 bit essentially). Again, I don’t doubt your ears, I am wondering why there is a difference as there absolutely should not be.
Both processes going to 24 bit should sound the same assuming everything else is equal. So let me do this with a mix in Reaper and see if it nulls. I expect it will.

NOTE: and maybe this is where you are missing my point as you seem defensive… the 24 bit output using either method should be identical. I am not saying 64bit FP and 24 bit FP will be identical.