Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Ronny]

I mentioned why recording 24 bit converters to 32 bit float is desirable when there is further processing. It just adds 8 empty zeros and eliminates having to convert to 32 float for processing and mixing. The files will analyze actual 24 bit until a process is performed. It's the same thing as recording at 24 bit but the added 8 bits are done in real time on the recording input, it just saves time from converting to float after the recording.

There are also other reasons. Some DAW programs only record at 16 bit and 32 float, no 24 bit recording. Adobe Audtion is one, early Sequoia is also another one. In the case of recording multi-tracks via 24 bit converters, if you set the recording depth to 16 bits, you don't utilize the 8 extra bits that the 24 bit AD offers, so it's a no brainer to record with the full 24 bits and 8 empty bits added, even if no processing is needed, because the save will be at 24 bit instead of recorded at 16 bit and saved at 16 bit where it doesn't matter if you add bits to the signal, you are still stuck with the quality of the 16 bit word. IOW by recording to 32 float, you capture the entire 24 bit word, whereas recording at 16 bit you lose 8 bits that the ADC provides.

[Jon Hodgson]

If the output of the ADC was being recorded straight to disk, with no further processing, then 24bits would be te superior format to save it in, since you would get zero quality loss, using less disk space and better performance (the CPU time required to convert an integer sample to float is a tiny fraction of the time required to read those extra 8 bits from disk).

However in most cases the ADC output is being passed through the mixer before going to disk, where the user may choose to do all sorts of processing to it. At this point 32 bit float becomes the superior format from a quality point of view, though not disk space or performance.

[Patrik T]

Quote:

However in most cases the ADC output is being passed through the mixer before going to disk, where the user may choose to do all sorts of processing to it. At this point 32 bit float becomes the superior format from a quality point of view, though not disk space or performance.

Thanks for this Jon. I have a floating point host (Sonar) and a integer host (SAW). The only kind of processing Sonar can provide while tracking is a DC offset removal. This is, according to the software programmers, the only function that'll bring the 24 bit word into floats, and affect it during recording. This is the only time I see why I should choose 32 bits when tracking with Sonar.

Anyways - according to you Ronny, I should then bounce my previously recorded 24 bit files to 32 bit float files before I even start to mix my tracks with my floating point host. But the question is - will this effort really be noticeable. Does it really change the sonic quality of the outcome in a dramatic way?

The bottomline is; I'm very happy that I have not tracked to 32 bit float before, since I safely can transfer those basic 24 bit files to the SAW environment (by just copying them from a audio folder) without any kind of worries. If they were saved as 32 bit floats, I guess the low, low level truncation would affect every individual track since I had to alter them back to 24 bit PCM's.

Well, this all is interesting I've to say.

[Patrik T]

To you Dan:

Thanks for your inputs.

The reason I do not want my software to, sonically, intrude with what the AD is spitting out is that I use the LavryBlue when tracking. I basically just want that word and data to be put somewhere on my HD, neatly in a 24 bit file. What makes me sick is the thought of software that might alter this information upon recording. If the LavryBlue can code a sound that creates a "natural" DC offset (say some brass instrument) and the Blue really get this information right, I kind of dislike that the software would correct this correctness (by, for instance, the anti DC function) upon the moment of recording.

I just want the Blue's info to be transferred as cleanly as possible to the storage place, without the software doing a s**t with either the wordlength or the sonics.

If you get my drift...

[Jon Hodgson]

Patrik T wrote on Thu, 06 April 2006 13:24

Quote: However in most cases the ADC output is being passed through the mixer before going to disk, where the user may choose to do all sorts of processing to it. At this point 32 bit float becomes the superior format from a quality point of view, though not disk space or performance. Thanks for this Jon. I have a floating point host (Sonar) and a integer host (SAW). The only kind of processing Sonar can provide while tracking is a DC offset removal. This is, according to the software programmers, the only function that'll bring the 24 bit word into floats, and affect it during recording. This is the only time I see why I should choose 32 bits when tracking with Sonar.

if the dc offset removal is being done by a high pass filter (which it would probably have to be if it's a real time process, rather than a post process after recording the whole take), then you are right that 32 bits would make a difference.
However if it is a simple subtraction of the DC offset value from every sample, then I wouldn't worry about it.

Patrik T wrote on Thu, 06 April 2006 13:24

Anyways - according to you Ronny, I should then bounce my previously recorded 24 bit files to 32 bit float files before I even start to mix my tracks with my floating point host. But the question is - will this effort really be noticeable. Does it really change the sonic quality of the outcome in a dramatic way?

No, if your mix engine is float then those 24 bit integer values will be converted to float before they enter it. Assuming you then record the result at 32bits, you lose nothing.

Quote:

The bottomline is; I'm very happy that I have not tracked to 32 bit float before, since I safely can transfer those basic 24 bit files to the SAW environment (by just copying them from a audio folder) without any kind of worries. If they were saved as 32 bit floats, I guess the low, low level truncation would affect every individual track since I had to alter them back to 24 bit PCM's.

Not at all.
If you had not done any processing to them, then the two way conversion should be totally transparant, bits in = bits out. You would have lost nothing.

[Ronny]

Patrik T wrote on Thu, 06 April 2006 08:24

Anyways - according to you Ronny, I should then bounce my previously recorded 24 bit files to 32 bit float files before I even start to mix my tracks with my floating point host. But the question is - will this effort really be noticeable. Does it really change the sonic quality of the outcome in a dramatic way?

I doubt that there would be much of a sonic difference if you aren't taxing the system as per Jon's mention, it's more of a question of processor accuracy. DAW programmers and digital console designers often use 32 bit for the mix buss. I'm not real familiar with Sonar, but check and see if you have an option to select 32 bit mixing, some DAW progs allow 32 bit mixing without manually converting the files.

In the case of an all-in-one recorder/mixer like the Yamaha AW4416, it has a hard drive that records 16 tracks and an 02r console that fronts the drive, the mixing buss going to the recorder section from the 24 bit ADC's is 32 bit. The eq has the 56 bit accumulator, so if you were to use, say an internal compressor and an internal eq on a microphone input to the recorder, the compressor would process at 32 bit, the eq would process at 56 bit, return to 32 bit mix buss and than record at 24 bit. Complex eq curves dealing with lot's of frequencies and their individual band levels benefit by increased bit depths compared to compressors that just deal with dynamic levels. IOW, there is a lot of shifting of bit depths for different processors, where it's beneficial for one to be at more depth than another less complex process. Adding and taking away bits can happen quite often when your final mix is down to the two track master, much of it out of the users hands.  

[Patrik T]

Hi again Ronny.

Well, in Sonar there have not been any options for the mixing engine. I recall that it went 32 bit floating in version 3. I guess it was fixed integers before that. Version 5 provides 64 bit double precision, which can be choosed on or off, by anyways - the mixing engine will calculate in minimum 32 bit float.

And, what I've been told is that it does not matter if you record at 16 or 24 bits - the audio will in the moment of any alteration expand into the 32 bit rattlesnake. I've never considered it necessary to alter 24 bit data to 32float just because the mix engine was working in 32float, but I might have to reconsider its possible benefits. Or just say: "nah".


I am aware of that a eq can have one depth, a mixer fader another and so on. The quite outdated DSP-factory card by Yamaha had this kind of greater and narrower architecture in its DSP mixer, all in integers. The DSP-card was a pretty good concept for the money. Ah, nostalgia...


Well, anyway, thanks for your input! Well appreciated.

[C-J]

Patrik T wrote on Fri, 07 April 2006 22:04

Well, in Sonar there have not been any options for the mixing engine. I recall that it went 32 bit floating in version 3. I guess it was fixed integers before that. Version 5 provides 64 bit double precision, which can be choosed on or off, by anyways - the mixing engine will calculate in minimum 32 bit float.

The Yamaha AW4416 that was mentioned, uses 32-bit FIXED, on its internal buses (except for the EQ). The accumulation is "biased" by placing 3 bits at the top (MSB) end of the original word, and 5 bits at the low (LSB) end. I don't know about other Yammie boards, but I presume that they may use the same system?

C.J., Finland

[Patrik T]

Hey ho Ivo and everybody else.


Some days ago I bounced all my recorded (unprocessed) 24 bit PCM files in one project to 32 float - as suggested by Ronny. I just provided each and everyone with the "below-bits" before they went into processing (level, eq, routing, effects or what ever...).

Not only was there an improvement while mixing (small fader movements came across much better) - the most important thing was that the bounce or export of this project into a stereo file (PCM or float) now had ALL TO IT! I really did not find any of the old crazy dissapointment which relates to "uh, this mixdown sound strange compared to what I hear during mix".

I could throw the mixdown into any software playback host and it sounded identical to how it translated during playback in the mixing host program. Decaying sound within a mix were not cut away, but instead continued until they were...gone.

For anyone using a floting point host - try it. You might get surprised at what it actually does to your headroom, your separation and everything when it comes to the mixdown. To me it just sounds like I have found the solution for what has been boggling my mind for years.

It's so weird, but in my host (Sonar 5 with the 64 bit engine) it really makes quite a dramatic difference to the sonic integrity. People might chime in and say "no way, jos

[Jon Hodgson]

Patrik T wrote on Sat, 22 April 2006 13:48

Hey ho Ivo and everybody else. Some days ago I bounced all my recorded (unprocessed) 24 bit PCM files in one project to 32 float - as suggested by Ronny. I just provided each and everyone with the "below-bits" before they went into processing (level, eq, routing, effects or what ever...). Not only was there an improvement while mixing (small fader movements came across much better) - the most important thing was that the bounce or export of this project into a stereo file (PCM or float) now had ALL TO IT! I really did not find any of the old crazy dissapointment which relates to "uh, this mixdown sound strange compared to what I hear during mix". I could throw the mixdown into any software playback host and it sounded identical to how it translated during playback in the mixing host program. Decaying sound within a mix were not cut away, but instead continued until they were...gone. For anyone using a floting point host - try it. You might get surprised at what it actually does to your headroom, your separation and everything when it comes to the mixdown. To me it just sounds like I have found the solution for what has been boggling my mind for years. It's so weird, but in my host (Sonar 5 with the 64 bit engine) it really makes quite a dramatic difference to the sonic integrity. People might chime in and say "no way, jos Patrik T Hero Member Offline Posts: 833 Re: Advantage of 32 bit floating processing ? Hi Jon. Yes. That's why I was turning my back on this issue. I always had my recorded 24 bit PCM's "read" by Sonar into the mix process and have told myself "it will become float when I start to process it" so nevermind. But, I just tried this out and did a variety of different output versions (the audio is in 96 kHz in the project). 1. To 24 bit PCM with no dither. 2. To 24 bit PCM with 24 bit TPDF. 3. To 32 bit float. 4. To 32 bit float, later to separate software SRC, back to Sonar and dithered to 16 bits. And to my ears, none of my former worries about a mixdown is present in any of these versions. I know the technical aspects of it, but in this case I let my ears judge and they kind of say "identical to playback". That's what is most important to me. It all might have to do with Sonars "64 bit" processing. Cheers. Jon Hodgson Hero Member Offline Posts: 1854 Re: Advantage of 32 bit floating processing ? Patrik T wrote on Sat, 22 April 2006 14:15 Hi Jon. Yes. That's why I was turning my back on this issue. I always had my recorded 24 bit PCM's "read" by Sonar into the mix process and have told myself "it will become float when I start to process it" so nevermind. But, I just tried this out and did a variety of different output versions (the audio is in 96 kHz in the project). 1. To 24 bit PCM with no dither. 2. To 24 bit PCM with 24 bit TPDF. 3. To 32 bit float. 4. To 32 bit float, later to separate software SRC, back to Sonar and dithered to 16 bits. And to my ears, none of my former worries about a mixdown is present in any of these versions. I know the technical aspects of it, but in this case I let my ears judge and they kind of say "identical to playback". That's what is most important to me. It all might have to do with Sonars "64 bit" processing. Cheers. I would expect all those outputs to sound the same to be honest, with the possible exception of the 16 bit version. 24 bit int ad 32 bit float are effectively the same as a final delivery format (since the float will be converted before being passed to the DAC), and dithering to 24 bits is a waste of time since all you are doing is adding a miniscule amount of noise (+/- half a bit or so) to a system which is already considerably noisier... no effect worth mentioning. Actually I was wrong in my emphasis in my previous post, it's not the final format that matters (assuming 24bit int or above vs 32bit float or above) but rather any intermediate files could potentially affect the results (say you bounce to a track with low gain, then boost that track later, with floats your quality is the same as if you bounced at the correct level in the first place, with ints you have lost quality). Assuming all other factors remain identical, if you hear a difference between reading from a integer file (convert on load) and reading from a float file (converted from the same int file beforehand) then there are only 2 possibilities 1) The guy who programmed it made a very stupid mistake 2) The difference is all in your mind, the result of self suggestion, a hugely powerful force (a lot bigger than the effect of the lsb on a 24bit pcm word, that's for certain). There is no option 3, so if it isn't one of those two then you have to be wrong about your conversion to float not including any other processing, or some other variable must have changed unrelated to the file format. Patrik T Hero Member Offline Posts: 833 Re: Advantage of 32 bit floating processing ? Whatever Jon. Quote: 2) The difference is all in your mind, the result of self suggestion, a hugely powerful force (a lot bigger than the effect of the lsb on a 24bit pcm word, that's for certain). I have not suggested this to be of any worth until I tried it. I told myself it would be a plain waste of time and do absolutely nothing. I really resisted to take it seriously, just because it would not, scientifically, do anything. Until I tried it. Quote: 1) The guy who programmed it made a very stupid mistake Now, I don't think Ronny - who mentioned this issue in the first place here - use the same floating point host as I do. So, I guess the programmers of that one must have made the same mistake as my programmers. So they must be equally stupid then. Jon Hodgson Hero Member Offline Posts: 1854 Re: Advantage of 32 bit floating processing ? Patrik T wrote on Sat, 22 April 2006 18:27 Whatever Jon. Quote: 2) The difference is all in your mind, the result of self suggestion, a hugely powerful force (a lot bigger than the effect of the lsb on a 24bit pcm word, that's for certain). I have not suggested this to be of any worth until I tried it. I told myself it would be a plain waste of time and do absolutely nothing. I really resisted to take it seriously, just because it would not, scientifically, do anything. Until I tried it. What you told yourself conciously has nothing to do with it, the very fact that you performed the test shows that you thought it MIGHT make a difference, making you susceptible to self suggestion. Patrik T wrote on Sat, 22 April 2006 18:27 Quote: 1) The guy who programmed it made a very stupid mistake Now, I don't think Ronny - who mentioned this issue in the first place here - use the same floating point host as I do. So, I guess the programmers of that one must have made the same mistake as my programmers. So they must be equally stupid then. I don't disagree with you, it is unlikely, especially since you'd really have to go out of your way to be that stupid (the conversion is part of C, and indeed most other programming languages), but as I said, there are only two options as to why a conversion from int to float should appear to produce different result depending on when it is done. There are not two ways to do the conversion correctly with two possible results, only one, and as I said, the rest of the system is also deterministic, same thing in = same thing out, at least up until the point where it hits the DAC (where variables such as power supply quality, RFI interferece and circuit temperature come into play). Here's a test for you, capture the digital stream that is being sent to your DACs in both cases, put it to disk, and compare it by subtracting one from the other. I would not expect to see more than one (or two at the outside) bits of difference at any point (and that only if they're using pseudo random numbers for internal dithering). More than that is quite probably a bug. Oh, and if you do see a difference of one bit (due to the dithering I suggested) then I would expect to see the same magintude of difference between two repetitions of the same technique. Print Pages: 1 2 3 [4]   Go Up « previous next » R/E/P Community > R/E/P > R/E/P Archives > Dan Lavry > Advantage of 32 bit floating processing ?   SMF 2.0.19 | SMF © 2021, Simple Machines | Terms and Policies XHTML RSS WAP2 Site Hosted By Ashdown Technologies, Inc. Page created in 0.081 seconds with 21 queries.

[Patrik T]

Hi Jon.

Yes. That's why I was turning my back on this issue. I always had my recorded 24 bit PCM's "read" by Sonar into the mix process and have told myself "it will become float when I start to process it" so nevermind.

But, I just tried this out and did a variety of different output versions (the audio is in 96 kHz in the project).

1. To 24 bit PCM with no dither.
2. To 24 bit PCM with 24 bit TPDF.
3. To 32 bit float.
4. To 32 bit float, later to separate software SRC, back to Sonar and dithered to 16 bits.

And to my ears, none of my former worries about a mixdown is present in any of these versions. I know the technical aspects of it, but in this case I let my ears judge and they kind of say "identical to playback". That's what is most important to me.

It all might have to do with Sonars "64 bit" processing.

Cheers.

[Jon Hodgson]

Patrik T wrote on Sat, 22 April 2006 14:15

Hi Jon. Yes. That's why I was turning my back on this issue. I always had my recorded 24 bit PCM's "read" by Sonar into the mix process and have told myself "it will become float when I start to process it" so nevermind. But, I just tried this out and did a variety of different output versions (the audio is in 96 kHz in the project). 1. To 24 bit PCM with no dither. 2. To 24 bit PCM with 24 bit TPDF. 3. To 32 bit float. 4. To 32 bit float, later to separate software SRC, back to Sonar and dithered to 16 bits. And to my ears, none of my former worries about a mixdown is present in any of these versions. I know the technical aspects of it, but in this case I let my ears judge and they kind of say "identical to playback". That's what is most important to me. It all might have to do with Sonars "64 bit" processing. Cheers.

I would expect all those outputs to sound the same to be honest, with the possible exception of the 16 bit version. 24 bit int ad 32 bit float are effectively the same as a final delivery format (since the float will be converted before being passed to the DAC), and dithering to 24 bits is a waste of time since all you are doing is adding a miniscule amount of noise (+/- half a bit or so) to a system which is already considerably noisier... no effect worth mentioning.

Actually I was wrong in my emphasis in my previous post, it's not the final format that matters (assuming 24bit int or above vs 32bit float or above) but rather any intermediate files could potentially affect the results (say you bounce to a track with low gain, then boost that track later, with floats your quality is the same as if you bounced at the correct level in the first place, with ints you have lost quality).

Assuming all other factors remain identical, if you hear a difference between reading from a integer file (convert on load) and reading from a float file (converted from the same int file beforehand) then there are only 2 possibilities

1) The guy who programmed it made a very stupid mistake
2) The difference is all in your mind, the result of self suggestion, a hugely powerful force (a lot bigger than the effect of the lsb on a 24bit pcm word, that's for certain).

There is no option 3, so if it isn't one of those two then you have to be wrong about your conversion to float not including any other processing, or some other variable must have changed unrelated to the file format.

[Patrik T]

Whatever Jon.

Quote:

2) The difference is all in your mind, the result of self suggestion, a hugely powerful force (a lot bigger than the effect of the lsb on a 24bit pcm word, that's for certain).

I have not suggested this to be of any worth until I tried it. I told myself it would be a plain waste of time and do absolutely nothing. I really resisted to take it seriously, just because it would not, scientifically, do anything.

Until I tried it.

Quote:

1) The guy who programmed it made a very stupid mistake

Now, I don't think Ronny - who mentioned this issue in the first place here - use the same floating point host as I do. So, I guess the programmers of that one must have made the same mistake as my programmers. So they must be equally stupid then.

[Jon Hodgson]

Patrik T wrote on Sat, 22 April 2006 18:27

Whatever Jon. Quote: 2) The difference is all in your mind, the result of self suggestion, a hugely powerful force (a lot bigger than the effect of the lsb on a 24bit pcm word, that's for certain). I have not suggested this to be of any worth until I tried it. I told myself it would be a plain waste of time and do absolutely nothing. I really resisted to take it seriously, just because it would not, scientifically, do anything. Until I tried it.

What you told yourself conciously has nothing to do with it, the very fact that you performed the test shows that you thought it MIGHT make a difference, making you susceptible to self suggestion.

Patrik T wrote on Sat, 22 April 2006 18:27

Quote: 1) The guy who programmed it made a very stupid mistake Now, I don't think Ronny - who mentioned this issue in the first place here - use the same floating point host as I do. So, I guess the programmers of that one must have made the same mistake as my programmers. So they must be equally stupid then.

I don't disagree with you, it is unlikely, especially since you'd really have to go out of your way to be that stupid (the conversion is part of C, and indeed most other programming languages), but as I said, there are only two options as to why a conversion from int to float should appear to produce different result depending on when it is done.

There are not two ways to do the conversion correctly with two possible results, only one, and as I said, the rest of the system is also deterministic, same thing in = same thing out, at least up until the point where it hits the DAC (where variables such as power supply quality, RFI interferece and circuit temperature come into play).

Here's a test for you, capture the digital stream that is being sent to your DACs in both cases, put it to disk, and compare it by subtracting one from the other.
I would not expect to see more than one (or two at the outside) bits of difference at any point (and that only if they're using pseudo random numbers for internal dithering). More than that is quite probably a bug.

Oh, and if you do see a difference of one bit (due to the dithering I suggested) then I would expect to see the same magintude of difference between two repetitions of the same technique.