MP3 clipping in WL

Hi,

I don’t understand why almost all my MP3 tracks that played through a normal player don’t clip my Rme digicheck when imported in wavelab inevitably clip my Rme Fireface ufx.
Moreover when I convert a wav to MP3 I need to set a ceiling to -0.6 dbx and inter sample limiter on to avoid any clip.

Any hint?

There are too many variables to say but I think it’s safe to say that either some of the apps do not have the output set to 0.0dBFS or they are not telling the truth.

When you play the mp3s from other apps, they might play the mp3 directly. WaveLab has to decode the mp3 to WAV before opening which I suppose could cause peak level changes. I would have to look closer to see if decoding the mp3 to WAV can also increase the peak levels just enough to trigger your clip lights in RME Digicheck. Loading mp3s into WaveLab is not something I normally do.

Of course, encoding WAV to mp3 with any app will cause peak level increases and the specifics of the peak level increases depend on many things such as the material itself, the loudness you try to achieve, the peak limiter style used, and of course the bitrate of the mp3 you encode to.

The lower the bitrate mp3, the higher the peak levels will be on the encoded mp3, and more frequent. Setting a ceiling of -0.6dBFS to prevent clipping on an mp3 encode is not unheard of depending on all the variables.

I’m guessing for the clipping you’re seeing, it’s because Wavelab 9 now decodes MP3 to 32 bit float, which is as it should be for analysis because that’s how Apple (and therefore Sonnox) do it for analysis. All prior Wavelab versions decoded to 16 bit fixed truncated.

You can either put a 24 bit dither in the master section to playback the converted MP3, which will probably eliminate the red lights you’re seeing, or you can save-as 24 or 16 bit truncated, since that’s how it was done in Wavelab before. Or render to 24 or 16 bit with dither. Any of those will probably reduce the clipping indication you’re seeing. The clipping will still be there in the MP3, which is why Apple accounts for it, but it’ll look more like your other players at fixed point.

Maybe there should be an option to decode to fixed point, because the new way brings in issues like this, that are possibly undesirable for longtime users, adding an extra step to get a 24 or 16 bit wav from an MP3.

But the 32 bit float convert should not be removed from a pro app imo, because it’s more correct and how it’s done for MFiT analysis. It was one of my feature requests. You can always go forward to 24 or 16 bit fixed point by render with dither or save-as (truncated), but you can’t go back to correct 32 bit float decode if the MP3 or AAC is initially decoded to fixed point.

I have noticed this also - very low quality mp3 files (96k or so) could require 1db or even more. Very high quality mp3 files (320k) should only need a small amount of headroom - maybe .3db?

Yeah, I don’t know all the science behind it but tools like Sonnox Pro Codec make it easy to test your master WAVs for all the various codecs so you can be sure you have enough headroom to avoid clipping. I’ve just noticed that the lower the bitrate, the more easily clipping is induced which is not really surprising to me.

WaveLab has some tools to check it as well but I’m so used to loading into Pro Codec, loading all the codecs you want to test and pressing one button.

I’ve found that the required headroom depends so much on the material itself, how high you push the average loudness, what limiter you use and where you set the output ceiling, and of course the end codec format. Some limiters of course have better oversampling and ISP protection than others.

I used to put NUGEN ISL2 after my main limiter and before final dither to help with intersample peaks and peaks after lossy encoding but NUGEN and WaveLab don’t play nice together so I recently started using Limiter No6 for the protection mode only.

The stock Brickwall Limiter is pretty good for ISP protection.

I’ll try and make some screenshots if I still have digicheck installed, but it makes sense to me that Wavelab 9 would decode with peaks above 0.0 db to your interface if your levels are on the edge, since it’s decoding 32 bit float now. Most store-bought MP3 and AAC would probably show the same, because most don’t adhere strictly to no clip levels or isp.

If you still have Wavelab 8 installed you can decode there and see the difference, if any, between 16 bit decode in Wavelab 8, and 32 bit float decode in Wavelab 9.

Thanks Bob. I knew you could explain it much smarter than I could, and I really have little experience decoding mp3s to WAV as I rarely do it.

I would say a 99.9% chance it’s because WaveLab now decodes to 32-bit floating point and the original material is already at or very close to 0.0dBFS.

Many thanks guys for the explanations.
I will do some tests and report back.

Thanks Justin. Certainly not smarter. I’m glad you understood what I wrote, because even I don’t understand what I wrote most of the time.

I just checked out the Encoder Checker a bit in Wavelab 9 and back again in Wavelab 8 and it’s pretty nice, but it would be nicer to have some sort of automatic level adjuster like in Sonnox.

I’m also a little confused about how to meter it, because the live MP3 encoder output is certainly after the Master Section meters, as I would expect, but it seems like the live MP3 output is also after the Wavelab Level Meter (at least in Wavelab 8). If I push the input level into the encoder checker, the peaks show as above 0.0db on the Level Meter, so must be before the 16 bit 0.0db max output of the live MP3 I would think. So where to meter the live MP3 output?

The bitmeter in Wavelab 8 is definitely after the Encoder Checker, because it’s reading 16 bit off the live MP3 decode.

Sorry, I haven’t kept up with the whole Post Processing / Metering situation.

Hi, after doing a more thorough I noticed no change after the application of dithering to 16bit.

For any further help, you may have to provide us with screen shots of the waveform with an analysis window open showing the peak levels of the source file and encoded mp3 file.

AFAIK converting to MP3 can often result in overloads on peaks with signals which peak at or just below 0dBFS. So it’s probably normal that you should have to leave a little headroom in order to avoid this. One recommendation is to use the supplied Brickwall Limiter set to -1dB with ‘Detect Intersample Peak’ active.