Timecode Timeline Disparity

[rainspell]

Using Reaper 6.04, I have a video rendered at 23.98 fps. My tempo is 120 bpm. I have snapping on bars enabled. As I move through the project on the timeline, the timecode in Reaper does not match the visual burn-in timecode in my movie - it drifts. Weirdly, also when I start playback at a new position - Reaper seems to re-align the video and sort of get back in sync - but if I take a screen shot the transport doesn't seem to line up with the visual time code. When I plug in 23.98 into the project settings - when I open it back up again it will change it back to 23.976. Not sure if this is affecting it or not - I've tried combinations of different settings all to no avail.

If I use the identical video in Cubase 10.5 the transport always displays the correct time code matching the visual burn in.

Any suggestions?
Thanks for any help.

[plush2]

23.98 and 23.976 are the same thing. The one is just a rounding up of that .976 to .98 to make it a shorter number to write down. The actual frame counting and length is exactly the same. Certain video editors export videos with that terminology.

I'm not sure why you are seeing drift. During playback does the video gradually drift out of sync? Is the difference between the Reaper timecode and the windows burn timecode consistent or does it vary every time you position the cursor at a known spot?

[rainspell]

Thanks for the clarification about 23.976 and 23.98. After some more investigating - I found that the I was looking at the real time counter - ugh. After I loaded the actual frame counter into the transport it worked. And it would stand to reason that the real time does drift based on that frame rate. Good safety tip - and sorry for not noticing before.

It seems that the only way to set the sequence start time is in real time(?) which is a little challenging for time code/post production video users. Hopefully added in a future update?

Thanks!

[plush2]

Originally Posted by rainspell

Thanks for the clarification about 23.976 and 23.98. After some more investigating - I found that the I was looking at the real time counter - ugh. After I loaded the actual frame counter into the transport it worked. And it would stand to reason that the real time does drift based on that frame rate. Good safety tip - and sorry for not noticing before.

It seems that the only way to set the sequence start time is in real time(?) which is a little challenging for time code/post production video users. Hopefully added in a future update?

Thanks!

As long as the main time unit is set to 23.976 then the offset will be in that format. The drift happens because 23.976 is what is known as a magic frame rate. These rates, 29.97, 23.976 etc. count back at 1.001 seconds for every real second. The names describe how many frames transpire in an actual second. They still count up 30 and 24 frames respectively, just over a longer period of time.