If I increase the level of a wav file in a montage well above zero to send to MP3 and AAC (iTunes+), then analyze the resulting MP3 and AAC with Global Analysis, the MP3 will have Digital Peaks well above zero. The AAC will not - Digital Peaks will be at or below zero.
It seems like something funny in the 32 bit float wav decode file. If I save the Wavelab decode file as 32 bit float wav and analyze it with afclip in Mac Terminal I get the same incorrect thing - Digital Peaks at or below 0.0. If I analyze the Wavelab AAC file directly in afclip (with the built in Apple AAC encoder doing the 32 bit decode behind the scenes) I get the correct Digital Peaks above 0.0.
Indeed, it seems the AAC encoder has some sort of limiter embedded.
Hi PG. Will the limiter be removed? It makes analysis results more different than Apple MFiT standards than they could be in Encoder Checker and Global Analysis. And obviously different from the MP3 analysis.
This is not an option of the FH aac encoder.
Really? Their MP3 encoder and AAC encoder both output 32 bit float, but only their AAC encoder limits the peaks to just below 0.0? Isn’t that kind of crazy?
The Apple doesn’t do that.
Dont compare 2 different encoder models.
My guess is that their encoder is optimized to encode a predefined range.
And anyway, what would be the interest of encoding an overloaded signal?
Sorry PG. I have no interest in encoding with overload. I’m strictly talking about analysis. If analysis or encoder checker or any of the metering is not given those peaks, it’s more different than Apple MFiT analysis than it could or should be in analysis tools, given that MFiT is one of the things that started this in the first place.
If there’s any way for them to change this, I really think they should remove the limiter, or at least make it possible to turn it off. Seems more like a leftover oversight than anything else to me.
Does Wavelab use Fraunhofer or LAME for MP3 decode?
Is it possible that this may not be a “limiter” … rather it may analyze the file, and reduce the input gain so that the resultant file is at or below zero. The Sonnox product can do this.
It appears to be in the decoder, not a clip-safe type of encoding. If you analyze the resultant AAC file using Apple decode (instead of Fraunhofer decode) there can be a million overs.
PG, the more I look at this, the more I think it’s just plain wrong.
The Fraunhofer AAC decoder clamps the output to -0.0003 db.
In Encoder Checker, select AAC, turn on Monitoring Point so the master section meters are reading the output of the AAC decoder, and the Master Section meters will just sit there at 0.0 db with no red lights no matter how hard you hit the input of the AAC encoder. It makes it nearly useless for any kind of Encoder Checker analysis, or Global Analysis of rendered files.
Luckily most people probably turn on True Peak metering and get red lights from that, and turn down from there, but the Digital Peak analysis and metering should be correct independent of that, not subject to a Peak Limiter in the decoder that you can’t turn off.
I’ll talk to Fraunhofer about this because I can’t believe it’s like this in Sonnox Pro Codec (although it might be). Maybe everybody’s using the Apple AAC decoder (which doesn’t have a limiter) in Sonnox, or they all have True Peak metering enabled. But I find it hard to believe I’m the first one to notice this after all this time.
The Fraunhofer MP3 decoder doesn’t do this.
I have delved into the FH documentation, and indeed, there is an integrated limiter which is On by default, and that can be disabled… I had enough time to make if Off for the upcoming 9.0.30
Wow, that was fast. Thank you Philippe.
Very nice, thanks!