Subject:Normaize Scan levels incorrect and inconsistent

Posted by: Rednroll

Date:11/12/2002 2:32:57 PM

There seems to be a bug in the Scan levels feature. It is totally incorrect and non-consistent. For expample generate a 2 channel Sinewave for 60seconds with the peak at 0dB. When you do a "Scan Levels" you get a Peak value of 0dB and an RMS Average of -1dB. According to my calculation of a RMS sinewave the RMS value should be -3dB.

20*Log 1/SQRT2= -3dB

Now do the same thing for a 10Khz sinewave and you get a -12.3 dB RMS level and a 100Hz signal gives you -15.3 dB RMS level. These also should give you -3.0dB RMS signal, so there's quite a big error in the calculation.

I found this out when trying to get RMS levels of Pink Noise and music (since there's no VU meter I might add). I scanned the same songs in Cool Edit Pro 2.0 and Sound Forge 6.0 and found drastic differences between RMS values between the two apps. I thought I would rely on Sound Forge, since it's the app I trust the most, and needed to generate Pink noise with a 2 to 1 Crest Factor for Thermal testing of an audio system. Wow, was that a mistake. I later found out I was -3.5dB off in the RMS Value, and pretty much wasted an entire day of testing, because my source material was incorrect. If it's 3.5 dB off in calculation for Pink Noise, then it really can't be relied on for music use. I also found this to be true with actual music. I found up to a 6dB level differenct when scanning levels in SF6 and SF4.5.

I later went back to Sound Forge 4.5 (Good ole reliable) and did some more "Scan levels" of the same material and they correlated almost exactly with what was in Cool Edit Pro 2.0. Both 4.5 and Cooledit Pro 2.0 gave me -3.0dB RMS for the sinewaves.

For now, I have to say, "the heck with any new features", just give us an app that we can rely on with the old features. I'm going back to v4.5, things may take longer, but at least what I hear and am procossessing can be trusted to be just that.

Red

Subject:RE: Normaize Scan levels incorrect and inconsistent

Reply by: kilroy

Date:11/12/2002 4:14:21 PM

Annoying, huh. You have my pity, dude.

Lets take this one step further. Has anyone else noticed that digital metering in general is all over the freaking map? Gadzooks, you can't trust anything. Some stuff, zero db is clipped pure and simple. Other gear the meters light 0 and you still if fact have a bit of headroom. If you are stuck recording to a low rez system you kinda want all the bits you can get so you are pushing the fringe of things. Kinda hard when that fringe is inconsistant from one piece of digital gear to the next.

Remember ADATS? When they came on the scene we always stayed under cuz 0 was *it*, right. Later on we discovered you could go ahead and light the bleeding things up like Christmas trees and as long as the red didn't really hang on you were OK. These were black face jobbies, I don't know if the newer ones were the same or not.

We *never* normalize\maximize up to 0db for CD burns. It's just dumb because some players look at a 0db peak and think it's clipped.

It is *really* strange that a pro audio app can't get a file generation right though. For that type of thing we have a good ol analogue VU we can strap across an output to make sure the file is what the host prog says it is. You shouldn't have to be bothered with nonsense like this, but for measurment purposes like you mentioned, it has to be right on the nail or you end up piddling your time away for nothing.

Subject:RE: Normaize Scan levels incorrect and inconsistent

Reply by: Sonic

Date:11/12/2002 4:26:17 PM

I'll venture that the actual problem is that the "Scan Settings" are being used even though we disable them when the "Normalize using: Peak level" mode is selected (which kinda makes sense since only the peak value is actually used in that case), but they should probably remain enabled so you can see what is being used for the RMS scan.

So...what were your scan settings? Please re-try your test with the "Maximize Peak Value" system preset or select "Normalize using: Average RMS" and verify that "Ignore below" is -Inf. and the "Use equal loudness contour" checkbox is *not* checked. Attack and release should probably be 200 ms or lower.

BTW, this problem exists in 4.5 as well. I expect you just had different scan settings between the two. Recall that the default settings loaded in the effect are the last ones *applied*, not just the last ones *selected*.

J.

Subject:RE: Normaize Scan levels incorrect and inconsistent

Reply by: Rednroll

Date:11/13/2002 9:56:39 AM

Ok, I verified what you said, and changing to the "Maximum Peak Value" Preset fixed the problem. When using the normalize function I normally use "Peak Level" normalization. It just happened in SF6.0 prior to this I was trying to use the RMS peak normilization to achieve my 2 to 1 crest factor pink noise and had checked the "use equal loudness contour". I later changed back to the "peak level" normalization and did the scan. Although the "use equal loudness contour" is greyed out in the scan settings, having this checked is effecting the scan levels. It remains checked because I had previously been in Average RMS mode. If I uncheck the "use equal loudness contour" and then changed back to peak normilazation and do a scan, I get the correct values. I also verified this is the case with SF 4.5, although I did get a 1 dB decrepency value between 4.5 and 6 when scanning the 1Khz 0dB sinewave with equal loudness contour checked. 4.5 RMS=0dB, and 6.0 RMS=-1dB and all settings where the same in both apps. I had gotten the correct values in 4.5 before, because the "use equal loudness contour" was unchecked and I was doing the scan in "Peak level". So is the problem, that although the "Scan settings" are greyed out, they're actually still functioning when in "Peak Level" normalization mode?

Thanks,
Red

Subject:RE: Normaize Scan levels incorrect and inconsistent

Reply by: Sonic

Date:11/13/2002 11:22:49 AM

Yes, the scan settings are used in the scan even when they appear disabled. When peak mode is selected, forge should either:

a) leave them enabled or,
b) skip the RMS scan and blank the text field

While for your case (scanning just for the info), (a) is a good choice, I'm more partial to (b) since in the scope of the tool itself, the RMS info is ignored in peak mode. Both are trivial changes, but (b) would draw more attention to the fact that you *must* pay attention to the Scan settings when interpreting RMS levels.

J.