WL9P opens a 44.1 kHz MP3 as a 32 Bit Floating Point file.
WL8.5 opens the same file as a 16 Bit file.
Also, although the average (raw) level is the same in both files, the peaks are higher in WL9 (the highest going over 0dBfs).
Interestingly, decoding the file in Sonnox Fraunhofer ProCodec (at 16 Bit) creates a file that is identical to the WL8.5 version. (Peak and Average levels)
The 32F Bit decode in WL9P may be intentional, but it would be helpful to know why – since to monitor it properly (theoretically) requires dither.
This change comes from (legitimate) user requests. The fact is, that the MP3 decoder produces 32 bit float audio samples. WaveLab <= 8.5 was truncating this to 16 bit.
However, for the computation and monitoring of true peaks, it is better to use the original 32 bit float samples.
Hence the change.
IOW, you now get the exact output samples from the decoder.
BW, I haven’t had time to use Wavelab 9 yet (only just installed), but I was one of the users who requested this. My reason was to ask that Wavelab be put more in line with how Apple decodes for MFiT analysis, which is done from 32 bit float decodes, and which include counts of clip levels above 0.0 within afclip.
If you decode to 16 bit or 24 bit fixed, you’re just pinning those clip levels at 0.0, and you’re getting clip count readings that can often be half of what Apple sees when they analyze for MFiT.
If you prefer to look at 16 bit decodes for comparison, you could just “save as” 16 bit. From what I can tell, dither was never applied to the 16 bit decodes in Wavelab. That might be the case with Sonnox 16 bit decodes as well, I don’t know.
(It would be nice if you could just change the temporary file properties (at the bottom right) to 16 bit and analyze that, without having to save a file, but that doesn’t seem to work for bit depth, only sampling rate. If you change the properties sampling rate (without saving) and do a pitch analysis, the pitch will be different. But it doesn’t work for bit depth, which seems odd. Maybe that could be implemented at some point.)
One last thing:
I would imagine Sonnox Pro can also decode to 32 bit float if they are MFiT “compliant” (?). Don’t know how they’d do it otherwise, because you can’t do it with 16 or 24 bit fixed.