Is Freeze & BTD reliable??

[Yiannis]

Hi guys...I am doing some null tests in DP 10 (and Logic too with identical results) to find out why VIs do not sound the same after freeze or BTD.

In my tests nothing completely nulls and as far I can see there are not phasing problems in waveforms.

I am using a Model 12 with a simple drum pattern.

Photo 1 = Model 12 + Freeze 1 _1024 buffer
Photo 2 = Model 12 + Freeze 2 _128 buffer
Photo 3 = Model 12 BTD + Freeze 1
Photo 4 = Freeze 1 + Freeze 2
Photo 5 = BTD + BTD playing and record it RT
Photo 6 = Freeze + Freeze (BTD)
Photo 7 = Model 12 + BTD 1024 buffer
Photo 8 = waveforms

[FMiguelez]

Hi, Yiannis.

Very interesting. This post is right up my alley

I've done tests similar to yours, with very surprising results.

Let me ask you, how is your session set up? Are you using 24 or 16 bits? I ask because, if you want to test DP real-time performance VS BTD or Freeze, you must set your session at 32bFP (in the transport). This way, your Freezes will be printed at 32bFP and not 24 or 16 bits, which makes a HUGE difference in the resulting noise floors in the difference meters.

From what I see, your noisiest picks reflect a 16 bit noise floor. How did you bounce it? When you bounce, make sure it's 32bFP too (DP's native internal precision), that way you compare apples to apples.
Let me suggest this little free gem, which lets you see the bit usage at any point in the chain.
https://www.stillwellaudio.com/plugins/bitter/

For me, my tests showed the following>
Playback, 32bFP VS BTD, 32bFP = Total null
Playback, 24 VS BTD, 24 = Total null **
Playback, 16 VS BTD, 16 = Total null **

** DP's internal precision playback was changed to 24 or 16 bits with Waves L2 limiter, with the proper settings to avoid seeing the quantization distortions stemming from the difference between 32bFP and 24 integer in the difference meter.

That worked fine by letting the limiter do the truncation with NO dither and NO noise-shaping. The moment one uses any of those parameters, all bets are off, and it led me to discover multiple issues with Waves Lx series limiters, such as>
Dither Type 2 does not work at all. The signal coming out with this setting is not dither. I still managed to make them null out.
If one uses Noise Shaping, then the difference meter shows very weird things and it won't null anymore with a high noise floor.

For Freeze (and Merge command), I discovered that DP does NOT use dither correctly (the dither in one of the menus) when freezing to 24 bits. It dithers correctly with any other bit depth, but NOT 24 bits.
Also, DP's MW limiter exhibit the same behaviour> No dither when using 24 bits. Another bit depth such as 11 bits is fine.

So if you guys have been using that, just know that all your 24-bit freezes are truncated from 32bFP resulting in QD.

As far as I could see, it mostly works as it should, except for the Freezing at 24 bits, which doesn't dither. The other difference I attribute it to a Waves bug.
Normally, the only difference between realtime VS Freeze VS BTD is the QD or dither from the from the 32bFP to 24 bits truncation (if not taken into account), which is totally expected.

So do your VIs sound that different when bounced or frozen?? It would be awesome if you post a couple of audio examples between Logic and DP, or between DP live VS DP BTD, so we can hear them. We might figure something out...

[Yiannis]

Hi FMiguelez ....thank you for the answer/infos!!!!!

I did the test using 24bits....everywhere....

I will do it again using 32 bit as you suggested...

Should I turn off Dither from the menu?

If interesting I can post the project here for testing......and I will of course come back with new results from Dp and Logic......I just need some time.....

EDIT: using 32 bit made everything null except the RT VI with the freeze or BTD

[FMiguelez]

Hi FMiguelez ....thank you for the answer/infos!!!!!

I did the test using 24bits....everywhere....

I'm pretty sure that's the difference in the meter that we're seeing (truncation from 32bFP to 24 integer).
We'll know soon enough, for sure

I will do it again using 32 bit as you suggested...

Awesome!
Yes, try 32 VS 32, then 24 VS 24 and 16 VS 16. You could also try 32 VS 24/16, just for the heck of it. You'd use a truncator when not using 32bFP, of course. You can even use the truncation part of any limiter ONLY (without limiting), but don't use the plugin's dither or noise-shaping for now (you could save that for another set of tests ).

Should I turn off Dither from the menu?

I would do tests with and without the dither in the top of the menu (forgot which one). Just make sure you always match and compare the same things/settings. See if what you get is what you expected to see (true good dither is supposedly random, or as random as they can get it. Yet, do you still get it to null out completely??)

And yes, please post a couple of audio examples of the most obvious or problematic ones (like one recorded from a live DP VS bounced or frozen).

Question, are you looking into this just for curiosity, or are you trying to solve an obvious problem that you noticed from the sound (as in your bounces/freezes sounding noticeably different)?

[Yiannis]

Question, are you looking into this just for curiosity, or are you trying to solve an obvious problem that you noticed from the sound (as in your bounces/freezes sounding noticeably different)?

Well mostly out of curiosity...a friend of mine gave me the idea about Vis.....


As I wrote in my edit above everything in 32 bit is nulling each other Dither or not......except the RT Vi with the BTD or FZ....

Its just a quick test following your suggestion.....but its working.....

So I guess 32bit projects is the way to go from now on.......

[FMiguelez]

So I guess 32bit projects is the way to go from now on.......

Hmmmm.... Yes and no...

I mean, if I were to work on a project where I need to constantly Merge or process lots of audio offline, I might consider it (but end up not doing it).

I would certainly NOT record or freeze my individual audio channels or VIs to 32bFP. That would be a colossal waste of space for virtually an unnoticeable change in noise floors (unless, of course, you can hear a difference between a -192 dB and -144 dB noise floor on top of your music and studio noise ---> You're human, so you can't).

Remember that DP ALWAYS processes everything internally at 32bFP anyway, even if you were working with 16 or 8 bit audio files, so you don't need individual 32bFP files.

Personally, the ONLY time I print to 32bFP, is when I print my final stems, and this is mostly to avoid dealing with the unavoidable issue of dither noise VS quantization distortion when truncating from 32bFP to 24 integer.

Honestly, I could print them at 24 bits perfectly fine and never know the difference, but that's one of the very few times I allow myself to indulge and go all-irrational, otherwise I might not be able to sleep worrying someone will hear QD at -144 dB in their iPhones while riding the bus on their way to work...

I suggest you do more tests, so you see all these details and see if you can convince yourself or not.
According to my tests, I'd print individual tracks/VIs at 24 bits, if I were you.

[Yiannis]

Thank you very much for your time on all these detailed explanations

All these was quite an eye-opener...

[terrybritton]

I would certainly NOT record or freeze my individual audio channels or VIs to 32bFP. That would be a colossal waste of space for virtually an unnoticeable change in noise floors (unless, of course, you can hear a difference between a -192 dB and -144 dB noise floor on top of your music and studio noise ---> You're human, so you can't).
------------------------------------------

Personally, the ONLY time I print to 32bFP, is when I print my final stems, and this is mostly to avoid dealing with the unavoidable issue of dither noise VS quantization distortion when truncating from 32bFP to 24 integer.

Honestly, I could print them at 24 bits perfectly fine and never know the difference, but that's one of the very few times I allow myself to indulge and go all-irrational, otherwise I might not be able to sleep worrying someone will hear QD at -144 dB in their iPhones while riding the bus on their way to work...

Quite the eye-opener and really quite a great sense of humor, my friend!

Terry

[Yiannis]

I've made two test files.

One is a bounce of the Vis .
Then I froze track by track the Vis and then bounced to disk.
Same volume and panning.
Files are at 32bits........they do not null because there are a lot of differences in the waveforms....don't know the reason.

Do they sound the same..??......I ll be happy to talk about it

https://www.dropbox.com/s/4b9jxcf7bqsc2 ... s.zip?dl=0

[FMiguelez]

I won't be able to listen to them critically in my studio until the weekend.
The way they sound in my iMac in the noisy apartment, they sound the same to me.

Yiannis, this is very important> Most VIs have lots of round-robin and random-sample playing, so you won't always get the same sample for the same performance.
There are certain elements, like analog emulation stuff within some VIs, that would probably never sound identical either.

Are you bouncing directly from the MIDI VIs or from their pre-rendered/recorded audio?
How are you bouncing? From VIs or audio files? That could make a LOT of a difference.

Since I suspect you're doing the former, my suggestion would be, to account for those variables, to make a few tests by recording (in 32bFP and 24 bits) your VI in an audio track. Then, from THAT audio file, try bouncing or freezing, as you've been doing.

The point of this test would be to see if those differences you see are due to what I mentioned above about round-robin samples, etc., or if there is truly some kind of problem with your freezes/bounces, which I doubt.
Also, to kill 2 birds with one shot, you could compare your 32bFP VS 24 bit recordings so you SEE for yourself that printing individual audio tracks/VIs at 32bFP is not worth it at all.

Also, I suppose MIDI playback will never be as accurate as audio playback. I wouldn't be surprised if there are lots of discrepancies at the sub-millisecond/sample level, and this would never let you get perfect nulls.

If there's a way for you to program one of your VIs to IGNORE round-robins and similar actions, that would be THE test to do too, of course, and much closer to what you're looking for. You could do this in Kontakt or MachFive easily.

[FMiguelez]

Now I'm almost sure your issue is what I said above.

From your files, I get total cancelation for the strings, the snare (not stick/rim), most of the kick, a lot of the bass, and some other stuff. The guitar seems immune to any cancellation, and it just sounds phased (again, in my apartment with my iMac). This intrigues me. How did you freeze it? Does the VI have like a million samples per velocity level and RRs? Which guitar VI is that and how does it work?

Testing just the guitar alone would be good too.

To know for sure, you'd need to do the test I suggested above. You need to guarantee you always get the SAME samples for the same performance. I don't see any other way.

[Timeline]

Hi, Yiannis.

Very interesting. This post is right up my alley

I've done tests similar to yours, with very surprising results.

Let me ask you, how is your session set up? Are you using 24 or 16 bits? I ask because, if you want to test DP real-time performance VS BTD or Freeze, you must set your session at 32bFP (in the transport). This way, your Freezes will be printed at 32bFP and not 24 or 16 bits, which makes a HUGE difference in the resulting noise floors in the difference meters.

From what I see, your noisiest picks reflect a 16 bit noise floor. How did you bounce it? When you bounce, make sure it's 32bFP too (DP's native internal precision), that way you compare apples to apples.
Let me suggest this little free gem, which lets you see the bit usage at any point in the chain.
https://www.stillwellaudio.com/plugins/bitter/

For me, my tests showed the following>
Playback, 32bFP VS BTD, 32bFP = Total null
Playback, 24 VS BTD, 24 = Total null **
Playback, 16 VS BTD, 16 = Total null **

** DP's internal precision playback was changed to 24 or 16 bits with Waves L2 limiter, with the proper settings to avoid seeing the quantization distortions stemming from the difference between 32bFP and 24 integer in the difference meter.

That worked fine by letting the limiter do the truncation with NO dither and NO noise-shaping. The moment one uses any of those parameters, all bets are off, and it led me to discover multiple issues with Waves Lx series limiters, such as>
Dither Type 2 does not work at all. The signal coming out with this setting is not dither. I still managed to make them null out.
If one uses Noise Shaping, then the difference meter shows very weird things and it won't null anymore with a high noise floor.

For Freeze (and Merge command), I discovered that DP does NOT use dither correctly (the dither in one of the menus) when freezing to 24 bits. It dithers correctly with any other bit depth, but NOT 24 bits.
Also, DP's MW limiter exhibit the same behaviour> No dither when using 24 bits. Another bit depth such as 11 bits is fine.

So if you guys have been using that, just know that all your 24-bit freezes are truncated from 32bFP resulting in QD.

As far as I could see, it mostly works as it should, except for the Freezing at 24 bits, which doesn't dither. The other difference I attribute it to a Waves bug.
Normally, the only difference between realtime VS Freeze VS BTD is the QD or dither from the from the 32bFP to 24 bits truncation (if not taken into account), which is totally expected.

So do your VIs sound that different when bounced or frozen?? It would be awesome if you post a couple of audio examples between Logic and DP, or between DP live VS DP BTD, so we can hear them. We might figure something out...

I'm glad someone explained this. I have been freezing and hearing slight differences for a while. I'm now exclusively in 32bitFP so I guess you recommend I turn off dither entirely from the pulldown audio menu select?

[labman]

this is all super interesting folks. Thanks for bringing this up Yiannis.

[HCMarkus]

Most VIs have lots of round-robin and random-sample playing, so you won't always get the same sample for the same performance. There are certain elements, like analog emulation stuff within some VIs, that would probably never sound identical either.

This.

And yes, FM... like Terry, I love the way you put things in context with an iPhone and a Bus.

[Yiannis]

Yiannis, this is very important> Most VIs have lots of round-robin and random-sample playing, so you won't always get the same sample for the same performance.
There are certain elements, like analog emulation stuff within some VIs, that would probably never sound identical either.

Very true ...how did I miss that????I will do another test project using Nano sampler...I suspect it does not use round robin

Are you bouncing directly from the MIDI VIs or from their pre-rendered/recorded audio?
How are you bouncing? From VIs or audio files? That could make a LOT of a difference.

Directly from the MIDI VIs.

Since I suspect you're doing the former, my suggestion would be, to account for those variables, to make a few tests by recording (in 32bFP and 24 bits) your VI in an audio track. Then, from THAT audio file, try bouncing or freezing, as you've been doing.

I will do as you suggest and post results

this is all super interesting folks. Thanks for bringing this up Yiannis.

Thanks labman...