Print

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

[Jon Hodgson]

TotalSonic wrote on Sun, 26 March 2006 00:02

Patrik T wrote on Tue, 07 March 2006 18:37 TotalSonic wrote on Tue, 07 March 2006 15:32 In the case of Bob Lentini's SAWStudio: yes, I can confirm via many internet conversations with Bob that it currently uses 64bit integer math for all multiples and divides (except for the built in eq's which use 64bit floating point math) which return an undithered full 32bit DWORD (instead of the 24bit + 8bit mantissa of a 32bit IEEE file) and pass this on to the next process in line - until final output, where the end user has the option of either truncating or dithering to 24bit. Steve, just a rapid question - Do you dither the output (post fader) with 24 bit dither when mixing in SAW (in the case of recording and exporting audio at 24 bits)? Hi Patrik - I simply haven't been able to hear any difference between just truncating the 32bit integer sum to 24bit output against dithering at the 24th bit when bouncing to disc in SAWStudio to 24bit - as any distortion that is possibly happening from requantizing from 32bit to 24bit is far below the noise floor - so I currently don't add dither to my 24bit in-the-box mixes.   When going to 16bit I always add dither though - as truncation is very easy to hear when going to that level. Best regards, Steve Berson

This makes sense. Dither is a way to decorrelate the error from the signal - if the error is correlated to the signal then it is distortion, is it is not then it is just noise, far less objectionable and noticable.

If the noise in the signal is already higher than a single quantization step (as it is at 24 bits), then the error will have no correlation, you're fine, d injecting more noise won't help. If it isn't (as is usually the case at 16 bits), then you have to inject noise

[Patrik T]

TotalSonic wrote on Sun, 26 March 2006 00:02

Hi Patrik - I simply haven't been able to hear any difference between just truncating the 32bit integer sum to 24bit output against dithering at the 24th bit when bouncing to disc in SAWStudio to 24bit - as any distortion that is possibly happening from requantizing from 32bit to 24bit is far below the noise floor - so I currently don't add dither to my 24bit in-the-box mixes.   When going to 16bit I always add dither though - as truncation is very easy to hear when going to that level. Best regards, Steve Berson

Thanks Steve! I'm still trying to sort out what is the best to do in SAW's integer environment. I come from a floting point host environment and, well, SAW behaves differently.

For the 16 bit dither - yes, naturally the truncation makes things overly digital and is a must. I've found that the Sonoris dither is simply amazing with the noiseshape #2. I am just stunned by what it does and what it does not do. Almost like a pow-r on steroids!


(BTW - Amazing music, the invert-thing.)

[Izhaki]

Ivo wrote on Wed, 25 January 2006 15:54

Thanks friends for all the replies. But to say the truth, now I am even less sure than before: Shall I set Samplitude to 24 bit or 32 bit floating ? What would be better for a practical recording and editing ?

Ivo,

Both 24Bit Integer and 32Bit Float will give you an effective word-length of 24bits. With this in mind, your settings in Samplitude only determine how files are stored on your hard drive NOT how they are processed or edited.

There is an issue here however, but I don't know how Samplitude implements its signal path. My guess is that like any other application (PT LE, Logic, Cubase) it uses float representation and arithmetic. This means that if you choose 24bit Integer, the application will have to convert from float to integer before writing to disk and vice versa when reading from disk. Such a conversion is additional process that could cause distortion, but it doesn't as all 24bit Integers can be converted to 32bit float and back to integer without an error. A simple C++ application can prove this very easily.

The only advantage of choosing 32bit float is that your application doesn't have to do integer/float conversions which saves some (meaningless) amount of processing power.

The one advantage that you get by choosing 24bit float Integer is that only 24bits are stored, as oppose to 32bit float where all 32bits have to be stored (so 24bit Integer files are 75% smaller than 32Bit Float ones). Also, some applications still cannot read 32bit float files.

I hope this helps.

[cerberus]

Izhaki wrote on Sat, 01 April 2006 09:52

The one advantage that you get by choosing 24bit float Integer is that only 24bits are stored, as oppose to 32bit float where all 32bits have to be stored (so 24bit Integer files are 75% smaller than 32Bit Float ones). Also, some applications still cannot read 32bit float files..

advantage?!?

jeff dinces

[Patrik T]

Izhaki wrote on Sat, 01 April 2006 15:52

This means that if you choose 24bit Integer, the application will have to convert from float to integer before writing to disk and vice versa when reading from disk. I hope this helps.

Wait a few seconds there...

If I choose 24 bit integer and the A/D is set to 24 bits, the host (samplitude, whatever) is supposed to just put the 24 bit word output from the A/D and place this in a file on the HD.

What good would it make to mock things up by taking the 24 bit integer A/D word, pad zeroes to it, then remove the zeroes and then put the data on the HD as a PCM integer file (when the recording depth is set to 24 bits)?

As to reading the disk - if the faders within the host are at unity gain and there is no real time processing, shouldn't the host then just play a 24 bit integer file with nothing done in the float area? Shouldn't it just pass this data straight to the D/A-converter as a 24 bit word?

As long as there is no processing of any kind, there should not be any kind of integer->float conversion.

I would NEVER choose the 32 float as a RECORDING depth as long as my A/D is spitting out a 24 bit integer word. This because the integer PCM is more bullet-proof in my opinion.

[Izhaki]

Maybe I should clarify a few points here:

Cerberus: As mentioned before, 24Bit Integer and 32Bit float has the same effective wordlength: 24 bits. In other words they have the identical digital quality. Hence when having two files of the same quality, it is an advantage if one is 75% in size.

Then, when a conversion is done from 24bit Integer to 32bit float, no zeros are added - only the representation changes and float requires 8 additional bits. Read about floating-point representation for more information (there is actually a good link on this thread).

Whether you want it or not your application will use float, even if all your faders are on 0dB. This is simply due to the way these applications are coded, their internal architecture and their real-time requirements which require a float signal flow. It is very likely that even a fader set on 0dB will multiply each sample value by 1; this is because a float multiplication is quicker than the condition involved in such scenario. In other words - faders don't put themselves on bypass if they are on 0dB.

It might not make sense to convert a 24Bit Integer data (from the ADC) into float and then back to 24Bit Integer in order to save it to disk. But with not relation to what the ADC 'shoots', for both ASIO and CoreAudio sound interfaces if such conversion takes place it is done IN THE DRIVER. Applications such as Logic and Cubase receive from the 'sound card' float numbers. Applications that use Windows Drivers receive them in Integers.

32Bit float representation let the application process all types of bit resolution (up to 24Bit) UNIFORMLY with no relation to the original file/ADC resolution. As someone who wrote audio code using Integers, believe me that it is light-years easier and more efficient (in terms of code) to use the 32Bit float system.

[Ronny]

cerberus wrote on Sat, 01 April 2006 19:38

Izhaki wrote on Sat, 01 April 2006 09:52 The one advantage that you get by choosing 24bit float Integer is that only 24bits are stored, as oppose to 32bit float where all 32bits have to be stored (so 24bit Integer files are 75% smaller than 32Bit Float ones). Also, some applications still cannot read 32bit float files.. advantage?!? jeff dinces

Size difference is a minor issue for me. I don't do much multi-tracking in DAW progs, but talking 2 track editing or prep-mastering. What I do is record via 24 bit A/D's to 32 float, it pad 8 zeros on in real time during the recording. This allows me to work at 32 native once the recording is done, which allows better analysis and processing, IMHO, due to the fact that you can read decibels over -0dBFs and have more bits to work with. If I'm not through for the day, I save the files in 32 float, work on them the next day, finish, save the final files at 24 bit fixed integer, archive them to stand alone hard drives, than I downsample if needed, dither and convert to 16 bit for the audio cd. The only time that file size is an issue is after the material is finished, the 32 bit files get deleted after I'm done so it's doesn't take up any more space than if I would have recorded at 24 bit and than converted to 32 float for processing and than saved at 24 bit after the final.

Regarding the comment that 24 bit fixed int. is better than 32 float, my ears hear no difference and neither is any more or less stable than the other from my experience. 32 bit allows processing over -0dBFS as long as you attenuate to -0dBFs or below on the output to the DAC and gives more footroom to process, in this regard audible differences are negligible but processing benefits by the floating point. There are arguments about 24 bit being better than 32 float as you can use double precision and process at 48 bit, but again, my ears can't hear any difference.  

[cerberus]

Izhaki wrote on Mon, 03 April 2006 22:16

Maybe I should clarify a few points here: Cerberus: As mentioned before, 24Bit Integer and 32Bit float has the same effective wordlength: 24 bits. In other words they have the identical digital quality. Hence when having two files of the same quality, it is an advantage if one is 75% in size.

if they contain identical data then they are identical quality; otherwise not. a 32 bit float file can contain samples with more information than will fit into a 24 bit file, i would not throw away anything important.

i think you and i see the world very differently... i see a lot of chatter about how great analog sounds compared to "in the box".. and no wonder.. a lot of itb engineers are more concerned with disk space than sound quality.

now let's talk about doubling the sample rate... does that hurt?  you bet it does.  but it hurts real good (imo).

Ronny wrote on Tue, 04 April 2006 04:14

I save the files in 32 float, work on them the next day, finish, save the final files at 24 bit fixed integer, archive them to stand alone hard drives, than I downsample if needed, dither and convert to 16 bit for the audio cd.

this is where i am at with mastering as well (it seems like izhaki is speaking of mixing, if not then i misunderstood him) ; because the final master will be 16 bits, i am assuming it is safe at this point to drop information in the 32->24 that is far below the level that will make it to the final cd.  however some respected engineers are now recommending a dither for this process as well.  i also think we should consider future delivery formats that will be better than 16 bits. in that case it might be better to have a strategy for a good sounding 24 bit master that is dithered, not truncated to 24 bits.  

jeff dinces

[danlavry]

cerberus wrote on Tue, 04 April 2006 10:53

Izhaki wrote on Mon, 03 April 2006 22:16 Maybe I should clarify a few points here: Cerberus: As mentioned before, 24Bit Integer and 32Bit float has the same effective wordlength: 24 bits. In other words they have the identical digital quality. Hence when having two files of the same quality, it is an advantage if one is 75% in size. if they contain identical data then they are identical quality; otherwise not. a 32 bit float file can contain samples with more information than will fit into a 24 bit file, i would not throw away anything important. jeff dinces

Hi Jeff,

The signal out of an AD contains less then 24 good bits. The lower bits carry noise, not audio data.
An acoustic signal (I am not talking about synth) arriving at the AD started with a mic, then a mic pre, and by that time chances are that the noise is much less then 20 bits...
So the best case you can dream off would call for 24 bits carrying music out of the AD.

But then, one goes into the digital world, where it may be important to have a lot more bits for computation of various functions, from digital EQ, to mixing channels and more.

One simple example: you want to add channel A to channel B, but you first want to boost channel A by X2, and attenuate channel B by 2.

Now, the X's are where your bits are, each X can be a 0 or a 1:

Here are the input signals:

Channel A: XXXXXXXXXXXXXXXXXXXXXXXX  
Channel B: XXXXXXXXXXXXXXXXXXXXXXXX  

Here is A multiplied by 2 (6dB boost) and B divided by 2 (6dB cut):

Channel A: XXXXXXXXXXXXXXXXXXXXXXXX0  
Channel B: 0XXXXXXXXXXXXXXXXXXXXXXXX  

Each processed channel now has one more bit (25 bits each) and when you add them you have to be ready for at least 25 bits...

So of course for a lot more processing, and with a lot of channels, the digital processing calls for a lot of bits.
But there is no magic. The signal limitation imposed by the mic, micpre, AD and possibly other gear inserted in series already set the limits on what is possible. Adding bits in the digital world allows all sorts of signal "manipulation", but the signal processing operates on a signal with distortions and noise already determined by the previous gear.

Of course, at the end of digital processing, one ends up with "extra bits" that need to be removed, because they contribute nothing and only "take space". Some extra bits may be "on top", some "on the bottom". So we make it into a 16 bit word for CD, or 24 bit format...

Then, once again we are getting out of the digital world into the analog, where we need to have voltage varying with time, not just a bunch of 0's and 1's. That calls for a DA. So once again we are facing real hardware, where we can not even do 24 bits, because the lower bits are buried in noise.

So 24 Bit is more then enough for conversion, and far less then enough for digital processing work. There are "conversion bits" and "digital processing bits" and they are different issues with each one.

And from hearing stand point, 24 bits of sound means 144dB dynamic range which is way above what a human can stand. Recalling the fact that the dB is a logarithmic scale, the difference between say 120dB and 144dB may not sound like much (24dB) but in fact it is a huge difference.

You will not be throwing away anything important...

Regards
Dan Lavry
http://www.lavryengineering.com

 

[Patrik T]

So, is it not better to set the recording depth to 24 bits and make sure that the recorded file is a 24 bit word (basically the word that comes from the AD that's being stored somewhere on the HD?

I can't understand, in reality, why there would be any benefit from setting a recording depth to 32 float when the AD is maximum spitting out 24 bits in a integer format. I mean -  the moment we tweak the recorded 24 bit audio in any tiny manner - then we'll make it "floating" if the host uses that algorithm, as the word expands.

I just do not get why there would be of any benefit to pad the 24 bit file with additional data that basically says nothing when we track the thing.

I believe that making sure that the recorded, BASIC, files are 24 bit integer PCM's on the HD causes less worries if they have to be transferred, cleanly and neatly, to another platform.

As soon we touch a digital fader, the audio is starting to float, so what difference does it make if it is 24 or 32 from the start. To me - none at all as long as my AD is a 24 bit machine.

[danlavry]

Patrik T wrote on Tue, 04 April 2006 20:09

So, is it not better to set the recording depth to 24 bits and make sure that the recorded file is a 24 bit word (basically the word that comes from the AD that's being stored somewhere on the HD? I can't understand, in reality, why there would be any benefit from setting a recording depth to 32 float when the AD is maximum spitting out 24 bits in a integer format. I mean -  the moment we tweak the recorded 24 bit audio in any tiny manner - then we'll make it "floating" if the host uses that algorithm, as the word expands. I just do not get why there would be of any benefit to pad the 24 bit file with additional data that basically says nothing when we track the thing. I believe that making sure that the recorded, BASIC, files are 24 bit integer PCM's on the HD causes less worries if they have to be transferred, cleanly and neatly, to another platform. As soon we touch a digital fader, the audio is starting to float, so what difference does it make if it is 24 or 32 from the start. To me - none at all as long as my AD is a 24 bit machine.

I certainly agree with you in principle. If it were up to me, I would do what can be done to store the original data from AD as 24 bits, not 32 bits. The "other" 8 bits will just take space and contribute nothing.

And yes, as soon as you touch a digital fader (or digital EQ, Revere and so on) I would go for more bits, 32 floating, 48 or 64 fixed... that is a whole other discussion...

I do not know all the software out there, so I can not rule out the possibility that someone decided to store the AD data as more then 24 bits.Why? I would not know, maybe it is easier from some point of view such as "to get the data ready to processing in floating format"???

All I can say is, that fundamentally there is nothing to be gained by inputting more then 24 bits. More bits would be a waste of space, and no sonic improvement.

Regards
Dan Lavry
http://www.lavryengineering.com
 

[cerberus]

hi dan;

it seemed like izhaki was advocating throwing away "processing bits" because it is during the intermediate stages of production, (e.g. after bouncing but before summing) when disk space issues are most critical.

i like your lucid (excuse the pun please) explanation of what is important and what is not when it comes to throwing away bits.

but here is something i cannot quite understand:  my preferred software sample rate converter likes to add extra bits to a 24 bit signal, i find this is unexpected, i can explain it if the signal is near digital zero, but i think it happens with samples that are not near digital zero too.... i barely understand what is going on, but the src sounds very clean, and measures very clean too (comparable to barbabatch for example).  

as patrik just mentioned, as soon as you touch a digital fader, the signal bit depth tends to expand; but with this type of src process i am already seeing data created that a protools or logic user would have to throw away before they even start mixing.  is it important?  is it doing more damage than good to bump up the sr and then immediately trucate the bit depth?

jeff dinces

[Ronny]

danlavry wrote on Tue, 04 April 2006 17:45

Patrik T wrote on Tue, 04 April 2006 20:09 So, is it not better to set the recording depth to 24 bits and make sure that the recorded file is a 24 bit word (basically the word that comes from the AD that's being stored somewhere on the HD? I can't understand, in reality, why there would be any benefit from setting a recording depth to 32 float when the AD is maximum spitting out 24 bits in a integer format. I mean -  the moment we tweak the recorded 24 bit audio in any tiny manner - then we'll make it "floating" if the host uses that algorithm, as the word expands. I just do not get why there would be of any benefit to pad the 24 bit file with additional data that basically says nothing when we track the thing. I believe that making sure that the recorded, BASIC, files are 24 bit integer PCM's on the HD causes less worries if they have to be transferred, cleanly and neatly, to another platform. As soon we touch a digital fader, the audio is starting to float, so what difference does it make if it is 24 or 32 from the start. To me - none at all as long as my AD is a 24 bit machine. I certainly agree with you in principle. If it were up to me, I would do what can be done to store the original data from AD as 24 bits, not 32 bits. The "other" 8 bits will just take space and contribute nothing. And yes, as soon as you touch a digital fader (or digital EQ, Revere and so on) I would go for more bits, 32 floating, 48 or 64 fixed... that is a whole other discussion... I do not know all the software out there, so I can not rule out the possibility that someone decided to store the AD data as more then 24 bits.Why? I would not know, maybe it is easier from some point of view such as "to get the data ready to processing in floating format"??? All I can say is, that fundamentally there is nothing to be gained by inputting more then 24 bits. More bits would be a waste of space, and no sonic improvement. Regards Dan Lavry http://www.lavryengineering.com

That's the whole deal as stated in my case above. We all know that processing at higher bit depths is beneficial, that's the reason for bit accumulators on console eq's and why DAW plug-ins process at 48 and 64 bit, so the only reason to save at 32 bit is if you are still working on the file. This eliminates saving an unfinished file at 24 fix int. and than converting back to 32 float for final processing. No sense in archiving at 32 bit though, as it takes 25% more space, but no sense in archiving until all processing is final.

Regarding going in. Yes your converters are 24 bit. When you record to float, the added bits are empty and only utilized when a process is performed. So if you record to float and and analyze the file, or save the raw file, it will be actual 24 bit. No sense in doing that if you aren't going to process any more, however, if you are intending to process the signal further, as Dan stated, the processing benefits by adding extra bits. ITR, if you know you are going to process further and want to do it higher than 24 bit, you can either add the empty bits on the recording, all of the songs will than be ready to process, or you can record at 24 bit and convert to 32 float afterwards, when you convert in the DAW after the recording, it just adds the same empty bits which again aren't utilized until you perform a process, which can be as minor as a 1dB fader tweak.

Getting back to the multi-track application. Many digital consoles have 24 bit AD converters, 32 bit mixing buss, 56 bit accumulators at the input of the eq section and back to 24 bit at the DA converters. The added bits at the eq helps the precision that it takes to calculate and compute complex eq curves, when the processing is done, the signal returns to the internal bus depth at 32 bit. Channels are mixed to the stereo buss and output the 24 bit DA's which are more than sufficient enough to transfer the signal back to the analog domain.  

[Patrik T]

Hi Ronny.

Quote:

...if you are intending to process the signal further, as Dan stated, the processing benefits by adding extra bits. ITR, if you know you are going to process further and want to do it higher than 24 bit, you can either add the empty bits on the recording, all of the songs will than be ready to process, or you can record at 24 bit and convert to 32 float afterwards, when you convert in the DAW after the recording, it just adds the same empty bits which again aren't utilized until you perform a process, which can be as minor as a 1dB fader tweak.

Hmmm. This is something I have not seen before and I do not get it completely.

Is the benefit of adding those empty bits at the moment of recording through a 24 bit AD that the data is being handled faster and more efficiently later on when we do that 1dB adjustment. Is it just a pure CPU-saving thing? Is it a sonic integrity-thing? Can you please explain the "ready to process"-part a bit more?

The way I've looked at this during the last couple of years is that a 24 bit file will have those bits added when it comes to the 1dB adjustment. When it is time for processing, the clean and original 24 bit wordlength will expand into a floating point rattlesnake, won't it?

I have always considered it to be a lot more bullet-proof to have the basic audio in a clean integer format than float, to facilitate the possible movement of the basic audio between different hosts and platforms.

An example: Somebody is recording with Samplitude and is mixing in Samplitude. Later on, this project is decided to be all-over-again-mixed in a high-end studio with...Pro Tools HD, plugins, a great console and an ocean of outboard gear. Isn't it in this case a good thing to always stick to putting the basic audio @ 24 bits on the "Samplitudes HD", since PT HD is a integer system?

Cheers.

[danlavry]

Patrik T wrote on Wed, 05 April 2006 12:29

Hi Ronny. Quote: ...if you are intending to process the signal further, as Dan stated, the processing benefits by adding extra bits. Hmmm. This is something I have not seen before and I do not get it completely. Is the benefit of adding those empty bits at the moment of recording through a 24 bit AD that the data is being handled faster and more efficiently later on when we do that 1dB adjustment. Is it just a pure CPU-saving thing? Is it a sonic integrity-thing? Can you please explain the "ready to process"-part a bit more?

I really can not explain "ready to process" too well. I am trying to find a reason why to record with more bits, but I am not a computer programmer. I see those "programmer folks" do all sorts of things I do not understand clearly. One such thing, is to "pre allocate" space for data, so I was thinking it could be a reason why someone would provide the storage space ahead of time (ahead of a computation). I hope we can have a programmer shed more light here.

Patrik T wrote

The way I've looked at this during the last couple of years is that a 24 bit file will have those bits added when it comes to the 1dB adjustment. When it is time for processing, the clean and original 24 bit wordlength will expand into a floating point rattlesnake, won't it?

Think of money transaction. Say you have an item that costs say $1.25 and you have to add tax of 10%. That means you need to add $0.125, a total of $1.375. But in the real world you must round it to either $1.37 or $1.38 because there is no such thing as 1/2 cent.

Tale the same $1.25 and try a tax of 11.25% and now the total is $1.390625 that kind of a "final format" is not acceptable, so you get to throw away more digits for a total of $1.39

This is the same concept as you do with bits. Yes it is a binary system, but the concept is the same. The simplest of processing can generate a huge number of digits. At some point, we get to keep 24 bits...

The real "fun stuff" is when marketing guys sell you a commercial DA box claiming it is say 20 bit, X16 upsampling DA. The Innocent buyer thinks that the DA will yield 20 bits when you input a 16 bit CD data. That is "4 bits" better or is it?
Of course not! When upsampling, we generate new samples, and that is done in order to help the analog filtering of image energy. But the interpolated data may fall on values BETWEEN the original samples, so the DA HAS to be able to generate signals at levels between those defined by a 16 bit grid. Of course, the interpolated values are based on 16 bit values so the outcome can not be any better then 16 bits.

A land survey based on markers that are within 1 inch of perfection does not yield a grid with better then 1 inch result. The grid lines can be 0.1 inch apart, but the whole thing is bound by the original reference markers.

So just because there are a lot of bits showing up, it does not mean that we have better signal. It means that we need all the extra bits to express the processed signal. If we loose those new bits, we will have less accuracy then the original signal...

And at some point, we need to "Lop off" some bits (for practical reasons), which calls for dither, which is a whole other story...

Regards
Dan Lavry