Print

Print


You know, this is a funny thing...

Oo I mis-read his post, because we had been doing so much talking about 
transfers at different sample rates. For some reason I read it as the 
client was asking for 24 bit - my apologies. I wasn't talking about 
processing, but transfers.

Best,

Alyssa.

On 21-Feb-06, at 1:29 AM, Dave Bradley wrote:

>> OK...so am I understanding correctly that you are transferring 
>> through your converter into your computer at 16bit, but then 
>> importing it into ProTools for 24bit?
>>
>> If this is the case, you're not "enhancing" the sound quality, but 
>> just using some kind of algorithm(s) in order to get a more complex 
>> file - information that was added, by the way, and has nothing to do 
>> with the original.
>
> That's not entirely accurate. In fact, it's quite INaccurate.
>
> Any adjustments made to the sound file will result in a mathematical 
> calculation which is never done as simple addition or subtraction. The 
> simple process of even just boosting the level by 3 db results in a 
> multiplication process that when fed 16 bits of data will result in 
> more than 16 bits of final calculation in the form of a decimal.
>
> Some people would simply say truncate that result back to 16 bits and 
> you're accurate enough for government work.
>
> The problem with that is that any additional work done on the file 
> will also result in a similar calculation.  Let's say this time it's a 
> bit of hiss reduction, and maybe some EQ boost to the 1KHz to 3KHz 
> band.  If each of those is working with the 16 bit PLUS decimal value, 
> then each calculation will result in a more accurate representation of 
> the final value. Only when all processing is done should you drop back 
> to 16 bits through whatever process, truncation, dithering, noise 
> shaping, etc. that you feel is appropriate.
>
> If, on the other hand, you leave the file as 16-bit, each calculation 
> done for each adjustment you make will leave an error which the next 
> calculation will amplify until you start to get noticeable problems.
>
> A totally made up example which gets the idea across could be as 
> follows.
>
> Initial value 179.
> Your first calculation is your initial value * 0.5749.
> Your second calculation is the result of your first value * 4.7768.
> Your third calculation is the result of your second value * 2.48.
> Your fourth calculation is the result of your third value * 1.17.
> Your final value is the result of the fourth calculation brought back 
> to 16-bit world.
>
> If you start at 16 bit and stay at 16 bit through this entire process, 
> then here's what you get.
> First calculation (179 * 0.5749) results in 102.90710000 which is 
> immediately truncated to 102 so it will fit entirely in the 16-bits 
> which has no room for the decimal value. No, it won't round it up to 
> 103.
> Second calculation (102 * 4.7768) results in 487.23360000 which is 
> immediately truncated to 487 so it will fit entirely in the 16-bits 
> which has no room for the decimal value.
> Third calculation (487 * 2.48) results in 1207.76000000 which is 
> immediately truncated to 1207 so it will fit entirely in the 16-bits 
> which has no room for the decimal value. No, it still won't round it 
> up to 1208.
> Fourth calculation (1207 * 1.17) results in 1412.19000000 which is 
> immediately truncated to 1412 so it will fit entirely in the 16-bits 
> which has no room for the decimal value.
> Your final value is 1412 after 4 simple adjustments to the audio data.
>
> Now, if you take that 16-bit file and import it as 24-bit, do your 
> calculations and then truncate, dither, or otherwise produce a 16-bit 
> final file, you'll notice the value changes drastically.
> First calculation (179 * 0.5749) results in 102.90710000 (the extra 8 
> bits holding the value to the right of the decimal place).
> Second calculation (102.90710000 * 4.7768) results in 491.56663528.
> Third calculation (491.56663528 * 2.48) results in 1219.08525549.
> Fourth calculation (1219.08525549 * 1.17) results in 1426.32974893.
> Let's assume you do a simple truncation at this point to go back to 
> 16-bit. That value is now 1426, whereas when you worked strictly in 
> 16-bit it turned out to be 1412.
>
> Hmm, which one was more accurate?
>
> You'll notice that in the "stay in 16-bit" example above, the 
> truncated results each time were small enough that they certainly 
> weren't using the full 16 bit capabilities of the digital sample.  
> (102, 487, 1207, 1412) The first number, 102, could be represented in 
> 6 bits, the second number, 487, could be represented in 9 bits, the 
> third number, 1207, could be represented in 11 bits, and the fourth 
> number, 1412, could be represented in 11 bits. So it's obvious that 
> we're not dealing with audio that is pressing the limit of 16-bit 
> sampling. The argument that because cassette tape is not up to CD 
> quality so any processing can remain in the 16-bit realm has just now 
> been invalidated.
>
> You MAY be able to capture all of the existing audio from a cassette 
> in 16-bit sampling, but NEVER do any processing in 16-bit. Do it in 24 
> or even 32 bit and then drop your final result to 16-bit through 
> whatever method you wish and you'll end up with a far more accurate 
> digital audio file than if you allowed all those computational errors 
> to creep in.
>
> (And in case you didn't notice, the difference between 1412 and 1426 
> is NOT just a small rounding up or down error.  It's 14 values 
> different.)
>
>
>
> -----------------
> Diamond Productions
> Preserving the past for the future.
> Dave Bradley   President
>