Main menu
You are here
Audio Clip Timing
I'm new to Qtractor (and to Linux audio), so excuse me, if this sounds stupid or if im just doing something wrong:
I loaded an audio file to a Qtractor audio Track. The file is a simple drum loop created in Hydrogen. When I now play the clip it sounds like there are some milliseconds missing at the beginning.
The drum hits in the clip's wave form representation in the track view are a little bit left of the bars where they should be. (I have not used any "humanizing" in Hydrogen and if i load the original audio file in Audacity, all drum hits are correctly timed.)
If i add a midi track to the qtractor project with samplv1 and load the same drum loop and i now play the track i get some kind of "flanger effect"
=> I got the impression, that when the audio file is loaded, the first few samples get lost and the rest is "shifted to the left" or stretched to the original length. It does not depend on the audio file format, i have tried this with WAV and FLAC files in stereo and mono.
Does this sound like a known bug or a wrong configuration of my system or my Qtractor installation?
re. Audio Clip Timing
check audio clip properties (double-click or menu Clip/Properties...); check whether is there any offset setting or time-stretch applied;
re. flanger effect: probably it's phasing effect instead and that's evidence of the same signal being played together but one displaced in phase by a few milliseconds. according to what you say above, it's all sounding as is: one of the samples is offset somehow.
cheers
re. Audio Clip Timing
Thank you for the quick answer.
I dont find a Clip/Properties options (is my Qtractor version too old, its 0.5.8? This is what i got from my repos), but in Clip/Edit I can see that there is no offset and no stretch.
In the 'Message' Section i sometimes see the message " XRUN(1): some frames might have been lost.", could this have something to do with my problem?
Update
Update: I managed to build Qtractor 0.5.11 from source. I still got a similar problem, but it is a bit different:
now the sample is stretched a little bit.
The sample is exactly 2 seconds long. In the Clip/Edit view I see a value of 00:00:02.177. This happens with the FLAC and the WAV version.
While i drag the samples to the track from the files view, the tooltip tells me the correct length of 2 seconds.
re. Audio Clip Timing
please, don't make an issue about clip time lengths.
qtractor is a sequencer, not a precision audio sample editor. when laid out in the track time-line, all clips times are somewhat fit or "rounded" to MIDI units (bars, beats and ticks), so that accounts to the little difference you may see between the original file length and its representation as a clip in an audio track.
and what about that other problem? does it still cut to silence the initial onset as you originally reported?
byee
re. Audio Clip Timing
No it does not cut away the starting samples, or at least not as many as before.
I'm sorry but I think clip time length IS an issue here. The sample seems to be stretched by about 9% and the last drum hits are displaced by about 160ms. As the sample is exactly 2 sec long (the length of 4 beats in the 120bpm track) there is no need for rounding.
I think the 2 issues might be related, in both cases, there are problems with the length of an imported audio clip. In both cases the audio clip seems to be stretched. In the older version the beginning is cut away, so the clip still has the same total length and in the newer version the clip is larger than it should be.
re. Audio Clip Timing
have you checked sample-rates (audio file's vs. jackd's) ? is your qtractor build compiled with libsamplerate support ?
byee
Problem resolved
Ah, that's it.
Thats actually pretty trivial. Sorry to have bothered you. As I said I'm new to this i didnt realize the role jack played in this and that it has its own fixed sample rate.
The loop's samplerate really was different from jack's. Now i use the same sample rate and got rid of any phasing and stretching problems.
I dont know if the repository version was built with libsamplerate support, but mine was not. So if libsamplerate is used the audio clip is dynamically resampled for jack?
It still seems as if there is something missing at the beginning of the sample but now i realized that only happens at the beginning of playback. If I place the playhead a bit before the loop it does not occur, so I think this is also a problem with jack playback or my audio hardware or whatever. But I think this a minor issue, anyway, because it seems not to affect the exported song and it is not as bad as the stretching.
Thanks for your help.
re. libsamplerate
if libsamplerate is used the audio clip is dynamically resampled for jack?
audio clip files are automatically resampled to current session/jackd's sample rate if different; resampling is carried out on the fly (playback) and that is the sole purpose of libsamplerate in qtractor.
proverbial undefined behavior occurs when qtractor is built and run without libsamplerate support and an audio sample file is played back to a session sample-rate that doesn't exactly match its own.
hth.
cheers
start of sample cut
Hi. New to this also. But having the same thing happen. Have made sure sample rates match. I'm finding that the at the begining of a track, or at the begining of a loop, the first sample, (if it set to begin at that point), has a portion of it's begining samples cut during playback. Playing 4 beats in a loops, it seems there is a slight catch up / lag each time at the begining with the first sample not playing from the begining. Seems to play from a few sample in.
re. start of sample cut
qtractor audio clips always get micro-faded-in at the on-set edge (also a micro-fade-out on the out-set edge); these micro-fade-in(-out) are there to avoid as much as possible any pops and clicks (aka. "zipper-effect") on clip cutting edges.
you may argue that is may be causing undesired distortion to the original audio sample, specially when its offset is zero: you might have a point but only on that special last case indeed.
i'll try to revisit that case and probably remove the micro-fade-in feature only for clips which are zero offset.
hth.
cheers
ps. might have been fixed on git head master today (qtractor >= 0.9.2.16git.2051d7).
Add new comment