Quote:
Originally Posted by r0lZ
Yes, the timecodes in the XML are in the form HH:MM:SS:FF, where FF is a number of frames, not a fraction of a second. There is no way to be more precise than that.
However, the timecodes displayed in the GUI, are in the form HH:MM:SS.sss, where SS.sss is a floating point. And IMO it is extremely difficult to understand what BDSup2Sub does when it converts the input frame rate to the frame rate displayed in the GUI. Usually, they do not match at all. And it's not simply a precision problem. There is obviously a bug here, but increasing the precision will not fix it.
For example, if the XML timecode is 01:27:38:11 at 23.976fps, the frame number is 5258 seconds * (24/1001) + 11 = 126077. Converted back to a timecode, still at 23.976fps, that gives 126077 / (24/1001) = 5258.4617 seconds = approximately 01:27:38.462. But in the GUI, the time code displayed is 01:27:43.716 !!! It is obviously completely wrong ! It seems that BDSup2Sub does ALWAYS a framerate conversion, even when that option is not enabled.
Anyway, we have to live with that terrible bug, since BDSup2Sub is not developed any more.
|
I thought the time codes were:
FF - milliseconds
0 - 000
1 - 040
2 - 080
3 - 120
4 - 160
5 - 200
6 - 240
7 - 280
8 - 320
9 - 360
10 - 400
11 - 440
12 - 480
13 - 520
14 - 560
15 - 600
16 - 640
17 - 680
18 - 720
19 - 760
20 - 800
21 - 840
22 - 880
23 - 920
24 - 960
I could be wrong but its always worked for me. I seem to remember testing by exporting and importing using the above conversion and the times remained correct.
Edited typo on numbering.
I always use --fps-target keep and the above numbers work for all FPS.