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 >