Originally Posted by arnyk
Holy nit picking, Batman!
Didn't I predict this almost precisely?
"Like a dog that returns to its vomit Is a fool who repeats his folly. Do you see a man wise in his own eyes? There is more hope for a fool than for him."
Darn tootin'! I can't believe I committed that sin again!
Between us chickens, that proverb counts on the common man who thinks dogs are like people instead of animals. The reality is different of course. Dogs vomit back what they think is dangerous to keep digesting. By throwing it up and chewing it further into smaller pieces, they avoid that potentially deadly blockage. Among dog owners is a saying that dogs get to enjoy their food twice while we once.
We feed our dogs raw food with bones and I get to watch this scenario all the time. They swallow a big piece of bone, bring it back up and chew and eat it again.
Anyway, enough religious discussions. Back to the topic at hand, there are three things that usually don't mix: someone who writes great software, knows signal processing, and math. When I first joined Microsoft I was testing our audio encoder and kept hearing this artifact that didn't sound like compression artifacts. The source files were all 44.1 but at the bit rates I was testing the sample rate was lower so I knew there was sample rate conversion going on. So I used my audio software and downsampled using that before encoding and the artifact vanished! I went to the head of our codec group and asked him what he was using for resampling and he said it was the Windows service. I told him about the problem and they built a high fidelity resampler in the encoder and problem was fixed. Similarly, I discovered something that had cost me a lot of time. The fact that changing the volume control affected sound! Again, poor design causing quantization errors. Don't know who had written these but no doubt it was a good software engineering not understanding the math and signal processing. I hired JJ to shoot the Windows audio stack in the head and fix all of these problems and the result was the much improved one that has shipped from Windows Vista on.
By the same token, I have found the stats in Audition suspect. The clues are right there in the pop up stats. Here is the same analysis that I did with latest version of Audition but now, with the version of the stats you have:
Immediately we see lack of knowledge on behalf of the person who programmed that dialog. It says "Average RMS Power." We can have Average power but what the heck is Average RMS power? There is no such thing as RMS Power. From the bible of the Internet, the wiki
, we have this:
So right away we see that there is no such thing as RMS Power. Only Average Power.
The formula calls for knowing both voltage and current. The waveform gives us the voltage. But where on earth do we get the current? Computing that requires knowing the load resistance which we do not have.
There is another problem in that dialog that I leave as an exercise for the reader to find.
Now let's look at the stats in my updated version of Audition:
We see an immediate improvement as you see in the line I highlighted values. The word "power" has been expunged from the stats and replaced with Amplitude. As I explained that is all the data we have in the audio file so nothing other than that can be computed. We still have a problem because they are using the term "Average RMS." RMS is actually an average so the term Average is redundant. Let's review what RMS is. Here is a simple sine wave:
If we just summed all the values we get zero since the positive and negative cycles cancel each other out. If we feed that sine wave to an amplifier, it would not generate zero power. Rather, it will generate power in both cycles, and the direction of current will simply be different from the positive to negative side. The concept of RMS came about to solve this problem. It creates an average that is insensitive to polarity by squaring the values, summing them and then dividing by the number of samples. We then take the square root and we find our RMS value:
So why still call this an Average? The key is that innocent looking "100 msec" field in the first graph above. The default for this is 50 msec as you can see in Arny's post. When you ask Audition to give you the statistics, it computes a piece-wise RMS value that is limited to that interval. If you give it a much longer interval than 50 msec, it would compute RMS values for each segment and then simply average all of those. In other words, it is the average number of a N number of RMS computations.
The problem with this is that if you select a large segment of your audio file or the entire track, the Average RMS value gets pulled down by areas of the track that are quiet or silent. You can see such a fade out in Arny's graph. If you are after some general stats about the clip, this is fine. And that is what Pros use it for. Trying to use it to compute amplifier power/Crest factor however, causes a problem. The amplifier does not get to average out an entire clip and amplify that. It has to amplify what it is told to amplify at any one instance. Its capacitor power reservoir can only handle milliseconds worth of power drain, not seconds and minutes. So what we want to see is short segments of the track analyzed as I showed in my examples, not long segments. Using long segments will artificially lower the average and hence "crest factor."
Anyway I better stop here before confusing everyone more
. The net is that the statistical analysis in Audion cannot be used superficially to make an argument about crest factor and amplifier power. While useful data can be extracted from it, it is not designed for this use and can easily produce garbage as I showed in my question to Arny. I have yet to see anyone making this amplifier crest factor argument correctly walk through proper analysis of the waveform and this discussion is another version of it. The famous expression, "Lies, damned lies, and statistics"[/i} most definitely applies here.