Lord Hasenpfeffer wrote:
Jonas Eckerman wrote:

When you say "at -10dBFS" do you mean when you set Normalize to
-10dbFS or do you mean that you used another application to analyse
the file and that other application said it had a -10dBFS RMS?


I set Normalize to -10dBFS... like this: "normalize -ba -10dBFS *.wav"

I still say you guys are fooling yourselves with this "-10dBFS RMS"
terminology. The terms RMS and dBFS contradict each other. The
measurement will be either RMS or dBFS.

Popular applications like SoundForge enable you to normalize to either
dbFS or RMS, not both. If the setting causes the waveform to exceed 0
dBFS, something has to happen to the peaks that makes them resemble
something other than the original waveform. If you use the RMS
method,the program asks you what you want to to if the normalize exceeds
0 dBFS - compress or clip.

Sure, "-10dBFS" might be the argument you pass in your command line
application, but I can't see that you really know how or where that
measurement is being made. It appears to me that that setting indicates
where the compression kicks in.

Artie

The -b engages "batch mode" (as opposed to "mix mode").
The -a indicates "amplitude" which is followed by my spec.

While conducting my little WAV-MP3-WAV noise floor tests last night I
used: "normalize -g -90dB test.wav" to attenuate the "gain" (hence the
"g" in my command line) by 90dB - after which I could *still*, though
just barely, make out some skeletal semblance of the original track
after amplifying to -0.5dBFS within Audacity. Using negative values
with Audacity's "amplify" feature, however, produced crap with anything
beyond -40dB. What can account for the huge difference between the way
Audacity and Normalize reduce loudness in a file by such different
amounts, however, I haven't the faintest clue (but that's another story).

Thing is that by setting Normalize to -10dBFS your actually *not*
normalizing the *file* to -10dBFS RMS if I understand the
documentation correctly. You are "normalizing" the file in such a way
as to make the *loud* *parts* of the file -10dBFS RMS.
That's quite a big difference.


No, I have never found reason to believe that the entire file wasn't
being affected uniformly from beginning to end. If that's what it's
doing, I'm completely unaware of it. Need some more screenshots? That
MFSL "Dark Side..." screenshot is a perfect, albeit low-res,
before/after comparison of what Normalize "in batch mode" does to a WAV.
I pulled in all 10 tracks from "Dark Side" for that screenshot after
"batch normalizing" them. It was *not* Normalized as a single file as
the image seems to suggest.

I must concede that as I didn't really understand Normalize's
documentation I might well be mistaken in this. They at least leads
me to believe that something like that is what the author intends.


I still have yet to read the online documentation at the URL you
provided. Too much stuff to do I have.

Also: When you use Normalize for batch normalizing the files from a
CD, you're certainly not normalizing all the files to -10dBFS RMS.


The "man page" for Normalize, seems to indicate that I am. Shall I post
that complete text for you here?

Your own answer to my question seems to be a rather long "yes". You
found that you liked the result you got when setting the Normalize
application to -10dBFS, wich as I understood the docs means that you
did not normalize the files to -10dBFS RMS.

Please correct me if I'm wrong.


I believe you are incorrect. However, I'm still new to the terms so I
still can't be sure that we're speaking the same language in every way.

I've only opted to use the abbreviation for "Root Mean Square" because
Geoff seemed to prefer it since he knows all about this stuff and I do
not. I don't wanna look stoopider than I iz.

Myke

"Artie Turner" wrote in message news:VXmPa.46

I still say you guys are fooling yourselves with this "-10dBFS RMS"
terminology. The terms RMS and dBFS contradict each other. The
measurement will be either RMS or dBFS.

Popular applications like SoundForge enable you to normalize to either
dbFS or RMS, not both. If the setting causes the waveform to exceed 0
dBFS,

Oh yes it can - maybe !

Although it is not absolutely clear in the 'Normalize' application Help, it
appears to normalise to a specified RMS ( a la SForge, etc) power, while
adding compression to prevent going over FS. However, the programmer also
says in the Help something to the effect that he knows F-All about audio
engineering, so who knows. Hardly inspiring....

Yes, the term "-10dBFS RMS" is an invalid and redundant expression. Of
course it is -10dB RMS *in relation to 0dBFS*, because as dB is a relative
scale, and FS is the only thing it can be relative to in the digital domain
! So "-10dB RMS" itself is an adequate explanation.

geoff

"Lord Hasenpfeffer" wrote in message
...
Artie Turner wrote:

I still say you guys are fooling yourselves with this "-10dBFS RMS"
terminology. The terms RMS and dBFS contradict each other. The
measurement will be either RMS or dBFS.

I believe the job of Normalize is to adjust a recording's loudness by
whatever dB factor is necessary to force the Maximum RMS of the
recording to become either -12dBFS by default or whatever other value is
specified by the user. Clipping or limiting is applied as needed in
order to carry out the particular task at hand.

You got it, if the Help/manual is accurate.

A .WAV file with a Maximum(?) RMS value that is already in excess of
either the default or user-specified value will be made quieter, not
louder, in order to complete it's job. In that case, no limiting or
clipping comes into play.

It would be most unusual to find music with an RMS level over -10dB .....

geoff

Geoff Wood wrote:

It would be most unusual to find music with an RMS level over -10dB
.....

I agree, if you're talking the so-called "Average RMS" level. But
whatever it is that Normalize refers to as "level" is almost always in
the -10dBFS to -6dBFS range on typical, recent, 24-bit digitally
remastered CDs.

Myke

--

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

"Lord Hasenpfeffer" wrote in message
...
Geoff Wood wrote:

It would be most unusual to find music with an RMS level over -10dB
.....

I agree, if you're talking the so-called "Average RMS" level. But
whatever it is that Normalize refers to as "level" is almost always in
the -10dBFS to -6dBFS range on typical, recent, 24-bit digitally
remastered CDs.

I thought we'd been there over a week ago. It is clearly RMS level of the
scanned track, averaged over the whole track. That it is not labelled as
such should be telling us something.

What that figure is, is purely related to the dynamic range or lack thereof,
and has nothing to do the 24 bits, or digital mastering/re-mastering..
Higher levels general indicate very compressed music, which can be either
through incompetence or desired special effect, or both.

Suggest this week you persue the FAQs already indicated, instead of in
reference to dB and how they work, with regard to what mastering and
remastering is.

geoff

geoff


geoff

Geoff Wood wrote:

I thought we'd been there over a week ago. It is clearly RMS level of the
scanned track, averaged over the whole track. That it is not labelled as
such should be telling us something.

What that figure is, is purely related to the dynamic range or lack thereof,
and has nothing to do the 24 bits, or digital mastering/re-mastering..
Higher levels general indicate very compressed music, which can be either
through incompetence or desired special effect, or both.

Suggest this week you persue the FAQs already indicated, instead of in
reference to dB and how they work, with regard to what mastering and
remastering is.

Good grief, Geoff. By merely mentioning 24-bit digital remastering in
my post you somehow infer that I believe in hard connections between the
remastering process and an RMS level. No wonder we've never been able
to communicate effectively.

I have ripped and encoded a *lot* of CDs in the past 2+ years and have
found that almost consistently my 24-bit digitally remastered discs have
"Normalize levels" of at least -10dBFS - often higher than that by 1 or
2 dBs. Because of this I usually do not touch (with Normalize) my
digitally remastered discs because "the experts in the industry" have
already mastered them at or above the loudness level I personally prefer.

In no way have I implied any connection with "Average RMS", or "Maximum
RMS" levels and 24-bit remastering in and of themselves. I've merely
noticed that newer 24-bit digitally remastered discs are almost always
"appropriately loud" as I like for them to be.

Myke

--

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

Jonas Eckerman wrote:
Please, if I'm completely wrong here, explain how.


The terms RMS and dBFS contradict each other.


How?

Maybe I hould have said that using the terms RMS and dBFS together is
confusing. dBFS implies a peak reading to me. RMS implies an average.
I'm sure there are others here who could explain this better than I - if
they hadn't lost interest a few hundred posts back - but the short
answer is there are peak meters and RMS meters, and you need to know
what kind of meter you are using when you declare something is "x dBFS"
The worst case scenario from not knowing which meter you have is that
your measurement will be off by ~ 3dB.


The measurement will be either RMS or dBFS.


RMS is a calculation while dB is a unit.

Both RMS and dBFS are based on calculations. Here's Bob Katz' definition
of dBFS:

"dBFS: The meters on DAT machines all read in dBFS, "decibels below full
scale". Full scale is the highest signal which can be recorded. Positive
going signals with a value of 32767 or negative with a value of -32768
at 16 bit are at the maximum. Levels below those are translated to
decibels, with 0 dBFS being full scale. For example, -10 dBFS is a level
10 dB below full scale."

Bob's definition appears to be slightly different from the AES-17
definition, but for the purposes of this discussion about
"normalization" it works just fine: a value of -x dBFS will have a
specific numeric value within the ranges of +- 32768



When you measure something you should specify both how you measure it and
in what unit you present the values.


Popular applications like SoundForge enable you to normalize to either
dbFS or RMS, not both.


You can't normalize to a unit, you must have some kind of basis for the
normalization.

Yes, you can. If you have a signal with -10 dBFS peaks, you can
normalize or boost that signal 10 dB before it exceeds the +- 32768
"bucket" and the peaks are distorted. (low level artifacts are another
matter altogether)

A typical normalization normalizes based on the peaks. The digital peak
values are typically presented in dBFS.

My guess is that when you tell SoudForge to normalize to dBFS you are
actually telling it to normalize to a peak value specified in the unit
dBFS.

Hmm, exactly. Where was the confusion? I suspect that "RMS
normalization" as employed by the UNIX command line utility you're using
is basically a form of boosting with peak limiting ala the LI
Ultramaximizer.

Artie

Regards
/Jonas

Maybe I hould have said that using the terms RMS and dBFS together is
confusing. dBFS implies a peak reading to me. RMS implies an average.

You need a unit in both those cases. Consider a completely different case:

You have ten ropes of different length. You measure the lengths of all the
ropes in inches.

You then calculate the average length of all the ropes.

Both the length of the individual ropes and the average length of the ropes
will be in inches.

(Of course, RMS isn't that kind of average.)

Both RMS and dBFS are based on calculations. Here's Bob Katz' definition
of dBFS:

That definition is not a calculation. It is the definition of what the unit
dBFS signifies. dBFS signifies how far below the loudest digital signal
(zero) you are.

RMS oth is a calculation done on a measurement, and when specifying an RMS
value you are not automatically specifying a unit. To be able to present a
usable RMS value, you must also either specify a unit, or use a unit that
is implied by convention or necessity.

In CoolEdit I have the choice of presenting RMS values based on two
different reference points, and both those could be called dBFS. One is
based on the RMS of a sine wave, the other a square wave. Both variants
presents the RMS values as to how far below the loudest digital signal you
are.

A value presented without a specied or an implied unit of measurement is
completely useless.

answer is there are peak meters and RMS meters, and you need to know
what kind of meter you are using when you declare something is "x dBFS"

Of course I nead to know if the meter shows peaks or RMS values.

Your own answer implies that dbFS is not only used for peak measurments. if
dBFS automatically implies peak measurements, then we would allways know
that "x dBFS" means a peak meter.

You can't normalize to a unit, you must have some kind of basis for
the normalization.

Yes, you can. If you have a signal with -10 dBFS peaks, you can
normalize or boost that signal 10 dB

You still can't normalize to a unit. You need to normalize to a value. You
can't normalize to dBFS, as that's just a unit.

Of course you can normalize to 0 dbFS, -2 dbFS and other values. But then
you're normalizing to specific values, not to a unit. In your example
above, you are normalizing to 0 dbFS.

I suspect that "RMS
normalization" as employed by the UNIX command line utility you're
using is basically a form of boosting with peak limiting ala the LI
Ultramaximizer.

Hey. I'm not using that strange utility. I've just tried to understand what
on earth it does. :-)

It isn't really like the L1 at all. It does calculate a whole bunch of RMS
values (not an average RMS though), and does a normalization based on the
loudest RMS values it found in the file or set of files.

It doesn't base the normalization on the maximum RMS though, it does some
more stuff so it will probably normalize on a value a bit below the maximum
RMS in most cases.

It does do peak limiting in order to allow digital clipping when necessary.
Not that depending on the file, it might raise or lower the amplitude of
the file.

/Jonas

"Jonas Eckerman" wrote in message


Your own answer implies that dbFS is not only used for peak measurments.
if
dBFS automatically implies peak measurements, then we would allways know
that "x dBFS" means a peak meter.

My answer implies that 0dBFS is the *only* fixed reference in the digital
domain. Other dB measurements are either purely relative (dB per se) , or
relate to physical analogue voltage or power levels (dBU, dBM, dBV, etc).

geoff

Jonas Eckerman wrote:

Of course you can normalize to 0 dbFS, -2 dbFS and other values. But then
you're normalizing to specific values, not to a unit. In your example
above, you are normalizing to 0 dbFS.

Is English your primary language? Of course there has to be a value
associated with the unit of measurement. I didn't think I'd have to
explain that.


I suspect that "RMS
normalization" as employed by the UNIX command line utility you're
using is basically a form of boosting with peak limiting ala the LI
Ultramaximizer.


Hey. I'm not using that strange utility. I've just tried to understand what
on earth it does. :-)

This whole thread was ostensibly about trying to understand what that
utility does! I have a problem understanding what's expressed by "-10
dBFS RMS" For me, as long as you're in the digital realm, the RMS part
of that expression seems redundant.

It doesn't base the normalization on the maximum RMS though, it does some
more stuff so it will probably normalize on a value a bit below the maximum
RMS in most cases.

It does some "stuff" and it "probably" does some other "stuff" in "most"
cases?

It does do peak limiting in order to allow digital clipping when necessary.
Not that depending on the file, it might raise or lower the amplitude of
the file.

So it's kinda like AGC on that CB radio in your granpa's closet? Thread
over.

/Jonas

I think you mean that dBFS implies a SCALE, not a peak reading Artie. RMS
indeed is an average by virtue of the math. The problem seems to exist
because Myke continues to do something that's simply not part of the process
under normal circumstances by re-normalizing an already MASTERED product.
He's "designing" new curves for product that no longer need new curves and
this is what I was getting on him about in the first place. The SENSIBLE
thing to do, should he want to make mp3s from a product with REDUCED overall
volume, is to simply load in the song, turn down the output volume until he
feels it's where the mp3 encoding process would do the best job, and process
it. I'm absolutely CERTAIN that by selecting peak normalization he is
severely changing the characteristics of the mastered song. I'm just as
certain that if he were to take the RMS average of the song and simply lower
it by some X of dB, that he'd be doing more of a service to his clients than
by his other method.

As far as the conversation between you and Jonas, remember, it's starting
from a faulty premise from Myke in the first place. One cannot explain
anything adequately when the premise for the explanation is wrong. dBFS is
a SCALE. RMS is an average POWER level. Peak readings are MAXIMUM dBFS, or
the absolute top something can hit on the scale. It is not how LOUD
something is. Myke is reducing the RMS value by using a normalization
process that changes all the values in everything it touches. The song's
not the same, the sound is not the same, the math is not the same. If we
reduce the RMS average by simply turning the overall output down, the values
may change but the constants are the same. Hence, the song remains the
same. If we do it any other way, the values have changed and the constants
have changed, hence, a different characteristic in the sound of the song.
It may sound good to Myke, but it's not the right way to do it at all.
--


Roger W. Norman
SirMusic Studio

301-585-4681




"Artie Turner" wrote in message
y.com...
Jonas Eckerman wrote:
Please, if I'm completely wrong here, explain how.


The terms RMS and dBFS contradict each other.


How?

Maybe I hould have said that using the terms RMS and dBFS together is
confusing. dBFS implies a peak reading to me. RMS implies an average.
I'm sure there are others here who could explain this better than I - if
they hadn't lost interest a few hundred posts back - but the short
answer is there are peak meters and RMS meters, and you need to know
what kind of meter you are using when you declare something is "x dBFS"
The worst case scenario from not knowing which meter you have is that
your measurement will be off by ~ 3dB.


The measurement will be either RMS or dBFS.


RMS is a calculation while dB is a unit.

Both RMS and dBFS are based on calculations. Here's Bob Katz' definition
of dBFS:

"dBFS: The meters on DAT machines all read in dBFS, "decibels below full
scale". Full scale is the highest signal which can be recorded. Positive
going signals with a value of 32767 or negative with a value of -32768
at 16 bit are at the maximum. Levels below those are translated to
decibels, with 0 dBFS being full scale. For example, -10 dBFS is a level
10 dB below full scale."

Bob's definition appears to be slightly different from the AES-17
definition, but for the purposes of this discussion about
"normalization" it works just fine: a value of -x dBFS will have a
specific numeric value within the ranges of +- 32768



When you measure something you should specify both how you measure it
and
in what unit you present the values.


Popular applications like SoundForge enable you to normalize to either
dbFS or RMS, not both.


You can't normalize to a unit, you must have some kind of basis for the
normalization.

Yes, you can. If you have a signal with -10 dBFS peaks, you can
normalize or boost that signal 10 dB before it exceeds the +- 32768
"bucket" and the peaks are distorted. (low level artifacts are another
matter altogether)

A typical normalization normalizes based on the peaks. The digital peak
values are typically presented in dBFS.

My guess is that when you tell SoudForge to normalize to dBFS you are
actually telling it to normalize to a peak value specified in the unit
dBFS.

Hmm, exactly. Where was the confusion? I suspect that "RMS
normalization" as employed by the UNIX command line utility you're using
is basically a form of boosting with peak limiting ala the LI
Ultramaximizer.

Artie

Regards
/Jonas

Ah, here I agree with you. Normalization via RMS utilizes a totally
different method which measures an electrical (or digital equivalent) output
and proceeds to bring things up to that level. Hence, RMS normalization
brings things up to a perceived LOUDNESS and the algorithm doesn't care
whether it's meant to be that way or not. Peak normalization picks a point
that is the highest on the scale and then brings everything up in the exact
same percentages necessary to maintain that peak level across the board even
as that PEAK reaches 0 dBFS or any percentage thereof. If one brings a 3
dBFS peak up to -.1 dBFS than peak normalization will bring everything else
up exactly the percentage necessary to maintain that ratio across the piece
of music. This action may or may not bring the overall perception of
loudness up.

Now that I rethunk that, it's obvious that RMS normalization would
inadvertantly change the overall values and constants represented in the
music, while peak normalization would have the values change while the
constants remain the same. I think I said it backwards in the last post.

However, this only happens under the normalization algorithm. RMS can be
lowered without adversely affecting the constants while the values do,
indeed change. It's when one approaches the maximum RMS values that the
constants are no longer constant in relation to the originals. Peak RMS
normalization would make everything constantly as loud as everything else.
Peak normalization on the dBFS SCALE would bring things up a certain
percentage and no further.

Damn, I hate when that happens.

--


Roger W. Norman
SirMusic Studio

301-585-4681




"Jonas Eckerman" wrote in message
. 1...
I believe the job of Normalize is to adjust a recording's loudness by
whatever dB factor is necessary to force the Maximum RMS

No. The docs are clear on this at least. Normalize does not base it's
operation on the Maximum RMS.

It seems to calculate the maximum RMS, but it uses something it gets from
smoothing a curve of RMS-values it has calculated in the file (and here's
where the docs get unclear again).

/Jonas

Roger W. Norman wrote:
I think you mean that dBFS implies a SCALE, not a peak reading Artie.

No, if you're using a peak meter, like on any DAT machine, -x dBFS
indicates a particular value re; the definition from the digido site. If
full scale, or 0 dBFS is a digital value of +32767, then a reading 10 dB
below that would a have a corresponding lower value.

If you have a .wav file with a the highest peak, positive or negative,
at -10 dBFS, you can normalize (increase the volume of the .wav in a
linear fashion) up 10 dB without clipping. Any process, regardless of
what name it goes by, that tries to increase the volume of that -10 dBFS
peak more than 10 dB will cause that peak to be clipped.

The SENSIBLE
thing to do, should he want to make mp3s from a product with REDUCED overall
volume, is to simply load in the song, turn down the output volume until he
feels it's where the mp3 encoding process would do the best job, and process
it.

I don't think he wanted REDUCED overall volume - nobody does. He wanted
louder files for tin-eared web junkies. He's basically trying to put 2
gallons in a one gallon bucket.


As far as the conversation between you and Jonas, remember, it's starting
from a faulty premise from Myke in the first place. One cannot explain
anything adequately when the premise for the explanation is wrong. dBFS is
a SCALE.

Depending on the number of bits in the sample rate - dBFS indicates a
precise value per Bob Katz.

"dBFS: The meters on DAT machines all read in dBFS, "decibels below full
scale". Full scale is the highest signal which can be recorded. Positive
going signals with a value of 32767 or negative with a value of -32768
at 16 bit are at the maximum. Levels below those are translated to
decibels, with 0 dBFS being full scale. For example, -10 dBFS is a level
10 dB below full scale."

RMS is an average POWER level.

Sure.

It may sound good to Myke, but it's not the right way to do it at all.

I don't think he cares. He's looking for the maximum sonic impact
regardless of the changes that might occur.

Artie Turner wrote:


RMS is an average POWER level.

No. MS is power. RMS is in the same units as what's
sampled; volts, pascals, sample values, whatever. You need
to square the RMS value to get power equivalents just as you
would need to square the voltage across a resistor to get
power.

RMS is the constant (DC) level that would need to exist to
generate the same energy (into the same physical resistance)
as some section of a time varying signal but it is not power
per se.

It makes sense to talk of the dBFS RMS level as long as you
define a reference related to FS. The one that makes common
sense is the RMS level of a sin wave with a peak value of 0
dBFS. Then dBFS RMS values would be defined as 20 times
log10 of the ratio of the RMS value of the signal to the RMS
value of that sin wave (which is just .707 if FS is 1.)


Bob
--

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

A. Einstein

Jonas Eckerman wrote:

I believe the job of Normalize is to adjust a recording's loudness by
whatever dB factor is necessary to force the Maximum RMS

No. The docs are clear on this at least. Normalize does not base it's
operation on the Maximum RMS.

It seems to calculate the maximum RMS, but it uses something it gets from
smoothing a curve of RMS-values it has calculated in the file (and here's
where the docs get unclear again).

Right. At any rate, it's close to Maximum RMS; definitely much closer
to that than Average RMS, I'd say.

Myke

--

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

Artie Turner wrote:

This whole thread was ostensibly about trying to understand what that
utility does!

No, it's specifically about whether or not boosting the amplitude of a
source WAV file enables one to preserve more of the original frequencies
in the digital recording after its been processed with a lossy
compression algorithm that employs an amplitude-oriented psychoacoustic
filter.

The fact that it has shifted to a discussion of what Normalize does is
technically off-topic but still related and often interesting nevertheless.

Myke

--

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

Roger W. Norman wrote:

It may sound good to Myke, but it's not the right way to do it at all.

I use non-standard methods for designing websites too.
The work wonderfully.

Myke

--

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

Artie Turner wrote:

The SENSIBLE thing to do, should he want to make mp3s from a product
with REDUCED overall volume, is to simply load in the song, turn down
the output volume until he feels it's where the mp3 encoding process
would do the best job, and process it.

But wouldn't turning the volume down cause more frequencies to be killed
off by the ATH-filter?

I don't think he wanted REDUCED overall volume - nobody does. He wanted
louder files for tin-eared web junkies.

This is not entirely true. I'm doing *several* things at the same time
with this software and my WAVs, not just one - and not all of them are
web-related. But that's beside the point.

It may sound good to Myke, but it's not the right way to do it at all.

I don't think he cares. He's looking for the maximum sonic impact
regardless of the changes that might occur.

I do care. I'm just not so anal about all of this from a
professional-CD-mastering POV - because I'm not in the business of
mastering professional CDs. If I was, I'd certainly take a
significantly different approach.

"Maximum sonic impact without doing obvious harm" is probably more like
it. There have been times when it was obvious that I'd Normalized a
recording too much. When this happens I simply re-Normalize to a more
conservative level (i.e. the app's default value of -12dBFS is usually
quite nice).

Myke

--

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