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.
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
> 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
> 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
> Diamond Productions
> Preserving the past for the future.
> Dave Bradley President