batch processor - potential bug and FRs

WaveLab
#1

9.5.15 Pro Mac, in batch processor using just the loudness normalizer - is there a way to generate a text file showing the analysis and all changes made to each file? or is that option already available if i go to ‘Parameters for XSLT processing’ under Generate XML file, and create a custom script?

an option that definitely does not exist that would be nice would be a way to bypass the peak limiter in the BP.

finally, using the loudness normalizer i’m getting some wicked jumps in volume every so often. screenshot attached as one example, original on bottom. there isn’t anything, sonically, unique about that section in the original file. what’s happening?

pop WL95 BP.png
pop WL95 BP.png832×728 72.3 KB

#2
  1. There is a batch plugin called “Audio Analysis”, that should suit you.
  2. Why bypassing the peak limiter? If you do so, you likely will go over 0 dB. Is it what you want?
  3. Never saw that before. Is it something you can reproduce, given some specific file? If yes, please send the material.
    BTW, the picture is not from WaveLab. Do you see the same waveform in WaveLab?
#3

Hi PG,

  1. thanks!
  2. because there’s no need for it in my case, so in my mind, the less processing/math the better. The BP is used almost exclusively, in my case with the EBU stock preset. This has never boosted a song requiring a limiter, only reduced the volume. So no, in this case, I see no reason why I’d go into clipping. And if a file did clip, I could enable the limiter. Wouldn’t it be better to at least allow the end-user the option to bypass it?
  3. I’ll attempt to reproduce it. Will take a few days because I’m stretched thin with projects this week, but this BP is very much part of my normal workflow, so I will certainly follow up in hopes of getting to the bottom of this. Also, if it isn’t repeatable, and just a random occurrence, it still begs the question what would cause the error. In this case, 4 of 10 files in the same BP session had these errors.

BTW) Yup, that’s Reaper. Those wavs were imported into Reaper after the BP ran, just part of my normal workflow. They display the same issues in a montage as well as in iZotope RX. It’s not an error in the peak file in Reaper or WL. It nearly shredded my ears playing it back the first time!

#4
  1. The PeakLimiter uses maybe only 1% of the process time, you would see no difference.
#5
  1. you’re assuming, incorrectly, this is about time. it has nothing to do with time. please re-read earlier post.
#6

Wll, I don’t understand where is the benefit of not having the peak limiter. Ok, it will not enter into play with your scenario. But what when the peak limiter does not enter into play, it does not change the sound, and as mentioned, does not affect process time. Hence, where would be the benefit?

#7

The reason I asked for a simple bypass checkbox was because I don’t see why, if the limiter isn’t required for attenuating file, it remains in the signal path. You never mentioned the limiter does not change the sound up until your last message. Instead, you assumed the request was about processing time, which is a bit of a straw-man, no? The limiter in question has no controls, no threshold, much less knee or attack and release values. It couldn’t be more opaque, just like the SRC parameters in WL. So I don’t think it’s all that bizarre that a user would want to know what’s actually happening with the process and know if the code is truly bit-transparent. Clearly I should have done some null tests before inquiring. :unamused:

#8

Actually, even if the Peak Limiter would alter the signal while not compressing anything, it won’t affect your signal in your case, indeed:
the meta-normalizer is a multipass process.

  • The 1st pass analyse the peak and loudness.
  • The 2nd pass modify the level without using the peak master at all if the gain was negative (your case), and then there is no more pass.
  • The peak limiter is only used when a positive gain has to be used.

IOW, there is an automatic “Limiter Off” switch, you could not dream better :wink:

#9

Just a quick update to this thread. I was able to recreate the normalization bug described above, but also found the errors (huge burst of level boost in just some section of a song) happened in other areas as well that were not repeatable. In the testing process, I switched out HDDs, and sure enough the errors went away entirely, so given the n of 1 in reporting this issue, I think it is safe to assume this is most likely something with read/write errors specific to my HDD, not a WL bug.