| Jon Hodgson wrote on Thu, 01 June 2006 09:19 |
| danickstr wrote on Thu, 01 June 2006 05:19 |
thanks dan for a realistic look at the pitfalls that can ensnare a digital summing device.
|
It's realistic, however the delay issue is completely controllable from a developer point of view. Sample streams ending up out of phase is not a question of some hard to access mathematical rounding, or some random error popping up in the system, it's down to passing the different signals through processing blocks with different latencies.
For example you might have a choice of two filters, one with a latency of 4 samples, the other with a latency of five. If you are going to pass a different signal through each of these blocks before summing them, then you need to delay the one through the filter with a four sample latency (which is a known factor, it's inherent to the design) by an extra sample. That's not difficult to do.
Actually it has nothing to do with whether the summing is digital or analogue, you'd get exactly the same issue if you converted to analogue after the filters and before the summing.
Things get a bit more awkward when you didn't develop the processing blocks and don't know their latencies. This is why plugin APIs have a facility to report latency to the host, it allows the host to implement delay compensation automatically.
|
There are cases where the delay is not a multiple integer of a sample period. Think of say IIR eq's. Yes, a plug-in may have the facility to report latency, but while one can compensate for a latency of non integer multiple (using an all-pass), as a rule, that process is less then perfect in terms of bit transparency, not to mention that some "all pass blocks" alters the phase response (that means the correction of time delays holds over a limited frequency range). Other types of "all pass blocks" are less than flat (amplitude vs. frequency). Choice of implementation is very impoprtent, poor implementation can cause problems.
But I do agree that analog is not totally free of time difference issues. Analog EQ also have the potential of introducing timing issues.
It is important to realize that summing first followed by EQ is very different then doing (different) EQ on individual channels followed by summing...
The first question in my mind is:
Can it be that digital summing got a "bad rap" because people (users and/or software impementers) did not properly deal with timing differences?
Much of what takes place depends on how one "connects the blocks" of the "system". I think a "typical" analog system is different then a "typical" digital system. In the case of digital, one has a lot of ability to do things that would cost a lot in analog. For example, in digital, one can do a separate EQ, a separate re-verb, a separate limiter, a separate compression on each channel... The software allows a lot of flexibility. In analog, it would cost a lot more to equip each track with a hardware EQ, a hardware re-verb, a hardware compressor....
The above may seem to indicate that digital is "better" due to the all that flexibility. But a lot of flexibility also means a lot more ways to screw things up. Of course a good solid professional will understand that it is un natural to apply a lot of re-verb to a piano, and not to the orchestra (or visa versa). A real pro will most often use compression AFTER the mix, not on some individual tracks... and so on...
The lesser flexibility of a typical analog system (mostly due to cost driven consideration) tend to guard the less experienced user from some major screw ups that are very easy to do in digital.
So my question is: How much of the "bad rap" of digital summing is due to misuse of modern digital audio workstation? I do not know the answer. I do know that many newer users and less knowledgeable users audio computing tend to "overdue things", which does screw up the end results. Just because the tools are there does not mean one has to use them
Regards
Dan Lavry
http://www.lavryengineering.com 
