Dithering before lossy encoders in Wavelab?

This question pertains to how the lossy encoders in Wavelab are internally implemented. I wonder whether dithering to 16 bits is good or bad in cases where I render to a mp3 or aac encoder. In principle, if the encoder implementation in Wavelab is internally using simple rounding or even truncation to 16 bits, I expect dithering before the encoder should be recommended. But if the implementation utilizes a higher fixed-point resolution or floating-point, there is no point in going to 16 bits, and hence no need for 16-bit dither.

Of course, someone might be argue that it’s a “don’t care”, given the lossy nature of these codecs. But I think it’s good engineering practice to apply dither only when called for.


All lossy encoders receive 32 bit float samples, hence no need to dither.

Yeah, what PG said.

I always encode mp3 and AAC from a 32-bit floating point source.

Unfortunately nearly all digital distributors require 16-bit WAV for them to do their encoding from.

Buddy Judge at Apple actually told me that Apple can technically accept 32-bit floating point files for Apple Music/MFIT/iTunes Store but it’s the digital aggregators themselves that impose the 16-bit limitation.

Is this true also in Wavelab Elements? No need to dither before rendering to mp3?

Yes. It’s not that unusual. You can encode directly from 32 or 64 bit float wav in iTunes. There is at least one program that restricts the encoding source in a lower priced version, but not Wavelab Elements.

Thanks, Bob!