I just did a test and was happily surprised.
 
I found I no longer had to split clips on either side before normalizing in order to not get a new track in the audio folder the full length of the original.
 
However, when normalizing ranges at different points in the mix, the new file normalized the tracks from the earliest sample of the earliest clip to the latest sample of the latest clip. So, if I normalize the first minute of a 60 minute track and the last minute of a sixty minute track, the normilization that takes place spans all the space in between as well (not shown). The wave form calculation has to happen from the beginning of the track to the end. If you wait for it, it will complete. I have an SSD so it goes pretty fast for me. If you do not have an SSD, you might wait for quite some time.
 
Basically, this means if you normalize a bunch of tracks around roughly the same time frame, it works better than it used to.
 
The problem now is that it starts at the very earliest part of the earliest clip for all clips and goes to the latest part of the latest clip. The normilization that happens is correct. In other words, if the loudest peak is somewhere in the middle it doesn't matter... this will be ignored. Only the range you are attempting to normalize will be normalized. 
 
The problem is 2 fold. 1. It takes a while to see the wave forms for newly normalized clips when you normalize at different places in the time range. 2. the file that holds the normalized data is much larger than necessary for the size of the clips.
 
This is not true when you select the same time range for multiple clips. In that case, the size of doing each clip separately and doing them all together is the same. Also, the size when splitting the clips first vs. the size when the clips are not split and you only select a region between markers will be the same.

gswitz
I just did a test and was happily surprised.
 
I found I no longer had to split clips on either side before normalizing in order to not get a new track in the audio folder the full length of the original.
 
However, when normalizing ranges at different points in the mix, the new file normalized the tracks from the earliest sample of the earliest clip to the latest sample of the latest clip. So, if I normalize the first minute of a 60 minute track and the last minute of a sixty minute track, the normilization that takes place spans all the space in between as well (not shown). The wave form calculation has to happen from the beginning of the track to the end. If you wait for it, it will complete. I have an SSD so it goes pretty fast for me. If you do not have an SSD, you might wait for quite some time.
 
Basically, this means if you normalize a bunch of tracks around roughly the same time frame, it works better than it used to.
 
The problem now is that it starts at the very earliest part of the earliest clip for all clips and goes to the latest part of the latest clip. The normilization that happens is correct. In other words, if the loudest peak is somewhere in the middle it doesn't matter... this will be ignored. Only the range you are attempting to normalize will be normalized. 
 
The problem is 2 fold. 1. It takes a while to see the wave forms for newly normalized clips when you normalize at different places in the time range. 2. the file that holds the normalized data is much larger than necessary for the size of the clips.
 
This is not true when you select the same time range for multiple clips. In that case, the size of doing each clip separately and doing them all together is the same. Also, the size when splitting the clips first vs. the size when the clips are not split and you only select a region between markers will be the same.

Processing time isn't an issue really - I'm using SSD's and the process is almost instant, it's the fact that it just doesn't work properly.
 
As far as the file size is concerned, I didn't see the issue you're seeing. The size of the bounced clips are tiny.
 
However, what I did see is that whereas the original file I imported was 16 bit, the bounced or processed files were 32 bit. This might account for your large file size.
 
As I said, neither of these issues problems for me. With most audio tracks (e.g. guitar), I'll just normalize the whole track as I go along. This is fine.
 
It's the clip issue that is a pain. 
 
If I split the track into 7 clips, and select clips 2 & 4 & 6 it seems to do the first clip, then messes 4 & 6 up completely. I get a spike at the beginning of each of those clips, and the rest is silent.
 
It's not just normalize that is affected either - gain does the same.
 
From what I can tell as long as the clips are actually in separate files (i.e. individually bounce each clip to themselves so it's actually saved them to disk), the process works.
 
While the clips are part of a single file, this is where the bug occurs.
 
I can check that they're in separate files by selecting all the clips involved, and then selecting "Associated Audio Files" from the right-click menu. If the number of files shown is the same as the number of clips I've selected, then I know they're all in their own file and I'm safe to proceed.
 
So for now, I guess the workaround is what I said in bold above.
 

I made a vid to try to show what I was talking about...
 

 
In this video I explore the size of files created using different methods for normalizing.
First, I split clips on either side of the range to be normalized.
Next, I normalize by selecting a range and note that the size is the same.
Lastly, I select a clip at the beginning and at the end of the project and normalize and notice the very large size of the file created. This is as if the entire range is normalized rather than just the clips themselves.

gswitz
I made a vid to try to show what I was talking about...
 

 
In this video I explore the size of files created using different methods for normalizing.
First, I split clips on either side of the range to be normalized.
Next, I normalize by selecting a range and note that the size is the same.
Lastly, I select a clip at the beginning and at the end of the project and normalize and notice the very large size of the file created. This is as if the entire range is normalized rather than just the clips themselves.

Thanks for this Geoff - interesting stuff.
 
I tried doing what you did, and got pretty similar results.
 
It was interesting to see the bug happen when you selected 3 clips over 3 tracks and the 3rd one came out all wrong.
 
However, if before doing any normalizing, I bounce each clip to itself (so, select each clip individually and do bounce-to-clips), I get different behaviour...
 
Firstly, selecting one clip at the beginning of on one track and another clip at the end of another track doesn't take as long. So it's definitely not going through the intermediate wave data (and why should it need to - they're now two separate smaller files). And of course you don't get a huge file for the two clips - just the two small ones.
 
Secondly, I deliberately picked a quiet area for the second clip. So doing what you did (i.e. not bouncing to clips), did normalize the waveform; but I found that doing it AFTER bouncing to individual clips resulted in a much louder waveform for that second clip.
 
This would indicate that while the clips are still part of the same file, the level of one clip affects the other during the normalization process. However when they are two separate files, they are normalized correctly in isolation.
 

It is an interesting question whether the level of one clip impacts another from a different track. This is not my experience when normalizing tracks at the same time in the timeline. For more than a decade i have bounced to clip before normalizing because it used to be required to keep the clip sizes small.

I know we all would like to see rms normalization some day.

I am curious to discover the secrets of how out its currently working just so i know. I do feel i know how to reliably use it for my purposes.

I came back to SONAR after spending time in a studio with S1/PT and started to use the clip gain envelope to give a steady vocal volume before feeding the signal to the compressor. I hardly use the normalise function at all now.
 
You can easily match vocal peaks with cuts in clip gain and vice-versa.  if there's something that doesn't sound right you can bounce the clip to a new track to visually inspect the new waveform.  It's non destructive, which I think is an advantage.  

richardskeltmusic
I came back to SONAR after spending time in a studio with S1/PT and started to use the clip gain envelope to give a steady vocal volume before feeding the signal to the compressor. I hardly use the normalise function at all now.
 
You can easily match vocal peaks with cuts in clip gain and vice-versa.  if there's something that doesn't sound right you can bounce the clip to a new track to visually inspect the new waveform.  It's non destructive, which I think is an advantage.  

I actually use the clip gain envelope later on in the mixing process, but this normalize procedure was a first pass cleanup operation.
 
I was cleaning up some vocals were done by my 5 yr old daughter, who can't sit still for more then 2 seconds let alone keep a consistent distance from the mic! What I end up with normalizing is a fairly consistent track, which is good enough to take to the next stage. It's also pretty automatic in the sense that I don't really need to listen to the volume to match it. All I need to do is identify the various phrases (which is easy visually), split them up into clips, and go through and normalize each clip to -2db.
 
If I didn't do this, then the clip gain envelopes would be all over the place, whereas what I want is to use the clip gain envelopes for more subtle tweaks later on.
 
I appreciate this is an extreme case, but it works for me!

gswitz
It is an interesting question whether the level of one clip impacts another from a different track. This is not my experience when normalizing tracks at the same time in the timeline. For more than a decade i have bounced to clip before normalizing because it used to be required to keep the clip sizes small.

I know we all would like to see rms normalization some day.

I am curious to discover the secrets of how out its currently working just so i know. I do feel i know how to reliably use it for my purposes.

This is exactly my issue I guess, in that it's inconsistent depending on how you select the clips, whether they're bounced etc. I'm gonna give Craig's export/import suggestion a go when I get a chance, and see if this works for me, but for the meantime I think I've cracked it with ensuring the clips are bounced to themselves first (and of course the save as separate clips is enabled).
 
I probably spent most of my time over the last 10 years in Sonar 8.5, and never had any of these issues.
 
I found X1 too buggy, and didn't really have the time due to family commitments in any case to do much apart from get basic ideas down.
 
Sonar X3 I found to be very stable, and normalizing worked as I expected it to. I never quite got used to the changes in take lanes from 8.5 (I've still not grasped it completely to be honest), 
 
If I get the chance, I may start rolling back Platinum to narrow it down to when it started playing up. Hopefully this will give the bakers some indication as to what might have caused it.
 
 

Bouncing before normalizing would be important to do, since normalizing audio of merely split sections is actually running the process multiple times on the same file. Normalizing one file is simple, but when you throw that curve ball at the algorithm, you have no idea how it was written.