I am not Dan. However, I can take on this part of the question adequately.

Mike Derrick wrote:Are there reasons for DAWs to be recording and editing at 24bits?

Or could we record in DAWs at 16bits and achieve the exact same sonic quality?

~ mike

I finally got some dinner and have a better way of writing this post.

Setup: You have two or more 16-bit files you want to mix together. In particular you might be interested in altering the levels from their recorded state.

Assumptions:

1) You likely recorded all tracks to maximize the use of the dynamic range where your equipment behaves very nearly linearly in response to signals.

2) Your sources had differing levels in reality, but to maximize the precision of the recordings (to avoid loss of precision in the low order bits) you (logically) raised the gain on a mic recording a quiet insturment. The thought here being that you might want to later raise the volume of the insturment relative to the other volumes you recorded.

Problem: When you mix together 16-bit tracks, you may want to raise or lower the levels of one track relative to another. When you do this, if you are only working with 16-bits, you may/will lose the low-order bits of the signal you lower. Thus, you have suffered a loss in precision.

Solution: Using 24-bits (or more) for the editing (while the signals are resident in memory) is a good idea. This ensures that lower order bits are not truncated. Engineers and computer scientists do not generally like to throw away bits before it is determined that they are not needed. In the case of a DAW outputting to CD, we can safely return to 16-bits when we prepare the 44.1/16 output. Additionally, the use of 24-bits allows any smoothing or more complex additive/multiplicative/convolution operations between tracks to be legitimately useful.

Example: You have 2 bits of resolution. Thus, you can only represent the values 0,1,2,3. I ask you to perform the following calculation:

11 / 10 = ??

In decimal this is 3 / 2, which you realize is 1.5. However, we are in a digital world. So, 11 / 10 = 10. At this point you gasp and realize that I just said that 3 /2 = 2. Surely I must be off my rockers with some sort of new age math.

No, I am not. The wonders of decimal. I should say that I just did that IEEE754 style with proper rounding. Many embedded systems simply drop the bit necessary for rounding and say 11 / 10 = 01. Yes, 3 /2 = 1;

This alone isn't that bad. However, what if we perform a calculation such as this on a multitude of tracks and then add them together! Now we can start to get answers that are really ridiculous. Lets do the following:

01 / 10 + 01 /10 = ??

In decimal, this is 0.5 + 0.5 = 1

In a system with rounding, we get a result of 2. And in a system that drops bits, we get 0. These are, clearly, undesirable results. Now, lets assume that I were to read in files that were two-bit precision files, but I represented them internally as 3-bit files for the purposes of calculation. To represent them, we take the original 2-bit bit value and add on some padding bits to the left. I will note them with a ,

These pad bits can be used to hold things that would otherwise spill off the end forcing us to round or truncate.

Now lets do that last problem again:

01,0 / 10,0 + 01,0 / 10,0 = ??

Breaking it down, 01,0 / 10,0 = 00,1

So, 00,1 + 00,1 = 01,1

Eureka, we can now complete simple divisions without a loss of accuracy for this case.

Moving Beyond:

Unfortunately, we will need more bits to perform other potential calculations. Consider 01 / 11 (in decimal 1/3). Clearly our single bit pad is no longer sufficient. In fact, we will not be able to achieve an exact representation of this value in our system! As you know, 1/3 is a reapeating fraction that looks like 0.333... (too bad I can't draw a venculum in a forum, oh well). Anyways, with our binary system we can only represent decimal values 1/2, 1/4, 1/8, 1/16, etc... Only by adding up an infinite number of ever smaller values such as these could we achieve an exact representation of the value 0.333... So, with only 1 pad bit, we could only do the decimal values 0.0, 0.5. With 2 pad bits, we could do 0.0, 0.25, 0.50, 0.75. With 3 pad bits, we could do 0.0, 0.125, 0.250, 0.375, 0.50, 0.675, 0.750, 0.875.

Hope this helps. Dan writes very clear explanations and perhaps he will clarify for my perhaps less than entirely elucidating explanation.

BTW, if topics such as this interest you, I might suggest a course on numerical analysis. I find the subject very rewarding.