743e - Doesn't like 3 decimal place timecodes

MrVideo

Active member
I have a program that will extract timecodes from Blu-rays. But, when I read in the M2TS file, the timecodes are off. For example, what was input, in the file, as 00:04:08.xxx, went to 4:39:xx.

If I use ^T and paste the 00:04:08.xxx value, the third digit is rounded.

VRD needs to be able to accept frame.txt files with 3 decimal place frame values, by either rounding the three digit value into 2 digits, or dropping the third digit.

But, even with 2 decimal places, in a 23.976 file, a value of 04:08.75 goes to 4:11.09. That is still incorrect.

UPDATE: I know why it is going to the wrong place. VRD doesn't work with decimal seconds. VRD wants the decimal number to be an absolute frame. So, for a 23.976 video, any frame value 25 thru 99 horks up VRD to going to the wrong place.

If VRD sees a 3 place frame value, the it should convert it to a frame value, i.e., .745 -> .18.

UPDATE #2: For the time being, I just set all of the frame values to 0, but even that doesn't get one to the right place. For example, 3:49.00 goes to 3:51.11. Oops.
 
Last edited:

Dan203

Senior Developer
Staff member
Where are you pasting it? In the go to dialog? Or are these chapter files?
 

MrVideo

Active member
Both. Initially it was a chapter file. I pasted some values into the GUI to see what would happen there.
 

MrVideo

Active member
As an added note, the error build up gets larger the larger the time value. For example, when the time is 2 hr even, you'll end up going to 2 hr and 6 seconds.
 

Dan203

Senior Developer
Staff member
The go to dialog only accepts hh:mm:ss.ff

The chapter files do support ms after the period but i think there may be a special format for that. Look at the chapter output by VRD in Tools->Options->Chapters. The formats we output are the only ones we can import.
 

MrVideo

Active member
Yep, I had looked at all those formats. I still do not know what ".hh" means.

That still doesn't solve the issue of importation error, i.e., meaning what you enter is not where it ends up (using 23.976 fps).

If you try and go to 1:30:00.00 (frame 129471), you'll get to 1:30:05.05 (frame 129600). Here is an interesting way to see the issue: Go to the first location by using the frame value. Now, do a ^T and see 1:30:00.00 in the dialog box. Do not enter anything, just hit the enter key to accept what is already there and you end up at 1:30:05.05.

Even with my simple math, I come up with the right value, doing the math on the values between the colons separately and rounding:

1 hr = 3600 sec *= 86313.6 frames = rounded 86314 frames
30 sec = 1800 sec *= 43156.8 frames = rounded 43157 frames
86314 + 43157 = 129471 frames

I do not know what your math formula is for converting time to frames, but obviously there is a major error somewhere in order to cause all that drift.
 

Dan203

Senior Developer
Staff member
You're not accounting for drop frame in your calculations. Drop frame is how editing apps display even time code values for files with fractional frame rates. I forget the exact calculation for 23.976 but essentially you drop a frame every X minutes/second to make up the difference between 23.976 and 24. So in your case the difference between 23.976 and 24 over an hour and a half is roughly 130 frames which works out to about 5.4 seconds. Which is why you're getting 1:30:05.05

Again I forget the exact calculation for dropped frames in 23.976 but in 29.97 it's 2 frames per minute, except every 10th minute. That reconciles the 108 frame per hour difference between 29.97 and 30. 23.976 has a similar pattern, which is why your frame calculation isn't matching ours.
 
Last edited:

MrVideo

Active member
The numbers I am quoting are directly from VRD. If you take 129471 frames (the value shown by VRD) and divide it by 23.976, you get 5400.025025 seconds, which is 1 hr and 30 minutes, the value displayed by VRD. No dropped frames involved.

Get a 23.976 movie that is at least a little longer than 1.5 hours and read it into VRD. Then put in the 129471 frame value. VRD will go to 1:30:00.00. As mentioned above, now do a ^T to bring up the dialog box. It will have 1:30:00.00 already loaded. Now just hit enter. Instead of going to 1:30:00.00, VRD will go to 1:30:05.05. VRD is screwing up with 23.976 video.

It appears that VRD is not doing any kind of drop frame calculation when displaying frame 129471 as 1:30:00.00. As a test, I turned off option 26 (NTSC drop frame) and it didn't make a difference.

The original values for the movies I was working with match up exactly with the location in the movies. The problem is that because VRD is not going to the time values entered, I have to manual get to those locations to correctly set the chapter marks.

From what I can tell, the industry is not doing any drop frame calculations for 23.976 source. I've even seen some program slates even indicating that the time is 23.976 NDFTC. I've done searches on the net and it seems that there is no SMPTE standard for 23.976.

If VRD is doing some kind of DFTC with 23.976, it doesn't appear to be so when what is displayed on the VRD output matches time values with NDFTC, as shown in my math.

The point of all this is that if a user enters a time value into VRD, VRD should go to that time value, not some other value. The left hand of VRD is doing one thing, while the right hand is doing another,

Also note, the hot keys to move X amount of time with 23.976 video is also off. One second moves 23 frames, not 24. Move 10 seconds and it goes to 230 frames. Jump 2 minutes and it goes 2,877 frames.

BTW, as another indicator, the total length of one of the movies as shown in VRD matches exactly the length of the movie as displayed by the Blu-ray player. There isn't even a 1 sec difference.
 
Last edited:

Danr

Administrator
Staff member
Drop frame is only supported for 29.97 and 59.94. All other frame rates use the frame number divided by the frame rate.
 

MrVideo

Active member
That is the result I see and supported by my math. VRD still has a bug in that with the 23.976 frame rate, the entered time value is not where VRD goes to. The cursor hot-key operations are not correct either, as pointed out.

I've had issues editing 23.976 material a well. When setting a cut point, it is not always where you seem to have put it. If you bounce the 1-frame arrow keys, you can see VRD finally get the location correct.

23.976 just seems to be a thorn in VRD's side. It is a horrible result as part of going color many decades ago. It was a stopgap fix for a minor problem, which has now created a major problem.
 

Dan203

Senior Developer
Staff member
Hmmm... the math still works out like we're assuming drop frame in the go to dialog. Maybe that's where the issue is, in the dialog calculation. I'll take a look at how that works and see if that's the case.
 

MrVideo

Active member
Thanks.

Looking at the cursor hot keys more closely, I discovered what ever hot-key motion you do, it is always one frame short. So, whatever internal calculations are done for the hot keys, add one to the result and all will be good.
 
Top Bottom