Audiosnap transient detection is much improved.

Can you send us the wave file for that segment where the transient is not detected? It would be useful to analyze to see why that one transient was missed.

Noel Borthwick [Cakewalk
]

Can you send us the wave file for that segment where the transient is not detected? It would be useful to analyze to see why that one transient was missed.

How's that for service?
 
Whatever problems there are, no one can say that these guys aren't trying...

I noticed it generally much better tonight also.  Keep it going though:)

Thanks

The old Audiosnap was all over the place when detecting transients which cause as much hand editing as Audiosnap produced.  Transient markers would be all over the place even on the most defined transients. Well, it looks like the transient detection has definitely been improved even if the additional tools I hoped for weren't integrated into the interface.

I'd be really surprised if they did that without mentioning it. I'll check it out, but I suspect it's placebo effect.


As for the one misplaced transient marker you showed, I'll wager if you zoom the amplitude on that transient, you'll find a discontinuity or bleed from another track that triggered the early placement.


You mentioned gating and filtering for drum replacement. It's not built in to AS, or course, but it is easy and helpful to apply gating and/or EQ to a clone of a drum track before enabling AS to get more precise transient detection. It's especially helpful when you get a lot of these early transient detections which I have seen before with some drum tracks. 


EDIT: If you've already done it, I'd be interested to see screenshots of the same track with AS applied in X1 vs. 8.5.3 that show a difference in transient detection.

As for the one misplaced transient marker you showed, I'll wager if you zoom the amplitude on that transient, you'll find a discontinuity or bleed from another track that triggered the early placement.

 
There was a minimum of two in a thirty bar section.  I scaled the waveform  prior to my post to see if there was some little niggle that was triggering the detection.  There wasn't one.
 
Regardless of that;
 
1) The Threshold and Resolution controls should be able to filter out any background bleed in a cut and dry, multitrack snare drum track.  The transients are too defined to not be able to accomplish that.
 
2) The ratio of wrong guess to correct guesses is irrevelant if this is supposed to be a professional app (especially in this particular situation.)  It's all about confidence in your tools here.  If you create a series midi events for the purposes of triggering a sequencer, you shouldn't have to waste your time resources checking to see if the tool actually performed as expected.  Your client isn't paying you to do that and Cakewalk certainly isn't kicking you back any rebates for it either.
 
3) Creation of midi events is included in Audiosnap.  This is naturally going to suggest drum replacement.  I've been harping (and suggesting via feature requests) that just a few more controls and some user preset saving features could put them in the game.  When AudioSnap detects the transients correctly, it is really easy to create layered (or replaced) drum tracks.

I'm no audiosnap expert having only used it a couple of times before but I've just been using it on a guitar line and it worked great. Definitely improved and easier to use than my last effort in 8.3, bbut I don;t think I was pushing the envelope by any stretch of the imagination.

Now if I could only get Sonar to record the guitar parts in time in the first place I wouldn't need it. 

FBBDefinitely improved and easier to use than my last effort in 8.3

There were huge changes between 8.3 and 8.5, and more from 8.5.0 to 8.5.3, but not so much (if any) from 8.5.3 to X1.


I did a little testing on  few clips, and did not see even a one-sample difference in where transients were located between 8.5.3 and X1b.


I did notice in the process, however, that the problem with spurious "User" markers (solid diamond handles) being added on beats that don't have corresponding audio transients persists in X1b.   Easily fixed by selecting all User markers and deleting them right after  enabling AS, but it's one of those little PITA bugs that would be nice to be rid of.


 

Noel Borthwick [Cakewalk
]

Can you send us the wave file for that segment where the transient is not detected? It would be useful to analyze to see why that one transient was missed.

I don't suppose Noel is still tuned into this thread, but thought I'd mention that the Kick and Snare tracks from the old Guilty demo by Unified Tribe are good examples of transient misdetection - due, at least in part, to long "pre-attacks" on drum transients that look to have been caused by a hardware gate/compressor with a long attack being applied to the analog signal before it every got recorded.

sdpate


Does anyone use the auto quantize or are you moving the transient markers by hand?

I get weird results with quantize but it works ok lining up the transients on a bass line, except you have to demote 1/8th notes on turn arounds.

 
I've been fond of saying that anything that "automatically" does something usually does it automatically wrong.  I usually move the transients by hand as I line problems up with another instrument that it relates to.  For example, a bass guitar with a kick.
 
I may at some times use an automatic mode to align a choppy rhythm guitar part and quantize with a percentage to a grid.

It's not as simple as select whole track/clip and quantize to get the results I want but then I find that true of any quantize, be that MIDI or audio.

 
+1 In my experience AS quanize works as well as MIDI quantize with the caveat that you have to make sure the transient markers are accurately placed, and ony the ones you want affected are enabled.
 
Then, as with MIDI quantizing, you have to make sure your're quantizing to the right resolution with notes close enough to the intended timing that they don't get quantized the wrong direction.