I have been using Fast bounce even while exporting  final mix for a while, coz I dont seem to notice any change in quality with that enabled. However just realized even the freeze options  dialog box in sonar has an option to disable fast bounce. This seems to imply that there must be some quality change with this option being kept enabled or disabled. Someone please enlighten me on this. 

No
 
It's just  to accommodate the few vsti's that don't get on well with fast bouncing/freezing

That's right. The rendering code is the same. Fast Bounce just writes the file as fast as it can get buffers of audio back from the plugin(s), rather than processing them in real time according to the audio clock. Some (few) plugins may have issues with Fast Bounce or need to be explicitly set to 'Offline' mode in order to accommodate it and/or to deliver best quality.
 
Also, since SONAR uses the real-time audio buffer size by default when Fast Bouncing, some plugins may not be happy with very low buffer settings. If an error (or grossly distorted output) results, you can either increase the buffer setting, or set a higher value for offline processing by BounceBufSizeMsec= in AUD.INI. The default of zero is what tells SONAR to use the real-time buffer setting. Values from 20-200 are a good starting point, and may improve processing speed with some plugins. I've had mine at 20 for a long time. Larger buffer settings will use more RAM - not generally a problem today, but could be in the past when bouncing a large project with limited RAM.
 
Problems with Fast Bounce aren't usually subtle, so you don't generally need to be concerned about it unless you hear something really bad.

Isn't there some difference in the selection of time-stretching algorithms or in oversampling?

Shouldn't be. My understanding is that it's exactly the same process except that it fills the output buffers at the normal playback rate rather than blasting it as fast as possible. Any extra processing such as time-stretching or AudioSnap or Melodyne will just be added into the time it takes to do the render.
 
I have encountered synths that need the slower speed, and (more rarely) I have seen synths that required the fast speed. Like brundlefly notes, when one or the other doesn't work it'll be obvious when you play back the frozen track.

I will add my 2 cents:
With digital audio, there isn't much of a difference in anything. Except 1 and zeros.
 
Not like in the old analog days when bouncing too many times would lead to degeneration.

bvideo
Isn't there some difference in the selection of time-stretching algorithms or in oversampling?

There can be a difference beween fast and real-time bounce of Audiosnap stretching if the 'Offline' algorithm is not set to 'Same as Online' (i.e. 'Groove Clip'). But in that case, Fast Bounce will use the more sophisticated (not always subjectively 'better') algorithm than real time. So you'll still get the same or better result using Fast Bounce in that case. 
 
The way I look at it in general is that bouncing in real time is adding the constraint of slaving the rendering and file-writing processes to a hardware audio clock, and it's more likely that this will actually interfere with processing than improve it.
 
Just because humans tend to produce better results when they work more slowly doesn't mean a computer will. ;^)

brundlefly
The way I look at it in general is that bouncing in real time is adding the constraint of slaving the rendering and file-writing processes to a hardware audio clock, and it's more likely that this will actually interfere with processing than improve it.
 
Just because humans tend to produce better results when they work more slowly doesn't mean a computer will. ;^)

+1

brundlefly
 
Problems with Fast Bounce aren't usually subtle, so you don't generally need to be concerned about it unless you hear something really bad.

Woot! Next time I hear "Man, that was terrible!" I can respond with," Yeah, I fast-bounced that one"

I do not think the comment on audiosnap is correct.   ANY bouncing or rendering I believe utilized the offline processing and the only time you'll maybe  hear a different in audiosnap is if you are just playing the track in real time (not renderering) but when ever the track is rendered, including realtime or audio render, I think the offline bounce is used.  Also make sure when using audiosnap you choose the correct algortithm and that all drums tracks are set to (online) percussion and offline = same as online etc. This applies ONLY to percussion.  Otherwise, online is set to groove-clip but depending on the type of track it is, there are numerous offline choices that are suited for different things like vocals vs guitars etc ( multiple radius choices for example).    Best to read the reference manual on this.  Only time to really need to use realtime bounce is if you are using external inserts or recording virtual instruments.  Bottomline, no matter how the project is rendered, it will sound identical in the end
 
 

brundlefly

bvideo
Isn't there some difference in the selection of time-stretching algorithms or in oversampling?

There can be a difference beween fast and real-time bounce of Audiosnap stretching if the 'Offline' algorithm is not set to 'Same as Online' (i.e. 'Groove Clip'). But in that case, Fast Bounce will use the more sophisticated (not always subjectively 'better') algorithm than real time. So you'll still get the same or better result using Fast Bounce in that case. 
 
The way I look at it in general is that bouncing in real time is adding the constraint of slaving the rendering and file-writing processes to a hardware audio clock, and it's more likely that this will actually interfere with processing than improve it.
 
Just because humans tend to produce better results when they work more slowly doesn't mean a computer will. ;^)