Subtitle timing slightly off

[Paddington]

@mpucoder
Thanks for your reply! I think I've got it now, so let me summarize what I need to do (as I don't extract the sup myself, but use other programs like PgcDemux for doing that, I cannot use the frame approach you promote, as I do not know whether we are dealing with a PAL or NTSC sup - it shouldn't matter anyways in the end):

Step 1: Determine the Presentation Time Stamp PTS
PTS = start_time_in_sec * 90000 = start_time_in_msec * 90;

Step 2: Duration value:
duration_in_frames = ((DCSQ_STM * 1024) + 1023) / frame_duration,
but we also have
duration_in_frames = duration_in_seconds * frames_per_second,
which leads to
duration_in_seconds = ((DCSQ_STM * 1024) + 1023) / (frame_duration*frames_per_second)
(and 3600*25fps_PAL==3003*29.97fps_NTSC==90000)
which is equal to:
duration_in_seconds = ((DCSQ_STM * 1024) + 1023) / 90000,
or
duration_in_mseconds = ((DCSQ_STM * 1024) + 1023) / 90 = ~(DCSQ_STM<<10)/90,
or vice versa
DCSQ_STM = (duration_in_mseconds*90)>>10
similar to what you derive, and independent of PAL or NTSC.

[Paddington]

@jeanl
If my above reasoning is correct, than I believe that DvdSubEdit v1.324 still has some problems when reading a SUP file (i.e. the video delay is not an issue here), e.g.:
PTS = 2044800
Duration = 3.504s
TimeCode: 00:00:22,697 --> 00:00:26,201
In other words, you divide 2044800 by 90090 to get to 22,697. However, I believe you should still divide by 90000 to get 22,720 (as 3600*25fps_PAL==3003*29.97fps_NTSC==90000). What do you think?

[mpucoder]

That depends on whether you want drop-frame or non-drop timecode values. Non-drop is preffered for authoring as it precisely identifies one frame. Drop-frame is valid only for wall-clock time (to determine which values are skipped), not very useful for elapsed time or arbitrary time.

And I can't stress enough that all time values for subs in DVDs must refer to a displayed video frame, hence the extra math and involvement of PAL/NTSV values for computing the duration.
And it really is easier to use frames, not seconds. The pts value 2044800 could not be a NTSC value, as it is not evenly divisible by 3003 (but is divisible by 3600, so probably a PAL value). Assuming PAL that is frame 568, or 00:00:22:18

[DonMartione]

Thanks, it seems many are working on their software to fix any problems related to this. I was wondering if any of them have fully fixed the error yet? I have been busy the past couple weeks, but just got some more free time and was hoping to play around with editing subtitles a bit more.

[jeanl]

DVDSubEdit uses the non-drop timecode, as indicated by mpucoder. I'm wondering if that should be made an option for the user. It would be a bit hard to explain though!!!
jeanl

[Paddington]

DVDSubEdit uses the non-drop timecode, as indicated by mpucoder. I'm wondering if that should be made an option for the user. It would be a bit hard to explain though!!!
jeanl

I don't think you need to ask the user, as it will depend on the IFO (or DVD) he opens. If the loaded IFO specifies you are dealing with a:

PAL DVD, divide the PTS by 3600 to get the frame, and by 25 to get the time (in msec).
NTSC DVD, divide the PTS by 3003 to get the frame, and by 30 to get the time.

[mpucoder]

jeanl meant whether to use non-drop or drop frame timecode. It depends on what the user is doing with the subs later. If staying with DVD non-drop is preffered. But if the user is converting to any of the other formats drop-frame will probably be the better choice, especially formats that specify time in milliseconds.

[jeanl]

coudln't have said it better myself!!! :)
This subject is still confusing to me, I must say... I haven't done my homework, I'm not even sure whether DVD players honor the drop frame thing or play a DVD at exactly 30fps...
jeanl

[mpucoder]

Players play the video at nearly 29.97fps (literally 90000/3003 = 29.97002997...), but timecodes throughout DVDs (example cell elapsed time in NAV, PGC and Cell playback time in PGC) are in non-drop timecode computed at 30fps.
So if you are working with DVD better to use non-drop. But if you want the actual time for another format use drop-frame.

Actually <tech warning> computing the time by dividing by 90000 gives you a real time similar, but not identical, to drop-frame. Drop-frame specifies exactly what frame numbers must be skipped (frames 0 and 1 every minute except minutes evenly divisible by 10, so one hour has 30*60*60 = 108000 frame numbers, but 108 are skipped yielding 107892 frames / 3600 (number of seconds/hour) = 29.97fps)
So, in drop-frame, there cannot be a timecode of, eg, 00:01:00:00, the numbers skip from 00:00:59:29 to 00:01:00:02
At the end of one real hour the values are nearly identical since 3600 * 90000 = 324000000 (ticks per hour) which divided by 3003 gives 107892.1079 frames. Drop-frame even has an adjustment for that tiny error.
Why are 2 frame numbers always dropped, and not just one? - NTSCs color subcarrier changes phase by 270 degrees each field, or 180 degrees each frame. In order to keep the frame numbers and color subcarrier phase relationship consistent 2 frames, called a super-frame, are skipped.</tech warning>

[Paddington]

If certain time codes are not possible, what happens if I would still generate them (e.g. for 00:01:00:00). Would the subtitle not be displayed? Or could the subtitle 'hang', i.e. remain on the screen indefinetely (I have seen that happen before, but don't know the reason)?

So for PAL it's easy (90000), but for NTSC, let's have a little multiple choice test:

1) After reading a time-based srt file, I have to:
A) Multiply by ~90090 to get non-drop PTS value for SUP
B) Multiply by 90000 to get PTS value for SUP

2) After reading a frame-based sub file, I have to:
A) Multiply by ~90090 to get non-drop PTS value for SUP
B) Multiply by 90000 to get PTS value for SUP

3) When manipulating (e.g. time shifting by +1 sec) a PTS-based sup file, I have to:
A) Add 90090
B) Add 90000

4) When converting a PTS-based sup file to a time-based srt file, I have to:
A) Divide by 90090 to get real time
B) Divide by 90000 to get real time

Four good answers will receive my eternal respect!

[kumi]

[..]Or could the subtitle 'hang', i.e. remain on the screen indefinetely (I have seen that happen before, but don't know the reason)?Some of my custom subtitles added to DVDs exhibit this problem. I would LOVE to know why this happens.

</hijack>

[DonMartione]

So does anyone know how I can edit the subtitles without having to re-synch the timings for every line? I got some free time now and was hoping to fix a few dvds with subpar subtitles.

[Paddington]

So does anyone know how I can edit the subtitles without having to re-synch the timings for every line? I got some free time now and was hoping to fix a few dvds with subpar subtitles.
There are two ways to synchronize your subtitles:

In case the DVD has original subtitles (that you can read), use SC's synchronize option to compare your text subtitles to the original ones (extract the original ones using PgcDemux or by using the DVD authoring wizard); you can now select matching pairs left and right near the beginning and end of the movie, and press synchronnize to do the rest.
If it's only a frame rate conversion, or you need to shift them, in the synchronize menu are options for that too.
Finally, you can use the original DVD to synchronize it: insert a subtitle when you want it to appear near the beginning and end of your movie, and synchronize them.

[DonMartione]

Thanks, I'll give that a try and see if I can't get it working. I'm only editing the subtitles slightly, but when I rip them into an editable form like .srt, the timings end up slightly off compared to the original dvd.

Thanks! That worked. They aren't exact, but much closer than before, enough so that there shouldn't be any problems. Now I can get to fixing up these subtitles.