NTSC DVD subtitle timings problem

[manusse]

Hi,

Let me create a new thread about a problem I've encountered those days. My current problem is to solve the NTSC timing bug (http://forum.doom9.org/showthread.php?p=989158#post989158)that SubtitleCreator seems to exhibit with VobSub NTSC files.

So in order to better understand how DVD NTSC subtitle timings are working, I've made some tests. First I've chosen a NTSC DVD I own. Then I've decided to measure the starting time of its last subpic with different softwares. Here are the results of my measurements:

Directly from the VOB files:

SubRip gives 02:08:15,582
VSRip gives 02:08:15:366 (when extracting sub/idx)
DVDSubEdit gives 02:08:07,733

From the SUP file extracted using pgcdemux:

SubtitleCreator gives 02:08:15,421
SupViewer gives 02:08:15.42
DVDSubEdit gives 02:08:07,733

When playing the DVD and trying to approximately measure when the subpic appears, I could measure:


PowerDVD 4 gives 02:08:08
WinDVD 4 gives 02:08:07
KMP gives 02:08:07

The PTS inside the sup file extracted by pgcdemux is 0x29480D77= 692587895

Do any of the experts here (I'm thinking about mpucoder and bigotti especially but maybe some others know) have an explanation and also could you tell me what the correct value is so that I can fix the bug in SubtitleCreator the correct way.

Thanks in advance
Manusse

:thanks:

[kumi]

Just a note, you can also use Muxman to measure timing: the standard edition imports subpictures from .SUP files, and the Professional version can also import from .VOB files. I assume whatever that program does is what mpucoder would advise ;)

[manusse]

How do you do that with the standard (free) version?

[kumi]

Sorry, I was mistaken. There appears to be no way to see timestamps when importing .SUP files in Muxman.

[jeanl]

For what it's worth, DVDSubEdit looks at the PTS of the subpic, (which is defined in its first pack), and computes the start time as PTS/90000 for PAL, and PTS/90090 for NTSC (non-drop timecode).
Here, you find 7687.7333 seconds.
I'm guessing the other results are obtained by using 90000 instead of 90090.

Check these posts for details:
http://forum.doom9.org/showthread.php?p=823346#post823346
Jeanl

[FitzGerald]

Off the top of my head I don't know how you could measure the start-time... but I would suggest is there a way you could calibrate with PAL timing and SubtitleCreator... since PAL DVD are already "correct" in SubtitleCreator use the timing closest to PAL?

Or maybe you want something else... that is just my suggestion.

(After more thinking)
I want to say with my experience of the bug that STC was slowing down the subtitles from the sub file, but software players were keyed into the .idx file... so I want to say that DVDSubEdit is the "correct" time. I guess I'm more inclined to believe the faster time....

Does the VSRip .idx/.sub file timings match?

If this is true that would mean this "bug" is seen in different software? If you need help debugging with a NTSC display I'm still using the same stand-alone-player that I had problems with.

[jeanl]

Manusse, there's no "correct" way to compute the time-code. It all depends on whether you want to express it as drop-frame time-code (which corresponds to real-time, i.e., is in sync with a wall clock) or non drop-frame time-code (which falls progressively behind real-time, because it assumes the video is played at 30fps instead of the true 29.97fps).

There are two ways to time-stamp video in NTSC, drop and non-drop, and both are used in practice (although apparently non-drop is usually preferred).
- drop-frame time-code has the advantage of being accurate (with real-time) but the disadvantage that the frame count is discontinuous (every minute, the time-code jumps ahead by 2 frames). Because of this discontinuity, this way ot time-stamping video is really impractical when editing etc.
- non-drop-frame time-code has the advantage of counting frames in a continuous manner, but unfortunately, the time measured that way progressively falls behind real-time.

Drop-frame time code is accurate because it assumes the video is played back at 29.97fps. Non drop-frame assumes the video is played back at 30fps therefore every second, the frame count goes up by 30, simple.

So, for your app, you have to chose whether you'll use drop-frame or non drop-frame timecode!!!! For novice users it's somewhat confusing to use non drop frame because it does not correspond to what you measure with your watch. For more advanced users, it's the preferred way because a given time-code corresponds exactly to 1 frame.

To confuse matters further, apparently the elapsed time code stored in the VOB file for each I-frame is non drop-frame! It's expressed as hh:mm:ss:ff but computed as if the video was played at 30fps, so when ff goes up by 30, ss is incremented by 1, which keeps things simple. The same goes for the cell and PGC times stored in the IFOs.
Now if your player displays that time-code as is, you will notice that a stopwatch will fall progressively behind the displayed time!! Again, that's because the VOB time-code assumes 30fps (non drop) but the true rate is 29.97fps.

It seems impossible to satisfy all users without obfuscating things to the extreme! If you use drop-frame time-code, your timing will be accurate with time measured with a stop-watch, but may not correspond to the time displayed by the player!. If you use non drop-frame, then chances are the time will correspond to what the player displays, but won't correspond to what you would measure with a stopwatch.
Given that nobody's going to time a subtitle with a stopwatch, but instead rely on the player's display, I would guess that using non drop-frame is the way to go (that's what DVDSubEdit does)...

Is this confusing enough? :D :D

Jeanl

[laserfan]

It seems impossible to satisfy all users without obfuscating things to the extreme!...Is this confusing enough? :D :DIf not, I can help! ;)

I found this week that my PAL DVD-originating VOB, after having DGPulldown applied to it (25fps-->29.97), muxed with .srt-->SubtitleCreater(PAL)-->.sup, and then edited with DVDSubEdit for timing, results in herky-jerky playback. I can edit anything else with DVDSubEdit, just not timings.

I've not reported this jeanl simply because my workaround has been to go back and edit the original .srt, then re-output and re-mux again. Not to mention that my PAL-based 720x576/29.97 vob is completely non-standard. Plays back from my Pinnacle ShowCenters just fine. Maybe for grins I'll burn a DVD with it someday and see if any of my players play it, but I'm expecting this to be a waste of $0.30! ;)

[jeanl]

So, it's the dvdsubedit re-timing that makes the movie jerky? This function hasn't been banged on enough... :(
Jeanl

[laserfan]

So, it's the dvdsubedit re-timing that makes the movie jerky? This function hasn't been banged on enough... :(Yeah, only the re-timing. But really I didn't mean to do any hijacking here--the last few posts just struck me as funny cuz I understand so very little of it.

Just amazed I guess given that I'd just this morning after several days' work including mucho trials-and-errors finished taking a 25fps PAL DVD all the way from Sweden via Hong Kong made from a 24fps motion picture then ripped & converted to 29.97fps and re-muxed with 25fps audio then added a .sup file made from my homemade .srt that's made-up of a simple list of timings & sentences and somehow the whole damn thing plays on my NTSC-what-640x480x29.97-SD-no-wait-my-720p-1366x768-HD display too but I sure dunno how-or-why it can possibly work omigod!?! :)