very often corrupt audiodata after normalizing or applying effects

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.


 
 

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.

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.

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.

mettelus
...I didn't realize the "3 files per clip" was even possible (take lanes?).

ceemusic
Sorry, I should've written 3 clips per track.

 
Mettelus was responding to THambrecht's posting "I mean 3 files per single audioclip. Sonar does not get these 3 files together while processing the clip."
 
This is indeed possible. If you destructively process only part of a clip, SONAR will write a new file for the processed section, and the unprocessed sections of the clip will still reference the original file. If you indepedently process many sections of a clip, you could potentially have dozens of files referenced by a single clip.
 
 

I was just answering Michael's question about how you get multiple files per clip and clarifying that it appeared to be based on the OP's post.
Ulitmately it's probably going to take a reproducible example in order for the Bakers to be able to fix it, but I would suggest one of you go ahead and get the ball rolling with a formal Problem Report providing as much info about the circumstances as possible and an example of a project with corrupted audio files.
     http://www.cakewalk.com/S...Contact/Problem-Report

I've never seen this problem, but if I did, this is how I'd proceed...
 
1. Close the project without saving.
2. Reload the project, perform the exact same procedure again and see if the problem re-occurs.
3a. If it does - and it probably will - then yay! the problem is data-specific, AND you have a repeatable test case for Cakewalk to step through.
3b. If it doesn't - and that's far less likely - then it's intermittent, and that means you either have a plugin that performs some kind of random modulation, or it's hardware.