Mysterious behavior after splitting audioclips

Regarding the first one, I've had something similar bite me when I snapped to zero-crossings. If the zero crossing was not on the beat and then I had another take that was snapped to the beat, there would be these tiny overlaps when cutting if the Take Lanes were folded up and I was working on the parent track. That may not be the cause of what's happening with you, but I end up with the same results.
 
Regarding the second, the people at Cakewalk are aware of this but can't reproduce it. I'm waiting until it happens in a project so  I can send the project to them, but it hasn't happened in months.

Because we are digitazing analog recordings we have many terabytes of audiodata. Therefore we observe such problems more often. Some projects have up to 80 GB audiodata. I don't want to do this in Wavelab or Adobe Edition.
Sonar is unbeatable and the best and fastest software for such audio projects.
But sometimes it is sad when the new updates also make some basic things flawed.
 
 
 

mettelus
It is unfortunate to see a daily bread and butter user get a canned response of "no endpoint in sight."

Are you referring to my response? If so, I'm simply another bread and butter user describing my experience. I'm a) confirming both phenomena, b) mentioning how the first one has happened to me and what caused it, and c) confirming that I've had the second occur but cannot reproduce, nor can Cakewalk. Cakewalk can't fix something they can't reproduce. Equating "no endpoint in sight" with "people are trying to reproduce and solve the problem" makes no sense. It's not my fault when something happens so rarely I can't summon it on command.
 
P.S. I do think it relates to mono files because I think it happened when I was working on narration. But this was almost a year ago so I can't be 100% I'm remembering the circumstances correctly. So you might think it's pointless for me to say anything, but if THambrecht reads this and the next time the second thing happens he was working on mono files, then we're starting to get somewhere...Cakewalk can then concentrate on trying to reproduce with mono files if that's a more common error mode (yes I know his screen shot shows stereo, but that may or may not be relevant to the cause...I don't know what the history of that waveform was).

THambrecht
In our case it happens daily.
I also cannot reproduce it. I don't even notice when such a bit of audioclip remains. It's nearly unvisible.
When I mark all clips and export hundreds of clips, I see a few exported wav-files with only 5 kB of length.
I thought it was related to the fact that we have clips with 1 or 2 hours.
 
But I try to figure it out. I'm trying to reproduce it.

 
Is the sliver in a different Take Lane?
 

chuckebaby
and you don't think "Bounce to clips" wont take care of this ?

 
I think it probably would, but I'm still curious how the "microclips" are being generated in the first place in case they're coming from someplace unexpected. For example, I wonder if Split will snap to zero crossings if that's selected, thus leaving a sliver behind if the clip extends beyond a zero-crossing. Don't have much to go by, so grasping at straws.
 

For a test, you could also keep "Snap to nearest Audio zero Crossing" checked, but set "Selection after single split" to "None".
You have to select the left side of the clip you want to delete manually and that's more work and maybe not feasible for you, but it should ensure that the clip portion is selected entirely.
 

I must correct myself.
The microclip is NOT the left side of the clip.
The microclip remains to the RIGHT side of the previous clip.
That was not to be seen immediately.
 
That is the evidence: (zipped 855 MB)
I have uploaded the project:

https://office.1und1.de/guest?path=K18936%20-%20info%40hambrecht.de&token=4849536D40C10A33&mandant=02&product=onlineoffice&locale=de&viewType=0&guestToken=cRgIUshXTuOTh2dBK1-7nw&loginName=info%40hambrecht.de

 
I have shortened the project to 1 audioclip:
- Just split at the end of the music at measure 1977.
- Delete the right portion.
- You will see a microclip at measure 1986
 
Fully reproducible - no coincidence.

I just looked at your project:
There is a second Lane (expand Take Lanes to see it) which contains the remaining portion of the clip (although in the same Lane).
 
You don't have to split the clip, the remaining microclip is already there.
 

--- deleteted ---

I opened your test project again and actually you don't have to expand Take Lanes.
If you zoom way in you'll see the (muted) microclip right at the end on the main track.
 
So, the second empty Take Lane is probably not important, but a previously split (maybe inadvertently) seems to be done and since the remaining clip is also muted (which is not the case of usual splitting), it looks like "Comping" has been used.
 
But it would take a couple of inadvertently pressed keyboard shortcuts to get this result, so it doesn't look like an oversight or user error.
 

It is nevertheless strange.
When I split clip 1 at the right end - and the following next clip 2 at the left beginning, there should never be a microclip between this two clips. Even if they overlap.
I know now what I must make in order to prevent this. But this is a program error.
 
The remaining microclip on the right side of the clip belongs still to the splitted and deleted clip snd audiofile - not to the following clip on the second layer. In my test project there is only "one" audiofile.
The more I think about it, the problem is not solved.

Hmm, you're right, the remaining clip belongs to the first recording, so it's not an overlap between two recordings.
 
Phew, I'm a bit lost here...sorry.
 
 

Klaus
Try not recording into Take Lanes:
Uncheck "Create New Lanes on Overlap" and check "Store Takes in Separate Tracks".

Please let us know what happens when you try this. If the problem still occurs, then at least we can exclude Take Lanes as being part of the issue.

It is now very clear.
After recording clip 1, and after that recording clip 2, the first clip 1 is automatically splitted at its right end and muted. Why the clips are overlapping is unclear. Stop and record should never result in overlapping clips. That means after "stop" the project jumps back 0,01 seconds.
 
So it remains a nearly unvisible and muted microclip from the last record - at this point the new record begins.
The picture shows 0,01 seconds:
You can not see it in this picture, but with marker "gn" ends the first record and the second record begins.
The overlapping clip 1 is then cut into a main clip and a muted microclip.
So I do not need to wonder when normalizing an audioclip and applying effects to an audioclip comes to corrupted audiodata. Because the main clip references in addition to an unvisible microclip that is muted. Operations to this main clip overwhelm Sonar and it comes to corrupt audiodata.
 
So the cause is found but the problem is not solved.
 
I know in my case how I now prevent this. The silly question remains - how to find this microclips and prevent thereby corrupt audiodata?
 

 
 

THambrecht
Since a few months, I watch a mysterious behavior after splitting audioclips.
I mark the whole clip and split it at a certain point.
In preferences I set: Selection after single split: "left portion".
So the left portion should be complete deleted - but every twentieth time a tiny bit of the audioclip remains at the left side. This tiny bit is so short (0,01 seconds), that is almost unvisible. 
I have been working for about 20 years with Sonar, earn my daily money with it,but I have only experienced that behavior since a few months.
This has effect to the clip when editing the visible main piece. Because Sonar holds the whole audiodata, even after "apply trimming" to the main piece, and references to the unvisible tiny bit. I also watch sometimes corrupt audiodata when normalising or applying an effect to an audioclip. I'm not surprised if problems occur by this behavior.
 

 
Thanks for the report, we'll look into it and work to resolve it in a future update.
 
Keith