Audiosnap/ Quantizing/ Tempo Maps- Flaws, bugs, and tricks

DESIGN FLAWS
 
Here are what I believe are some fundamental design flaws with Sonar's Audiosnap/ Quantizing/ Tempo Map tools. I really hope Cakewalk will take notice and fix these.
 
If I am wrong about anything here, please let me know!!!!
 
1) There are too many ways of going about the same thing. Here are the options:
Quantize
Groove Quantize
Quantize to Pool
Extract/ Apply Groove tool
Tempo Mapping
 
It took me hours of reading, and re-reading the online help, and experimenting, to understand the fundamental differences between all these methods. The online help is terribly disorganized, because information about these various approaches is scattered in bits and pieces.
 
2) There seems to be a great deal of redundancy between these different tools. For example, Groove Quantize seems to be fundamentally the same as Quantize to Pool. They both work by analyzing the transients of a given track, and applying that data to a quantized track. The only fundamental difference I can see is that when Groove Quantizing, Sonar stores that data in the Windows clipboard. When Pool Quantizing, Sonar stores that data in something called a "pool." Why have 2 methods of doing the same thing?
 
Next, Quantize to Pool is fundamentally the same thing as Extract/ Apply Groove. They both work by extracting transients to a pool and applying them to a quantized track. The only differences are:
-When you use Extract/ Apply Groove, the pool is automatically cleared after issuing the command.
-Quantize to Pool allows you to layer transients onto the pool from various sources. Extract/ Apply Groove does not.
- Quantize to Pool provides a dialogue whereby you can adjust the strength of the quantize, whereas Extract/ Apply Groove does not.
 
All these nuances are painfully unclear in the manual, and I don't think all this redundancy is needed.
 
3) Controls for these various methods are scattered all about the interface in an illogical manner. For example Quantize and Groove Quantize are available under the Process menu, but Pool Quantize is buried in an obscure location in the right click menu that only becomes available if the Transient Tool is selected. Quantize and Tempo Mapping are available from the AudioSnap palette, but Groove Quantize and Pool Quantize are not. But if you want to use Groove Quantize on an audio track, you first have to open the AudioSnap palette and click a button called "Copy to Midi," which seems totally counter-intuitive.
 
4) When humans play music, there are tiny timing imperfections that create feel in the music. The goal is to quantize in a manner that makes the music tight, but without losing this human touch. When multiple audio tracks are perfectly synced to a time ruler (metronome,) the human element is stripped away from the music, and the result sounds too mechanical. I believe the fundamental purpose of Groove Quantizing/ Pool Quantizing was to address this problem. It works by analyzing the transients of a "master groove" track, and then quantizing other tracks to those transients.
 
But the fundamental flaw is this: In order for any given beat to be groove quantized/ pool quantized, that beat must be provided with a transient in the master groove track. Otherwise, the quantized beat has nothing to snap to. But what happens if the source groove track has no transient on that particular beat?
 
Example:
Let's say we have a rhythm guitar clip with an awesome, behind-the-beat groove to it. A percussionist recorded his track too ahead of the beat. COMMON problem. We want to quantize the percussion clip, to the groove of the rhythm guitar clip.
 
For simplicity, let's say the rhythm guitar clip has 2 transients: A downbeat strum, and a backbeat strum. The percussion clip also has 2 transients, but they are both on the downbeat.
 
If you extract the groove/ pool from the rhythm guitar clip and apply that to the percussion clip, then the first beat of the percussion track will adjust into alignment with the guitar clip. The reason is that these are both downbeats, roughly at the same place.
 
But the second percussion beat will not quantize to the guitar, because that was a downbeat, and there was no corresponding downbeat on the guitar clip to quantize to. The result is that the beats in the percussion track have adjusted disproportionately to one another. If the percussion track was off time pretty badly, then the quantized percussion will sound terrible.
 
To present an extreme case, how would you quantize a bassline that is played on all downbeats, to a rhythm guitar track that is played on all backbeats? You can't. There goes raggae!
 
5) To fix this problem, Sonar offers what is called "Add MBT to pool." The idea is to steal metronomic beats off the Time Ruler and add these to the pool. You can select whether to take 16th beats, or quarter beats, and so on. This is supposed to fill in the missing markers for our backbeats.
 
But the problem with this feature is that it adds pool markers for ALL beats, not just the ones for which a transient marker was missing. So on each beat that the musician played a note, you'll have TWO pool markers right next to each other: The one played by the musician (which represents the right "feel" of the groove,) and the one taken off the time ruler.
 
Let's return to our earlier example, the rhythm guitar track has a great, behind-the-beat groove to it. But the poor percussionist always plays ahead of the beat. The MBT pool marker will come right before the strum marker. Then the percussion transient, which was early, will be quantized to the MBT marker, rather than the guitarist's strum. The guitarist's "behind-the beat" groove is not captured. This completely defeats the whole purpose of groove quantizing in the first place. And this is a very real-world situation.
 
Even if the problem of doubled markers was resolved, this method still would be flawed, because all the downbeats of this percussion track would have a  "behind-the-beat" groove, while all backbeats would be played precisely on the metronome, which makes no sense.

SOLUTION TO GROOVE QUANTIZING: ALIGN TIME RULER TO CLIP
 
The solution I found for groove quantizing audio is not to use groove quantize at all. (Or pool quantize.)  The answer is in tempo mapping. The documentation for this feature is so poor that I had to read it some 10 times over 2 days, and set up a series of test files, before I finally "got it."
 
The reason why tempo mapping is so great, is that it stretches the timing of all beats within a measure proportionately, whether those beats happened to fall on a groove's transient or not. I am getting awesome results with this. It works by automatically assigning a slightly different tempo to each measure of the groove track. The project time ruler is then adjusted to fit that tempo, and all other tracks can be Quantized to that time ruler (using regular Quantize,) using any level of resolution needed. Then your quantizing will sound "human" rather than mechanical.
 
Here's how it works:
 
1) For all your audio tracks, right click to "Edit Tempo Map" and set whatever Average Tempo and Number of Beats values you want in those fields. You must do this first because if you do it later, you'll lose all your transient edits (as explained above.)
 
2) Choose which track you want to use for defining the groove for all other tracks. It should have a great rhythmic feel and it should be fairly accurate. I'll call this the "groove source" track. (I'm assuming the entire track is just one clip. You can safely bounce to clips before doing any time stretching.) First, let's quantize your groove source track to the time ruler just a little bit, to make sure it has fairly good rhythm.  If your groove source track is audio, then you need to set the transients. Use only a half note or a whole note of resolution. Why? Because if 2 transients are too close to one another, the result can sound unnatural or forced if they are stretched too much. Let the stretching occur proportionally over 2 or 4 beats.

What this means is, just lock in 1 or 2 key transients per measure, maximum. And this is critical: The transients you choose must fall on either the 1, 2, 3, or 4 downbeat of the measure. That's because you'll need to anchor beatmarkers to them later. Don't bother with any 8th note backbeat transients, you don't need them. Play with the threshold and resolution in Audiosnap to get you close to this result, then disable/ adjust from there.
 
3) Check the transients, because occasionally Sonar throws them off arbitrarily. Disable or adjust transients that are off.
 
4) Promote all the transients so that your disabled ones won't be re-enabled against your will (see above.)
 
5) Quantize your groove source track to the Time Ruler. Don't overdo it- I like a strength of 50% (assuming your player started out with good rhythm.) Remember you don't want to squash all the humanity out of it. Choose the smallest value of beat that you have in your track (I find that 16th beat is the smallest you can go in a human-played track. You may get better results with larger values, like 8th or quarter notes. If you choose 16th beats, you risk certain 8th notes going off to a 16th beat, etc. Experiment.) 
 
6) You'll have to listen to the quantized material for any notes that were quantized to the wrong direction. I typically undo the quantize, streatch that particular note so that it will fall within the range of your beat resolution, then re-quantize.

7) While still in the Transient Tool, right click the groove source track and select Edit Tempo Map.
 
8) Now you'll need to adjust the beat markers. This takes a tremendous amount of patience. The beat markers can get off, so you have to go trough the whole track, zoomed in pretty close. Try locking in the beginning and end of the track first. Then the rest of the markers will fall into line pretty close.

CRITICAL: The beat markers MUST BE "ANCHORED" (RED) in order to affect the time ruler. (I mentioned this complaint above.) So every measure needs at least one beat marker that is anchored to a transient. I have found this is all you need. Again, the beauty of this method is that all other beats in the measure will adjust proportionally. (Obviously, if there are any erratic beats in your groove source track, you probably shouldn't have chosen this track as your groove source in the first place.)

As you are doing this, realize that your other tracks will eventually be quantized according to this tempo map.
 
You may occasionally need to manually add a transient to snap a beat marker to, if there wasn't a good one to anchor to. (For example, if a whole section is 8th note backbeats.)  Turn on the measure gridlines, it will make them easier to see.
 
9) Repeat all the above steps for the tracks you want to quantize (applies only to audio tracks) . Midi tracks can be quantized too, but you don't have to mess with the transients etc.
 
10) Under clip properties, make sure that the time base for all clips in your project are set to Musical Time.
 
11) Select your groove source track, and in the AudioSnap palette, click "Project tempo follows clip." Choose "Beat" as the resolution. (We assume your source track has no erratic beats at this point, because you quantized it earlier to the time ruler.) The project tempo is changed to follow the groove source track. Click around- you will notice that your project tempo changes slightly with each measure, reflecting the slight timing nuances of the performance. Amazing.
 
12) Because the time ruler is now adjusted to match the timing nuances of your groove source track, all other tracks may simply be quantized to the time ruler. Select any clip or track you want to quantize, then select Process > Quantize (NOT groove quantize.) 
 
I find that a quantize of 60-70% sounds most natural. Remember that it would be impossible for a drummer to have 100% matched every little rhythm idiosyncracy of the guitarist, etc. This is why I'd never choose 100% strength- it sounds a bit unnatural, it would be impossible to do.
 
All beats of your quantized track will be quantized to the groove source track. And here is the clincher: Smaller beats (like 16th beats) will not be ignored: They will automatically be interpolated proportionately between the other beats! This is the critical benefit that Pool & Groove Quantizing are missing.
 
13) Again, you'll need to methodically check the quantize results to make sure that nothing got stretched to the wrong beat.

14) I'm brand new at this so if other people have other methods or can point out any errors here, please weigh in!
 
Good luck!

I've never used Audiosnap but if I do I'm going to read this thread a couple of times first and keep it open while I work. Thanks for posting this valuable resource of information.

I think Sonar would be able to distinguish itself from its competition by creating great tempo management tools.

I agree. I can imagine consolidating the jumble, and bringing everything into a single dialogue that permits all this to happen in a far more intuitive way, in an organized sequence of steps. Right now, it's like the tools are there, but there's not enough clarity on how they should be used, and in what order. So the user is left to figure out the maze.

I think this is a common problem in software development. Sections of code are added on as more features are added, from one release to the next. But then at some point, the design of the whole no longer makes any sense, and the developer has a difficult choice to make: Do we clean up the jumbled mess that is already there, or do we just keep layering on more features?  I think Sonar might be there right now. If Version 9 cleaned this up without adding a single new feature, I'd jump on it in a heartbeat:)

ight now, it's like the tools are there, but there's not enough clarity on how they should be used, and in what order. So the user is left to figure out the maze.

I agree with this to some extent, but different users also have many different goals in different situations, and the apparent overlap of tools and functions sometimes gives a shorter path to achieving each of those goals by one route or another. For example the difference between Groove Quantize, which is meant to allow quantizing to a saved or imported groove pattern, vs. Quantize to Pool, which is meant to allow quick and selective quantizing of one track to another already in the project. Also there are circumstances where it makes sense to do either of these, even when the overall project is already well-aligned with timeline. If you consider all the different ways you might want to modify the timing of a project with reference to both MIDI and audio, I don't think there's really that much redundancy in the design.


I also think there's a limit to how intuitive you can make these functions. Understanding all the complexities of musical time's relationship to absolute time, and how it's represented in SONAR's timeline (where M:B:T intervals are fixed, and absolute time is malleable) is inherently challenging. A lot of what confuses users about Audiosnap boils down to a basic misunderstanding of these relationships, and/or failure too put the time and energy into understanding it all that you have. There's no royal road to learning some of this stuff.

Yes, very well thought out and possibly indicates that the designers and implementers of audiosnap confused themselves along the way.

Some points though:

Why have 2 methods of doing the same thing?(from post #2)

They aren't the same thing. Quantize to groove to me means taking a rhythm scheme essentially from a midi or midi-like specification. Grooves can be created from midi and saved as "grooves". That idea predates audiosnap as far as I can remember. That would be one reason for having the groove items on the menu bar. The audiosnap pool is integrated with grooves mainly by two ways:
1.converting the pool transients into midi and then saving that as a groove, or
2. using a groove as a source for quantizing audio. 

Quantizing from the pool skips the step of saving the pool as a groove. But quantizing from a groove requires either selecting a groove from the saved grooves or creating a groove by way of a midi sequence which by the way could be generated from the pool.

To me, the pool is a nebulous and, well, "transient" collection of transients, whereas a midi track is a much more clearly visible representation of a pattern. Some of the difficulties of editing and preserving transients in the pool would be much more easily managed by putting them on a midi track and editing them there and maybe even permanently saving them in a "groove". But maybe only because the existing implementation of the pool is hard to work and buggy.

-Quantize to Pool allows you to layer transients onto the pool from various sources.

Did you mean that Quantize to Pool layers the transients? I didn't think so. Or did you mean that the Pool is an aggregate of the layered transients from various sources. Which can then be used to quantize.

Anyway, it might be useful to keep in mind that the task of layering a rhythm that is not completely represented by any one audio or midi track is complex by nature. You want some beats, but not all, from one track and you want other beats, but not all, from another track.

It seems that a midi track might be an easier venue in the current implementation for constructing a rhythmic pattern. Many things that are difficult or buggy with the pool can be done maybe easier on a midi track. Then the midi track can be used as a "groove" for quantizing.

Bill B

Could you explain how your process in post #4 preserves the finer-grained timings? Seems like you might have meant that "all other beats in the measure will adjust proportionally" implies something that could align the finer grained transients, but I don't see how.

I see how using "quantize" (not quantize to pool or groove) would align the major beats that were used to derive the tempo map, but I don't see how the finer grained timing is applied. Or maybe it is good enough to let the finer grained timing of the different instruments to not be aligned with one another.

One more thing about grooves. When applying a groove (including a groove derived from the pool) to a midi track, the relative intensity of each transient can be mapped into velocity in the hits being quantized, thereby transferring not just the timing part of the rhythm but the emphasis of the individual hits as well. This is another way that the whole "groove" notion differs from quantizing audio, since there is no attempt to apply an emphasis pattern to an audio track.

Bill B

Seems like you might have meant that "all other beats in the measure will adjust proportionally" implies something that could align the finer grained transients, but I don't see how.

All he's saying is that aligning the timeline to the audio clip beats with a tempo map means that beats between tempo changes are proportionally spaced, so you can quantize to any lower resolution, and SONAR knows where that point is in the measure. Whereas with Groove Quantize or Quantize to Pool, SONAR can only move events to/toward the nearest beat in the pattern.

   I also have been silently learning from this forum, but I've spent many hours trying to learn audiosnap 2.0 have some things to add.  My only use for audiosnap so far is to match tracks I record and tracks made from loops to drum tracks composed with PGMusic's RealDrums.    I basically only use Quantize to Pool or it's equivalent extract/apply groove, or I manually line up transient markers in the new tracks to drum transients.  This is after I spend a lot of time disabling and adding transient markers.  The Threshold and resolution filters get me most of the way there, but I usually have to edit markers to fine tune it.    The one thing that hung me up the most was an instruction in the Sonar Reference Manual on page 407:
   "Until your project is mixed and finalized, it is recommended that you use the Freeze function instead of Bounce to Tracks(s) or Bounce to Clips(s) if you need to temporarily off-load CPU processing power. "
   I did this on several songs I was recording thinking I could come back and fine-tune audiosnap markers later.  That was unfortunately wrong.  When I opened up most of these songs at the later time, tracks were missing transient markers and waveform displays on sections of the tracks but not others.  I had some copies of these tracks that I had cloned from sitting in an archived folder, so I had to go back to re-do the audiosnap work.  There were some tracks that were not backed up this way, so I had to salvage them by resetting the transient markers the best I could, bounce to clip, and start over.  After the 2nd pass of audiosnap, I carefully saved the work using bounce to clip, making sure I was totally satisfied before locking it in and moving on to the next track. 
   I don't know if I was doing something wrong, but I don't trust Sonar to save audiosnap markers.  I don't hit the save button until I completely finish working on a track, bounce to clip, and turn off the display of markers on that clip.

-- Jim

Maybe its just me but I can very rarely move any audio without getting ugly artifacts.  I can quantize a bass clip with the same exact settings 2 times, bounce it down..sometimes I will have ugly sounding atifacts sometimes I will not.

Anyhow, thank you Big Lion for posting this info, I will keep around for future info should I someday be able to stretch audio in Audio Snap without getting really ugly noises.

-Mike

Big Lion,

I think I'll need a couple of weeks to digest your post and try them out myself...currently I have left AS in the Sonar shelf (temporarily) because it's so frustratingly hard to understand and to get right!

Cake should commission you to do the AS Master Class videos!! 


Btw, excellent post!

bvideo


Yes, very well thought out and possibly indicates that the designers and implementers of audiosnap confused themselves along the way.

Some points though:

Why have 2 methods of doing the same thing?(from post #2)

They aren't the same thing. Quantize to groove to me means taking a rhythm scheme essentially from a midi or midi-like specification. Grooves can be created from midi and saved as "grooves". That idea predates audiosnap as far as I can remember. That would be one reason for having the groove items on the menu bar. The audiosnap pool is integrated with grooves mainly by two ways:
1.converting the pool transients into midi and then saving that as a groove, or
2. using a groove as a source for quantizing audio. 

Quantizing from the pool skips the step of saving the pool as a groove. But quantizing from a groove requires either selecting a groove from the saved grooves or creating a groove by way of a midi sequence which by the way could be generated from the pool.

To me, the pool is a nebulous and, well, "transient" collection of transients, whereas a midi track is a much more clearly visible representation of a pattern. Some of the difficulties of editing and preserving transients in the pool would be much more easily managed by putting them on a midi track and editing them there and maybe even permanently saving them in a "groove". But maybe only because the existing implementation of the pool is hard to work and buggy.

-Quantize to Pool allows you to layer transients onto the pool from various sources.

Did you mean that Quantize to Pool layers the transients? I didn't think so. Or did you mean that the Pool is an aggregate of the layered transients from various sources. Which can then be used to quantize.

Anyway, it might be useful to keep in mind that the task of layering a rhythm that is not completely represented by any one audio or midi track is complex by nature. You want some beats, but not all, from one track and you want other beats, but not all, from another track.

It seems that a midi track might be an easier venue in the current implementation for constructing a rhythmic pattern. Many things that are difficult or buggy with the pool can be done maybe easier on a midi track. Then the midi track can be used as a "groove" for quantizing.

Bill B

Hey Bill B,

I just wanted to respond to some of your thoughts-

-Yes, Groove Quantize is designed to operate from Midi. But, isn't it presented as a method of quantizing from audio as well? All you need to do is click the "copy to midi" button in the Audisnap palette. So my question was, why couldn't all these quantizing functions just be combined under a single dialogue? For example, once the user has collected a "pool" of transients, (from either an audio, OR a midi source,) why not give the user the option of saving that as a groove file? Then this one dialogue can provide the functionality of both features. All I'm saying is, maybe there is a way to bring all this under one hood, along with a few check-box options that give the user options. So that it's not scattered about. But I'm not really a software designer, it was just an idea;)

-Yes, I meant that the Pool can be an aggregate of the layered transients from various sources, which can then be used to quantize.  Why not allow that feature as well, in the same dialogue. (Perhaps as a check box- ie, "Ammend or replace current pool.")The odds of someone at Cakewalk actually reading this and taking suggestions seem pretty slim though, so it's probably just water under the bridge;)

  "Until your project is mixed and finalized, it is recommended that you use the Freeze function instead of Bounce to Tracks(s) or Bounce to Clips(s) if you need to temporarily off-load CPU processing power. "
  I did this on several songs I was recording thinking I could come back and fine-tune audiosnap markers later.  That was unfortunately wrong.  When I opened up most of these songs at the later time, tracks were missing transient markers and waveform displays on sections of the tracks but not others.

Yeah, I think that freezing tracks is very suspect for planting bugs in a track. I can't prove it, but I'm staying away from freezing tracks for now because I've had the same experience. Cakewalk's solution was to bounce the bugged clip to clips, but when you do that, your transient edits are all lost, like I pointed out in the earlier post... bumma.

I'm beginning to think this tool should basically just not be used. Does X1 have any bug fixes on AudioSnap?

 
BL - I just stumbled on to this thread today.  VERY interesting stuff.  And, I definitely am of the feeling that AudioSnap is best put on the side except for those occassions where the task is simple and easy to accomplish.
 
For complex stuff - like using multiple clips/tracks and adjusting the pool, etc...  it's just not "there" for me yet.   So I do prefer not to use AS if I don't need it.
 
I suspect X1 isn't going to see a whole lot of fixes/tweaks to a few areas  (AudioSnap, The Matrix, who knows what else) because I suspect this new interface rewrite is the main focus and they probably want to see what bugs shake out when it's released to the public.
 
I DO hope X1 point releases DO see improvements in the other areas most/many of use have expressed with concerns.
 
But I, too, want to thank you for your amazingly thorough and thoughtful post on this entire subject.  So Thanks!
 

Big Lion, thanks for all the work on this. I have run across many of the issues you outline and thus end up working with short clips only or manually align the tracks. Audiosnap and the transient analysis of audio needs additional work.

What I basically need is to get bass and drums perhaps one rhythm instrument to align quickly after recording. That is where a reasonably automated approach would help the most.