Since the last two or three updates I get again and again corupt audiodata after normalizing an audioclip.
In principle this happens only when I split a recording into several takes and I want to normalize one of this takes or applying an effect to this take. Sometimes this can prevented when I first apply trimming to all audioclips and then normalize. Often this trick does not work. Sometimes I must bounce the audioclip to itself, before normalizing. But even that does not help anymore.
It also happens that after normalizing the audioclip is simply empty.
We have 3 (different) computers and on EACH computer these errors occur continuosly. And it happens on EACH project no matter what computer. The error occurs once a day since the last two or three Sonar-updates. Earlier we had this error once a month - now we have it daily.
Batch-normalizing 50 clips is not anymore possible without control each clip.
This can also happen by applying an effect to the clips. It's not linked to a special plugin.

Saving and restarting the project does not inform that there is a corrupt audio data. So you can loose a recording without realizing it immediately. In the worst case, the audioclip is simply empty or is not playable.
 
Because this happens on three computers with different hardware and different audio-interfaces since the last two or three Sonar-Updates I think this problem is up to Sonar.
 
Note:
When I batch-normalize the audioclips outside of Sonar via Adobe Edition or Steinberg WaveLab the error does not happen. (Therefor I have to copy the project creating a file per clip.)

As I see it happens mainly when the audioclip is associated with 2 or more clips.





BEFORE Normalizing I can see that the audioclip is associated with 4 files. I think this causes the error. But bouncing the clip to itself does not help. Because bouncing makes the same corrupt audiodata.


 
 

Can you give a recipe to reproduce? I've had this happen a couple times - like once every couple years (!) - but could never figure out how to reproduce it, and didn't pay much attention because it was so rare. I do recall it happening only on mono clips.

THambrecht
 
BEFORE Normalizing I can see that the audioclip is associated with 4 files. I think this causes the error.

 
Yes I would guess that's right. That shows that other destructive rendering process have been performed on sections of the clip, creating new files for those sections. Before reading this, I was going to suggest that having one file per clip was the reason you don't see a problem outside of SONAR. You probably wouldn't see a problem inside of SONAR in that case, either. As you probably know, it is possible to save a project to another location and specify 'one file per clip'; maybe you need to start doing that before normalizing.
 
Like other destructive rendering processes, Normalize always writes a new file. If multiple clips are selected; it writes a single file and references all the clips from that new file. If some corruption is reported after normalizing, it would seem to be related to a problem writing that new file.
 
I just did a few quick tests normalizing multiple clips referencing multiple files each, and couldn't reproduce a problem. Per Craig's suggestion, I used mono clips.

This is because we digitaze hundreds of tapes and vinyl. We have 10 to 20 terabytes of audiodata. So we normalize thousends of clips per week. So we have the problem a thousend times as often.

Unfortunately I cannot give a recipe to reproduce this.
In this special case a record from 1 hour was splitted into 5 takes. An equalizer (Waves Q10) was applied to 3 of 5 takes with different settings. 2 other takes are not processed.
Sonar keeps to all of the 5 takes a file with the full length of the original. 3 files have a processed position within this large file.
In this case Sonar has obvios the problem to normalize the 3 clips - while Sonar keeps the full lenght to the original file with unprocessed regions. That would not happen when Sonar would create ONE file per clip.
The error happens - so my experience - when an audioclip is associated to more as one clip.
 
A solution would be a command that forces Sonar to create one clip per file. Or a check of the programming when editing with an audioclip that is associated with more as two files.
 
 

Copying the project with "creating one file per clip" is also a problem and no solution.
But only since the last 2 or 3 updates.
Because in this case we get a new project with corrupt audiodata. Affected clips are empty or have corrupt regions in the audiodata.
That means the copying process destroys some of the audiodata.
There is no error message when loading this project.
This is a profound problem. Since the last 2 or 3 updates Sonar has a problem to handle audioclips which consists of multiple files. I mean not 1 file per 10 clips. I mean 3 files per single audioclip. Sonar does not get these 3 files together while processing the clip.

Sounds like it may only manifest when working with very large files. And if you have to do a thousand normalize operation to get a handful of failures, that will definitely be difficult to diagnose. Could also be an interoperability issue with your particular storage hardware and drivers. Seems likely you will need to work closely with the Bakers to get to the bottom of it, but you might start by rolling back to the last update that had no/fewer problems and see if stability returns.

Plat caused 2 corrupted audio files (in 2 projects) this week using the latest version.
Both when processing gain on clips (using Process/ Apply affect/ Gain)
This has happened before over the years at random. Never on a single audio file but with several clips within the track.
 

It just happened to me again.
3 clips on a track, one was gain chained properly, other 2 corrupted.
I used undo, bounced the 3 clips to one then processed the gain successfully.
( I also tried recompute & clean audio folder but neither helped.)
 
I've also experienced it changing the placement of a few clips in the timeline. The clips had locked position enabled.

A clip is merely a "window" into the underlying wav file, so numerous clips of the same file can be present. I can definitely see how this could throw SONAR for a loop as mentioned above, but I didn't realize the "3 files per clip" was even possible (take lanes?). In that situation, does bouncing to new clip (or even track) help?
 
I guess I am more confused on the multiple files per clip concept.

Sorry, I should've written 3 clips per track.
 
Also to add another timing issue occurred after using the gain feature on a track with multi clips. The gain staging was correct but one of the clips were moved about a 1/4 note off. These clips were also locked in position.