• Hi and welcome to the Studio One User Forum!

    Please note that this is an independent, user-driven forum and is not endorsed by, affiliated with, or maintained by PreSonus. Learn more in the Welcome thread!

Audio Bend Issue

shoelesscraig

New member
Hi there...first post here. I searched first and found nothing.

I'm having a weird audio bend/quantize issue I'm wondering if you can advise me on. What I'm about to explain is something I've experienced on MULTIPLE songs I've tracked, not just one.

I've recorded drums (2 overheads, kick, snare, and 4 tom mics). Everything sounds decent, but I have a few minor timing issues. I "group" the drum tracks together, analyze, and then from that point I do one of two things. 1) If the whole track needs timing adjustments, I quantize. 2) If it's just a few places, I manually move the bend markers to correct timing.

The issue that I'm finding is that when I do either one of the above, I get random spots of silence in the overhead mics. Like, you'll hear cymbals ringing out, then a SUPER short blip (microseconds?) where it goes silent, then comes right back. It might show up in only 1 place, or maybe 2 or 3 depending on the track. Once it shows up in these specific spots, it is completely repeatable in the exact same spot EVERY time you play the track. It does this even when I solo the track with the issue (in other words...I can solo JUST the left overhead for example and hear it). Undoing the bend action causes it to go away and back to normal. It's like I'm getting a phase issue (even though I'm literally listening to only 1 microphone when I solo that single track) or something. I zoom in on the waveform and don't see anything weird (I don't think).

Again, repeatable, same spots every time for that particular song/track. This happens to me regularly on nearly any song I attempt this on...just different places depending on the song.

I've tried everything I can think of: Using different tracks as the "guide" before quantizing, using various degrees of "strength", etc....can't seem to figure out what it is. Again, even if I "analyze" the track and just manually move a bend marker or two, it is likely to do this.

It's very noticeable in the mix...to the point where I have to undo it and just live with the timing issue, otherwise the drop in output ruins the song. When you're in the middle of a song and the overheads blip, it's super obvious.

I'm 100% sure I'm doing something wrong, but can't figure out what. If it matters, I'm running S1 V6 and all updates are installed (plus I've had this issue for over a year now with various updates installed during that time....another reason I know it's something I'm doing wrong).

I'm ready to learn.....tell me what I'm doing wrong!
 
This is a bit of a complicated issue to reproduce without the actual song at hand.
Have you tried using the slice option against the bend option? In my experience doing it the „beat detective“ way does work a bit better than bending the material:

 
Yes, it's a quite complex issue. When you get this, is it with the auto quantize or manually moving? If quantizing, what happens some times is you have two bend markers that are "almost" on top of each other, but get moved in different directions with the quantize, leaving a gap.

I've found quantizing like this is next to impossible unless you have a really good drum track and if you have a drum track that good it might be best to just leave it alone.

Another question... Are you analyzing bend markers on "all" the tracks? That also doesn't work very well. Usually you should pick only one ore maybe two tracks to use as the guides, only analyze those without grouping, then group and assign those tracks as the guides. Maybe pick snare and kick or just snare. Also, after you analyze, but before you start moving things, you should go through the track painstakingly removing many bend markers to get it down to just the backbeat hits. Another tip, when you move a bend marker, be aware that it moves against the previous and the following bend markers, if those bend markers are not duplicated on the other tracks you get things out of time track to track.

To get this right with all but the simplest parts is very detailed and difficult. Another idea that works ok is to do it in stages. Delete all markers but the ones on the "one" of each bar, go through and move all those to the "one" and then bounce the tracks. Now you have each bar starting on the right spot, now analyze again and go through and leave only the bend markers on the 1/4 notes and quantize those. Repeat as necessary to get it all done. Or just go through bar by bar and get each bar right manually. Be aware if you do that, you first need to put "anchor" bend markers on the "one" of each bar, so when you move things in between it only affects that bar.

Or, hire a drummer!!
 
Hi guys, thanks for the replies. Yes, it does this in BOTH cases (when I quantize AND manually move). Here's the super weird part...the "blip" in audio will be (usually) NOT in the spot where I made the edit. It will typically be somewhere near there, but several seconds later (past several other audio bend markers that I did NOT move). It's a super weird thing...I don't get it.

I'll continue messing around and see if I can nail it down to one particular thing I'm doing. Again, I'm sure it's me. I wouldn't think the software would be randomly doing this, especially with no one else complaining about it.
 
Hi guys, thanks for the replies. Yes, it does this in BOTH cases (when I quantize AND manually move). Here's the super weird part...the "blip" in audio will be (usually) NOT in the spot where I made the edit. It will typically be somewhere near there, but several seconds later (past several other audio bend markers that I did NOT move). It's a super weird thing...I don't get it.

I'll continue messing around and see if I can nail it down to one particular thing I'm doing. Again, I'm sure it's me. I wouldn't think the software would be randomly doing this, especially with no one else complaining about it.
I have an idea… do you use a tempo map? and does this maybe happen when you make any edit/bending near a dot for a tempo change on the tempo track?
 
Just for fun. I tried this again, I haven't done one of these in a while and not since V7 came out. I have mostly been doing better bands with better drummers so haven't had to tweak as many parts in the past few years. If the part is good, I like the feel of letting it move a little.

So I brought up a recent song, where the drum part was used "as is" and just for fun put it all on the grid. I'll have to say, things actually have improved! I analyzed a snare track, went through it to get bend markers only on the hits on the 1/4 notes. Then grouped all the drum tracks and set the guide to be the snare track. Then quantized it 100% to the grid.

No problems at all, it worked perfectly, all the tracks moved in phase as they should and the resulting parts were perfectly accurate. I didn't have any drop outs or problems at all. If anything, it's better than it's ever been.

Then I closed the file without saving, as I don't want my drums on the grid :)

Bottom line, I'm not sure what you're doing or if there are settings some where that are causing you problems. The only thing I can report is that on my machine, with my settings, I don't get this problem.
 
Last edited:
I had this problem in the past several times. Parts of silence after audio bend, missing graphics and so on. Sadly I never could really narrow it down. After reporting it I was told, that I should wait for an update of the audio bend algorithm or use Asio4All instead of my RME drivers (which by the way didn't solve anything). But there was some thing which much more often caused issues with the audio bend. And that was in conjunction with a larger amount of recorded takes.
What I suspected was, that it could have something to do with the length of the audio file, because takes are more or less single audio files with markers where to start the next takes if I'm correct at this. But maybe it was only random. As it's not something which can be reproduced by some defined actions it's very hard for the support to get into this problem. (if it still occurs in V7, which I din't recognized yet)
Today I use audio bend only as the last possibility if slicing doesn't work or if I don't have stuff from another take. Even with the transient protection I prefer the result of slicing over the bending.
 
I had this problem in the past several times. Parts of silence after audio bend, missing graphics and so on. Sadly I never could really narrow it down. After reporting it I was told, that I should wait for an update of the audio bend algorithm or use Asio4All instead of my RME drivers (which by the way didn't solve anything). But there was some thing which much more often caused issues with the audio bend. And that was in conjunction with a larger amount of recorded takes.
What I suspected was, that it could have something to do with the length of the audio file, because takes are more or less single audio files with markers where to start the next takes if I'm correct at this. But maybe it was only random. As it's not something which can be reproduced by some defined actions it's very hard for the support to get into this problem. (if it still occurs in V7, which I din't recognized yet)
Today I use audio bend only as the last possibility if slicing doesn't work or if I don't have stuff from another take. Even with the transient protection I prefer the result of slicing over the bending.

Yes the slice method creates a more accurate result as none of your transients get stretched. I wouldn't ever use ASIO4ALL especially if you have an RME interface as their drivers are the best.
 
This was a suggestion from the support. ;) But it was not a real surprise that it didn't do anything better.

Interesting, that seems very strange. I would bet that RME's engineering staff would not be happy with that suggestion. ASIO4ALL isn't real ASIO at all. It's a middleware application that talks ASIO to the application and then translates that to windows audio. Any proper ASIO driver bypasses windows all together and talks directly to the hardware. RME has some of the best ASIO drivers on the market. But all Pro audio interfaces these days have proper ASIO drivers and operation. But I digress.
 
Interesting, that seems very strange. I would bet that RME's engineering staff would not be happy with that suggestion. ASIO4ALL isn't real ASIO at all. It's a middleware application that talks ASIO to the application and then translates that to windows audio.
Yes, I know, I think it was a bit of a helpless suggestion because there was not a real chance to get deep into the problem. But I really don't know if something has changed in the meantime, there is not a lot of documentation about how often the elastique algo gets updated. It's hard, if there is no way to really reproduce a behaviour.
 
Back
Top