Will unchecking Fast bounce in Freeze options improve the audio quality of freezed tracks?

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. 

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.

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
 
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"

stxx
... when ever the track is rendered, including realtime or audio render, I think the offline bounce is used.

I'm with you on most of that, and had forgotten that Percussion algorithm could also be used 'online'. But 'offline' by definition means 'not real-time', so I don't think it's possible for SONAR to use an 'offline' algorithm while rendering in real time with Fast Bounce disabled. The calculations (and probably some look-ahead) used by those more sophisticated algorithms are incompatible with any kind of real-time processing.

stxx
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.
 

Uh Uh.. I am confused on reading this. You mean virtual instruments need real-time bounce or certain problematic virtual instruments need real time bounce?