Are the Punch-In Audio Gaps Fixed in 8.5?

Just wondering as I've just noticed gaps while doing punches in 8.3.1.  Thought it was my playing!

Thanks Brundle!

Honestly, I've never paid any attention to this problem since my method for 'punching in" is apparently different than yours. Here's my method (as an example):

The artist plays a 3 minute guitar track but there is a problem at 1:50 through 1:55. I simply cut the clip somewhere around there, slip edit away the bad notes. Then we backup a few seconds or measures, hit record and then have the guitarist start playing along with the music. Obviously when he gets to the open section he simply plays though until the bad notes have been replaced. Then I drag the ends of the new clip until they line up with the previous performance in a way that sounds seamless. There is an automatic crossfade when I align the ends of the new clip so all is as it should be. Is this method more labor intensive than other methods? Perhaps. But we're talking about a few mouse clicks. It never seemed to bother me and in the end, it seemed like a better method since I have control over where the punch in/out edges are. It's been my experience that sometimes the notes immediately before and after the punch-in locations are sometimes better than what was there before - so keep the new notes.

Samplitude makes you define the punch-in locations before you begin recording (no sound on sound recording like in Sonar) but they provide an automatic crossfade at those punch in locations. The only potential problem with this method is that recording doesn't actually start until you hit those predefined locations. Any notes played before or after those locations are lost.

The other option I've used on occasion is to simply play the new part on a new track and then drag the new clip to the previous track after I've established the ends of the replacement clip.

It's not intended... it doesn't happen in WDM, it's an oversight... Cakewalk used to get the easy out; "how can SONAR tell what the ASIO devices hidden buffer is... it's the ASIO devices fault"... but now that we see the correct gap size reported by SONAR it's hard to think that the reason it can not be fixed is because the size can not be measured by SONAR.

It seems to be a case of it just hasn't been fixed.

It bites me in butt every time I do a over dub.

best,
mike

This shoud be fixed immediately.

 
Was going to post a response about how all possible solutions to this issue would involve compromises, none of which are really particularly more desirable than the one that's currently implemented. But in the course of thinking through the logic, I did another test, and got no gap at the end of the punch. 
 
The difference was that I was loop recording with a loop range wider than the punch range. Previously, I just did a single pass.
 
Have to experiment some more, but thought I'd mention it.
 
 

Here is a loop record test I just made a minute ago. I just activated a input... that is why there is no audio waveform... but you can see on the zoomed shots that SONAR is confused on both ends of the loop.

So, it is worse than before.

Mike,
 How far did you zoom in at the clip start ??? How many samples did it miss?
   Bill B

Isn't this a general problem, but when you make a normal take you never start playing withing the audio buffer timerange, because it's just a millisecond or so, so you never notice it.

I mean that you always listen to a audio buffer late data, but realtime is realtime and should be adjusted when stored to the proper spot assuming this fact.

Maybe it is possible to set a huge latency and find out for any recording?

It might be that all takes are off by the latency buffertime, and it just becomes obvious when doing punch-in-out.

I think I saw some general settings for adjusting this, some general nudge thing for audio?

Does anybody remember seeing this?
I will have a look and come back.

Ok, I understand what you are saying... and that may be what is happening.

I can tell you this, I have zoomed in all the way many times because I have to when I'm sticking the cut short tail end of one loop up against the beginning of another.

It is the first time I noticed this gap.

I find the SONAR time line difficult to read... but I'll take another look later today.

Perhaps someone with better eyes can try as well.

best,
mike

bvideo was right about the front gap I displayed earlier... this time I ran some noise and recorded it. You can see that at the tempo the 5 measure started right in the middle of a sample.

bump to mention that addendum have been added in the post above

This is quite a disappointment to me, I thought software was much more accurate than this. I know of aging hardware better than this.

 
Personally, I think these concerns are a little oveblown. If you hear anything at the end of a punch, it's probably not the gap, it's the sudden truncation and/or mismatch between the instantaneous amplitudes of the signal at the punch point. Even without the gap, the phase and amplitude of the punched waveform arne't going to match up perfectly with the existing material; you're still going to have to massage the ends of a punch to get an audibly seamless transition.
 
Tape (a.k.a. aging hardware) doesn't have the same problem, because there is capacitance/inductance in the analog circuits and heads that automatically smooths the transitions; it's not technically as precise, but it's musically more transparent. If you were to record a punch-in done on tape into your DAW and zoom in, I'm sure you'd see several milliseconds of amplitude and waveform weirdness at the punch points; it's just not as noticeable as the discontinuity caused by an instantaneous change in amplitude from one sample to the next.
 
And compensating for the latency presents a logical problem when it comes to looped takes. Basically you have a choice between having a gap or having your loop end late to capture another buffer full of data to fill the gap. Pick your poison.

The biggest problem is when you end up wanting to use the last note as a sustain with intention of picking it up from the next loop... it doesn't cut and paste into the previous loop as seamlessly as it should easily do.

The second problem is when someone naively copies or grooves the clips and looses track of the fact that the gap will cause a significant drift over the course of many instances.

Obviously you can do the workaround... been doing the work around for many years.
 
bummer,
mike