RMS in CEP, just in from Syntrillium
Peter Larsen
I have received an email response from Syntrillium, with permission to
post this:
STATEMENT FROM SYNTRILLIUM BEGIN
Cool Edit and Cool Edit Pro's RMS calculation are relative
to a 0dBFS sine wave, that is, a 0dB RMS reading is equal
to a maximum amplitude sine wave. This is probably why some
users are getting confused.
I think what you were looking for was the value relative to
a max amplitude square wave, which is exactly 3.01dB higher,
thus the readings would be 3.01dB lower. So the RMS reading
of "+2.9" would really be "-0.1" relative to a max amplitude
square wave. You will never see the RMS value in Cool Edit
go above +3.01dB for 16-bit audio.
STATEMENT FROM SYNTRILLIUM END
Not my words, posted by permission. Comments, queries to Syntrillium,
they get an email CC of this post as a courtesy.
Kind regards
Peter Larsen
--
******************************************************************
* This posting handcrafted by Peter Larsen, pla...@teliamail.dk *
* My homepage is at: http://w1.1358.telia.com/~u135801844/ *
******************************************************************
André Huisman
380301D7...@teliamail.dk...
> I have received an email response from Syntrillium, with permission to
> post this:
> STATEMENT FROM SYNTRILLIUM BEGIN
> Cool Edit and Cool Edit Pro's RMS calculation are relative
> to a 0dBFS sine wave, that is, a 0dB RMS reading is equal
> to a maximum amplitude sine wave. This is probably why some
> users are getting confused.
Just as we thought. Though wrong (and the RMS notation has NO place in
something like this) it is something you can validate for some purposes.
STILL, Syntrillium better remove the RMS from their numbers and name it
something else like "RMSine" or something like that ;-)
> I think what you were looking for was the value relative to
> a max amplitude square wave, which is exactly 3.01dB higher,
> thus the readings would be 3.01dB lower. So the RMS reading
> of "+2.9" would really be "-0.1" relative to a max amplitude
> square wave. You will never see the RMS value in Cool Edit
> go above +3.01dB for 16-bit audio.
Too bad Syntrillium didn't look at how other programs did it (or read into
how things like RMS are calculated). Would have reduced the ASCI on this
subject quite a bit.
Is Syntrillium going to change the algorithm in the future? OR is it going
to chance the _incorrect_ RMS notation?
--
André Huisman
New Line licht & geluid
hui...@new-line.nl
http://www.new-line.nl
http://www.djfaq.cjb.net
--- pardon my French, I'm Dutch ---
Peter Larsen
"André Huisman" wrote:
> Just as we thought. Though wrong (and the RMS notation has NO place in
> something like this) it is something you can validate for some purposes.
It has obvious sense in some contexts, such as for instance predicting
how much was clipped off of a waveform. Then the expression to use is
however peak value of rms equivalent sine, and it is MUCH simpler to
give the actual RMS value and suggest that if people can see clipping,
then the instantaneous peak of the sine - if it was a sine - would have
been three dB higher. But there is a basic severe problem, and that is
assuming that sinewaves is a valid model of the sound analysed. Those
Hollywood sound effects are NOT clipped, but their RMS specification
done the CEP way indicates them to so be.
> STILL, Syntrillium better remove the RMS from their numbers and name it
> something else like "RMSine" or something like that ;-)
It is obvious to simply display both, there is plenty room on the screen
or to have a selection of what they want to display, but to call
something RMS that is something else is not good, not at all good.
> Too bad Syntrillium didn't look at how other programs did it (or read into
> how things like RMS are calculated). Would have reduced the ASCI on this
> subject quite a bit.
How about those people who have based decisions on incorrect RMS values
since 1996, most probably used that display for the entertainment value,
but probably not all.
> Is Syntrillium going to change the algorithm in the future? OR is it going
> to chance the _incorrect_ RMS notation?
I prefer to respect what they told me I could post and could not post,
I'll leave such speculations for them to address. And I am still waiting
for a simple to the point reply on whether I have data that can be
converted to rms data by subtracting 3 dB or whether the relationship
between actual RMS and the value Cool Edit comes up with is so curveform
dependant that the entire dataset is useless or the situation is
somewhere in between.
I am not in a good mood about this, but I decided to finish the
documentation project this has become by documenting some vinyl based
examples transferred to an other "one off" CD for listening tests, for
what it may be worth. I wished I didn't have that question, but I'm so
far with it that I might as well round it off with a comparison with
what they did 25 years ago, so that we can all appreciate the tremendous
gain in quality this industry has obtained in the digital era.
O;-)
> André Huisman
Greg
Peter Larsen wrote in message <380378F5...@teliamail.dk>...
>And I am still waiting
>for a simple to the point reply on whether I have data that can be
>converted to rms data by subtracting 3 dB ........
I don't think so. I generated a 30 sec clip of pink noise and ran the
statistics with 100ms whatever in the Cool Edit software. The numbers
came out to be.
Peak -1.57
Min RMS -13.3
Max RMS 10.19
Avg RMS 11.74
Converting the above so that the Peak is referenced to 0 ( add 1.57 to
all of the readings).
Peak 0
Min RMS -11.73
Max RMS -8.62
Avg RMS - 10.17
I then took the same file of pink noise and analyzed it with MathCad
where I know I am calculating the RMS, the peak is normalized to 0 dB.
Peak 0
Min RMS -13.3
Max RMS -9
Avg RMS -10.75 (eye balled)
Cool Edit is off by a half to one and a half dB depending on what
numbers you want to use. If you subtract 3 dB you will end up in worse
shape, at least for this example. Since the RMS and Peak for a sine
wave in Cool Edit is off by 3 dB, i.e. the RMS is 1.414 times to high
and the noise is not. If Cool Edit was instead computing the average
and multiplying by 1.57 then that would explain the sine wave peak and
RMS being the same (the average value of a sine wave is .637 times the
peak a 3.9 dB difference). If the input signal is Gaussian noise then
the average would read more than 2 dB lower with the same signal on a
RMS meter, perhaps 2.5 to 3 dB lower. This is my theory:
1) They calculate the average.
2) The average is then multiplied by 1.57 (3.9 dB) which causes the
peak and "RMS" to be equal.
3) For noise a average will read -2.5 to 3dB to low, add the fudge
factor of 3.9 dB and it will now read about 1 to 1 1/2 dB to high.
So it looks to me like Cool Edit is doing a average not a RMS, they
simply scaled the average to be close on high C.F. waveforms.
Greg
Peter Larsen
Greg wrote:
> ..[Done snipped some did I].. This is my theory:
>
> 1) They calculate the average.
> 2) The average is then multiplied by 1.57 (3.9 dB) which causes the
> peak and "RMS" to be equal.
> 3) For noise a average will read -2.5 to 3dB to low, add the fudge
> factor of 3.9 dB and it will now read about 1 to 1 1/2 dB to high.
>
> So it looks to me like Cool Edit is doing a average not a RMS, they
> simply scaled the average to be close on high C.F. waveforms.
It is beyond me if it is the right barn, but it does look to be some
barn in Sunnyvale county all right, so can I please get a release of
that post for my website. I reckon they had been in 'public posting
mode' by now if they wanted to give any kind of a better explanation,
and I don't think we'll really come any closer unless someone does what
one is not supposed to AND is very good at reading uncommented machine
code .... O;-) ...
I still rate this problem in the pentium class, if not for any other
reason then because they did not - not as found my me, but I understand
the windows helpfile format to be about hiding information in the most
efficient way possible - document that they took a short cut, because it
"would never matter, would it?". And THAT is the pentium class attitude.
Mind you: I'm not into bashing them, I don't want to go for the jugular,
it is great programme to work with, and you don't have to have a
ultrasuperturbofast 2 Ghz pentium 6AV to use it. It is OK with me that
they took a shortcut, it is the lack of accurate labelling I have a
problem with.
> Greg
André Huisman
SYOM3.85$Jc....@newsfeed.slurp.net...
> >And I am still waiting
> >for a simple to the point reply on whether I have data that can be
> >converted to rms data by subtracting 3 dB ........
> I don't think so. I generated a 30 sec clip of pink noise and ran the
> statistics with 100ms whatever in the Cool Edit software. The numbers
> came out to be.
> Peak 0
> Avg RMS - 10.17
> I then took the same file of pink noise and analyzed it with MathCad
> where I know I am calculating the RMS, the peak is normalized to 0 dB.
> Peak 0
> Avg RMS -10.75 (eye balled)
I did the same with a 1 second (long enough IMO) pink noise signal. Outcome
listed below:
Pink noise (1 sec length, normalised to 0dBFS)
Cool Edit Pro (100ms RMS window width)
Peak Amplitude: .07dB (life above FFFF???)
Minimum RMS power: -10.53dB
Maximum RMS power: -7.1dB
Average RMS power: -8.79dB
SoundForge
Peak Amplitude: 0.00dB
RMS power: -11.79dB
(No other numbers available)
Wavelab (100ms "resolution")
Peak Amplitude: 0.00dB
Minimum RMS power: -14.36dB
Maximum RMS power: -10.99dB
Average RMS power: -11.80dB
Opened file in CEP again (to see if the life above FFFF still exists):
Peak Amplitude: .07dB (still life above FFFF???)
Minimum RMS power: -10.53dB
Maximum RMS power: -7.1dB
Average RMS power: -8.79dB
What do these numbers show? They show that (in this case at least) the RMS
level of CEP is roughly 3dB higher than WL and SF (roughly being the 0.01dB
difference between WL and SF).
Though it might well be possible, I don't personally think that ALL THREE of
them are wrong. So Greg might look into his algorithm for possible errors?
If anyone has a reason why a 1 second pink noise source isn't a valid test,
I'd like to hear.
Peter Larsen
"André Huisman" wrote:
> Opened file in CEP again (to see if the life above FFFF still exists):
And it is getting crowded up there, I'm redoing the lot after Greg made
a good case for also having 100 ms data, and this time with normalized
mono-versions all the way though (gives a clearer image fo the total
envelope in a screen snapshot too .... ), and 2 of the first three of
the original samples ended up having rms values above digital zero with
a 1 ms "rms window".
>
> Peak Amplitude: .07dB (still life above FFFF???)
> Minimum RMS power: -10.53dB
> Maximum RMS power: -7.1dB
> Average RMS power: -8.79dB
>
> What do these numbers show? They show that (in this case at least) the RMS
> level of CEP is roughly 3dB higher than WL and SF (roughly being the 0.01dB
> difference between WL and SF).
My head temporarily hurts less, but I worry that "there be tigers".
> Though it might well be possible, I don't personally think that ALL THREE of
> them are wrong. So Greg might look into his algorithm for possible errors?
>
> If anyone has a reason why a 1 second pink noise source isn't a valid test,
> I'd like to hear.
Gone looking for something else to check the whole stew with. Your pink
noise says that my idea of simply subtracting 3 dB is OK, Greg has made
good points that anything could be happening, Syntrillium still hasn't
given a straight yes or no answer to whether I simply subtract 3 dB, I'm
gonna go get some glue and glue that target to the graund so that it
gets easier to hit! - this has become enough of a project as it is, it
doesn't have to be difficult too. Suggestions for distributable software
that can redo the analysis and get it right gladly accepted ASAP.
> André Huisman
Peter Larsen
Hi Folks,
I just received an email from Syntrillium containing this explanation, I
would wrong them if I didn't quote it verbatim:
EXCERPT FROM SUPPORT EMAIL BEGIN
The reporting of the RMS value, after calculations are finished,
is converted to decibels for easier viewing. When you convert
a value to decibels, it must be relative to some known value.
We chose that known value to be a maximum amplitude sine wave.
This person was expecting that value to be a maximum amplitude
square wave. They are probably expecting the 'square wave'
interpretation because that is what happens if you just take the
sample values normalized to the range +/-1.0, do the RMS calculation,
and convert directly to decibels using the formula dB=20*log(rms_value).
At this, a full scale sine wave is -3.01dB. Using a sine wave as
the base, the square wave becomes +3.01dB. So it's just what you
use as the base. We used a full-scale sine wave because it makes
more sense musically and scientifically. But in working with
electricity and power, I suppose leaving the value of a full scale
sine wave at -3.01dB makes more sense - maybe.
I guess there's room for debate.
EXCERPT FROM SUPPORT EMAIL END
I can only read this to the effect that all I have to do is to subtract
3.01 dB from all RMS values stated by CoolEdit to actually get RMS
values by their geometric definition.
Kind regards
Peter Larsen
Greg
André Huisman wrote in message <7u200s$1ad$2...@news1.xs4all.nl>...
>Greg <gfre...@slic.com> schreef in berichtnieuws
>> >And I am still waiting
>> >for a simple to the point reply on whether I have data that can be
>> >converted to rms data by subtracting 3 dB ........
>> I don't think so. I generated a 30 sec clip of pink noise and ran
>>the statistics with 100ms whatever in the Cool Edit software. The
>>numbers came out to be.
>> Peak 0
>> Avg RMS - 10.17
Lets include the rest of the data here, first the original.
Peak -1.57
Min RMS -13.3
Max RMS 10.19
Avg RMS 11.74
Then normalized.
Peak 0
Min RMS -11.73
Max RMS -8.62
Avg RMS - 10.17
>> I then took the same file of pink noise and analyzed it with
>>MathCad where I know I am calculating the RMS, the peak is
normalized
>>to 0 dB.
>> Peak 0
>> Avg RMS -10.75 (eye balled)
I said eye balled because I only display it as 100ms windows strung
together in a graph.
>I did the same with a 1 second (long enough IMO) pink noise signal.
Not in my opinion, your making a statistical measurement, the more
data the better. For example I generated 10 samples of pink noise at
one second. The first 5 were with the "Intensity" in the noise
generator set to 40. The difference between the Avg. RMS and the peak
were as follows:
8.13
8.76
8.86
8.28
8.72
The mean value of the 5 is 8.55dB
Now with the "Intensity" set to 20.
9.71
9.15
9.1
8.42
8.84
That give us a mean of 9.04 for those 5 samples.That also amounts to a
1.58 dB difference between the highest and lowest samples. I did the
same thing with the 30 second samples. First with "Intensity" at 40.
9.73
9.59
9.75
9.83
10.29
Mean value is 9.83
Now the "Intensity" is set for 20.
10.1
9.99
10.15
9.61
9.53
Mean value is 9.87
The difference between the samples in both sets in the second group is
.76 dB. There is clearly a trend on the "one second data", something
is not random here. I ran the first condition another 10 times and the
numbers still fall in the range of the first 5 (mean of 8.6dB). So do
100 samples of each condition and I suspect that you would find a
consistent difference between the two sets of data. Notice that the 30
second samples do not suffer from the
same problem and are 3/4dB to 1 1/4 dB larger than the 1 second
samples.
>Outcome listed below:
>Pink noise (1 sec length, normalized to 0dBFS)
>Cool Edit Pro (100ms RMS window width)
>Peak Amplitude: .07dB (life above FFFF???)
>Minimum RMS power: -10.53dB
>Maximum RMS power: -7.1dB
>Average RMS power: -8.79dB
>SoundForge
>Peak Amplitude: 0.00dB
>RMS power: -11.79dB
>(No other numbers available)
>Wavelab (100ms "resolution")
>Peak Amplitude: 0.00dB
>Minimum RMS power: -14.36dB
>Maximum RMS power: -10.99dB
>Average RMS power: -11.80dB
>Opened file in CEP again (to see if the life above FFFF still
exists):
>Peak Amplitude: .07dB (still life above FFFF???)
>Minimum RMS power: -10.53dB
>Maximum RMS power: -7.1dB
>Average RMS power: -8.79dB
>What do these numbers show?
They don't show anything other than CEP is off. What the data I have
shown seems to imply is that for 1 second samples the intensity has an
effect on the "Avg. RMS" to "Peak" that a 30 second sample seems to
avoid. It also shows that a 30 second sample will have a higher C.F.
than a one second sample. This should not come as a surprise since the
probability of a higher peak occurring increases with time.
> They show that (in this case at least) the RMS
>level of CEP is roughly 3dB higher than WL and SF (roughly being the
>0.01dB difference between WL and SF).
Now try it with a 30 second sample and make sure you generate at least
10 samples so you at least have some idea of the distribution.
>Though it might well be possible, I don't personally think that ALL
THREE of
>them are wrong.
No it is clear though that at least one is wrong and yes it is
possible that they all are though I doubt it. I still question the
usefulness of the limited statistics provided by Cool Edit.
> So Greg might look into his algorithm for possible errors?
No problems with the algorithm, it but it does not provide the data in
the same
way, I do not compute the "Avg. RMS" as such. The C.F. is calculated
by extracting the highest peak from the data that is being used to
generate the 100ms RMS value. Cool Edit OTOH takes the highest peak
and supplies the highest, lowest and computes the average RMS. To
take the difference of the average and the peak and call it the C.F.
is misleading since the highest peak will have occurred at a point
when
the RMS was near it's highest or "Maximum RMS Power". The fact that
they call it "RMS Power" is in itself incorrect since the information
required to compute power is not available.
For MathCad the calculation is quite straight forward. The samples are
all stored in an array and squared, they are then summed divided by
the total number of samples and the square root taken. Not including
the declaration statements for the variables it is 2 lines of code.
Each number is calculated to 16 significant digits or a little more
than 53 bits, something I doubt that Cool Edit does. The peak is even
simpler, convert all the elements of the array to their absolute value
and find "max", again 2 whole lines of code. This whole discussion was
about crest factor or at least that was the direction it took after
the original poster had his problem solved. It should be clear from
the graphs I sent you that integrating over a 100 ms it is rare to see
anything above 20 dB. If you study the graphs you will see when it
does exceed 20dB that it does not happen when the music is at it's
loudest. Since we monitor the levels through a sound system with
averaging type meters the method I used seems far more appropriate.
>If anyone has a reason why a 1 second pink noise source isn't a valid
test,
>I'd like to hear.
I think I made that clear.
Greg
Neil Gould
As a CEP user, I've been following this thread with some interest. However,
I'm not sure where the "problem" lies...
Peter Larsen wrote in message <3804C64D...@teliamail.dk>...
>
>EXCERPT FROM SUPPORT EMAIL BEGIN (SYNTRILLIUM)
>
>The reporting of the RMS value, after calculations are finished,
>is converted to decibels for easier viewing. When you convert
>a value to decibels, it must be relative to some known value.
>
(snip)
>
>I can only read this to the effect that all I have to do is to subtract
>3.01 dB from all RMS values stated by CoolEdit to actually get RMS
>values by their geometric definition.
>
Wouldn't that depend on the true nature of your waveforms? If your signal
was all square waves, then I think your presumption would be correct.
However, if not, then you'd wind up with just another "wrong" value.
Perhaps I've missed something, here? Syntrillium has indicated their
references, and it's then up to the user to apply that to their recordings.
I am unaware of any typical metering methods that significantly differ from
this approach.
Regards,
Neil Gould
-------------------------------
Terra Tu AV www.terratu.com
Technical Graphics & Media
Ken Nelson
I tried to find the start of this thread (including Deja news) but no
luck.
Can someone re-post or summarize the initial issue?
I'm used to RMS values when used to calculate AC power (eg amplifier
efficiency), and also when used to discuss audio "loudness" and VU meter
readings. What I don't understand is what use is being made of CoolEdit's
RMS reading that makes this RMS discussion a big deal. I just use CE 96
for editing and audio processing (and it rocks!).
Thanks for any info.
ken
Peter Larsen wrote:
> I have received an email response from Syntrillium, with permission to
> post this:
>
> STATEMENT FROM SYNTRILLIUM BEGIN
>
> Cool Edit and Cool Edit Pro's RMS calculation are relative
> to a 0dBFS sine wave, that is, a 0dB RMS reading is equal
> to a maximum amplitude sine wave. This is probably why some
> users are getting confused.
>
> I think what you were looking for was the value relative to
> a max amplitude square wave, which is exactly 3.01dB higher,
> thus the readings would be 3.01dB lower. So the RMS reading
> of "+2.9" would really be "-0.1" relative to a max amplitude
> square wave. You will never see the RMS value in Cool Edit
> go above +3.01dB for 16-bit audio.
>
> STATEMENT FROM SYNTRILLIUM END
>
> Not my words, posted by permission. Comments, queries to Syntrillium,
> they get an email CC of this post as a courtesy.
>
Peter Larsen
Neil Gould wrote:
>
> Hi all,
>
> As a CEP user, I've been following this thread with some interest. However,
> I'm not sure where the "problem" lies...
Here is an example that illustrates it:
NDA_001.wav:
CREST FACTOR 19.95 dB /* comes from AVG RMS */
PEAK AM 00.00 dB /* verifies normalization */
PERHAPS CLIP 1 sample /* not limited! */
DC OFFSET 1.111 % /* indicates ABS polarity */
RMS WINDOW 1 ms 10 ms 100 ms 300 ms
MAX RMS +02.48 dB -01.18 dB -09.31 dB -11.28 dB
MIN RMS -63.54 dB -51.16 dB -43.21 dB -42.19 dB
Really simply said that the RMS value (and RMS is a simple geometric
un-interpretable definition) of a signal should be larger that the
maximum peak value of it is pure and utter nonsense. They defend their
way of doing it by saying that "it fits real music better, because that
is what the peak of a sinewave would be" - or, as I understood them,
words approximately to that effect.
So what they call RMS is in fact "peak value of equivalent sine". The
example data are from a recording of a New Orleans jazz band, so it is
music. What this means is that if you want the RMS value when you ask
for the RMS value, then you have to subtract 3.01 dB from what CoolEdit
claims to be the RMS value but is in fact what the peak value would have
been if it was a sinewave, which real music unfortunately isn't. All the
confusion is theirs.
They have a point in as much as that it might be valuable to know what a
peak clipped peak would have been like if it wasn't peak clipped.
However as the appear to actually compute the RMS value correct, and
then add 3.01 dB to it, then it had been a lot simpler if they had added
the following text to the data-display window: remember that the actual
peak value of a sinewave that produces the displayed RMS value will be
3.01 dB higher.
I'm redoing all the data because of various enhancements suggested on
the way, so if there is a wish for a repost of the entire dataset (which
will eventually appear on my website), then please say so now, and I
will do my best to remember it when I have finished this major
documentation project it has become.
[it appears that I have yet again missed follow ups courtesy of Telia
... ]
> Perhaps I've missed something, here? Syntrillium has indicated their
> references, and it's then up to the user to apply that to their recordings.
> I am unaware of any typical metering methods that significantly differ from
> this approach.
Real simple: RMS is a geometric definition, it is false - as in soap
sold under the name soap not actually being soap - if they label
something RMS that isn't. There are no possible interpretations, and IF
they want to do it differently, then they had better label it correctly
OR as a bare bones minimum write on the data-display screen that if one
wants RMS when one asks for it, then one should subtract 3.01 dB from
what is labelled RMS but isn't to get what actually is RMS.
What started me on this project was that André and others mentioned
Crest Factors for music that seem to be too small in comparison with my
understanding of them. André was the one that discovered that CoolEdit
gets a-logical results, the above is just a proof that any claim of
applicability of their theory to real music results in RMS values
displayed that are above digital zero. And that pretty much nails it:
THEY GOT IT WRONG.
It is my very clear understanding that they are well aware of the
problem and that they will address it, but I don't think it would be
polite to keep forwarding my public comments in this context to them, if
they didn't get the hint about this thread by having the starting of it
CC'ed so that they could make their own case, then it is their problem.
Don't get me wrong: the have been nice and helpful - mind you: I'm using
an unreg version - but I feel kinda stuck with having to come up with
their side of this, while having some fairly simple proof that their
theories about how to display RMS lacks correlation to the real world. I
don't want to bash them, it is a great tool, and it does it stuff in a
great way, but they left me using a yard-stick (96 cm) that they just
re-labeled a meter (100 cm) stick, without counting the
lightwave-wavelenghts right ...
I'm gonna get darn good at subtracting 3.01 rsn .... I don't want to
start the data conversion to the real world before I'm finished
collecting data ... it could go even more wrong if I did.
> Regards,
>
> Neil Gould
> -------------------------------
> Terra Tu AV www.terratu.com
> Technical Graphics & Media
--
Peter Larsen
Ken Nelson wrote:
>
> Hi all,
>
> I tried to find the start of this thread (including Deja news) but no
> luck.
>
> Can someone re-post or summarize the initial issue?
Just did in a nearby post.
> I'm used to RMS values when used to calculate AC power (eg amplifier
> efficiency), and also when used to discuss audio "loudness" and VU meter
> readings.
And RMS is darn simple: it is the area circumscribed by the curve,
whatever it is, or rather a computational trick that should give a
near-correct result by mathematicians definitions.
> What I don't understand is what use is being made of CoolEdit's
> RMS reading that makes this RMS discussion a big deal.
Measuring Crest Factors of various types of music and types of
recordings thereof. It all started with a discussion about
powerhandling, and eventually people confronted me with data showing
that I was too careful when I said a Crest Factor of 25 dB was not
improbable. They all put their estimates in the 15 to 20 dB range.
Reckon they based their comments on Cool Edit data as well. So what do I
do: I start measuring some location recordings made with penultimate
equipment, and have to concede that my estimate of 25 dB being the
realistic value in system dimensioning in terms of required headroom is
wrong, and post to that effect, also in alt.support.tinnitus.
André then finds funny data from CEP that he uses, the eventual outcome
is that I was right all along, because CoolEdit displays a 3.01 dB
larger value for the RMS than the actual value by its geometric
definition. I take having posted a correction of something I previously
posted because a flawed, trusted measuring tool erroneously proved me
wrong, when I was in fact right all along, as personal, but then perhaps
I care too much about getting things right, I don't know. I just do not
want to mislead people. IT is also a major issue when ""an entire
industry"" says to me that I was wrong, because they had trusted the
same tool.
> I just use CE 96
> for editing and audio processing (and it rocks!).
It absolutely so does, it is a great tool. It will probably become even
greater because of this, but the reasoning behind saying that "we think
displaying RMS as RMS[actual] + 3.01 dB and then just label it RMS makes
sense to us" is not different from the points made when the windows
calculator could calculate and the pentiums didn't do no better. As for
this documentation project, well - it ended up wasting quite some time,
but in the end it will gain in quality too.
> Thanks for any info.
Ask again if it wasn't what you wanted to know!
> ken
Kind regards
Peter Larsen
[I'll make the exception of leaving this in for reference]
> Peter Larsen wrote:
>
> > I have received an email response from Syntrillium, with permission to
> > post this:
> >
> > STATEMENT FROM SYNTRILLIUM BEGIN
> >
> > Cool Edit and Cool Edit Pro's RMS calculation are relative
> > to a 0dBFS sine wave, that is, a 0dB RMS reading is equal
> > to a maximum amplitude sine wave. This is probably why some
> > users are getting confused.
> >
> > I think what you were looking for was the value relative to
> > a max amplitude square wave, which is exactly 3.01dB higher,
> > thus the readings would be 3.01dB lower. So the RMS reading
> > of "+2.9" would really be "-0.1" relative to a max amplitude
> > square wave. You will never see the RMS value in Cool Edit
> > go above +3.01dB for 16-bit audio.
> >
> > STATEMENT FROM SYNTRILLIUM END
> >
> > Not my words, posted by permission. Comments, queries to Syntrillium,
> > they get an email CC of this post as a courtesy.
> >
> > Kind regards
> >
> > Peter Larsen
> >
Mike Rivers
In article <3805FCAD...@here.please> n...@here.please writes:
> I'm used to RMS values when used to calculate AC power (eg amplifier
> efficiency), and also when used to discuss audio "loudness" and VU meter
> readings. What I don't understand is what use is being made of CoolEdit's
> RMS reading that makes this RMS discussion a big deal. I just use CE 96
> for editing and audio processing (and it rocks!).
Convenience, mostly. The discussion (at least the part that interests
me) has to do with the ratio of peak to RMS level in recorded music.
This sort of defines the amount of headroom that you need to leave
yourself when mixing.
For a "loud pop music" mix, you want the RMS level to run pretty high,
very close to the peak, even if you have to squash the piss out of it.
This makes a CD that, in a stack, will sound loud. For classical music,
where loud peaks are damn loud enough and there isn't a loudness
competition, the RMS level can be somewhat lower, leaving more mixing
headroom.
Cool Edit Pro has a function that computes the RMS level of a selected
chunk of audio, so it's a convenient tool for evaluating the crest
factor (peak-to-RMS ratio) of various types of music. The issue worth
arguing about is how long a chunk you should look at, and which chunk.
Since a VU meter has an averaging time constant of 100 msec (or is that
300 msec?) and a real VU meter (damn few of those left today) correlates
fairly well with the way we perceive loudness, it makes sense that you
should look at 100 msec chunks. But of course the RMS level of a bunch
of different chunks will certainly be different, so do you really want
to take the average (or RMS?) of a whole lot of chunks sampled
throughout the song to get a good eardrum-average?
--
Mike Rivers (I'm really mri...@d-and-d.com)
Greg
Mike Rivers wrote in message ...
>In article <3805FCAD...@here.please> n...@here.please writes:
>> I'm used to RMS values when used to calculate AC power (eg
>> amplifier efficiency), and also when used to discuss audio
>>"loudness" and VU meter readings. What I don't understand is
>>what use is being made of CoolEdit's RMS reading that makes
>>this RMS discussion a big deal.
The statistics in Cool Edit uses a "RMS window length" to compute the
"Maximum RMS Power" and the "Minimum RMS Power". If you set the "RMS
window length" at 100ms then the program computes the RMS value for
100ms increments. This is a simplified example but it will illustrate
what is happening. If the file is one second it will produce 10 RMS
values for each 100ms of that 1 second sample. The highest one of the
10 RMS values will be displayed in the statistics as "Maximum RMS
Power" and the lowest value will be displayed as "Minimum RMS Power".
The "Average RMS Power" is then computed from all the samples which in
this case is 10. The "Peak Amplitude" is simply the highest point in
the 1 second file. Lets say we have ten RMS samples as above. Now for
each of these samples we can look and find the highest peak in each
samples time window. We now have 10 RMS samples and 10 peak values
associated with them. For the sake of simplicity let the peak for each
sample be 3 times the RMS value (about 9.5dB) so we have:
(note: I am using a fictional voltage since it easier to explain, at
least for me)
RMS PEAK
1) 1 3
2) 1 3
3) 1 3
4) 2 6
5) 3 9
6) 2 6
7) 1 3
8) 1 3
9) 1 3
10) 1 3
If we look at each set we can see that the C.F. is 3 for all the
samples. Cool Edit would report in the statistics that the "Peak
Amplitude" is 9, "Minimum RMS Power" is 1 and "Maximum RMS
Power" is 3. From there the "Average RMS Power" would be calculated
to be 1.55. If using the statistics from Cool Edit we attempt to
extrapolate that the crest factor is the difference between the
"Average RMS Power" to the "Peak Amplitude" we would arrive
at a C.F. of 5.8. To translate that to dB a C.F. of 5.8 is about 15dB.
> The discussion (at least the part that interests
>me) has to do with the ratio of peak to RMS level in recorded music.
>This sort of defines the amount of headroom that you need to leave
>yourself when mixing.
Exactly!
>Cool Edit Pro has a function that computes the RMS level of a
>selected chunk of audio, so it's a convenient tool for evaluating the
>crest factor (peak-to-RMS ratio) of various types of music.
>The issue worth arguing about is how long a chunk you should
>look at, and which chunk.
I agree with you for the reasons you outline below.
>Since a VU meter has an averaging time constant of 100 msec (or is
>that 300 msec?) and a real VU meter (damn few of those left today)
>correlates fairly well with the way we perceive loudness, it makes
>sense that you should look at 100 msec chunks.
Which has been the point I have been trying to make.
> But of course the RMS level of a bunch
>of different chunks will certainly be different, so do you really
>want to take the average (or RMS?) of a whole lot of chunks sampled
>throughout the song to get a good eardrum-average?
NO! You want to know what the peak is for each chunk. I hope I made it
clear with my example that using the average RMS will lead to a
exaggerated requirement of how much headroom you will need.
Now why is the example above a simplification? For 100ms your going to
compute the RMS for about 4400 samples. So if a calculation was done
on samples 1 to 4400 you would not want the next group of samples to
be 4401 to 8800. Instead the second set of samples might be 2 to 4401,
then 3 to 4402 and so on. This is done to produce a continuous
integration of the signal similar to the way we hear.
Greg
Peter Larsen
Mike Rivers wrote:
> Cool Edit Pro has a function that computes the RMS level of a selected
> chunk of audio, so it's a convenient tool for evaluating the crest
> factor (peak-to-RMS ratio) of various types of music. The issue worth
> arguing about is how long a chunk you should look at, and which chunk.
To maintain repeatability I decided to take the average over the entire
song in all examples analysed, it is reasonably fast to so do.
> Since a VU meter has an averaging time constant of 100 msec (or is that
> 300 msec?)
Yup, it is.
> and a real VU meter (damn few of those left today) correlates
> fairly well with the way we perceive loudness, it makes sense that you
> should look at 100 msec chunks. But of course the RMS level of a bunch
> of different chunks will certainly be different, so do you really want
> to take the average (or RMS?) of a whole lot of chunks sampled
> throughout the song to get a good eardrum-average?
You can not compute the area circumscribed by the curve unless you
define a stretch of curve to look at. This is what the integration time,
or the "rms window" size as they call it, is all about. You can then
select a section - or the whole song - to analyse with that integration
time, this is in effect a smoothing that overlooks short variations. So
if you analyse with a long integration time, then short sharp peaks will
be effectively omitted. Not exactly like the way a real physical meter
with that integration time and its additional ballistics problems and
the damping circuit to ameliorate them, but it comes close. However the
integration time you specify and the amount of sound you want analysed
is to different functions.
Somebody asked why it matters if Cool Edit does it in a way that appears
to be at least a dialect of the usual definition of RMS. Let us assume
for a moment a compilation CD, where a policy choice is made to the
effect that all songs shall be lined up level-wise accordingly to the
rms-level measured with a 300 milliseconds RMS window. The masters are
compiled by two different sources, one uses Sound Forge, and the other
uses Cool Edit. Both adjust the volume on entire songs to match the
average of -18 dB relative digital zero that they have been asked to
comply with. Cool Edit however displays the RMS value 3.01 dB larger
than it is by its geometric definition, and Sound Forge follows the
geometric definition. The result is that the actual average level from
the source who used Cool Edit is in fact 3.01 dB lower than specified.
This is detected in mastering, and when the phone rings at the producer,
and mastering says "we have to correct a minor problem, so the bill will
be a bit larger than what we talked about" the producer really can only
say: "OK, go ahead - I'm really sorry for this, I know you are on a
tight schedule, and the guys promised this should be OK, what songs are
too weak?" The next phonecall could be from the producer to the guy that
delivered something other than the specified average level including
perhaps: you fool, sue if you like, but this is gonna come out of your
fee, and it your fee gets negative, then it will be a bill!
In real life the above probably will never happen, with the present
progression in average levels they should become positive relative to
digital zero in approximately three years. The suggested standard for
the medium happens to be some -15 to 18 dB relative to digital zero, so
the example above is realistic, albeit perhaps not really in the world
we live in ...
> Mike Rivers (I'm really mri...@d-and-d.com)
Bill Roberts
Peter Larsen wrote:
>
> Somebody asked why it matters if Cool Edit does it in a way that appears
> to be at least a dialect of the usual definition of RMS. Let us assume
> for a moment a compilation CD, where a policy choice is made to the
> effect that all songs shall be lined up level-wise accordingly to the
> rms-level measured with a 300 milliseconds RMS window.
Dang. I always put the level of songs where they sounded right
to the ear relative to each other. Sometimes that had some
not hitting zero but being a little under. No doubt some songs
averaged higher than others. You know, a ballad that is mostly
acoustic guitars and light orchestration and percussion, then
the next song is a rocker, different average levels.
Times change I guess :(
-- Bill
Peter Larsen
Bill Roberts wrote:
>
> Peter Larsen wrote:
>
> >
> > Somebody asked why it matters if Cool Edit does it in a way that appears
> > to be at least a dialect of the usual definition of RMS. Let us assume
> > for a moment a compilation CD, where a policy choice is made to the
> > effect that all songs shall be lined up level-wise accordingly to the
> > rms-level measured with a 300 milliseconds RMS window.
>
> Dang. I always put the level of songs where they sounded right
> to the ear relative to each other.
This is a grave matter. You're not supposed to do that kind of thing, it
is way too sensible. What would become of the industry if all people
started doing such things.
> Sometimes that had some
> not hitting zero but being a little under. No doubt some songs
> averaged higher than others. You know, a ballad that is mostly
> acoustic guitars and light orchestration and percussion, then
> the next song is a rocker, different average levels.
Exactly, personally I have nothing against the practice of using the
full dynamic range available, the example was an imaginary example, I
don't think it would ever happen quite like that. But it was the
original intention that that was how it should be, and that is why
CD-players got their 2 volts at digital zero output voltage. They are
actually supposed to match average levels on playback with line level
sources providing more compressed material running at a max peak level
of 0.5 to 1 volts.
Know what, I don't think you can suggest any other way of ensuring
pre-matched average level for songs that you can not hear next to
another, admitted the example is imaginary, I'm not into mastering, but
to me it appears to be the next best option, assuming it is all "songs".
If you imagine a compilation with something with only one example with
some real FFF (musical notation correlated) then the overall average
could have to be even lower.
> Times change I guess :(
Nooo, not likely, it was only me in a non-obvious soapbox mode when
concocting that imaginary example ... if they change in the direction of
somebody actually specifying average levels in CD production, then those
specifications will be positive with respect to digital zero ... O;-)
> -- Bill
Mike Rivers
> Dang. I always put the level of songs where they sounded right
> to the ear relative to each other. Sometimes that had some
> not hitting zero but being a little under. No doubt some songs
> averaged higher than others. You know, a ballad that is mostly
> acoustic guitars and light orchestration and percussion, then
> the next song is a rocker, different average levels.
You're adjusting levels based on your aural perception of the crest
factor. But you know, people today like to attach numbers to what they
hear (or what they think that others will hear). Some of them like to
use the numbers to validate their by-ear choices, others don't have the
experience to make decisions by listening so they figure that it's OK if
the computer says it's OK. That's why some people adjust EQ by looking
at a spectrum display.
--
vol...@mindless.com
wrote:
>If anyone has a reason why a 1 second pink noise source isn't a valid test,
>I'd like to hear.
Pink noise is white noise eq:d to reflect the characteristics of the
ear, but you probably knew that already. :)
Since the level is normalised, I don't think there should be a
problem, unless you can vary the "window width" used in the RMWhatever
algorithm.
Regards,
volley
Robert Strand
> On Wed, 13 Oct 1999 13:00:16 +0200, "André Huisman" <new...@usa.net>
> wrote:
>
> >If anyone has a reason why a 1 second pink noise source isn't a valid test,
> >I'd like to hear.
>
> Pink noise is white noise eq:d to reflect the characteristics of the
> ear, but you probably knew that already. :)
Strictly, Pink noise is not EQ'ed to match any characteristic of the ear, like
A-weighting etc.
Its spectral characteristic has constant power per octave bandwidth. It does
sound 'flat'
but in the strict sense flat is a function of the sound level (hence why we have
B,C,D weightings)..
Regards
Rob
Darryl
You were saying......
>Pink noise is white noise eq:d to reflect the characteristics of the
>ear, but you probably knew that already. :)
Is it? I thought it was white noise, but band limited to the audio
spectrum. I thought it was still flat across those frequencies.
__ \ \ __ /__ / \
| | _ \ / / _ \
| | ___ \ / / ___ \
____/_/ _\____|____|_/ _\
Richard D Pierce
<vol...@mindless.com> wrote:
>On Wed, 13 Oct 1999 13:00:16 +0200, "André Huisman" <new...@usa.net>
>wrote:
>
>>If anyone has a reason why a 1 second pink noise source isn't a valid test,
>>I'd like to hear.
>
>ear, but you probably knew that already. :)
For the umpteenth time, pink noise IS NOT WHITE NOISE EQ'D to
reflect ANY characteristics of the ear!
White noise is a random signal whose frequency distribution
results in an equal amount of energy per unit bandwidth. This
means that a 10 Hz wide band of noise centered at 10 kHz has
precisely the same energy as a 10 Hz wie band of noise centered
at 100 Hz.
Pink noise is a random signal whose frequency distribution
results in an equal amount of energy per percentage bandwidth.
This means that a 10% wide band of noise centered at 10 kHz
(which is 1000 Hz wide) will have precisely the same energy as a
10% wide band of noise centered at 100 Hz (which is 10 Hz wide).
This has NOTHING to do with ANY characteristics of the ear
whatsoever.
Pink noise is designed specifically as a signal stimulus for
constant percentage bandwidth analyzers, such as 1/3 octave
real-time analyzers and such.
--
| Dick Pierce |
| Professional Audio Development |
| 1-781/826-4953 Voice and FAX |
| DPi...@world.std.com |
Whatagy
>From: vol...@mindless.com
>Date: Mon, 25 October 1999 01:44 AM EDT
>Message-id: <3813ea18...@nyheter.chalmers.se>
>
>On Wed, 13 Oct 1999 13:00:16 +0200, "André Huisman" <new...@usa.net>
>wrote:
>
>>If anyone has a reason why a 1 second pink noise source isn't a valid test,
>>I'd like to hear.
>
>Pink noise is white noise eq:d to reflect the characteristics of the
>ear, but you probably knew that already. :)
>
>problem, unless you can vary the "window width" used in the RMWhatever
>algorithm.
>
>Regards,
>volley
>
Pink noise is not EQ'ed to replicate the response of the ear. It has a 3
dB/octave filter applied so that it will display a flat line when measured with
a constant percentage bandwidth analyzer. White noise will display a flat
curve when measured with a constant bandwidth analyzer. In order to replicate
the response of the ear weighting curves such as A or C must be applied.
Rodney
Richard D Pierce
>>ear, but you probably knew that already. :)
>
It is not, as explained elsewhere.
>I thought it was white noise, but band limited to the audio
>spectrum. I thought it was still flat across those frequencies.
Nope, again, the difference between white noise and pink noise:
White noise has equal energy per constant unit bandwidth.
Pink noise has equal energy per constant percentage bandwidth.
White noise has a spectrum that if measured with a constant
bandwidth analyzer (like a heterodyne spectrum analyzer or FFT)
results in a flat frequency response across the noise's
bandwidth. If measured with a constant percentage bandwidth
analyzer (such as a 1/3 octave real-time audio analyzer), it has
a frequency response wich rises at +3 dB per octave.
Pink noise has a spectrum that if measured with a constant
bandwidth analyzer (like a heterodyne spectrum analyzer or FFT)
results in a frequency response across the noise's bandwidth
that decreases at -3 dB per octave. If measured with a constant
percentage bandwidth analyzer (such as a 1/3 octave real-time
audio analyzer), it has a frequency response which is flat.
Harvey Gerst
>In article <384601c1....@news.mpx.com.au>,
>Darryl <dkl...@removethisbit.ieee.org> wrote:
>>Hi vol...@mindless.com,
>>
>>You were saying......
>>
>>>Pink noise is white noise eq:d to reflect the characteristics of the
>>>ear, but you probably knew that already. :)
>>
>>Is it?
>
>It is not, as explained elsewhere.
>
>>I thought it was white noise, but band limited to the audio
>>spectrum. I thought it was still flat across those frequencies.
>
>Nope, again, the difference between white noise and pink noise:
>
>White noise has equal energy per constant unit bandwidth.
>
>Pink noise has equal energy per constant percentage bandwidth.
<Great explanation from Dick Pierce snipped>
Lemme see if I can explain it for everybody in even simpler terms:
White noise and pink noise is just all frequencies going at the same
time. If we limit ourself to the range from 20 Hz to 20 kHz, it will be
easier to understand.
Let's look at the first octave of white noise, from 20 to 40 Hz: You
have frequencies of 20 Hz, 21 Hz, 22 Hz, etc., all going with equal
energy over a period of time. 20 to 40 = 20 different frequencies.
Now take a look at the next octave, from 40 to 80 Hz. Here you have 40
different frequencies, all going at equal energy over a period of time.
That's double the number of frequencies going, compared to the first
octave, which results in a 3 dB increase. The third octave (from 80 to
160 Hz) doubles the number of discrete frequencies going at once (to 80)
and you have another 3 dB increase.
Because the number of frequencies doubles with each additional octave,
we hears white noise as hiss, mostly treble. The highest octave has as
much energy as all the other octaves combined. Pink noise counters this
rising 3dB per octave characteristic of white noise with a -3 dB per
octave cut to more accurately reflect equal energy percentages between
octaves.
In other words, with pink noise, the energy from the top octave (10 kHz
to 20 kHz, with 10,000 different frequencies all going at once) will be
the same as the energy from the bottom octave (20 to 40 Hz, with only 20
discrete frequencies).
I hope this didn't make it more confusing. <g>
Harvey Gerst
Indian Trail Recording Studio
http://ITRstudio.com/
David Josephson
>In other words, with pink noise, the energy from the top octave (10 kHz
>to 20 kHz, with 10,000 different frequencies all going at once) will be
>the same as the energy from the bottom octave (20 to 40 Hz, with only 20
>discrete frequencies).
>I hope this didn't make it more confusing. <g>
Owwwww... Harvey, you're gonna turn the rest of Dick's hair white. It's a
valiant effort, but there ain't no such thing as 10,000 different frequencies
going all at once. Maybe this makes sense to someone as a quick explanation of
bandwidth, but please, be sure you put somewhere in there that it isn't really
like that. The bit about pink noise having the same amoung of energy in the
top octave as in the bottom octave is right, but can't you just leave it at
that?
--
David Josephson / Josephson Engineering / San Jose CA / da...@josephson.com
Harvey Gerst
> har...@ITRstudio.com (Harvey Gerst) writes:
>>In other words, with pink noise, the energy from the top octave (10 kHz
>>to 20 kHz, with 10,000 different frequencies all going at once) will be
>>the same as the energy from the bottom octave (20 to 40 Hz, with only 20
>>discrete frequencies).
>
>>I hope this didn't make it more confusing. <g>
>Owwwww... Harvey, you're gonna turn the rest of Dick's hair white. It's a
>valiant effort, but there ain't no such thing as 10,000 different frequencies
>going all at once. Maybe this makes sense to someone as a quick explanation of
>bandwidth, but please, be sure you put somewhere in there that it isn't really
>like that. The bit about pink noise having the same amoung of energy in the
>top octave as in the bottom octave is right, but can't you just leave it at
>that?
Sorry, David, Sometimes I get carried away with trying to oversimplify
and my images and analogies occasionally get flawed. <g> Somebody
should probably just shoot me. But, as with the "measure RMS" thread,
the basic question is still, "why?". If you really need to use this
stuff, you should already know how it works.
I get just as upset when I hear the letters THD, or TIM, or "tube
distortion", "warmth", digital "stairsteps", Nyquist theory, and a dozen
other things that people throw around without understanding. And I'm as
guilty as they are when I step out of the areas I really think I know.
To sum up: pink noise has the same amount of energy in the top octave as
it does in the bottom octave. White noise energy increases by 3 dB per
octave, compared to the previous octave.
Bill Roberts
Harvey Gerst wrote:
> To sum up: pink noise has the same amount of energy in the top octave as
> it does in the bottom octave. White noise energy increases by 3 dB per
> octave, compared to the previous octave.
Well then, I'm sure glad I can't hear up to a gigaherz. OUCH!!!!!
Sort of like the "ultraviolet catastrophe" of pre-quantum
theory...
-- Bill
Bob Smith
>
> White noise has equal energy per constant unit bandwidth.
>
> Pink noise has equal energy per constant percentage bandwidth.
In lieu of sound engineer certification, bits of knowledge such as this
ought to be tatooed on foreheads, and for some genius' on their butts.
Bob Smith
Amateur Recordist
--
Bob Smith - BS Studios
rsm...@bsstudios.com
http://www.bsstudios.com
Harvey Gerst
>Richard D Pierce wrote:
>> White noise has equal energy per constant unit bandwidth.
>> Pink noise has equal energy per constant percentage bandwidth.
>In lieu of sound engineer certification, bits of knowledge such as this
>ought to be tatooed on foreheads, and for some genius' on their butts.
>
>Bob Smith
>Amateur Recordist
I have no room left on my butt, or on my forehead. That's why I get this
stuff wrong all the time. <g>
Key Audio (Kenneth Kareta)
However,
If you REALLY want a rocker to learn anything,
the aforementioned tatoo must be placed on a strippers breast!
--
Ken Kareta owns,
Key Audio Services
(What does a stripper do with her @hole before work? Drops him off at band
practice!)