When using Process Audio->Normalize on multiple clips, some of the clips end up blank or corrupted:
 

 
Doing the clips one at a time is fine:
 

 
It's frustrating, as I use this technique when cleaning up vocals, when the vocalist has a habit of changing their distance to the microphone. I cut up the waveform into each vocal phrase, and normalise to a common value, which sounds much more natural than compression.
 
At first I thought it was treating all the clips as one, and attempting to normalise to the common most loudest point of all the clips, but this doesn't explain the blank clips or corrupted ones.
 
If I wanted it normalised as one clip, I'd bounce to clips first in any case. What I'm trying to do is run the normalise individually on all the clips I've selected.
 
 

I've encountered the same problem, and do not have a fix for it.
 
However, the following may be a workaround - I discovered it by accident so haven't verified recently. When you export individual clips as BWFs and bring them back into Sonar, each clip ends up on its own track. IIRC you can then select all those clips and they will normalize as expected. Then bounce them back into a single track.
 
If you try this, let me know if it works.
 

Thanks for the suggestion Craig, I'll give it a go.
 
In the meantime, I set up a key mapping for CTRL + ALT + N to map to Normalize.
 
I can then use CTRL + ALT + Keypad 4 / CTRL + ALT + Keypad 6 to select the clips, and basically do:
 
CTRL + ALT + Keypad 6  (selects next clip)
CTRL + ALT + N  (selects Normalize)
ENTER (applies affect)
 
and repeat that process to go through every clip in the track.
 
However the weird thing is the clip corruption thing STILL happens randomly - even on a singly selected clip. In this case, I press CTRL+Z to undo, select with the mouse instead, then CTRL + ALT + N, which works pretty reliably.
 
So as long as I keep a close eye on the rendered waveform, I can go through the clips fairly quickly using this method.
 
I really wish the bakers would fix this bug though. If you're not paying attention, it can seriously screw up your tracks without you noticing.

Add one more key command to bounce each clip to itself first. But the more I think about, the BWF thing might be the fastest. Create a folder in your project audio folder, find it in the browser, drag all the clips to it, then bring them back in again at the bottom of the track view. Select, normalize, bounce...done. If it works, of course 

Dragging the clips out doesn't seem to work as expected. What it's doing is bouncing all the clips into one when exporting, rather than keeping them as separate clips.
 
Even if I drag them over individually, it doesn't retain the original time position of the clips so putting them back together would be a nightmare (none of these clips are snapped to any grid value, because they're generally parts of vocal phrases).
 
Just out of curiosity, I tried the original method in Sonar 8.5. I works, but not how I wanted it to. It's applying the normalization as if it was a combined clip, i.e. the quieter clips are kept quieter because it's taking the volume of other clips into account. I'd hoped it would apply the normalization individually to each clip.
 
[Edit]
Tried it on X3, and it works exactly how I want it to.
 
Pity it's broken in SPLAT & CbB 

msmcleod
Even if I drag them over individually, it doesn't retain the original time position of the clips so putting them back together would be a nightmare (none of these clips are snapped to any grid value, because they're generally parts of vocal phrases).

I forgot you need to drag them over individually, so bouncing to itself with a key command might be faster. However, they will retain their time position if you go Edit > Preferences > File > Audio and check both "Export Broadcast Waves by Default" and "Always Import Broadcast Waves at their Timestamp."

If you look in your project file you'll see it takes all your selected files, packs them into one big file and normalizes that.
 
Your individual audio clips are now in fact pointers into that one mega audio file.
 
I submitted a bug report way back when but it never got fixed.
 
Save to a new directory with the one audio file per clip setting separates them out again.
 

Its been an issue for some time and I just bite the bullet and normalize track by track.  Its usually a one time operation and at the most maybe need to do 24 tracks if ALL initial recorded tracks aren't within proper levels but obviously that is worst case scenario.  Just do one track at a time and you'll be safe.  Also a shile back some one mentioned to first run "apply trimming" but that doesn't always fix the issue

I split clips on the front and end. I use ctrl g to move to start of clip and ctrl shift g as custom map to move to end of selection. S to split. Alt p n for normalize, or something course to that. Otherwise it normalized the full length of the original wave and takes time. It will only impact that clip, but it might make a really big wave file.

jpetersen
If you look in your project file you'll see it takes all your selected files, packs them into one big file and normalizes that.
 
Your individual audio clips are now in fact pointers into that one mega audio file.
 
I submitted a bug report way back when but it never got fixed.
 
Save to a new directory with the one audio file per clip setting separates them out again.

 

Anderton
Add one more key command to bounce each clip to itself first. 

Ok, it seems like a combination of setting the one-audio-file per clip, and bouncing each clip to itself solves the problem.
 
The behaviour seems to be as follows:
 
1. Without the one-audio-file-per-clip setting, the whole normalize a clip thing is buggy unless I
    (a) Always select the clip with the mouse and;
    (b) Only normalize one clip at a time.
 
2. With one-audio-file-per-clip enabled, but WITHOUT bouncing the individual clips to themselves:
    (a) For multi-select, if all the clips are contiguous, then it treats them as a single clip - i.e. the normalize for each clip is affected by the volume in the loudest clip, as if they were indeed just one clip.
    (b) For multi-select, if the clips are not contiguous, then the bug returns and it's random as to whether I get a blank or corrupted clip, or a successful normalization.
    (c) For single-select, it seems to work fine. So I can do my CTRL+ALT+KeyPad 6, CTRL+ALT+N, ENTER, repeatedly to go through each individual clip. 
 
3. With one-audio-file-per-clip enabled, and WITH bouncing the individual clips to themselves:
    (a) I can multi-select all the clips and the normalize seems to apply the effect individually to each clip - i.e. the volume of the other selected clips is not taken into account.
    (b) The repeated CTRL+ALT+KeyPad 6, CTRL+ALT+N, ENTER works too, as expected.
 

Anderton

msmcleod
Even if I drag them over individually, it doesn't retain the original time position of the clips so putting them back together would be a nightmare (none of these clips are snapped to any grid value, because they're generally parts of vocal phrases).

I forgot you need to drag them over individually, so bouncing to itself with a key command might be faster. However, they will retain their time position if you go Edit > Preferences > File > Audio and check both "Export Broadcast Waves by Default" and "Always Import Broadcast Waves at their Timestamp."

Given that I have to go through each clip individually anyhow, I'm not sure doing an export will speed things up here. I will take your suggestion for having a key binding for bouncing though, so I can just repeat this (with CTRL+ALT held down):

• KeyPad 6 (select next clip)
• B (bounce to clip - i.e. bounce this clip to itself)
• N (normalize dialog pops up)
• ENTER (apply normalize)

I'm really dumbfounded as to how inconsistent the behaviour is here though, and I've not tested these scenarios extensively enough to be confident they'll work all the time. 
 
@Noel & the team - Please fix this bug!