Main menu
You are here
Wave files begin with a slight fade in
10 December, 2009 - 16:09 — Louigi Verona
Yep - that's what I found. It is heard best with drum loops - the first kick gets slightly muffled. If you paste the loop several times into a track you would get the same effect - as the loop begins over, first kick will be faded in and with softer kicks might seem to disappear at all.
Forums:
Re: Wave files begin with a slight fade in
That's true, all audio clips are slightly faded-in and out at their edges, allegedly to avoid glitches as much as possible. This "artifact" can be indeed very noticeable if you happen to run jackd with large buffer sizes and slower sample rates (=> higher latencies). As first try, reduce the buffer size, for instance to 128 frames which is one good compromise all around. You'll see the slight just becomes slighter, or else. :)
But now that you ask, there's one hack of an idea I got this very moment: audio clips with zero-offsets, that is, their start frame equals the first frame of the audio file which they represent, should not be targets to that anti-glitch fade-in or so. That obviously assumes the audio file is well cut from the start. Nice eh?
Be prepared to play catch up with svn trunk ;) a fix will be cooking in no time ;)
Cheers
[UPDATE:] faster than lightning: qtractor 0.4.3.1452+ (svn trunk) already does the hack!
Yay! Compiled from svn -
Yay! Compiled from svn - beautiful!
Works very nice man, thank you a lot for the fast response.
Hm. My joy was a bit
Hm. My joy was a bit premature in a sense that with 1024 frames it still does not work properly - it does not always exhibit the fade out, but sometimes it will. For instance, if I have 4 clips of the loop, on the 3rd it would typically have the muffling again. If I have two clips, it would usually have the fade in thing on the second one. If I set a range and loop it, the previous version did a better job looping it, in this case there is an audible "jump" and in case of a beat the first base drum may sort of sound twice.
However, when I switched to 128 frames, all of these problems have genuinly disappeared.
Btw, why?
Re: Wave files begin with a slight fade in
The so called anti-glitch fade-in/out ramps are actually being applied to the first and last buffer periods of an audio clip. That should explain the audible difference between 1024 and 128 frames/buffer usage: the ramp is one order of magnitude shorter in the latter case (eg. 23ms vs. 2ms @ 48kHz). You can look at it as like a 10 fold faster attack :)
However, that only explains old behavior. Assuming all clips have zero offset, as you say, there shouldn't be any of this onset muffling anymore. Are you sure all repeated clips are exact copies of each other? or are the slower attack ones the result of cut-segments from a greater one? in this case, you must be aware, these won't be zero-offset audio clips and so those first-period-fade-ins will get into action :/
I'll try to do my homework anyway, 'coz I have something else in mind for the future, like making this ramps independent of buffer/period size for good. Meanwhile, try to find a pattern on the repeated clip muffling if you can. Maybe there's something else more hideous bug lurking in there :(
Cheers && thanks
Okay, figured the woof thing
Okay, figured the woof thing (woof is a sound you get when the fade in occurs on a base drum :)
It does not occur anymore when you are playing a tune without a loop. As soon as you turn loop mode on - woof comes back. And when you turn off the loop mode - in fact, it would still woof for some time, but then go away. Occasionally, I would get a woof even in non-loop play mode, but very rare and I found no pattern.
The loop playback is not very good - it has a small crackling sound when it restarts. If you loop a midi clip, you would get weird results. Sometimes it would miss first notes, so if you loop a chord, it might not play it at all - as if the playhead has skipped the notes and so they do not sound. Next iteration - it would play it okay. But in general the loop mode playback is not seamless.
Hope this helps. If more testing is needed concerning this, tell me what to do.
;)
Re: Okay, figured the woof thing
Indeed. I only got to feel this woof thing on bigger buffer sizes (eg buffer size = 4096) where it gets really noticeable (and annoying, yeah:) Will investigate it further, over the holidays perhaps ;)
Re. the MIDI looping drop notes, I must tell there was a serious mistake on the drift correction code on one of these recent SVN revisions, maybe that's what have been troubling you. Maybe not. I'll ask you to update from svn trunk again, giving today's qtractor 0.4.3.1461+. If it ain't much for you, build with
./configure --enable-debugand, among other things, watch for these messages coming out from the console (stderr):qtractorMidiEngine:drift(): iAudioTime=99999 iMidiTime=99998 (1) iTimeDrift=1 (0.0015%)point here is that iTimeDrift value must not, er, drift away too much and most importantly, the bracketed number and percentage should be near or rounding zero from either side (-/+), at all times. These numbers (inside brackets) get higher valued as higher the audio (jackd) buffer size is, so you'll have lower drifting/jitter as well as lower latencies. If these values get somewhat crazy, stop and try with another MIDI timer resolution (see View/Options.../MIDI/Playback/Queue timer (resolution)). Or a smaller buffer size. As said before, you should be comfortable with a 128 frames buffer size (-p128) as a reasonable target and a double- or triple-period per buffer (-n2 or -n3, these are all jackd parameters, of course).
BBL
I will do that and get back
I will do that and get back to you!
Re: Wave files begin with a slight fade in
OK. Today's qtractor-0.4.3.1462 (svn trunk) tries to scrap all this woofing issue altogether, its change-log says:
- Make anti-glitch audio clip micro fade-in/outs independent
from current buffer size as much as possible. (EXPERIMENTAL)
Hope it's the cure of all pains now... Wait, not all, but some at least :)
Cheers
Add new comment