Bounce vs Real Time

[supersonic]

I have just done a little test on a short VI sequence to track the difference between a Real Time recording of a mix vs bounce. I did that by once running the bounce and then running the master AUX into a separate audio track. I then switched phase on one of them to see what was left.
I have quite quickly established that the test cannot be done on LIVE VIs as those often play difference samples for the given note every time they are played, hence giving a non null result when summed. However. Even with the test being done on audio tracks only the sum of the two gave quite a lot of high frequency content. This happens either with or without any plug-ins running on them. Any thoughts from your end? Have you tried any tests of the kind?

[Guitar Gaz]

I always mix and print tracks in real time. I only use bounce for completed mixes (say saving as an mp3). It works fine - but people have had problems bouncing when using VI's and plugins or trying to bounce when mixing.

[supersonic]

Which mean Pro Tools has something going for it as its real time vs offline bounce gives a perfect null.

[MIDI Life Crisis]

I've been using BTD for virtually everything I've produced for many years now and except for a few highly scripted VIs in Kontakt (slide guitar, specifically) I've never had a problem or complaint. Not from broadcasters, engineers remixing, DVD manufacturers, theaters, or anyone else.

If it's a movie I always re-export it in iSkysoft to comply with specific video settlings and codecs. But as far as BTD in DP it's been flawless. Would my results pass the "null" test? Do I care?

[supersonic]

Same here. I have been doing a lot of Bounce operations but these tests make me think if what we send is really what we here while mixing. When mixing critical material I always record in real time, still.

[MIDI Life Crisis]

I always listen to the actual bounce so I know what I send is what was in the bounce. If it sounds good, it is good.

[supersonic]

So do I. And yet it makes me wonder...

[groove]

Always real-time. I find it more productive: if what I'm listening is fine, then I know the file is. Otherwise, I can stop anytime a problem occurs. I don't see the added value of waiting for a bounce to complete and then listening to it in real time anyway to make sure everything's OK. Kind of a redundant approach.

I export the master file in other formats from within DP if needs be or convert to mp3 and itune+ with Sonnox Codec Toolbox.

[mikehalloran]

I'm not using heavily scripted VIs in Kontakt so I can't attest to that.

Otherwise, I use BTD and it has been flawless—every version of DP over the many years I've been using it. I've never done a null test. As has already been said, "If it sounds good..."

When BTD crashes as it has 3 times, I look for the bad RAM, find it, replace it and all is good again.

BTD and bad clones are the two best indicators of bad RAM I know. BTD is reliable in that regard whereas you don't always know that a clone failed — until you try to access it, that is.

[Tritonemusic]

Is this something that you've tested with previous versions of DP (didn't notice which version you're using)? I'm still in the Stone Age with 7.24. However, I have tested many times, and everything nulls completely, every time. It's actually a waste of time not to use BTD, in my situation.

[MIDI Life Crisis]

...waiting for a bounce to complete and then listening to it in real time anyway to make sure everything's OK. Kind of a redundant approach.

Yes, it may be considered redundant, and it could also be looked at as "quality control." I learned long ago that NOTHING leaves the studio unless I listen to it in real time, regardless of how the recording was achieved. Frankly, I would say it is actually foolish to "watch" the recording and then assume it's ok without listening to the file and even then, I listen in several apps. Redundancy at the quality control level is not a waste of time, as far as I am concerned. Not that your approach is bad, per se. If it's working for you and you're confident you can record and release, go for it. My clients would have some very ruffled feathers if I delivered something on a tight deadline and had to redo it because a tiny little tick got into the data stream. It happens and you might not hear it in the "real-time" recording as you are NOT listening to the finished file. If there is a way to do that, please tell me how.

In the days of tape heads that would playback the finished product after a separate head recorded it (often called a three head machine in the cassette world - simul-sync in the TEAC world, etc.) yes, you could actually hear the finished product while recording. Not so with digital recording AFAIK, at least not in DP. Or am I missing something obvious?

[groove]

Yes, it may be considered redundant, and it could also be looked at as "quality control." I learned long ago that NOTHING leaves the studio unless I listen to it in real time, regardless of how the recording was achieved. Frankly, I would say it is actually foolish to "watch" the recording and then assume it's ok without listening to the file and even then, I listen in several apps. Redundancy at the quality control level is not a waste of time, as far as I am concerned. Not that your approach is bad, per se. If it's working for you and you're confident you can record and release, go for it. My clients would have some very ruffled feathers if I delivered something on a tight deadline and had to redo it because a tiny little tick got into the data stream. It happens and you might not hear it in the "real-time" recording as you are NOT listening to the finished file. If there is a way to do that, please tell me how.

Maybe I wasn't clear enough - apologies for my bad english - I should have said that the gain in time of BTD is small so I prefer to do real time. This gives me the opportunity to stop the recording if needs be. I've never said I just "watch" the wavefile for any problem and that I don't listen to the master file. I've used redundancy for lack a better word. Don't worry, I have more than my share of stems listening sessions before delivery to the re-recording house!

[MIDI Life Crisis]

I routinely bounce up to two plus hour scores for silent films and BTD is really a godsend for that. I also do a lot of work where i need to send edits super-fast (like within a few minutes of receiving the source files). Again, BTD is critical in those super-tight (read: non-existent) deadlines.

I wonder if there is, in fact, a way to monitor the finished file as it is recording. That would surely help some folks, but as far as I am concerned, BTD does exactly what it's supposed to do and it does so with close to 100% accuracy. I can live with the .005% errors as long as nobody hears them - especially me!

[Shooshie]

Which mean Pro Tools has something going for it as its real time vs offline bounce gives a perfect null.

That's certainly a good thing for Pro Tools, and in the past it has been true for DP, as well. The question is whether BTD and RT are actually giving different results, or the same results, just at slightly different times. If the results are different, not merely askew, are there real-time variables that could explain it?

Either way, it would make me a lot more comfortable if MOTU would make BTD perfection a priority. I don't like using BTD when I'm not sure the results are 100% accurate.

A null test is, of course, irrelevant to what we hear if our ears tell us that the BTD sounds as we intended. But it still stands as the final arbiter of whether BTD and RT are the same.

[Shooshie]

Which mean Pro Tools has something going for it as its real time vs offline bounce gives a perfect null.

Question: When recording the real time version, were there other auxes, tracks, or masters through which the audio could have been traveling? When bouncing, it only bounces the selected tracks. But I often have many other tracks involved, just not that I use for a bounce. For example, I may not select a master track, if I have one, if all the tracks are outputting to a submaster, first. But in real time, the master track may be part of the routing. I don't know if that could explain it or not, but it's worth looking into. I may try my own null test if I get some time.

Shoosh