Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

The Crest of the Wave (reference stuff!)

6 views
Skip to first unread message

Peter Larsen

unread,
Oct 6, 1999, 3:00:00 AM10/6/99
to

Hi Everybody,

I was left wondering a bit when I read André's peak to average data, but
one should not always expect too much from commercial releases. Some
people seem to think the best thing about the digital revolution is
compression in the digital domain. All data are acquired with Cool Edit
96 shareware version. I will crosspost this to rec.audio.pro as it might
interest that newsgroup as well, but please note that I can not be
expected to see follow ups made only to that newsgroup.

The full duration of the actual musical performance is used for all
examples, and I have cut really close to them to get the averaging
valid. The selection of these samples was not made for this specific
purpose, it simply is a reference CD I made for listening tests on
various equipment.

PEAK AMplitude, MAX RMS, AVG RMS, MIN RMS, DYN RANGE and CREST FACTOR
are all specified for 1 ms, 10 ms and 300 ms integration time ("rms
window") for all examples to the extent the distinction is applicable. 1
ms appears reasonable as a definition for acceptable duration of
amplifier clipping that should not be (too) audible.

Please note that I do not want to bet on the accuracy of the MIN RMS
value with a 1 ms "rms window", and thus also not on the accuracy of the
(calculated) dynamic range with this "rms window", they look probable
and I have tried to eliminate obvious erroneous data by cutting closer,
but I just might have goofed with something.

Do not make too many bets in terms of the indication of a physical
instrument with electronics with those integration times - it is NOT
that simple, physical instruments have inertia!

All numeric values are in dB, those with a negative prefix are
referenced to digital zero.

Example 1:

Sound source: New Orleans Band playing "Sweet Georgia Brown", negligible
PA, not vocalist, only amplification is on acoustic pianette and and
clarinet. Microphone pair (4006) was behind the bells of the brass for
practical reasons and because it gives the best balance in that room, a
bar that probably is officially a 50 seater if all are to be seated.
Duration 7:01:34. No clipped samples according to CoolEdit. Please note
that the only information in the dynamic range data for this recording
is that a jazz audience is more noisy than a chamber music audience.

RMS WINDOW 1 millisecond 10 milliseconds 300 milliseconds
CHANNEL LEFT RIGHT LEFT RIGHT LEFT RIGHT
PEAK AM -01.54 -00.83 -01.54 -00.83 -01.54 -00.83
MAX RMS -00.90 -00.10 -03.29 -04.69 -12.03 -13.17
AVG RMS -22.15 -21.84 -22.15 -21.84 -22.15 -21.84
MIN RMS -64.27 -64.08 -50.97 -51.54 -44.46 -42.73
DYN RANGE 62.73 63.25 49.43 50.71 42.92 41.90
CREST FACTOR 20.61 21.01

Example 2:

Sound source: Female vocalist singing Amazing Grace a capella, no PA.
Microphone pair (4006) was set up for the band, so the microphone
distance was some 5+ metres. It would have been nice to know about this
in advance and to be able to suggest where she should have been, but
that's life. Small to medium city church, moderate acoustics, probably
an 800 seater at Christmas. Duration 2:44:79. NO clipped samples
according to CoolEdit. Such events at the start of a concert, expected
to be loud, are what 24 bit resolution is all about.

RMS WINDOW 1 millisecond 10 milliseconds 300 milliseconds
CHANNEL LEFT RIGHT LEFT RIGHT LEFT RIGHT
PEAK AM -16.27 -16.22 -16.27 -16.22 -16.27 -16.22
MAX RMS -17.67 -16.23 -18.51 -17.09 -22.07 -21.59
AVG RMS -38.27 -37.39 -38.27 -37.39 -38.27 -37.39
MIN RMS -87.30 -87.61 -71.99 -71.55 -64.95 -63.93
DYN RANGE 71.03 71.39 55.72 55.33 48.68 47.71
CREST FACTOR 22.00 21.17

Example 3:

Sound source: Gospel choir a capella, no PA, singing something about
washing the water (?). Microphone pair (4006) was set up for the band,
so the microphone distance was some 5+ metres, and it was intentional as
their main function in the concert was background. And there wasn't
anywhere else to place them anyway. Small to medium city church,
moderate acoustics, probably an 800 seater at Christmas. Duration
4:22:08. NO clipped samples according to CoolEdit. Such events at the
start of a concert, expected to be loud, are what 24 bit resolution is
all about.

RMS WINDOW 1 millisecond 10 milliseconds 300 milliseconds
CHANNEL LEFT RIGHT LEFT RIGHT LEFT RIGHT
PEAK AM -15.38 -13.75 -15.38 -13.75 -15.38 -13.75
MAX RMS -16.54 -15.29 -20.02 -19.90 -23.47 -22.93
AVG RMS -36.02 -34.60 -36.02 -34.60 -36.02 -34.60
MIN RMS -86.10 -84.93 -69.74 -73.24 -60.75 -61.90
DYN RANGE 70.72 71.18 54.36 59.49 45.37 48.15
CREST FACTOR 20.64 20.85

Example 4:

Sound source: classic rock band, 2 guitars, fender rhodes, bass, drums,
amplified vocals, not included in this take. Miked up with an XY-pair of
Sennheiser MD421's in Loppen, Christiania, suspended from the (low)
ceiling above the dance floor, some 3 meters from the band. Recorded on
stock Revox A77 on Agfa PE36 in 1975. Loppen is
probably a 400 seater and not very reverberant. This is a version that
was equalized for the known frequency response aberrations of the
microphones and a wee bit of extra treble lift to compensate for the
acoustic shadows jumping around in front of the band. It was a magical
evening, just a one off 'spare time band' jamming, but not a single out
take, and I ran out of tape before they ran out of music (4 full sets!).
General direction of musical style: a la Tim Buckley, but hey, it was
all them good ones through the ages. They just don't DO concerts like
that anymore ... or do they? Duration 9:45:30, no clipped samples
according to CoolEdit, can't remember what the Revox thought of it, but
its VU meters are strong and do not bend needles easily, and as I recall
the transfer it is well inside the linear range of the tape. Please
remember that peak to average ratio is likely to be higher for a close
miked recording!

RMS WINDOW 1 millisecond 10 milliseconds 300 milliseconds
CHANNEL LEFT RIGHT LEFT RIGHT LEFT RIGHT
PEAK AM -01.64 -01.57 -01.64 -01.57 -01.64 -01.57
MAX RMS -00.42 -00.52 -03.56 -04.42 -07.02 -06.61
AVG RMS -14.64 -14.81 -14.64 -14.81 -14.64 -14.81
MIN RMS -65.61 -65.99 -53.52 -55.82 -46.05 -47.57
DYN RANGE 63.97 64.42 51.88 54.25 44.41 46.00
CREST FACTOR 13.00 13.24

Example 5:

Sound source: 4 hand (!) Concert Grand Piano, no name on it, Brahms'
"Akademischer Festouverture". Recorded in Ny Carlsberg Glyptotek,
Copenhagen, Denmark, I reckon it must be a 600-something seater, very
reverberant but not "echoic". Miked up with a pair of 4006's some 3
meters from the piano, sensibly above it. Duration: 10:29:83. No clipped
samples according to CoolEdit. SV3800 agrees.

RMS WINDOW 1 millisecond 10 milliseconds 300 milliseconds
CHANNEL LEFT RIGHT LEFT RIGHT LEFT RIGHT
PEAK AM -01.31 -00.40 -01.31 -00.40 -01.31 -00.40
MAX RMS -01.68 -01.38 -06.89 -05.82 -10.07 -08.32
AVG RMS -19.51 -18.29 -19.51 -18.29 -19.51 -18.29
MIN RMS -92.60 -90.31 -67.83 -64.28 -54.05 -54.25
DYN RANGE 91.29 89.91 66.52 63.88 52.74 53.85
CREST FACTOR 18.20 17.89

Example 6:

Sound source: Danish Concert Band recorded in the Church of our Saviour
on Christianshavn in Copenhagen, Denmark. This church is cathedral
sized, probably a 1000 seater at Christmas, maybe more, and its
reverberation while musical is anything but terse. It is a cross shaped
room, with the band in one of the corsairs, miked up with a pair of AKG
CK452EB with omni capsules, some 4 meter above the floor and 1.5 metres
behind the conductor. The music is the second half of Edward Gregson's
"The Sword and the Crown". Duration 9:37:87. No clipped samples
according to CoolEdit, SV3800 agrees.


RMS WINDOW 1 millisecond 10 milliseconds 300 milliseconds
CHANNEL LEFT RIGHT LEFT RIGHT LEFT RIGHT
PEAK AM -01.65 -02.55 -01.65 -02.55 -01.65 -02.55
MAX RMS -00.50 -01.11 -05.23 -04.20 -08.25 -10.42
AVG RMS -22.22 -23.26 -22.22 -23.26 -22.22 -23.26
MIN RMS -84.29 -86.50 -67.81 -69.14 -62.13 -62.69
DYN RANGE 82.64 83.94 66.16 66.59 60.48 60.14
CREST FACTOR 20.57 20.71

Example 7:

Sound source: Nesa Concert Band, recorded in Gentofte Town Hall, the
closest suburb north of central Copenhagen. Large, reverberant and very
oblong "near echoic" hall with lots of marble, this is not the poorest
suburb and never was. The music is Poul Hart's "Cartoon", a collection
of the audio amateurs greatest from anything from Stravinsky to West
Side Story. The microphones are 4006's, placed approximately 1 meter
behind the conductor and some 3.5 metres above the floor. Duration
9:43:55. No clipped samples according to CoolEdit, SV3800 agrees.


RMS WINDOW 1 millisecond 10 milliseconds 300 milliseconds
CHANNEL LEFT RIGHT LEFT RIGHT LEFT RIGHT
PEAK AM -03.32 -01.95 -03.32 -01.95 -03.32 -01.95
MAX RMS -03.64 -02.00 -08.00 -06.73 -10.71 -09.52
AVG RMS -23.33 -22.65 -23.33 -22.65 -23.33 -22.65
MIN RMS -78.94 -83.40 -66.36 -66.20 -60.79 -60.18
DYN RANGE 75.65 81.45 63.04 64.25 57.47 58.23
CREST FACTOR 20.01 20.70

Example 8:

Sound source: the Jalina Piano Trio, violin, cello and a compact Yamaha
concert grand, mechanically it is an excellent instrument and being
freshly tuned for this concert also sonically just about as capable as
it gets. The recording is made in the marble hall of Oeregaard Gymnasium
(= college, approximately!) in Hellerup, another non poor suburb north
of
central Copenhagen, next to Oeresund. As halls go it is probably a 300
seater, but with a very high curved glass ceiling. It is airy, vibrant
and very much alive, but not at all "echoic", outstanding location for
chamber music. A large membrane absorber made the hall even better for
this concert - a tarpaulin (sure hope this is the right word!) covering
some of the preparations for the annual students theatre performance.
The music is the final allegretto from Dmitri Schostakowitsch's Piano
trio Nr. 2, e-minor, Opus 67. Microphones are 4006 some 2.5 metres above
the floor and some 2 metres from the ensemble. Duration 10:52:06.
Cowardly gain riding of some 1.5 dB was applied as per the suggestion of
the SV3800, silly me, it never got so loud again. Half the piece before
the gain reduction, and half after, so it is probably not an issue in
this context. Cool Edit thinks there could be 2 (two!) clipped samples.
My SV3800 thinks it is worse.


RMS WINDOW 1 millisecond 10 milliseconds 300 milliseconds
CHANNEL LEFT RIGHT LEFT RIGHT LEFT RIGHT
PEAK AM -00.78 +00.00 -00.78 +00.00 -00.78 +00.00
MAX RMS -01.38 -00.32 -05.55 -03.67 -09.20 -07.47
AVG RMS -21.85 -21.10 -21.85 -21.10 -21.85 -21.10
MIN RMS -81.46 -83.17 -67.36 -65.01 -55.67 -54.59
DYN RANGE 80.68 83.17 -66.58 65.01 54.89 54.59
CREST FACTOR 21.07 21.10

Example 9:

Sound source: The Gladsaxe Girls Guard, with the drummer girls standing
in front of the stage immediately below the 4006's some 4 metres above
the floor and 3 metres above the stage of a "squarish" concrete hall -
approximately a 400 seater, fortunately some absorbers/diffusers on the
walls, not a crowded concert. Duration 3:24:45. CoolEdit thinks there
could be 8 clipped samples.


RMS WINDOW 1 millisecond 10 milliseconds 300 milliseconds
CHANNEL LEFT RIGHT LEFT RIGHT LEFT RIGHT
PEAK AM +00.00 -00.27 +00.00 -00.27 +00.00 -00.27
MAX RMS -01.95 -00.43 -03.59 -04.40 -10.45 -10.29
AVG RMS -18.95 -18.88 -18.95 -18.88 -18.95 -18.88
MIN RMS -82.04 -82.53 -63.96 -64.21 -55.81 -54.82
DYN RANGE 82.04 82.26 63.96 63.94 55.81 54.55
CREST FACTOR 18.95 18.61

--
******************************************************************
* This posting handcrafted by Peter Larsen, pla...@teliamail.dk *
* My homepage is at: http://w1.1358.telia.com/~u135801844/ *
******************************************************************


Greg

unread,
Oct 6, 1999, 3:00:00 AM10/6/99
to

Peter Larsen wrote in message <37FA8A9B...@teliamail.dk>...

>I was left wondering a bit when I read André's peak to average data,
>but one should not always expect too much from commercial releases.

I was also, the Average RMS was a bit curious.

>All data are acquired with Cool Edit 96 shareware version.

I too have the shareware version so I looked a little deeper into what
it was doing. First I recorded AJA by Steely Dan. The length of the
file is 4:27. I then did the same statistics that both Andre and Peter
have done and came up with the results:

Peak -4.96
Min RMS -62.6
Max RMS -12.87
Ave. RMS -22.21
C.F. 17dB

By Andre's and Peters way of calculating C.F. (crest factor) we come
up with about 17 dB. The next thing I did was locate the peak and
recalculate the RMS for 100ms around the highest peak. If the math is
right then the RMS min, max, and avg. should all be the same since it
is calculating the RMS for 1 window of 100ms. Well it was not, I
had to adjust the window although it wasn't severe. The results were:

Peak = -5.03
RMS = -17.89
C.F. = 12.86dB

Now as expected the C.F. was lower since I was not using the entire
file. I randomly selected 100ms slices and calculated the RMS, Peak,
and C.F:

Peak -16.88 -9.15 -7.52
RMS -21.6 -21.58 -20.59
C.F. 4.72 12.4 13

After looking at Andre's posting of "average RMS" it seemed that the
RMS was being calculated for 100ms slices of time, added together, and
averaged. It seems more a practical work around due to computer
limitations. To properly calculate the RMS you would need to square 12
or 13 million samples, add them together, divide by the number of
samples, and take the square root. The last thing I did was select the
entire file as was done originally and set the RMS window to the same
length as the song (267000ms) and recalculated the average.

Peak = -7.52
Min RMS = -24.38
Max RMS = -17.63
Avg RMS = -20.59
C.F. = -13 dB

There is obviously something wrong here as I should have gotten
numbers that were similar to the original calculations. To quote Bob
Pease "computers lie". At this point I would suggest that the best way
to view the peak Vs. RMS would be to graph the dB difference against
time. The RMS would be calculated for some time window, perhaps 100ms,
This would be about 4100 samples. The peak would be the largest
absolute value of those 4100 samples. The first sample is then drooped
and the 4101'st sample is added and the RMS is again calculated as
well as the peak. This would be continued to the end of the file and
graphed. I did the above calculations in a spread sheet by importing a
ASCI text file of pink noise. It was very slow, very very slow! The
graph did in fact show a crest factor of about 10 +1/ -2dB as expected
but only allowed me to graph about 3/4 of a second worth of data. If
we were doing live sound and monitoring levels with a averaging type
meter (i.e. VU) then it would be worth knowing what the max expected
peak levels would be relative to the meter. I see no value in a Peak
Vs. "Average RMS" as determined by Cool Edit for an entire piece and
would view them as suspect.

Greg

André Huisman

unread,
Oct 6, 1999, 3:00:00 AM10/6/99
to
Greg <gfre...@slic.com> schreef in berichtnieuws
hgAK3.357$n7....@newsfeed.slurp.net...

>
> Peter Larsen wrote in message <37FA8A9B...@teliamail.dk>...
>
> >I was left wondering a bit when I read André's peak to average data,
> >but one should not always expect too much from commercial releases.

> I was also, the Average RMS was a bit curious.

That's one of the things I have the least problems with actually. One can
calculate the RMS level of ONE sample AND one can calculate the RMS level of
a bunch of samples (say window of 100msec). One can then see this 100msec
RMS window as a new sample and can RMS a bunch of those together again. I
don't see any problem with this procedure. And of course, different window
sizes will give different values for both the lowest and the highest RMS
ratings.

According to the helpfile of Cool Edit Pro, the "average RMS" (probably a
bad choice of words because it indicates the use of averaging while it might
well be that he's actually using the Root Mean of the Squares) is done over
the entire selection, no matter what the window length is set at. Because of
this, one wouldn't expect the "average RMS" to change with different window
settings. I just tested it with the 3 different wav's mentioned earlier and
didn't find any change in the "average RMS", regardless of window setting.
Also (and this seems logically to me at least) there was no change in the
highest peak. I did see some differences in the min/max levels (which again
would be logically to me).

> >All data are acquired with Cool Edit 96 shareware version.

I used Cool Edit Pro. Might well be that CE96 has a different means
(algorithm) which might well be flawed.

> I too have the shareware version so I looked a little deeper into what
> it was doing. First I recorded AJA by Steely Dan. The length of the
> file is 4:27. I then did the same statistics that both Andre and Peter
> have done and came up with the results:

> Peak -4.96
> Min RMS -62.6
> Max RMS -12.87
> Ave. RMS -22.21
> C.F. 17dB

> By Andre's and Peters way of calculating C.F. (crest factor) we come
> up with about 17 dB. The next thing I did was locate the peak and
> recalculate the RMS for 100ms around the highest peak.

I don't see the point. The "peak" is just a single number. If you want to
RMS that, you should do so over 1/44100th of a second (one sample size).

> After looking at Andre's posting of "average RMS" it seemed that the
> RMS was being calculated for 100ms slices of time, added together, and
> averaged.

I tested it with several types of signals (signals I created myself and of
which I could calculate the actual RMS level quite precisely) and found CEP
to be correct for those (pretty simple duty cycled sine waves). As a result
of that "test" I tend to think that (though CEP calls it average) CEP just
Roots the Means of the Squares of the windows in question. Since that is the
way how we derive the RMS level of a window, why would the program use
another method to derive the means of the windows together?

The way I see it: If I RMS a 100msec window and find it's level, I can then
do that for a whole bunch of other windows, treat all those values as if
they were samples (sample rate=10Hz) and do the whole RMS thingie on them as
well. Doesn't involve all that much computing power.

> It seems more a practical work around due to computer
> limitations.

What limitations? Even if CEP were to square every single sample (which only
takes one instruction per sample AND probably 20 bytes to store the
accumulation in and 10 bytes for sample counter) and divide the end result
(the accumulation pointer) by the counter and root that, we would find the
outcome. All this is within the grasp of even the smallest PC probably.

> To properly calculate the RMS you would need to square 12
> or 13 million samples,

ONE at at time of course!

> add them together,

Nope, just add the outcome of the square to the "accumulation" memory. Of
course you would need a bit more than a "double precision" for that but hey,
those are just bytes (and in most PC's memory adresses can contain quite
large numbers if properly programmed).

> divide by the number of samples,

Which was being tracked by the sample counter.

> and take the square root. The last thing I did was select the
> entire file as was done originally and set the RMS window to the same
> length as the song (267000ms) and recalculated the average.

> Peak = -7.52

That's a value I would suspect! Why? Because I can't see HOW the peak would
change if only the window size would change. That's probably caused by a big
glitch somewhere.

> Min RMS = -24.38
> Max RMS = -17.63
> Avg RMS = -20.59
> C.F. = -13 dB

> There is obviously something wrong here as I should have gotten
> numbers that were similar to the original calculations.

Indeed. The PEAK for one would be exactly the same, no matter what the
window size is (for a peak is but a peak is but a single sample's value). In
my limited tests, I have never encountered the PEAK to change (no matter
what the setting) UNLESS the actual investigated data changed (maybe you
investigated a different piece of the wave somewhere along the line?). Same
would go for the Avg RMS. Again, my small test (just now, again with 3
different wav's and windows ranging from 1msec to full wave length size) did
not indicate a change in both PEAK (as I suspected) and Avg RMS. It did show
changes in min and max RMS (something I find very logical).

> To quote Bob Pease "computers lie".

Apart from the buggy P1's numerical unit, most of the time the programs lie
;-)

> I see no value in a Peak
> Vs. "Average RMS" as determined by Cool Edit for an entire piece and
> would view them as suspect.

What's the alternative?

Maybe Peter has a "calorimeter" (sp) in his office so he can check the
outcome of CEP against a known procedure.

Will follow up more when time allows (for I've used CEP also to find out
power distribution in active systems (using actual wave files as stimulus
instead of the dreary pink noise!)).

--
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 ---

Mike Rivers

unread,
Oct 6, 1999, 3:00:00 AM10/6/99
to

Interesting data, Pete and co. I was interested in the crest factor
numbers because I think that what we call "mastering" today (making all
the important parts of a mix audible when played on a variety of
systems) is related to crest factor. I'm used to seeing the number as a
fraction or ratio rather than dB, but it seems that I've heard that
about 4:1 is pretty typical for pop music. Sure enough, the classic
rock band example (13 dB) translates to about 4.5:1.

I'd be curious to see that figure measured on some pop CDs with the
tools that you have available to see how good the correlation is.

--
Mike Rivers (I'm really mri...@d-and-d.com)

Peter Larsen

unread,
Oct 6, 1999, 3:00:00 AM10/6/99
to

Greg wrote:

> Peter Larsen wrote in message <37FA8A9B...@teliamail.dk>...
>

> >I was left wondering a bit when I read André's peak to average data,
> >but one should not always expect too much from commercial releases.
>

> I was also, the Average RMS was a bit curious.

I'm actually still wondering, because results were not as I had expected
them, basically that was what made the worth posting in so extensive a
form. I had expected more of a difference between differing RMS time
windows for one thing, not that it was not there, but it was where I had
not expected it, i. e. in the lowest level value.

[leaving this in just so that we remember the tool used]

> After looking at Andre's posting of "average RMS" it seemed that the
> RMS was being calculated for 100ms slices of time, added together, and

> averaged. It seems more a practical work around due to computer
> limitations.

I don't know the inner workings of CoolEdit, I selected the method of
using it for two reasons: A) it would be comparable to the data André
posted and B) it was a lot simpler and faster - even with a P133 - than
coming up with an accurate test setup for a calorimetric measurement.
That one probably still would be the best way to get a true integration
over the entire item. I know I should have kept those old voice-coils
....

> To properly calculate the RMS you would need to square 12

> or 13 million samples, add them together, divide by the number of
> samples, and take the square root. The last thing I did was select the


> entire file as was done originally and set the RMS window to the same
> length as the song (267000ms) and recalculated the average.

[inserting dataset from above to aid in the comparison]

> [rms window unspec] [rms window length of tune]
> Peak = -7.52 Peak = -4.96
> Min RMS = -24.38 Min RMS = -62.6
> Max RMS = -17.63 Max RMS = -12.87
> Avg RMS = -20.59 Ave. RMS = -22.21
> C.F. = 13 dB C.F. = 17dB


>
> There is obviously something wrong here as I should have gotten
> numbers that were similar to the original calculations.

Hmmm .... you may have a point vis a vis the way the program does it,
BUT absolute peak should absolutely not change, nor should average RMS.
These were constant for the interval of integration times I used: 1 ms,
10 ms, 300 ms. Average RMS also did not change within that interval of
"rms window", so I find it difficult to grasp the concept of the quoted
to datasets being from the same .wav-file, something must have gone
wrong.

> To quote Bob


> Pease "computers lie". At this point I would suggest that the best way
> to view the peak Vs. RMS would be to graph the dB difference against
> time.

Calorimetric is the only alternative that ensures precise determination
of the area below the curve. You point about what method used by
CoolEdit to determine the average RMS may not void it, it doesn't really
matter if it uses a fixed length window and then averages that reduced
dataset to determine the average RMS over the length of the tune, it
would only be a smoothing function and in this context it is irrelevant.

> but only allowed me to graph about 3/4 of a second worth of data. If
> we were doing live sound and monitoring levels with a averaging type
> meter (i.e. VU) then it would be worth knowing what the max expected
> peak levels would be relative to the meter.

Oh, that is simple: it could be anything depending on the conditions.
Physical meters are not good at displaying a single transient. The
headroom to implement above 0 VU becomes a policy decision.
Traditionally 10 dB is used for systems with a non-critical overload
characteristic, such as magnetic tape. For systems with a critical
overload characteristic it should be 15 dB, and the suggested line up
for a DAT to a VU-metered system is that 0 VU should be 15 to 18 dB
below digital zero.

> I see no value in a Peak
> Vs. "Average RMS" as determined by Cool Edit for an entire piece and
> would view them as suspect.

You do not make a credible point voiding the data because there is
something wrong with the data you use to make that point. A few seconds
of logical thought suggests that your point against the validity of Cool
Edits averaging method for the average over the entire tune is AT LEAST
not a major point. My brain is however one of the old mechanical ones,
so the drivebelt may have slipped.

The average value over the length of the tune should be a decent
approximation to the amount of energy actually contained in the tune,
and that information has implications for the required long
term loudspeaker power handling as well as in the context of hearing
safety, in that context with a caveat about impulse related damage, but
simply said it is generally a matter of the total energy transferred. So
it is all about transducer burn out probability.

The difference from the general trend of these data to the general trend
of my old, by now anecdotal, cumulative average data is on the order of
magnitude of 5 dB. That does not constitute an indication of a gross
error voiding it. Cumulative averaging is about the most frequently
occurring level, not about the rms average, but it happens to be a
standardized method to determine average sound pressure level, otherwise
I don't think the explanation of it that I relied on had been in an SPL
meter manual. Another error source is that I did not then have accurate
methods for determining max peak, and didn't care either, because it was
a bonus set of data that came with some acoustic measurements done to
investigate whether a neighbour complaint had any merit. Max peak could
have been determined then by borrowing an oscilloscope, but using the
known limitations of the media involved was good enough for me then, as
it is perhaps not only my experience that max peak capability of any
media will as a general rule be used. I am complete satisfied that I was
quite probably wrong back then.

> Greg

Art Ludwig

unread,
Oct 6, 1999, 3:00:00 AM10/6/99
to
Interesting thread. As posted on my web site, I did a similar calculation,
but using my own Matlab program. So I know exactly what the program is
doing. I read in the actual digitized signal. Peak is simply defined as the
biggest value in the sample (there were quite a few values close to the
peak). RMS power is simply the square root of the sum of the squares of all
of the values, divided by the number of values. I found a ratio of 47:1 or
about 17 dB of peak to RMS power. I also digitally filtered the signal with
a first order filter, crossover 300 Hz, and found half of the power and
higher peaks in the high range. I have only had time for processing one
sample. Regards, Art Ludwig www.thesoundpage.com.

Peter Larsen

unread,
Oct 7, 1999, 3:00:00 AM10/7/99
to

Art Ludwig wrote:
>
> Interesting thread.

It was pre-meditated, i. e. a spin off of a power handling discussion
once upon a time, and also of some hearing safety issues in another
context. Notice the very high average level of example 4, bass and
guitar carry that one, drums are unamplified.

[using matlab]

> of the values, divided by the number of values. I found a ratio of 47:1 or
> about 17 dB of peak to RMS power.

It does appear within the same range.

> I also digitally filtered the signal with
> a first order filter, crossover 300 Hz, and found half of the power and
> higher peaks in the high range.

Interesting.

> I have only had time for processing one sample.

I believe you. These are not examples that I can put on my website, no
way - not even a snippet, they are all NDA stuff, but to me the
advantage of using known recordings made with known, simple technology
outweighed the comparability concern. What I can do and is working on is
to post some screen snapshots of the entire envelope and the frequency
distribution of each full tune. And to get that done in this millennium
I had to settle for doing the latter analysis in mono. Doing that has a
wee bit of merit anyway, because it takes some of the room influence out
....

> Regards, Art Ludwig www.thesoundpage.com.

Peter Larsen

unread,
Oct 7, 1999, 3:00:00 AM10/7/99
to

Hi André,

"André Huisman" wrote:

> > >All data are acquired with Cool Edit 96 shareware version.
>
> I used Cool Edit Pro. Might well be that CE96 has a different means
> (algorithm) which might well be flawed.

It doesn't make development sense not to use the same module.

> > and take the square root. The last thing I did was select the
> > entire file as was done originally and set the RMS window to the same
> > length as the song (267000ms) and recalculated the average.
>
> > Peak = -7.52
>
> That's a value I would suspect! Why? Because I can't see HOW the peak would
> change if only the window size would change. That's probably caused by a big
> glitch somewhere.

Such as in 'not the same sample'. I didn't say it was intentional, but
something went wrong, it could be as simple as selecting a part of a
file, and trying to re-select the same part.

> Indeed. The PEAK for one would be exactly the same, no matter what the
> window size is (for a peak is but a peak is but a single sample's value). In
> my limited tests, I have never encountered the PEAK to change (no matter
> what the setting) UNLESS the actual investigated data changed (maybe you
> investigated a different piece of the wave somewhere along the line?). Same
> would go for the Avg RMS. Again, my small test (just now, again with 3
> different wav's and windows ranging from 1msec to full wave length size) did
> not indicate a change in both PEAK (as I suspected) and Avg RMS. It did show
> changes in min and max RMS (something I find very logical).

MAX PEAK and AVG RMS did not change with the size of "rms window" I
used.

> Maybe Peter has a "calorimeter" (sp) in his office so he can check the
> outcome of CEP against a known procedure.

I don't have one, but it is crude and simple technology: a known
quantity of water with a small surface area, a thermo bottle might be
close enough, a heat element and a thermometer. It would be essential to
use a big amp so as to get a big heat increase, otherwise heat losses
would be too much of an error source.

> Will follow up more when time allows (for I've used CEP also to find out
> power distribution in active systems (using actual wave files as stimulus
> instead of the dreary pink noise!)).

Hmmm ....

> André Huisman

David Wozmak

unread,
Oct 7, 1999, 3:00:00 AM10/7/99
to
Please, if you would... discuss "crest factor".

1) what is it;
2) what does it taste like;
3) would you be upset if you stepped in it;
4) will it be the new marketing-weasel buzzword;
5) discuss nominal vs. boundary values for it, with respect to audible
differences.

Thanks!!!

dwoz

Peter Larsen

unread,
Oct 8, 1999, 3:00:00 AM10/8/99
to

Hi David and Mike,

David Wozmak wrote:
>
> Please, if you would... discuss "crest factor".
>
> 1) what is it;

Lift your right hand, press the red button on the top of your head, thus
engage brain, then take a look at the data. ... O;-) ... OK, in *this*
context it is the buzzword describing the relationship between average
and maximum peak, for simplicity expressed in dB's.

> 2) what does it taste like

Strawberries (Dybdal) with fresh cream and a dash of sugar. And just
like strawberries it is a sensitive produce, easily destroyed by
improper storage.

> 3) would you be upset if you stepped in it

Lots of people step on it every day, and they are not upset.

> 4) will it be the new marketing-weasel buzzword

If so, then I want a fee in a percentage of the turn-over.

> 5) discuss nominal vs. boundary values for it, with respect to audible
> differences.

That is what the post is about. I used homebrewn organic recordings in
spite of the obvious problem with comparability because it would be the
only recordings that actually contained some valid crestfactor
information that would relate to what music actually is like. Otherwise
one never knows what happens to the recording on the way from the venue
to the end consumer, but it quite probably does.

> Mike Rivers wrote:

Nice to find this quote of you,

> > Interesting data, Pete and co. I was interested in the crest factor
> > numbers because I think that what we call "mastering" today (making all
> > the important parts of a mix audible when played on a variety of
> > systems) is related to crest factor.

It probably always was, but only the disc-cutting mastering engineer
really cared about it, if he didn't have any problems, nor would anybody
else. Keeping all parts of the mix audible of course goes back to having
them in decent proportions to begin with. An observation I once made
what that a good mix is characterized by the absolute peaks of the
instruments being equally strong, with some exceptions applicable for
'high rms instruments' and - depending on function in the piece in
question - keyboards, specifically piano.

> > I'm used to seeing the number as a
> > fraction or ratio rather than dB, but it seems that I've heard that
> > about 4:1 is pretty typical for pop music. Sure enough, the classic
> > rock band example (13 dB) translates to about 4.5:1.

Please remember that bass and guitars carry that one, the drums are
unamplified, I would expect close miking to result in higher crest
factor. Snapshots of the envelop and the frequency distribution will
become available on my website in some time, unit of time = days, not
weeks.

> > I'd be curious to see that figure measured on some pop CDs with the
> > tools that you have available to see how good the correlation is.

I'm not going to do that, this machine DAE's at speed 0.56 - it probably
would help to swap the cd-rom drive with the secondary harddisk on the
other IDE channel .... I do in fact have CD that it could be fun to
check to see HOW POOR it is, but basically this is the DIY part of it.
Anybody can get hold of a DC at the equivalent of USD 9.95, the
difficult is to come up with recordings made with only 2 microphones and
1 tape recorder and nothing else. Not that there are not released CD's
that are made like that, but the difference is KNOWING how it is
recorded instead of guessing.

> > Mike Rivers (I'm really mri...@d-and-d.com)

--

Mike Rivers

unread,
Oct 8, 1999, 3:00:00 AM10/8/99
to

> Please, if you would... discuss "crest factor".

> 1) what is it;

It's the peak to average ratio.
> 2) what does it taste like;

Mint

> 3) would you be upset if you stepped in it;

Only if I slipped on it

> 4) will it be the new marketing-weasel buzzword;

I doubt it, though a couple of years ago when Bob Katz was looking for
a slogan to put on buttons for people to wear at the AES show to
express a distaste for music recorded with little dynamic range, I
suggested (too late for the buttons) "Support Amnesty for Crest
Factors".

> 5) discuss nominal vs. boundary values for it, with respect to audible
> differences.

Huh?

If you have a high crest factor, your VU meters are reading around -20
most of the time, while the overload light on your DAT is flashing
nearly all the time. The music sounds pretty good, but you have to
turn up the volume if you want to hear it very loud. If you have a low
crest factor, the VU meters read around 0 and the overload light never
flashes. The music sounds awful, but it's loud even at a low setting
of the volume control.


--
I'm really Mike Rivers (mri...@d-and-d.com)

André Huisman

unread,
Oct 8, 1999, 3:00:00 AM10/8/99
to
Peter Larsen <pla...@teliamail.dk> schreef in berichtnieuws
37FA8A9B...@teliamail.dk...

> I was left wondering a bit when I read André's peak to average data, but
> one should not always expect too much from commercial releases. Some
> people seem to think the best thing about the digital revolution is
> compression in the digital domain.

I just "checked out" a few new Top-40 releases.

There was one I just couldn't deprive you off:

Melanie C - Goin' Down.

Of course you can say that you don't want to have anything to do with crap
like this but it's this crap that _I_ actually have to PA.

Anyway, the numbers (window=100ms):

Peak Amplitude: 0dB (left) 0dB (right)
Minimum RMS power: -13.65dB (left) -16.38dB (right)
Maximum RMS power: -2.31 dB (left) -2.66dB (right)
Average RMS power: -5.52dB (left) -6.09dB (right)

No need to say how it sounds? It sounds like total crap. About the worst
form of audio torture I've ever seen. So now I have a song that has a crest
factor which is SMALLER than that of PINK NOISE. Pity me for having to PA
this kind of garbish. Maybe they should get a reward or something? I guess I
won't see the 0dB level on my (10ms peak meters) mixer with this song ;-)

Peter Larsen

unread,
Oct 8, 1999, 3:00:00 AM10/8/99
to

"André Huisman" wrote:

> Melanie C - Goin' Down.
>
> Of course you can say that you don't want to have anything to do with crap
> like this but it's this crap that _I_ actually have to PA.

Well, she looks kinda pretty - would strong glasses and earplugs help?
... O;-)

> Anyway, the numbers (window=100ms):

The example I would have included is a "best of" album with some Björn
Afzelius songs, probably quite similar dynamics. When I can get my Denon
1520 to work (it only works on a cold start, on the next CD it gets lost
... ) I usually DA via my SV3800GT - the 1520 DA is very good, the
SV3800 is better, and I'm not comparing analogue stages for some subtle
reason - and I almost for an instance thought the peakmeter circuit was
defective in it. I really wondered whether that could be to his liking,
because the early stuff he recorded with Hoola Bandoola Band is so good
- nothing much that could be done wrong with that studios gear .... O;-)

> So now I have a song that has a crest
> factor which is SMALLER than that of PINK NOISE. Pity me for having to PA
> this kind of garbish.

That of course voids some powerhandling assumptions, and I just thought
I had something to base them on - including frequency distribution of
max peak power requirement. I'm working on a website update that will
include the envelopes and the frequency content displays right now.

> Maybe they should get a reward or something? I guess I
> won't see the 0dB level on my (10ms peak meters) mixer with this song ;-)

Ah - it dawns on me that she does a playback show? - actually this
reminds me about by DBX 117/119 two way expander contraption project for
VOA, but it is no longer available on cable FM, awful sound but great
music and some occasional live transmissions. Ah well - the users have
voted, and voted some new commercial stations in. The vote of course
only including the direct customers of the cable supplier, and not the
indirect (90 percent!) customers.

> André Huisman

soun...@ix.netcom.com

unread,
Oct 9, 1999, 3:00:00 AM10/9/99
to
On Fri, 8 Oct 1999 13:59:45 +0200, "André Huisman" <new...@usa.net>
wrote:

>No need to say how it sounds? It sounds like total crap. About the worst
>form of audio torture I've ever seen.

I think there might be worse. Try a vinyl copy of Deep Purple's "In
Rock", arguably the most compressed recording ever released. There's
less than 1 db of movement with ballistic meters.


Patrick Callahan
soun...@themothership.net
www.themothership.net

Ton Willekes

unread,
Oct 9, 1999, 3:00:00 AM10/9/99
to

soun...@ix.netcom.com heeft geschreven in bericht

>I think there might be worse. Try a vinyl copy of Deep Purple's "In
>Rock", arguably the most compressed recording ever released. There's
>less than 1 db of movement with ballistic meters.
>

How about: Tears for Fears: ''Songs from the Big Chair'' album

>Patrick Callahan
>soun...@themothership.net
>www.themothership.net

André Huisman

unread,
Oct 9, 1999, 3:00:00 AM10/9/99
to
Peter Larsen <pla...@teliamail.dk> schreef in berichtnieuws
37FD1CF9...@teliamail.dk...

> I'm not going to do that, this machine DAE's at speed 0.56 - it probably
> would help to swap the cd-rom drive with the secondary harddisk on the
> other IDE channel ....

DAE at 0.56..... HA.

When stuck with IDE, get either an Afreey 50/56 (DAE ~22 speed) or an Asus
40 (or higher; DAE ~14 speed) (there are others but I've forgotten them).
Both of them do perfect DAE and have no re-positioning errors (number one
cause for synchronisation glitches).

Better (IMO): Get one of those cheap SCSI carts and treat yourself to an
Ultraplex40. DAE at 24+ speed without ever ever losing a sample. My plex
doesn't even have problems with CD's that have scratches (test disc) upto
1.6mm (using 4 speed DAE for this test BTW). And that's another good point
about the Plex. If you have problems (old and damaged discs) reading the
disc, you can set the DAE speed to a lower setting.

Peter Larsen

unread,
Oct 10, 1999, 3:00:00 AM10/10/99
to

"André Huisman" wrote:
>
> Peter Larsen <pla...@teliamail.dk> schreef in berichtnieuws

> 37FA8A9B...@teliamail.dk...


>
> > I was left wondering a bit when I read André's peak to average data, but
> > one should not always expect too much from commercial releases.

Obviously also not from software, I'm wondering a great bit less now
that an error in programme logic of Cool Edit is proven beyond any
doubt. My bewilderment seems to have been highly appropriate.
Just to be overcomplete here is another beautiful proof that something
goes wrong, and substantiating my theory about this, namely that Cool
Edit displays the peak value of the equivalent sinewave that would have
produced the RMS value it calculates.

To be ridiculously overcomplete - and that can be a very good idea - as
well as because the concept off typical for rock music worked itself
into this, I decided to supplement the data by an investigation of EMI
Chrysalis 7243 8 54482 2 5, Runrig: "the best of runrig - long distance"
record 1 of 2 in the box. Tracks to investigate were randomly selected
by Audiograbber, and are 1, 2, 7, 10, 11, 12, 13, 14 and 17. Track 17 is
a live track, so it was kept for itself, also because it has some unique
properties. To get the grand total, I removed obvious man made fade outs
and fade ins, and replaced them with a 1 second linear fade of the
appropriate kind, summed the lot to mono to save time in frequency
analysis, normalized to 100 percent and pasted the lot together like I
did with that Hollywood Edge sampler. The min RMS data omitted, because
the min RMS in this context is man made, and not a property of the
music.

Statistics for Runrig's studio productions:

300 ms:

PEAK AM 0 dB
CLIPPED SAMPLES 506 ; They aren't, they are limited.
DC OFFSET -.002 % ; did they get the polarity wrong?
MAX RMS -7.05
AVG RMS -12.33

10 ms:

MAX RMS -1.04 dB
AVG RMS -12.33

1 ms

MAX RMS 2.59 dB ; here we go again, Cool Edit finds life
AVG RMS -12.33 dB : beyond digital zero!

Mind you, this is a very good record, equipment demonstration quality
stuff most people would cherish to use, but one conclusion gets
unavoidable. It must make perfect sense to subtract 3 dB from any
statement about RMS value that Cool Edit comes up with. Consequently I
will do that when I combine all of this for my website. If anybody can
come up with reasons to not so do, and then state that a probably
correction of a gross error ONLY in Cool Edit's rms-calculation has been
applied to the data listed, I would appreciate to know that before I put
it up, thank you!

Syntrillium support gets a CC to facilitate commenting in the thread, it
appears highly probable that they may wish to so do. Kinda funny to
prove bugs that alpha testing on software that was released 3 full years
ago should have shown them ... O;-) ...

> André Huisman

Mike Rivers

unread,
Oct 10, 1999, 3:00:00 AM10/10/99
to

In article <7tnb5d$8r2$1...@news1.xs4all.nl> new...@usa.net writes:

> > I'm not going to do that, this machine DAE's at speed 0.56 - it probably
> > would help to swap the cd-rom drive with the secondary harddisk on the
> > other IDE channel ....
>
> DAE at 0.56..... HA.
>
> When stuck with IDE, get either an Afreey 50/56 (DAE ~22 speed) or an Asus
> 40 (or higher; DAE ~14 speed) (there are others but I've forgotten them).
> Both of them do perfect DAE and have no re-positioning errors (number one
> cause for synchronisation glitches).

What are you guys talking about? Surely not crest factor.

Peter Larsen

unread,
Oct 10, 1999, 3:00:00 AM10/10/99
to

Mike Rivers wrote:
>
> In article <7tnb5d$8r2$1...@news1.xs4all.nl> new...@usa.net writes:
>
> > > I'm not going to do that, this machine DAE's at speed 0.56 - it probably
> > > would help to swap the cd-rom drive with the secondary harddisk on the
> > > other IDE channel ....
> >
> > DAE at 0.56..... HA.

As DAE is not the purpose of this machine, I simply do not care, just
moving the CD-rom drive would probably solve the problem and so what?
The advice is of course appreciated, and I will have it in mind at an
eventual hardware update.

> What are you guys talking about? Surely not crest factor.

Nah, about Digital Audio Extraction from a CD-rom drive, sorry - I
should have kept that out of this thread, but it was the way the data
got into the computer ...

> I'm really Mike Rivers (mri...@d-and-d.com)

--

Peter Larsen

unread,
Oct 15, 1999, 3:00:00 AM10/15/99
to

Hi Patrick,

soun...@ix.netcom.com wrote:

> I think there might be worse. Try a vinyl copy of Deep Purple's "In
> Rock", arguably the most compressed recording ever released. There's
> less than 1 db of movement with ballistic meters.

Hmmm ... the world sure looks different through this ISP's newsserver
...

Nothing promised, but I have the record, and might include it, but it
will have to be analyzed via the sound card input .... I can't really
remember how it sounds, but it was not actively on the forefront of my
mind when I compiled materials for some reference CD's for listening
tests.

> Patrick Callahan

0 new messages