Bounce v. Freeze v. Realtime: What's the skinny?

[MIDI Life Crisis]

We've been reading here on m'nation from some members that realtime is the only way to go. Bouncing, they say, is "not reliable" and "leaves pops and clicks" in the mix to which I have said: phooey! Well, I will have to eat a few of my words on that - but y'all who think bouncing is bad are not quite off the hook yet and I will continue to bounce more than ever now. Here's why...

I started to encounter this problem for the first time last week on a wonderful new piano VI (True Keys from VI Labs) and of course, I blamed the new VI. Bouncing always worked extremely well before, so why now and why with this VI?

FIRST: Not all VIs are created equal.

Some are more demanding than others and I suspect that the more elaborate VIs with more samples, velocity switching, release samples (like the sound of the damper leaving the string when you release the key on the True Keys VI) etc., require more processing. In realtime playback, this isn't an issue and you don't get loud clicks or dropouts, but in freezing and bouncing DP is obviously doing some serious calculation under the hood.

So I started looking not at the bounce process itself for clues as to why this was happening, but to the MIDI tracks themselves. What I discovered, at least in this instance, was that if a note off occurs "too close" to the next note on (and I cannot define what that means just yet and probably never will) then the file would not render correctly. The drops outs I was getting always occurred when there was a note off followed by a note on in quick succession at the same pitch. I don't mean fast repetitions as you might normally play notes as a human, but fast repetitions that are NOT playable by most humans and which most instruments (if any) are not capable of.

Along these same lines, what I also discovered was some of the clicks and pops and dropouts were the result of double notes. How they got there is another story, but they were there and they were causing the problem; NOT DP, in and of itself. If I listened very carefully to the MIDI/VI playback, I could hear what I'll call "weirdness" but there was, indeed, an artifact in the MIDI playback before the bounce was performed and it needs to be corrected in the MIDI performance.

SECOND: Velocity rip-tides! I can't think of a better name, but here's what I mean.

Passages with sustained loud content that doesn't decay before the next wave of sound washes in can make the audio signal "stack up" and peak a little hot. Again, in realtime, this is not a problem and if it is, you hear it and fix it. But in the virtual world of bouncing and freezing, again, DP is making calculations as a high rate of speed and a particularly complex set of instructions in a VI might be "misinterpreted." Or are they?

I was getting clipping at sections like that with True Keys and when I looked at the original MIDI performance data I noticed that I had several very high velocities in a row. When I focused my attention to the MIDI/VI playback, I could hear a very tiny amount of clipping I had not noticed before. But in bouncing and freezing, they became very noticeable. Once I dropped the velocity setting on a couple of them slightly, even just a few points in an inner voice, the tiny click in MIDI playback was gone, as was the glitch in the bounce.

Once I corrected the duplicate notes, fast repetitions (again, not anything that affects the actual music performance, but apparent performance errors) as well as the velocity caused clipping (which again, was barely audible but there in the MIDI playback) then the bounce was PERFECT. BTW, you might not hear the clipping in your realtime record, but if it's there, it's there, and at some point a digital copy may well reveal the error. I've been there and it's not a pretty place to be and I am thankful that I can find it with bouncing to disk before some TV station uber-compresses my score and the clicks pop out!

BOTTOM LINE:

Bouncing is 100% reliable, but like a chain, it is only as strong as it's weakest link. Fix the inherent problems and the resulting audio is exactly as it appears in the project.

I am indebted to True Keys for helping me discover this on my system. Not only did it reveal what the issues are for bouncing and freezing and why we hear clipping and artifacts, but in doing so it also helped me clean up my tracks of errant notes, gentle clipping, and performance anomalies.

[Shooshie]

I agree. Before I bounce to disk, I do several run throughs (if there is time, but always at least one run through) listening carefully for clicks and pops. If I hear one, I go back a few measures and listen again, to determine if it's in the tracks themselves, or if it was something like an appliance coming on somewhere else on the electrical circuit. Once I've determined that the tracks are clean, I bounce. I've never had a failure.

Sometimes I have to separate notes that are too close (or especially overlapped). I've learned that if I reduce the entire mix a few dB so that I'm not recording so hot, I do not encounter many problems of clipping, and those that I do encounter are fixable with a brick wall limiter set for -1dB with a -2dB threshold -- in other words, not something that will affect volume, but will effectively limit peaks.

I read the threads about bouncing to disk not being reliable, and I don't respond, because it gets into something like a religious battle, and I really don't want to get involved. Besides, I cannot prove that bouncing to disk is reliable on someone else's computer, only on mine. That's why I haven't stood up and yelled "STOP! This is crazy talk!" All I can say is that when I have cleaned my tracks of anything that would cause a pop, bouncing to disk has always been 100% reliable on my computers.

Shooshie

[MIDI Life Crisis]

Thanks for posting that, Shoosh. I thought I'd have to get my asbestos under garments ready and frankly I'm surprised at the silence. Clearly, we both found the same cause and solution and you'd think folks who are died in the asbestos non-bouncers would check their tracks at the critical points. you would think that, or at least, I did. Oh well...

And now for something entirely different...

[FMiguelez]

That was an awesome post, MLC!

You may have nailed at least one common cause of BTD unreliability. I think you found a pin in a haystack, and a unintended new way to use BTD.

I will certainly keep your findings in mind next time I bounce some VI stuff, and will do some tests as well. Perhaps I will discover some of these little Gremlins in the MIDI you talked about.

OTOH, I must say I've had at least an equal amount of BTD errors when bouncing audio-only stuff. Actually more like 90% of the time, because I usually print all my VIs in realtime in one pass, so when I bounce it's almost always audio-only.

I am one of those who recommend recording the final mix in real time, but I am ALWAYS careful to add and imply that my BTD problems could very well be not DP's fault, but the fact I'm using an old and underpowered computer (G5) as my master computer.

The only constant observation I've been able to make is that the unreliability is directly proportional to the size and complexity (automation and I/O routing) of the project.

Hopefully I will eat my own words and enjoy BTD when I get a new computer... We'll see.

[MIDI Life Crisis]

I should also mention that BTD with a low buffer setting can be a disaster. Go the higher settings whenever possible.

[cloudsplitter]

I have never had a problem with btd...ever....i do make sure that MIDI notes never "touch" for lack of a better word. I do that by expanding the MIDI notes and checking their durations. Also freezing a MIDI track first and listening back to the freeze is a good way to monitor the outcome of the bounce

[FMiguelez]

i do make sure that MIDI notes never "touch" for lack of a better word. I do that by expanding the MIDI notes and checking their durations. Also freezing a MIDI track first and listening back to the freeze is a good way to monitor the outcome of the bounce

Wow!
With all due respect, if I have to do all those things just to get a reliable bounce, then it is a waste of time because you accomplish the same, at a fraction of the time and effort, by recording in real time.

Not only that, but depending on the instrument and VI, sometimes one MUST have some overlap between MIDI notes.

I just can't imagine going through every track adjusting the note releases for BTD to work.
If it worked, none of that would be necessary. That's the bottom line.

[MIDI Life Crisis]

Well I hate to sound academic about this as I am far from an academic in the first place, but precise data entry on a reliable controller will generally result in a performance that is not in conflict with the standards of notation and/or playing an actual instrument. The VIs are modeled after these real world instruments and personally, I find great comfort in the fact that the virtual instrument requires (in some cases) a musically correct, precisely articulated performance. Sloppy overhanging parts, double notes, too much volume, etc., can cause it to misbehave. I like that.

For myself, I like that it forces me to play better, be more observant, understand how the music works, not the technology. If the notes are entered precisely the technology should not get in the way. What I am finding is that the more careful I am in my performance the better my chances the technology will behave. Still, in my current project I have need for MIDI data like this (all high velocity):



So yes, be courageous, break the rules! But when things start going bad on your bounces, just remember that it's not the bounce that's bad, but something in your data. If you're ok with that and choose to do realtime, go for it. Personally, I want to know where the problems are and I want to fix them - at least as many as I can find.

[Kubi]

I never bounce. Has nothing to do with technology, though - when I listen to the music as I "print to tape" my brain works differently - no matter how many times I have listened to it before, no matter how many "last nips and tucks" rounds I have already given myself, I inevitably find a couple more things to change, but only *if and when I'm printing.*

So since the days of actually going to tape I need the printing stage for my last nips and tucks, it's become an integral part of my creative process.

Back to your technical discussion! I do believe that bounce works just fine!!!!



(PS: That is, I do seem to remember talk that there are/were at some point a few 3rd-party time-based processing plug-ins around that aren't/weren't too good with bouncing - but I really wouldn't know....!)

[Frodo]

Bouncing is 100% reliable, but like a chain, it is only as strong as it's weakest link. Fix the inherent problems and the resulting audio is exactly as it appears in the project.

107% agreed.

It's just that now I want to do a three-way shoot-out on Bounce/Freeze/RT in the same project just to *see* what's up.

I'm wondering if there are any instances in which the "clean" MIDI rendering results in any artifacts (clicks or pops). That would concern me the most. If I've done sloppy MIDI input, it's easily fixable. But, if I've cleaned up my MIDI "ons and offs" and the bounce or freeze or RT render results with glitches, then it would raise the question-- "what do I do next?".

So far, that hasn't happened (happily). Granted-- I got this new machine only a couple of months ago and then left town for a while. I have yet to really hammer away with it and DP8 on a major project to uncover any noticeable anomalies with respect to the topic at hand.

FIRST: Not all VIs are created equal.

Some are more demanding than others and I suspect that the more elaborate VIs with more samples, velocity switching, release samples (like the sound of the damper leaving the string when you release the key on the True Keys VI) etc., require more processing.

Very true!

That said, on older machines, I'd resort to first bouncing or freezing *stems* (according to the VI group) just to keep tabs on how a particular VI functions under the duress of rendering. (Audio tracks have been much more predictable on this end.) These are good "yellow flags" to watch out for.

In general, pops and clicks for me had always been a result of hard drive or buss shortcomings. I'm just not 100% sure the extent to which the older considerations have changed in 64-bit world. On the surface, it all feels so much better-- smoother-- more stable, but the 'evil is usually in the 'etails.

Thanks for the 'etails!

[labman]

Frodo said ..."It's just that now I want to do a three-way shoot-out on Bounce/Freeze/RT in the same project just to *see* what's up."

Will be most excited to hear your results!!! Ours tests here indicate that we should not bounce at all, but freeze is great over 90% of the time, and prints in realtime are always correct. But we use tons of trks and VEPro slaves etc so that must be taken in to consideration with our results.

[cloudsplitter]

i do make sure that MIDI notes never "touch" for lack of a better word. I do that by expanding the MIDI notes and checking their durations. Also freezing a MIDI track first and listening back to the freeze is a good way to monitor the outcome of the bounce

Wow!
With all due respect, if I have to do all those things just to get a reliable bounce, then it is a waste of time because you accomplish the same, at a fraction of the time and effort, by recording in real time.

Not only that, but depending on the instrument and VI, sometimes one MUST have some overlap between MIDI notes.

I just can't imagine going through every track adjusting the note releases for BTD to work.
If it worked, none of that would be necessary. That's the bottom line.

Fm....the key word in my phrase was "check"....i rarely have to make modifications.....maybe shorten a decay after a note off message to fit the music or something but it only takes minutes...im getting old so i like to see as well as hear...

[MIDI Life Crisis]

What I am also noticing (and if I weren't getting pops and clicks I wouldn't have looked into all this) is that a plugin like a limiter can also cause some issues. It's as if not enough CPU power is being used or it isn't rendering properly, but if I eliminate, for example, a limiter, I can eliminate a lot of dropouts [no pun intended].

But with all that said, there are still some pops and clicks that can sneak in (as mentioned by Frodo and others) that have no relation to any data we can see or control. Sometimes I'll see them at a pedal (ctl 64) or an orphaned controller on a track that is otherwise silent or fading out. But if I alter a few note lengths in the section, even by a "ticky" all is well.

So my hypothesis about bad data being a culprit has some validity, is not the mastermind of this plot to send us all to digital ruin. Next to look at would be deeper setting in DP such as MIDI resolution, work quanta, which is not something that will yield the same results on every system, (AFAIK) and which could screw things up royally.

And maybe that's just the way of things? <sigh>

[FMiguelez]

What I am also noticing (and if I weren't getting pops and clicks I wouldn't have looked into all this) is that a plugin like a limiter can also cause some issues. It's as if not enough CPU power is being used or it isn't rendering properly, but if I eliminate, for example, a limiter, I can eliminate a lot of dropouts [no pun intended].

I've thought of that too because it's so strange... BTD, being an offline process, should be able to use any and all CPU resources as needed. There's nothing else going on other than the bounce process.

I mean, nobody is "rushing" DP to do the bounce... it could take as long as it needs as long as it is ensured that no artifacts will result for lack of processing power.
Shouldn't it take as much CPU and time as necessary?

I never bounce. Has nothing to do with technology, though - when I listen to the music as I "print to tape" my brain works differently - no matter how many times I have listened to it before, no matter how many "last nips and tucks" rounds I have already given myself, I inevitably find a couple more things to change, but only *if and when I'm printing.*

This made me laugh because I do the same, and I've never understood how I can hear things during the print operation that I didn't notice in any of the previous 100 check passes or mixing process

It's like the brain shifts focus or becomes more "critical" or listens for different things...

[groove]

Call me old school but, I never BTD a final mix.

I "print to tape" using the mix1 return from CueMix. Listening while printing allow me to double-check everything and look at my metering plug-ins; if something is wrong I can stop right away and I don't have to wait for the BTD to finish.

EDIT: I should have read all the posts, 'cause I basically repeat what Kubi said.