Another open-source tool (simple truncation, no rounding or dithering)
I compared the results using FFT spectrograms and I’m sad to report that of the above, only WaveLab gave rise to aliasing artifacts (very quiet but still there).
The attached pictures show Hanning spectrograms with FFT size of 4096 (from Audition 3).
I’m attaching the original 24-bit wav file (7zip archive inside a zip archive, because your server has 4MB limit and doesn’t accept 7z format uploads).
If you want to reproduce this, please keep in mind that the gamma of the pictures was substantially increased to make the artifacts easier to see (they are too quiet, so they are rendered in very dark colors). If you do not increase the gamma, you won’t be able to see them.
All of this might not be a flaw but a subtle difference in how the programs approach the conversion. How does WaveLab convert to 16 bits?
One thing that comes to my mind — does WaveLab supersample the data to a much higher sampling rate before the bit depth conversion, then converts to 16bit and finally downsamples to the original sampling rate? If so, then I think that could definitely be the cause of the artifacts. The solutions would be either not to supersample or to do the conversion to 16bit as the very last step.
BTW, I might not be the only one who noticed something strange with conversion to 16-bit (didn’t have time to read the thread though, might be wrong): Signal generator distorting in 16-bit
I think you’re slightly confused. Sample Rate and Bit Depth have nothing to do with each other - no sample rate conversion, either up or down, should occur when changing bit depth.
Gr8h8m, it seems to me you spent 5 seconds at maximum to “read” my post. Believe me that I’m not confusing sample rate and bit depth. And I know what they mean. So, please, re-read my post to understand better what I wrote and why I mention sampling rate when the problem is bit depth conversion.
No, WaveLab does not resample anything, for sure, when converting to 16 bit. What it does is a raw truncation of the extra bits.
There are several ways to truncate samples, and WaveLab chooses the fastest method. There is another method that implies some rounding of the lowest bit, which certainly corresponds to what some other applications do.
The reasons why WaveLab does not round sample values:
it’s faster
the difference only concerns the lowest bit of about half the samples: if the user is concerned by this last bit (-90 dB), then that means he should know that dithering should be used when converting from 24 to 16 bit.
This is why I consider this not an issue. Else, in which case would it matter, according to you?
Note: I tried with the latest Audition version, and it does exactly as WaveLab.
Apologies if I’ve somehow offended you - not my intention, merely to educate. No sample rate conversion should be taking place at all to change bit depth.
Well, then WaveLab uses exactly the same method as the open source tool (raw truncation without rounding, no resampling, no dithering).
So then how can WaveLab produce the aliasing artifacts while all of the other applications do not? And the open source application — I know what it does, as I read the very simple and short source code.
This is easy to reproduce with the attached file. You can use any of the listed applications plus WaveLab Pro 10. But please don’t forget to increase the brightness or gamma of the FFT spectrogram, because the artifacts are the quietest levels so the darkest colors.
I have looked closely at what WaveLab does before my first answer. I also tried your file and a few other applications (this is why I said the latest Audition version operates as WaveLab).
This being said, I have already answered: WaveLab truncates in a slightly less accurate but faster way.
Don’t be misled by your over-amplified graphics that reveal frequencies at a level as low as -90 dB.
This results from the WaveLab choice: “favor speed over accuracy.”
Now, I have to admit that today, compared to 15 or 20 years ago, the performance gain of the WaveLab method is probably negligible.
In fact, “truncating” is also a way of rounding. This is rounding “toward zero,” which is used in WaveLab and Audition. The other way is to evaluate if the lowest 8 bits of the 24-bit samples are closer to 0 or 1 in the 16-bit space (aka nearest rounding).
But you did not answer me (see my previous message): where is the actual problem, since your report is about a procedure nobody should do (not using dithering when reducing the bit depth). Especially for someone like you who seems to be knowledgeable about audio quality
First, thanks for looking into this, and responding so quickly in the official forum while discussing the internals of how your product works (not very common in the field of commercial software).
Now, I’m not sure if I’ve been making myself entirely clear, because you haven’t answered the most important question. So let me rephrase this.
Does WaveLab do this in C++ terms to convert from 24 to 16 bits?
a_16bit_val = a_24bit_val >> 8;
If yes, then it does exactly the same as the tool whose output you see in the screenshot.
So why does WaveLab produce the aliasing and the tool does not? And it doesn’t matter it is quiet, it is still there and something a pro mastering application should strive to avoid at all cost.
In other words, it is obviously possible to produce alias-free 16bit version without dithering and without rounding. So why does WaveLab not do that and the others do?
Your final question is not really relevant here, because 1) none of the other apps used dithering either (so I’m comparing apples to apples) and 2) if I use ‘Save As’ in WaveLab, I don’t see any option to dither (so I could turn that around and ask you why does WaveLab allow this use case that nobody should do? ).
WaveLab does not do this because, internally, all samples are 32 or 64-bit floating points. Hence the computation is different (I don’t want to enter details here).
Aside from this, “a_16bit_val = a_24bit_val >> 8;” in the integer space, is not the most accurate way to round samples (but it’s the fastest).
I have measured today the impact of using the more accurate way, and it’s rather neglectable as I expected. I will therefore change this in the next update so that you can have nice graphics
But from the audio POV, nobody will ever notice the difference.
Again, this is a corner case since this is not a procedure anybody should do if he cares about getting the best audio quality (and for those who don’t, that micro difference doesn’t obviously matter).
Wow, honestly, I’m pleasantly surprised. As I was reading this, I did not expect you would actually go ahead and make any changes to WaveLab. Bravo and thank you!
I am still very curious though as to what caused that aliasing? It’s a complete mystery to me. Since the fact that WaveLab internally converts everything to 32- or 64-bit floating point numbers shouldn’t cause that, right? There should be something else…
By they way, I would like to get back to your question – you asked what is the point of all this if you should always dither when going from 24 to 16 bits. Well, I have a different opinion — dithering is not always required when converting from 24 to 16 bits. On the contrary, in some cases (like this one) it should be avoided. For example, any normalized sample that doesn’t have quiet portions (like this I was using), typically a synth instrument – a single looped tone. In such cases, dithering is not only redundant but can even be harmful, for the following reasons:
(1) It introduces redundant noise to something that was completely noise free (eg. a synthetically generated waveform such as this one, and some DAWs still don’t support 24bit samples)
(2) If the rendered sample is used as an instrument in music creation, the dither is going to accumulate and get louder. 10 or more sustained notes playing simultaneously (nothing unusual in string pads) amplified by echo/reverb effects and also a final extra dither will be applied somewhere at the end when converting to 16 bits.
So there, that is my use case for 24-to-16-bits conversion without dithering.
Hello, so I can happily report that this issue is fixed in Wavelab Pro 11.1, even though the changelog appears to be completely silent about it. That’s one more reason I am still quite curious to learn how the aliasing was caused.
Thank you!
