Hey PG,
During processing any file that is close to 0dB with MP3 or ACC encoders the resultant file invariably contains ‘overs’ due to the encoding process.
Other encoder plugins alter the peak volume of the files to eliminate ‘overs’ during processing.
Does the encoder checker in Wavelab 8.5 also incorporate safe guards against ‘overs’?
5am
No, you have to use a limiter before the encoding, eg. set to -1dB. Try the Steinberg Brick Wall limiter for instance.
5am, what plugins can do this? I’m not aware of anything that does this automatically to eliminate overs in the encoded lossy files. I know of isotope ISP, and I believe Wavelab can eliminate overs and ISP in generated Wav files, but an automatic lossy lookahead and adjust I haven’t heard of. Does Sonnox do this now?
bob99 …
The Sonnox has always offered this option which is indeed very useful. It does not ‘eliminate’ them. Rather, it renders to a temporary file, looks at the overs generated, automatically lowers the input gain to compensate, and then re-renders.
I use it literally every day.
Thanks Paul. Didn’t know.
Yep,
RAT is totally correct, I was referring to the Sonnox range of encoders.
This is very disappointing PG, your work around is not fool proof because a limiter at -1.0dB pre-encoder may not be enough to prevent overs, so this is a bit ‘hit n miss’ trying different limiter settings until the resultant file has no ‘overs’ Also very time consuming when converting lots of files, please can we have ‘overs protection’ built in?
i shall continue to use the Sonnex encoders which is really frustrating because Sonnex do not provide the iTunes+ Codec for PC users, hence my reason for upgrading to 8.5 because in a previous email you confirmed the iTunes+ codec was available within Wavelab on a PC , something it appears Sonnex currently cannot or will not provide.
Although Sonnex do offer the official iTunes + codec for MAC they only provide a ACC codec that is ‘close’ to the iTunes + format for PC users, not the official codec.
Is the iTunes + codec in the encoder checker in WL8.5 the official iTunes+ codec or a approximate codec?
5am
Is the iTunes + codec in the encoder checker in WL8.5 the official iTunes+ codec or a approximate codec?
This is not the Apple codec, this is the Fraunhoffer codec.
Concerning the peak issue, I did extensive tests on many files: using -1dB / True Peaks has always been sufficient not to create any overs.
5am, the official iTunes+ codec changes with OS updates anyway. The iTunes+ codec in iTunes for Windows is very close to the one in Mac iTunes and the MFiT toolkit, they nearly null. Clip and ISP count will be off maybe by 1 or 2 measured with afclip. Apple certainly wouldn’t have a problem with that by itself, and many MFiT albums have clips and ISP. There’s no rule about that, only recommendation.
But last I heard, they still insist you buy a Mac and use their tools to test and audition if you’re going to be sending them any wav files for MFiT. AFAIK that policy hasn’t changed.
Just trying the Encoder Checker, PG, I think it’s great you added Ogg Vorbis there. The metering is great. Is it just me or is Ogg much closer looking to the original than anything else in there? Everything I’ve tried looks that way.
Tried your iTunes+ AAC and analysed in afclip, and find it generated fewer clip levels than the Apple codec, maybe 1/3 as many.
I agree an automatic input gain would definitely be nice if possible, but other than that I think it’s pretty great. One thing I miss vs. the MFiT tools is a printout of clips and isp like afclip. It would be great if something like that could popup after render.
Is it just me or is Ogg much closer looking to the original than anything else in there?
Look at the compression ratio: it is as low as the quality is good, and you find your explanation.
Philippe
If you mean the compression ratio of the Ogg, I was just using the default “6” I think, and the original and encoded lines were perfectly on top of each other. Almost too perfect, I was thinking. I’ll try null tests tomorrow.
The MP3s and AACs at any rates and quality settings didn’t look nearly as good.
If you don’t compare similar ratios, the game is biased.
Not exactly a scientific test (I had to try to freeze the display on the fly on the same beat each time), but the Ogg consistently looks better, and nulls better than AAC or MP3. After rendering, these all produced files of 8Mb, so they were pretty equal, all 256 CBR. 4 minute song I think.
It’s not pictured because I couldn’t get equivalent MP3 and AAC size, but the Ogg VBR preset looks absolutely remarkable. But it makes a 15Mb file. The Ogg encoding is also slower than the others I think. But this is definitely worth trying for yourself.
PG, I tried changing the default quality number (6) in the Ogg VBR settings to 1 and to 10, but it didn’t seem to make any difference in the file size. It always created a 15Mb file. Any idea why?
VBR means somehow: “the encoder decides the bit rate on the fly”, therefore there is little control on the final size.
Converning CBR, I have noted that at 256 kbps, the OGG still compresses a bit less than the MP3 encoder at 256 kbps (hence this means it keep more original frequencies).
Remember also this: the principle behind lossy compression is to remove the frequencies that the human ear can’t hear, because masked. Deciding which ones is directly related to the quality of the encoder. And this might not be “visible” with the eyes. Hence the importance of the ears.
My personal feeling, after using the Encoder Checker, is that the various encoders work better than than originally presumed 
Thanks PG. Very helpful getting your take on this. I’ll have to mull on the differences in the frequency response, and take the blind test. I know I’ve never done very well in the past telling high bitrate MP3 from full res. Thank you.
So PG …
I really like the Encoder Checker. I am trying to ingrate it into my workflow.
One question: If I am not mastering for iTunes only, what I would typically do is play the mastered track back with the Sonnox loaded. This would display the overs generated by the codec both in the plug and on WL meters. I can then make level adjustments for MFiT with confidence.
If I load the Encoder checker as an effect, this seems to do exactly the same thing as the Sonnox (overs recorded on the WL maters are basically the same as well).
Is this correct?
BTW I am loving latest release. All plug problems gone. Totally stable. Wonderful work!
Paul
If I load the Encoder checker as an effect, this seems to do exactly the same thing as the Sonnox (overs recorded on the WL maters are basically the same as well).
You can still use the Encoder is the post mastering slot. In that case, to see the peaks in the Master Section, activate this button:
Independetly from that, the independent level meter always show the peaks since it is totally beyond the Master Section.
BTW I am loving latest release. All plug problems gone. Totally stable. Wonderful work!
After working with the Encoder Checker some more, I still think it’s pretty great, (although I agree with others that it should definitely have an automatic input gain control, not only a level and peak limiter recommendation, which might work fine in some cases but isn’t optimal if you’re splitting hairs on level. Also peak limiting is controversial and not normally recommended for MFiT in any of the documentation I’ve seen. Normally, simply lowering the input gain to the encoder is recommended.)
But I do question the lack of the Apple AAC codec, and the Fraunhofer AAC codec being called “iTunes +” in the AAC preset. The Fraunhofer is really dissimilar to the Apple in at least one important way: the encoder clip level and inter-sample peak total numbers. The Fraunhofer encoded AACs have about 1/3 to 1/2 the number of clip and ISP levels when analysed in afclip than Apple MFiT AACs for the same program. Those numbers are one of the most important things as far as Apple is concerned in preparing Mastered for iTunes files. And while third party tools like the Encoder Checker are not currently approved for MFiT, they might be in the future, so if you’re simply preparing for standard iTunes or preparing for MFiT, the Apple codec would be a more accurate representation of what will be sold in the iTunes store.
So I’d like to ask if the Apple AAC codec could be added to the Encoder Checker, as that could rightfully be called “iTunes +”. I believe the Sonnox uses the Apple codec in their encoder checker, on Mac and Windows, and that it’s already there in Quicktime on both platforms. The Apple codec on Windows is extremely close to the Mac as far as clip and ISP numbers go, so it would be perfectly usable on Windows to my mind. It’s close enough for Apple to call it the same thing (“iTunes +”) on both Mac and Windows.
Also I believe the Encoder Checker could really use an indication of the total numbers (clip and ISP) after a render, preferably a pop up in a text file, similar to the readout in the Mac terminal “afclip” command, and conforming to the numbers and sensitivity of their readings.
The Apple codec is only available on the Mac, AFAIK. As you mention, it “clips more” than the AAC. These reasons make it unlikely that it is used in WaveLab in the future.
This being said, I thought about this feature, for the batch processor: “an encoder aware normalizer”:
1st global pass, it checks for clips. If there is any, the gain is reduced. Then the process is tried again. Then the audio is encoded.
I did not do this for a matter of time, in 8.5, but also because the AAC encoder changes the peaks/level so few that it was not a priority.
But no buyer’s ever going to hear the Fraunhofer AAC, unless you’re selling your own AACs. The aggregators and Apple take the mastering wav and encode it themselves with the Apple codec. If you have a process analyzing the clips of the Fraunhofer, that’s not how the iTunes file will turn out.
