Dick Pierce wrote:

This statement, all by itself, shows the patent absurdity of "Lords"
position, illustrating how technically inept he is. The terms
"average RMS" and "maximum RMS" are meaningless: RMS is RMS. There
is but a single RMS figure for a sognal computed over the interval.
There is no "maximum" or "avergae" RMS.

Not quite true. In CEP, for example, one can specify a
window of evaluation and it will report the maximum RMS
value over that width window (50 ms is the default) within
the file.


Bob
--

"Things should be described as simply as possible, but no
simpler."

A. Einstein

"Bob Cain" wrote in message


Dick Pierce wrote:

This statement, all by itself, shows the patent absurdity of "Lords"
position, illustrating how technically inept he is. The terms
"average RMS" and "maximum RMS" are meaningless: RMS is RMS. There
is but a single RMS figure for a sognal computed over the interval.
There is no "maximum" or "avergae" RMS.

Not quite true. In CEP, for example, one can specify a
window of evaluation and it will report the maximum RMS
value over that width window (50 ms is the default) within
the file.

I see no conflict here. Piece said that there is but a single RMS figure
for a signal computed over the interval. What CEP does is chop the user's
interval into smaller intervals the size of the window, and then report RMS
values for selected windows.

I don't get why people are talking about RMS values in the context of CEP
and normalization when it is so clear that CEP bases normalization on the
largest magnitude any single sample in the user's interval.

Bob Cain wrote in message ...
Dick Pierce wrote:

This statement, all by itself, shows the patent absurdity of "Lords"
position, illustrating how technically inept he is. The terms
"average RMS" and "maximum RMS" are meaningless: RMS is RMS. There
is but a single RMS figure for a sognal computed over the interval.
There is no "maximum" or "avergae" RMS.

Not quite true. In CEP, for example, one can specify a
window of evaluation and it will report the maximum RMS
value over that width window (50 ms is the default) within
the file.

No doubt, and that is entirely consistent with my statement:

"There is but one RMS figure for the signal computed over
the interval."

Please note the phrase "over the interval," congruent with the width
of the evaluation window.

Regardless of whether you use the qualifier "window width" or "over
the interval," there is one and only one RMS figure for the data.
If Lord HuffenPuffer is making statements about "average RMS" and
"maximum RMS," he is either utterly clueless as to the principles
involved or is being a deliberately destructuve troll.

Arny Krueger wrote:

I see no conflict here. Piece said that there is but a single RMS figure
for a signal computed over the interval. What CEP does is chop the user's
interval into smaller intervals the size of the window, and then report RMS
values for selected windows.


Not sure what you mean by "interval" here. The Analyze
funtion runs a sliding window of a specifiable width over
the selected region and samples the RMS value within the
sliding window to report it's "Maximum" and "Minimum"
values.

I don't get why people are talking about RMS values in the context of CEP
and normalization when it is so clear that CEP bases normalization on the
largest magnitude any single sample in the user's interval.

Unless you use it's "Group Normalize" function accessable in
2.x from the multitrack view. The "Analyze" function
available in track view has always had "Average", "Maximum",
"Minimum", and "Total" RMS values in its report. I'm not
sure the distinction between "Average" and "Total".


Bob
--

"Things should be described as simply as possible, but no
simpler."

A. Einstein

"Bob Cain" wrote ...
Dick, have you actually used CEP's "Waveform Statistics"
function (sorry, Arny, I called it "Analyze" in my response
to you)? What you say is not correct. The function runs a
window of a specifiable width over the overall region that
is selected and remembers the maximum and minimum values
seen in that window. There is a separate value reported
which is the single value that you refer to which applies to
the whole selected region.

50mS is the default interval.
I wonder if the average (RMS) of all the 50mS averages is the
same as the average over the entire file?

Richard Crowley wrote:

"Bob Cain" wrote ...
Dick, have you actually used CEP's "Waveform Statistics"
function (sorry, Arny, I called it "Analyze" in my response
to you)? What you say is not correct. The function runs a
window of a specifiable width over the overall region that
is selected and remembers the maximum and minimum values
seen in that window. There is a separate value reported
which is the single value that you refer to which applies to
the whole selected region.

50mS is the default interval.
I wonder if the average (RMS) of all the 50mS averages is the
same as the average over the entire file?

This has puzzled me. "Average" and "Total" are usually
pretty close but they do differ. I think, but am not sure,
that "Average" is just the average of all the windows while
"Total" is what we usually measure as the RMS level of a
region. I'm not really sure how to interpret the
difference.


Bob
--

"Things should be described as simply as possible, but no
simpler."

A. Einstein

"Bob Cain" wrote in message


Arny Krueger wrote:

I see no conflict here. Pierce said that there is but a single RMS
figure for a signal computed over the interval. What CEP does is
chop the user's interval into smaller intervals the size of the
window, and then report RMS values for selected windows.

Not sure what you mean by "interval" here. The Analyze
function runs a sliding window of a specifiable width over
the selected region and samples the RMS value within the
sliding window to report it's "Maximum" and "Minimum"
values.

The RMS measurement interval is the width of the window, right?

I don't get why people are talking about RMS values in the context
of CEP and normalization when it is so clear that CEP bases
normalization on the largest magnitude of any single sample in the
user's interval.

Unless you use it's "Group Normalize" function accessible in
2.x from the multitrack view.

The Help file seems to say that Group Normalize still bases its operation
on peak values.

The "Analyze" function
available in track view has always had "Average", "Maximum",
"Minimum", and "Total" RMS values in its report. I'm not
sure the distinction between "Average" and "Total".

I can't see where the help file sheds any light on that question. My
understandings suggest that they should be the same, but they clearly aren't
often the same with real world signals.

BTW, thanks for the stimulus to read the docs, even if not all my questions
were answered.

Bob Cain wrote in
:



Dick, have you actually used CEP's "Waveform Statistics"
function (sorry, Arny, I called it "Analyze" in my response
to you)? What you say is not correct. The function runs a
window of a specifiable width over the overall region that
is selected and remembers the maximum and minimum values
seen in that window. There is a separate value reported
which is the single value that you refer to which applies to
the whole selected region.

So the program computes RMS within a window, shifts the window (with or
without overlap) and repeats. So each interval has one unique RMS value,
no? This would still agree with what Mr. Pierce is saying.

Tim

On 6 Jul 2003 14:21:29 -0700, Dick Pierce wrote:

If Lord HuffenPuffer is making statements about "average RMS" and
"maximum RMS," he is either utterly clueless as to the principles
involved or is being a deliberately destructuve troll.

Which is more or less where we came in with the arse whipping he gave
MFSL ;-)

Browntimdc wrote:

Bob Cain wrote in
:



Dick, have you actually used CEP's "Waveform Statistics"
function (sorry, Arny, I called it "Analyze" in my response
to you)? What you say is not correct. The function runs a
window of a specifiable width over the overall region that
is selected and remembers the maximum and minimum values
seen in that window. There is a separate value reported
which is the single value that you refer to which applies to
the whole selected region.

So the program computes RMS within a window, shifts the window (with or
without overlap) and repeats. So each interval has one unique RMS value,
no? This would still agree with what Mr. Pierce is saying.

Perhaps I misunderstood but my interpretation of what he
said was that the idea of a minimum and maximum RMS value
have no meaning. I'm just saying that it can be given a
meaning by assigning an RMS value to each point that is the
the RMS value of a window centered on that point. In that
case minima and maxima can be discussed and have intuitive
as well as utility value.


Bob
--

"Things should be described as simply as possible, but no
simpler."

A. Einstein

Martin Tillman wrote:

CEP analyses a file by looking at specific time intervals (default 50ms)
and calculating the RMS power for that interval. Someone might find
that useful. It then reports the max and min values it found - meaning
the max and min for the 50ms intervals. If you want to normalise your
file based on the value of 50ms of it, please feel free.

Then it takes all the RMS values for the file and averages them. This
gives the average of all the values (just to be clear...). It also
reports the total RMS power of the file, which is not the same as the
average of all the values.

Normalize uses similar procedures and reports back its own Maximum RMS
level as the "level" of the song - and *that's* the level that it uses
as a guide for adjusting loudnesses, not the Average RMS level as
everyone has been assuming to be the case.

Myke

--

-================================-
Windows...It's rebootylicious!!!
-================================-

In rec.audio.tech Lord Hasenpfeffer wrote:
: and the range is right there waiting for you to use it - I say, by all
: means, do.

But that is done by saturating the original recordings, long before
mastering. All the normalizing in the world is not going to increase
the dynamic range of the recording.

Scott

sgordon wrote:
In rec.audio.tech Lord Hasenpfeffer wrote:
: and the range is right there waiting for you to use it - I say, by all
: means, do.

But that is done by saturating the original recordings, long before
mastering. All the normalizing in the world is not going to increase
the dynamic range of the recording.

You are correct.

Myke

--

-================================-
Windows...It's rebootylicious!!!
-================================-

"Lord Hasenpfeffer" wrote in message
...
Martin Tillman wrote:

CEP analyses a file by looking at specific time intervals (default 50ms)
and calculating the RMS power for that interval. Someone might find
that useful. It then reports the max and min values it found - meaning
the max and min for the 50ms intervals. If you want to normalise your
file based on the value of 50ms of it, please feel free.

Then it takes all the RMS values for the file and averages them. This
gives the average of all the values (just to be clear...). It also
reports the total RMS power of the file, which is not the same as the
average of all the values.

Normalize uses similar procedures and reports back its own Maximum RMS
level as the "level" of the song - and *that's* the level that it uses
as a guide for adjusting loudnesses, not the Average RMS level as
everyone has been assuming to be the case.

The CEP normalize function is based on peak levels - the sample in the data
being normalized with the largest magnitude.

Arny Krueger wrote:


The CEP normalize function is based on peak levels - the sample in the data
being normalized with the largest magnitude.

Arny, CEP 2.x has a "Group Normalize" function available
from the multitrack view which works on multiple files and
utilizes RMS levels.


Bob
--

"Things should be described as simply as possible, but no
simpler."

A. Einstein

Arny Krueger wrote:

As far as I can tell this is irrelevant to the discussion at hand which
relates to 2-channel MP3s. I see it as just one of many red herrings that
were dragged in, resulting in a complex and inconclusive discussion of a
fairly simple problem.

And MiniDiscs...

Myke

--

-================================-
Windows...It's rebootylicious!!!
-================================-

Arny Krueger wrote:

"Bob Cain" wrote in message
...

Arny Krueger wrote:

The CEP normalize function is based on peak levels - the sample in the
data
being normalized with the largest magnitude.

Arny, CEP 2.x has a "Group Normalize" function available
from the multitrack view which works on multiple files and
utilizes RMS levels.

As far as I can tell this is irrelevant to the discussion at hand which
relates to 2-channel MP3s. I see it as just one of many red herrings that
were dragged in, resulting in a complex and inconclusive discussion of a
fairly simple problem.

Perhaps the thread is too long for your limited attention
span, and perhaps it has wandered about some, but initially
it was about normalizing groups of CD tracks prior to making
MP3's from them. The question of basing that on RMS levels
has been relevant from the beginning and I'm pointing out
how CEP can do that (which you said it couldn't.) Bad day,
Arny?


Bob
--

"Things should be described as simply as possible, but no
simpler."

A. Einstein

"Paul Dormer" wrote in message


Normalizing a bunch of tracks together isn't a bad idea, but I would
discourage newbies from normalizing individual tracks - software just
doesn't understand the difference between ballads and trash metal..

IOW, normalizing is a poor choice as a means to match perceived loudness.

Matching perceived levels based on RMS values is generally more effective
than using peak levels. However, RMS measurements don't consider spectral
balance, which is very important to perceptions of perceived loudness.

Could I enter this discussion, or is private?

Today, rock and pop music is largely electronic and composed in the
mixing room. It's also compressed to the point of near death. How
one handles this is largely a matter of taste. Since it's already
been clipped, smashed and otherwise manhandled almost any method of
volume adjustment will work just fino.

In the case of classical music, I imagine a perfect recording is the
starting point--no compression, clipping, and the level of the
original is adjusted so that it has a full dynamic range, but as
little as possible wasted at the peak. This works well on the
original, but makes for some awkwardness in the release version. It's
entirely possible that a full symphony orchestra will have more than
one peak level: The apparent maximum output, and also the absolute
instantaneous peak that could easily run 10's of db above the apparent
maximum level, but only for a few milliseconds.

The human ear/brain is highly nonlinear. The shorter a peak is, the
less apt the brain is to give it full value. So, the solution is to
compress these very short peaks so that there's room left to bring up
the apparent level to where it sounds much the same as other
recordings.

A very good article on this subject is entitled "How can the headroom
of digital recordings be used optimally?" Written by Manfred Krause
and Holger Petersen, it's in the Journal of the Audio Engineering
Society, Vol 38, No.11, dated November 1990.

Norm Strong




"Bob Cain" wrote in message
...


Arny Krueger wrote:

"Bob Cain" wrote in message
...

Arny Krueger wrote:

The CEP normalize function is based on peak levels - the
sample in the
data
being normalized with the largest magnitude.

Arny, CEP 2.x has a "Group Normalize" function available
from the multitrack view which works on multiple files and
utilizes RMS levels.

As far as I can tell this is irrelevant to the discussion at hand
which
relates to 2-channel MP3s. I see it as just one of many red
herrings that
were dragged in, resulting in a complex and inconclusive
discussion of a
fairly simple problem.

Perhaps the thread is too long for your limited attention
span, and perhaps it has wandered about some, but initially
it was about normalizing groups of CD tracks prior to making
MP3's from them. The question of basing that on RMS levels
has been relevant from the beginning and I'm pointing out
how CEP can do that (which you said it couldn't.) Bad day,
Arny?


Bob
--

"Things should be described as simply as possible, but no
simpler."

A. Einstein

Paul Dormer wrote:

Normalizing a bunch of tracks together isn't a bad idea, but I would
discourage newbies from normalizing individual tracks - software just
doesn't understand the difference between ballads and trash metal..

This is an excellent point. I remember when I got to my John Denver CDs
and Normalized them in my usual way. "Take Me Home, Country Roads"
sounded painfully wrong to my ears after that. Needless to say, I redid
those files at a much more conservative level.

Myke

--

-================================-
Windows...It's rebootylicious!!!
-================================-

On Fri, 11 Jul 2003 23:19:42 -0500, Lord Hasenpfeffer wrote:

Paul Dormer wrote:

Normalizing a bunch of tracks together isn't a bad idea, but I would
discourage newbies from normalizing individual tracks - software just
doesn't understand the difference between ballads and trash metal..

This is an excellent point. I remember when I got to my John Denver CDs
and Normalized them in my usual way. "Take Me Home, Country Roads"
sounded painfully wrong to my ears after that. Needless to say, I redid
those files at a much more conservative level.

Did you set your normalize value to 0 ? That's where Denver sounds
best.

You're welcome.

George W. wrote:

Did you set your normalize value to 0 ? That's where Denver sounds
best.

You're welcome.

Are you implying that John Denver's music sucks big green donkey dongs?

Myke

--

-================================-
Windows...It's rebootylicious!!!
-================================-

Lord Hasenpfeffer wrote:

Bob Cain wrote:

Perhaps the thread is too long for your limited attention
span, and perhaps it has wandered about some, but initially
it was about normalizing groups of CD tracks prior to making
MP3's from them.

Actually, that's not entirely true - as I also do a lot of MiniDisc
recording which is also lossy although to a much lesser extent than with
common MP3s. That's why the thread in the other NG says "(With Lossy)"
instead of "(With MP3)".

That's right, it was for ATRAC rather than MP3. Chalk it up
to my limited attention span. :-)


Bob
--

"Things should be described as simply as possible, but no
simpler."

A. Einstein

While we're on the subject of "normalizing" (not responding to any previous
msg in particular)...

Can anyone recommend a freeware/shareware application for the Macintosh that
can do this?

Thanks,
- John

Geoff Wood wrote:

Almost any audio software should have this as one of it's primary features.

No, no... Normalize is in a class all by itself!

Myke

--

-================================-
Windows...It's rebootylicious!!!
-================================-

While we're on the subject of "normalizing" (not responding to any previous
msg in particular)...

Can anyone recommend a freeware/shareware application for the Macintosh that
can do this?

Thanks,
- John


I think that Pro Tools Free can do this.
Richard H. Kuschel
"I canna change the law of physics."-----Scotty

In article ,
Ken Bouchard wrote:
OK, since Nyquist was mentioned, I'll go ahead and ask this:
According to Nyquists theorem, a waveform only has to be sampled at a rate
TWICE it's highest frequency, right?

Wrong, it's more than twice.

Hence, we sample most audio waves (for
CD anyway) at 44.1 KHZ because thats about TWICE the highest frequency we
humans can hear, right?
OK, let's take a waveform that's got a sound in it with a frequency way up
there like at 22 KHZ. (I've got REAL good hearing:-)
How can that high frequency be faithfully reproduced if it's only being
sampled a couple times?

Because if your waveform is at 22 kHz, any deviations from that
22 kHz sine wave MUST be at multiples of 22 kHz, and anything at
22.05 kHz and above MUST be eliminated by the prerequisite
filtering any sampling system must have.

Let's look at it more fundamentally. A 44.1 kHz system MUST have
its bandwidth limited to less than 22.05 kHz. This is simply the
correlary of saying that you must sample at more than twice a
waveform's frequency. If the bandwidth is limited to 22.05 kHz,
only one kind of 22 kHz waveform can possibly exist: a 22 kHz
sine wave. You can't have a 22 kHz square wave or triangle wave
or perfect tone burst because ALL of those waveforms have
components outside of the 22.05 kHz bandwidth that this system
has.

Given that, the number of points needed to PERFECTLY represent a
22 kHz SINE waveform with PERFECT fidelity is only slightly more
tha 2 per cycle. Only one sine wave can pass through those
points. Only one, and that's the original waveform. That's
essentially the non-methematical statement of the mathematical
proof of the sampling theorem.

Now, you are undoubtedly still wondering how this can be. If you
take these two points and "connect the dots," you don't get a 22
kHz sine wave. You get something else entirely. Well, if we were
to look at the spectrum of the signal represented by the
"connect-the-dot" waveform, we'd find that it would consist of
since components at 22 kHz and at many other frequencies, all
above 22.05 kHz. For example, you'd have a component at 22.1
kHz, one at 44 kHz, one at 44.2 kHz and so on and so forth. But,
all those extra components aren't permitted, since they all
violate the Nyquist criteria. So, as soonas we get rid of them
all, all but the 22 kHz component poof! we have our 22 kHz
waveform back again, just as it originally was.

So filtering is needed in two places: first, when we sample,
because Nyquist says we cannot sample wavforms equal to or
greater than the sampling frquency: That;s at the original A/D
stage. Second, when we convert back to the analog domain: the
extra components that result from the "connect-the-dots" or
"stair case" (or whatever representation) are outside the
Nyquist band and also must be eliminated.

It works just fine boith in theory and in practice.

--
| Dick Pierce |
| Professional Audio Development |
| 1-781/826-4953 Voice and FAX |
| |

Harvey Gerst wrote:

(Richard D Pierce) wrote:

Let's look at it more fundamentally. A 44.1 kHz system MUST have
its bandwidth limited to less than 22.05 kHz. This is simply the
correlary of saying that you must sample at more than twice a
waveform's frequency. If the bandwidth is limited to 22.05 kHz,
only one kind of 22 kHz waveform can possibly exist: a 22 kHz
sine wave. You can't have a 22 kHz square wave or triangle wave
or perfect tone burst because ALL of those waveforms have
components outside of the 22.05 kHz bandwidth that this system
has.

It works just fine both in theory and in practice.

And in practice, nothing above 11 kHz is gonna get through unscathed, unless
it's a pure sine wave (and if it isn't, it will be after the filtering). If
you're willing to go for just the first overtone, you can reproduce stuff
accurately up to around a little above 7 kHz, but don't expect any more than the
octave component. From around 5 kHz and down, you can start doing a credible
job on sawtooth and triangle waves, but you hafta go a lot lower to do a square
wave any justice. Doesn't mean that 44.1 sucks, but you should be aware of
those limitations.

And all perfectly irrelevant because you will never hear that.

"A E" wrote in message

And all perfectly irrelevant because you will never hear that.


And is the same in any band-limited scenario ( not just digital) , as in
recording with real-world micophones, onto reel tapes, etc.

geoff