Best to do realtime bounces?

There are a few reasons to prefer offline bounces.

1. You don't have to wait 2 hours for your podcast to be bounced. Instead you can have the result in a few minutes.
2. The realtime constraint may actually result in dropped buffers that you may or may not notice during listening.
3. You can check the offline bounce afterwards and listen the exact same signal over and over again. There are indeterministic factors in realtime playback that potentially make every single pass different. For proofing a result, being able to listen back with consistency is essential.
4. Many plugins use better internal settings for offline renders. That may be better interpolation, higher oversampling, better implicit function solvers (or just more iterations), etc. Especially modern plugins with analog modelling or those that consume a lot of CPU work like this. You only get the best quality if you bounce offline.
5. Even if you have sources or processors in your project that can only run realtime, like external sound generators or processors, it is usually better to render those to single audio tracks once for consistency and reproducability and then bounce the entire mix offline.
6. Improved timing for automation and midi events, including notes. A host running playing back in realtime will try to keep the processing buffer size constant, forcing parameter changes and other events onto the grid of buffer start times. During offline rendering, the host can be a lot more flexible and change the buffer sizes adaptively to match the spacing of the parameter events.

So from my perspective, which is that of a developer, there is really not much think about. Use offline unless you have a very good reason not to.

Cheers,

Jazz

Sorry... but I'd have to respectfully disagree that "offline is best". Granted, an offline bounce does not have the extra burden of playback whilst bouncing, but I prefer to bounce what I've been listening to throughout mix-down, (not a silent, quick summary)!

In my experience, no two bounces of a final mix are the same (whether online or offline) - there are small discrepancies in timing - especially with time based delays. I always bounce final mixes in real-time, & if I don't like what I'm hearing, I'll stop & start again. I have a long standing habit of pressing play / stop in quick succession to clear the buffers, & make sure the song start is sample accurate, (even with a pre-roll).

Often bouncing in realtime (online) is the quicker method - why go through multiple offline bounces if your not happy with a certain level in a vocal when you can hear it instantly in realtime?

1. Without the realtime constriant, the DAW has much greater freedom to utilize the CPU cores better and even for a busy mix, offline bouncing will usually be faster. This advantage is sometimes compensated for by the additional processing that plugins do when they run offline. But for the same output quality, offline should be noticable faster.
2. The point is that you cannot get buffer underruns for offline bouncing, so you don't have to listen for them. You may well miss such small issues in a realtime bounce, especially if you only listen while the bounce renders.
3. The point made earlier was that you proof your bounce during the bounce time and start again if you hear an issue. Most people would skip listening again to the realtime bounce after is had been done. So the point of having an offline bounce is that you will listen to it with the option of going over the same position several times. I sometimes hear problems that upon a second inspection have not been there. So if you really want to send out something that has been proofed, it's better to do it offline.
4. With increased processing power come algorithms that use it. Especially with the newer analog simulations you can spend a lot of CPU on getting it right. And because approximative methods are used, there is no upper limit for CPU time spent. Anti-aliasing is another thing that is usually done better for offline rendering. U-HE's Diva does both for example and even a modern CPU is struggling with it. Or complicated mathematical perception models, like Gullfoss uses, can run in different levels of detail and can easily stress out a modern CPU.
5. Not sure I understand your point. You would have to bounce the external devices in realtime, but on a per-track-basis. My argument was to do that first and independently of a final bounce.
6. If your DAW skips over automation then that's a bug. In general, automation is more accurate if you bounce offline. And the midi timing you are listening to in realtime has a buffer-sized jitter attached to it. That's not something musical that you want to keep, like groove or feel. Having the originally recorded or quantized timing rendered out correctly will generally improve the vibe of your music. This is one reason why a lot of people (offline) render their instrument tracks to audio early in mixing.

Do you have any physical realtime audio or MIDI device like an external instrument? If so you do the bounce in realtime. Otherwise, offline is perfect.

WD

@ Kerochan... no, it's not necessary to be online (ie. connected to the internet) to do a realtime bounce - "online" is simply another term for realtime bouncing, (as opposed to offline)

Jazzmaniac... great to hear from a developer's perspective, & you raise some very valid points.

In response to some of them :

1. Completely agree it's pointless waiting around for a 2 hour bounce in realtime. That being said, if you've got a really busy mix with lots of tracks & plugins, often it's not actually that much quicker going offline - perhaps giving you only a 50% time saving.

2 If buffers do drop in playback, it's better to hear them whilst they occur - every mix has 'difficult' passages, where CPU usage can max out & cause errors, so it's better to listen out for them.

3. Whilst I agree it's good to proof a constant source - no reason why you can't proof a realtime bounce afterwards.

4. I'm not a developer, but surely with current computing power there's an argument that plugins should have the same audio quality during playback & offline bouncing?

5. Completely agree that it's best to render external synths or time critical parts - this is where offline bouncing is really useful.

6. This is my main problem with offline bouncing - often automation get's skipped over - particularly with FX based automation. I also prefer midi timing to be as I've been listening to - not some 'improved' version!

Offline bouncing is undoubtedly a useful tool, but when it comes down to final mix down I still prefer realtime bouncing, (or recording to a Tascam DVRA 1000).

Peace & goodwill to all!

(I did, after saying I didn't). It is a short piece, and though well intentioned, it is based on anecdotal "evidence" (the writers own experiences) and simply untrue. Especially the part about "proofreading".

Don't need to read. Offline is better. Period.

"You can hear the whole mix" - what BS. I bounce, then I listen carefully in iTunes. Same thing "proofreading". Artefacts in a realtime bounce are the consequence of doing the realtime bounce in the first place, so it is a silly, self-defeating strategy.

Always respectful - we all have our quirks!

I would add that it's a different story at 5am... especially after a long day.

But in the scheme of things, I think you'll agree, there's far more important things going on in the world...

Jazz,

Thanks for clearing up Realtime/Offline bouncing. Next time I'm using outboard FX and using Realtime to include them in mix, I'll bounce those tracks and run the whole mix offline. Very informative.

Sorry Eriksimon... Cross posts.

I didn't bother to read too.

WD

Yup. Oui.