View Issue Details

IDProjectCategoryView StatusLast Update
0002282ardourbugspublic2008-12-03 06:22
Reporterjohne53 Assigned To 
Status confirmedResolutionopen 
Product VersionSVN/2.0-ongoing 
Summary0002282: Timecode wrap-around problem at 96K sampling frequency
DescriptionThere seems to be a timecode wrap-around problem when working with high value timeline timecodes at any sampling rate higher than 48KHz. I discovered the problem at 96KHz but I suspect that it will happen at any sampling frequency higher than 48K.

Create or open a 96KHz session. Set one of the big clocks to display 'Timecode'. Type in a timecode of exactly 11 hours. Notice that the time in the clock window is correct. Now click on the actual Timecode track. Note that instead of the edit cursor being reposition to approx 11 hours, it actually gets positioned to around 00:22:45:00 (this particular effect may be dependent on the value of the end marker because it also happens at lower sample rates).

Now type exactly 13 hours into the clock. Notice that it reads the wrong timecode (usually around 00:34:20:00, but this can vary) 14 hours will give a reading of 01:34:20:00 etc etc. The timecode value must be getting truncated somewhere to a 32-bit integer, which doesn't have enough range to cope with sample rates higher than 48KHz.
Additional InformationI discovered this in SVN3117 although I'll be upgrading to something newer this week and will check it again
TagsNo tags attached.



2008-06-11 13:39

administrator   ~0005007

i believe this should be fixed by my change about 3-4 weeks ago to make the Editor use 64 bit frame values everywhere. let me know if not. you can't represent times out to 24 hours with a 32 bit frame counter with SR>48kHz.


2008-06-14 06:15

reporter   ~0005022

Last edited: 2008-06-14 17:22

Hi Paul. After an initial hiccup with Jack I managed to update to Jack svn 1100 which is apparently the latest version to be compatible with 64studio. It includes jack_get_time() which is the bit that I had problems with.

I've now managed to build Ardour 2.4.1 (revision 3343 / svn 3461). However, the problem is still present.

I suspect that the problem has more to do with the location markers than the timeline itself. For example, if you set an 'end' marker at 11 hours timecode, then grab it and try to move it forwards, it actually moves backwards. In fact, all location markers seem to "want" to have an upper limit of around 6 hours 13 minutes, so I suspect that they're still being implemented as signed 32-bit integers.

[Edit: Ardour's svn number corrected]


2008-06-14 17:33

administrator   ~0005024

Your guess is correct. All that was changed was stuff in the GUI. The backend still defines nframes_t as an unsigned 32 bit integer (the same way that WAV does, alas). I do plan to change this, but it will require careful performance measurement on x86 systems to make sure that the hit is not too great.


2008-12-03 06:22

manager   ~0005462

Confirmed to still be an issue on Ardour 2.7


Issue History

Date Modified Username Field Change
2008-06-07 17:45 johne53 New Issue
2008-06-11 13:39 paul Note Added: 0005007
2008-06-11 13:39 paul Status new => feedback
2008-06-14 06:15 johne53 Note Added: 0005022
2008-06-14 17:22 johne53 Note Edited: 0005022
2008-06-14 17:33 paul Note Added: 0005024
2008-12-03 06:22 seablade Note Added: 0005462
2008-12-03 06:22 seablade Status feedback => confirmed