One main concern I see is that when Ozone 6 dithering is enabled and set to 16-bit for example, the Ozone bit meter shows 16-bit but the Wavelab bit meter still reads 24-bit. With any other dithering I try, the Wavelab meter reads 16-bit as expected when dithering to 16-bit in a montage.
I am going to guess that it’s an Ozone bug and I have reported to them, but I wanted to mention this incase anybody else is already using Ozone 6 both as a warning, and maybe somebody can double check this issue post their results. I don’t think I have any other place to analyze bit depth like I can in Wavelab.
Thanks for reporting, I’ll be upgrading later, and will get back with results. I don’t use MBit in Ozone anyway since we already have it in WL, but it should work correctly ofcourse…
Lorne from iZotope is telling me that Ozone " is not actually changing the bit depth or truncating the file (it is merely applying dither). As such, if source file is 24-bit, it should still read as 24-bit after Ozone in the signal chain (it is assumed the host program will change bit depth upon export)."
I don’t know what to make of this, but I know that anytime I add dither to 16-bit via a limiter like FabFilter Pro-L, Elephant, Waves L2, and even Ozone 5 and the standalone MBIt dither that comes with Wavelab, that the bit-meter in Wavelab changes to 16-bit.
Ozone 6 is the only plugin I have where setting the dither on the plugin still causes Wavelab bit-meter to show 24-bit (as that is the bit-rate of the source file in my montage).
I have some doubts about Ozone 6 dithering properly. Alexey from iZotope (I believe) says that it could be that the DC offset is after the dither and that would certainly be wrong and produce strange results. I have to agree with him but will keep trying to get iZotope to look closer.
If anybody else has any idea or info on what is happening it would be appreciated. I honestly haven’t used Ozone as a final limiter for some time now but it would be good to have it working proper if needed.
Yeah, sure, the source file is 24-bit but IMO the important thing is the apparent bit resolution of the audio data, not the bit resolution of the source file. I believe I am correct in saying that this is what the bit meter is detecting. It shows us the wordlength being used to express the audio in the file, not the source file resolution. So it seems odd that if you set Ozone 6 to 16-bit and you see 16-bit on the Ozone bit meter, this is not detected on the Wavelab bit meter.
If you use any other 16-bit dither on a 24-bit file and render / process in place and then de-activate the dither plug-in, you see 16 bits on the bit meter. You could still save this audio as a 24-bit file, but when you re-load it into Wavelab it would still register as 16-bit on the bit meter. In other words it’s a 24-bit audio file where the audio data within the file is expressed in 16-bits.
In the case of applying 16-bit dither to a 24-bit source audio file, how can Ozone “merely apply dither” without also reducing the bit depth used to express the audio?
Dither is a signal added before truncation, and ensures that the truncation produces the best possible result. If you don’t truncate, you haven’t damaged the signal, but have merely added noise; but there is no point in dithering if you are not going to store the truncated result.
As you are presumably going to store a truncated file after dithering (there’s no point otherwise), there’s no need for the dither routine to zero the bits that are going to be discarded; in practice some do and some don’t.
Of course, we need to bear in mind that there are circumstances where you’d want to add dither to a signal after digital processing and save it in the same resolution as the source.
The thing I don’t understand about the Ozone 6 example is the bit meter (see the screen capture above). Are you suggesting that the bit meter within Ozone 6 displays something different to the Wavelab bit meter (one displays 16-bit while the other displays 24-bit for the same audio material)?
Surely, both meters should be measuring the actual bit resolution of the data and therefore measure the same number of bits?
Which plug-ins (other than possibly Ozone 6) do not zero the bits that are going to be discarded?
After further testing our QA team was able to find an issue where the DC Offset Filter was incorrectly being applied post Dither and Maximizer. This can definitely cause the signal to pass the ceiling level in the Maximizer. I am not sure if this would also affect the bit meter, however our QA and Development will be investigating this further either way.
In the meantime, disabling the DC Offset Filter should at least stop the signal from passing the Maximizer ceiling. I am sorry for any inconvenience this may cause!
I think that they made a mistake by having the DC offset last in the chain. Not only is it causing improper or lack of actual dither, it’s also causing signals to go over 0dB when they should not.
I can easily create a situation where the Ozone bit meters read 16-bit, while the Wavelab bit-meter reads 16-bit. One of them isn’t right and in this case it has to be an Ozone 6 problem.
I’m curious. I have Oz5 and 6 and I’m not having this problem. The WL program has the control over the file type you are going to save, whether 16bit or 24, or 32, etc. So I load Oz6 and turn it’s dither to 16bit, select the 16bit file save option in WL and I produce a 16 file with the appropriate dither.
What are you guys talking about? Perhaps are you saying that because I choose to add the 16bit dither in Oz6 and setup WL to export in 24bit - that I should end up with a 16bit file? You are not suggesting this are you?
Addressing the first post, your sound source is 24bit, you set the dither in Oz6 to 16bit, and you end up with a 24 bit file upon rendering. Correct? I did not see that you were using the DC Offset in Oz6, which is another problem entirely. And I agree, this is broken in Oz6.
My initial concern is that when I have Ozone 6 inserted last in the chain, and set the dithering to 16-bit, the Wavelab bit-meter still shows 24-bit when playing the audio. This is prior to any rendering and different behavior than all the other dithers I have access to, including the iZotope MBit dither bundled with Wavelab. Setting the standalone MBIt dither module to 16-bit in a 24-bit montage, causes the Wavelab bit-meter to read 16-bit, even just when playing the montage before doing any file rendering.
Yes, the rendered file is 16-bit if I choose 16-bit and render, but with all the other limiters and dithering I have access to, setting the dither to 16-bit while playing 24-bit files in a montage causes the bit-meter built into Wavelab to show 16-bit when playing back prior to actually rendering the file.
For this reason, I question if Ozone 6 is properly applying dither.
IMO Jperkinski has not been suggesting this at all. In terms of the actual bit resolution of the data, the result of this exercise would depend entirely upon whether the Ozone 6 16-bit dither zeros the bits that are going to be discarded. If it zeros the bits that are going to be discarded then you would indeed end up with a 24-bit file within which the audio data would have an apparent bit resolution of 16 bits.
At this point (when you turn Ozone 6 dither to 16-bit), does the Wavelab bit meter also read 16-bit?
I have WLE8 and an independant bit rate meter. When I switch Oz6 to a 16 bit rendering and add the 16 bit dither (and do not use the DC offset feature) my bit rate meter shows that Oz6 is producing a 16 bit product. So things seem fine with Oz6.
I’m simply speaking of what the Wavelab bitrate meter shows prior to rendering, when I’m just playing 24-bit audio in the montage. I am not talking about what happens on a rendered file.
Every limiter and/or dither I have besides Ozone 6 causes the Wavelab bit meter to read whatever I set the dither to. If I set the dither to 16-bit on a limiter or dither module, the Wavelab bit meter shows 16-bit. Again, not on the rendered file, just in the montage on playback.
For some reason with Ozone 6, setting the dither to 16-bit still causes Wavelab bit meter to show 24-bit. DC Offset is disabled.
For some reason, only the 8-bit setting on Ozone 6 causes Wavelab bit meter to also read as 8-bit.
Eh, I’m using the ‘rendering’ word incorrectly, my bad. Rendering is a WL word the refers to a finished file. However there is a bit rate truncator within Oz6 - in the area to the left of the Oz6 dither display. Here you can/must select different bit rates within Oz6 if you want to change the bit rate. The function is prior (I assume) to the Oz6 dither option.
Arrg! Sorry about this misdirection, I was away from my DAW and was trying to help - but I see that when you choose the bit rate in Oz6, then the dither follows. You probably caught this, too, but you have the DC offset turned on in your picture - this is fubar in Oz6. But if you have turned this off and still cannot get the WL meter to show a 16 bit rate then I have no solution for you. Sorry. Using my independent bit rate meter called ‘bitter.vst’ from the Stillwell site, I am not having any problems here. Perhaps you could download the free bitter plugin and see if you get the same results?
Yes, I’m aware of how the dither is suppose to work in Ozone 6. When dither is set to 16-bit in Ozone 6, and running live in real-time in a montage, the Wavelab bit meter reads 24-bit. All other dither modules and limiters with dither that I have cause the Wavelab bit meter to read whatever the dither module is set to.
This leads me to believe that Ozone 6 isn’t dithering properly despite what the built in bit meter of Ozone says. I think if Ozone 6 were dithering properly, the Wavelab bit meter would show the same bit rate as I have Ozone set to, and what the Ozone bit meter says when running live in a montage. The only time that the Wavelab bit meter matches the Ozone bit setting, is when I set Ozone 6 to 8-bit for some reason.
Again, this is not for rendered or processed files, I’m just running Ozone 6 live in a montage with a 24-bit file as the source. iZotope has acknowledged a problem with the DC Offset module so of course these tests are without DC Offset active, but perhaps the positioning of the DC Offset module is causing this bit rate output problem with Ozone 6.
I’ll attach results again with a few different dither modules and limiters that have dither. Every single one causes Wavelab bit meter to correspond to the dither settings. Ozone 6 is different and suspect.
OK, I see your screen shots and I see what you are describing. Honestly, I do not have this experience over here.
I can run a 32 bit float track and run through all the bit rates in Oz6 without a hitch. (However, I DO have to hit the ‘reset button’ on the bit rate display meter in Oz6 for it to actually show in Oz6 what is happening.) But all the while, my Bitter plugin tracks the changes, no problem.
Since the Bitter plugin shows things correctly, I have to wonder if is a case where Oz6 does not talk to the WL bit rate meter correctly?
iZotope is trying to equal WL as a mastering program, maybe there is some unintentional conflict? Meanwhile, are other users of Oz6 and WL experiencing your problem? I can’t imagine it’s just your setup. Maybe ask PG to download Oz6 and try it?
