Audio clip's offset incorrect after tempo change

Forums

When an audio clip has an offset then the time stretch/squeeze after a tempo change works but the offset is changed although it shouldn't.

See example session http://suedwestlicht.saar.de/download/tempochange.qtz

Steps to reproduce it:
1.) Place an audio clip with offset on an audio track
2.) Copy that clip to a later position
3.) Add a tempo change between those 2 clips
4.) In the 2nd audio clip the offset has changed but it shouldn't

== Before tempo change (BBT / Time / Frames) ==

Original clip:
Start 4.1.000 / 06.000 / 288000
Offset 4.0.240 / 08.125 / 390000
Length 2.0.480 / 04.250 / 204000

Copied clip:
Start 8.1.000 / 14.000 / 672000
Offset 4.0.240 / 08.125 / 390000
Length 2.0.480 / 04.250 / 204000

== After tempo change at 7.1.000 from 120 to 240 bpm ==

Original clip:
Start 4.1.000 / 06.000 / 288000
Offset 5.0.480 / 08.125 / 390000
Length 2.0.480 / 04.250 / 204000

Copied clip:
Start 8.1.000 / 13.000 / 624000
Offset 8.0.480 / 08.125 / 390000
Length 2.0.480 / 02.125 / 102000

The offset in BBT of the original clip changed from 4.0.240 to 5.0.480, and I don't think thats's correct, although the audio file is long and goes beyond the position where the tempo change occurs.
It's played correctly, though. But when I edit the offset only a little bit, e.g. 5.0.480 to 5.0.482, place the cursor in the BBT flield an press ENTER, then it jumps to the later 5.0.x position.

The offset in BBT in the copied clip changed from 4.0.240 to 8.0.480. I don't think that's correct, either.
It's NOT played correctly. It starts from a later position since the offset is higher.

I think BBT for audio clips' offset is highly problematic. Offset should always refer to the unprocessed audio file, so only Time and Frames make sense.

I think BBT for audio clips' offset is highly problematic. Offset should always refer to the unprocessed audio file, so only Time and Frames make sense.

yes, editing clip values in BBT maybe problematic, specially if it's taken on separate or worse, across different locations and time-frames...

the problem there seems you're probably making the wrong assessment while looking to clip offsets exclusively in BBT:

the very same offset (in linear time or frames) will show different values when converted to BBT, exactly because the two clips are located at different tempi (and/or time-signature) locations.

try making your checking otherwise in Time or Frames display formats, then I think you won't see any "incorrect" offsets :)

hth.
byee

After the tempo change from 120 to 240 I had to edit the offset value in frames in the copied clip after the tempo change position. It was the same as before the tempo change. When I set it to half the value it was correct.

So I guess you count the offset in the processed wav file. Then you have to change it according to the tempo change as you do it with the length already.

Add new comment

The content of this field is kept private and will not be shown publicly.

Markdown

  • Parses markdown and converts it to HTML.
  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type='1 A I'> <li> <dl> <dt> <dd> <h2 id='jump-*'> <h3 id> <h4 id> <h5 id> <h6 id> <img src alt height width> <strike> <pre> <p> <br>
  • Lines and paragraphs break automatically.

Filtered HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <b> <i> <pre> <img src alt height width> <strike>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.

Plain text

  • No HTML tags allowed.
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.
File attachments
Unlimited number of files can be uploaded to this field.
2 MB limit.
Allowed types: jpg jpeg gif png txt doc docx xls xlsx pdf ppt pps odt ods odp zip gz bz2 xz patch diff wav ogg flac ogv mp4 qtz.