I've been having the same problem.

But there's something else going on. Even though I have the timeline set for Non-drop 27.97 fps, he numbers that end up in the .sub file don't agree with what's in the timeline unless I set the timeline for plain SMPTE 30. The non-drop setting doesn't match the output.

In the example I'm looking at, the timeline values (in SMPTE 30 format) show a region ending at 21:41:10. In the .sub file is shows as 21:41:33 (which is correct). The next region starts at 21:42:00, but the .sub file shows it as 21:41:00.

Huh?

I'm using the Unicode version of the subtitle script I posted in another message in the forum.

Any idea what the final goal for format of the timecodes in the .sub file is ? The .txt file output seems to use the timecode without any conversion, but the .sub is doing some strange calculation. What exactly is the TimeToString function trying to do ?


I found out that skipping around the DVD can cause the subtitles to not be displayed for some time or until the next chapter is reached. I frequently saw the beginning of a chapter not have any subtitle when I used the "next/prev" buttons to jump to it. I tend to use the subtitle for a date reference on home movies. So while watching the DVD, you can have access to the date when the video was taken, but you don't have to have it on the screen all the time if you don't want to.

My original intent was to modify the script to take long spans of the same subtitle and break it into shorter ones which repeat the same subtitle text. I got this working fine (set the span to 5 sec), but these overlapping (and unknown conversions are bugging me). I had planned to make the .txt files work the same way, so I guess I can do those and use .txt files instead of .sub files (skipping the whole TimeToString function). It bugs me when something doesn't work right, though.

If anyone wants me to post the modified script when I'm done, let me know.

Anyone know where to find format specifications for the ".sub" files (or at least the ones used by Vegas/DVDA since there seem to be several different flavors) ?

-Jeff

After adding some debug statements in the script, I figured out what's going on here.

The time.ToString(RulerFormat.Time) call (in TimeToString function) causes the timecode being manipulated to be in a format like hh::mm::ss.ddd (as shown in the comments) where ddd is fraction of a second. When I did my original editing, I used SMPTE drop, and then changed to non-drop for exporting subtitles (as advised). If you zoom in closely on regions that stop/start on the same frame, you may notice that they don't truly stop and start at the exact same spot. When the time format is set to "Time" or "Seconds" you can see the actual difference. In the case I originally posted in SMPTE non-drop at 00:18:51:23, with "Time" chosen, this now shows up as the first subtitle ending at 00:18:52:932 and the second subtitle beginning at 00:18:52:898.

So I understand now that the overlap is real, and I just didn't notice it until the subtitle script started looking at a tighter precision than a single frame. I'm a little baffled about exactly what is the best time format to edit in, though.

A couple of things that bug me about this is that:
1. I'm pretty sure I used standard drag-n-drop techniques and the numpad 7/9 keys to jump from event to event to insert markers and regions. It seems that when zoomed out, Vegas should be a little smarter about how the regions line up with frame borders (but I'm still somewhat new to this, so maybe I'm doing it wrong ?).
2. (This seems like a bug) - Using the overlap regions mentioned above, when in SMPTE drop or non-drop mode, if I zoom in and use the left/right arrow keys to jump from frame to frame, in effect going from one region marker to the other, the "current time" (shown below the timeline) changes frame numbers (as expected). But when I CTRL-Left/Right to jump from one marker/region to the next, the "current time" does not change. When in "Time" time format (where fractions of seconds are shown), both going from frame to frame (left/right) and marker/region to marker/region (CTRL-Left/Right) cause the "current time" to change. This seems inconsistent.

This is hard to explain. Hopefully, I've been clear. But the bottom line for me seems to be I should be editing in "Time" format, and zoom in tight when adding markers/regions.

-Jeff

Hi,
I don't know if this helps, but here we go:

Most subtitle software (that I'm familiar with) resolves titles to frames, since professional subtitlers (that's my job ... when I'm not playing film director) work to cuts. So, for example, when you subtitle a hollywood film for, let's say Germans, you usually get a video cassette and sit there spotting the subtitles according to where the dialogue is and where the cuts are. And of course, you shuttle betwen frames to find the right in and out points.

By experimenting, I've discovered that all millisecond values (in PAL 25fps) between 0-39 are resolved to the first frame. Numbers 40-79 are resolved to frame 2 and so on. That makes sense, since the second is divided into 25 parts. In NTSC, I guess the figures are a bit lower, but the same principle must apply.

Working in frames also makes sense since if you want frame-perfect subtitles, you are usually working with timecode in the picture (HH:MM:SS:FF) and skipping from frame to frame, not in millisecond jumps.

For more info, please see "subtitle tips"

alexz

I think that if you have Quantize to Frames set, you don't have to worry about accidental overlapping regions -- you can only set the cursor on a frame boundary.

But there's more going on here.

First of all, there is a bug in the TimeToString function in the script. The millisecond portion of the time gets rounded to hundredths of a second, but if the value is near one second (in my case, 998), the result rounds to 100 and the result is printed as "00". This caused an "overlapping subtitle" complaint from DVDA when it caused the beginning of a subtitle to be moved forward by almost a second.

This problem can be crudely fixed (the only way I know to program Jscript at the moment) in TimeToString by putting the statement:

if (iCentiseconds >= 100) iCentiseconds = 99:

after iCentiseconds is set to the rounded millesecond value.

Secondly, I noticed that all the subtitles past a certain point in my project were on frame + .850 boundaries. (I could only see this by setting the time format to Absolute Frames). I know that when I was entering the titles I had "quantize to frames" set. I'm guessing that some final editing I did making use of Auto Ripple somehow moved all the titles past the edit point by a fractional number of frames.

Thirdly, there's an interesting wrinkle with NTSC.

The times put into the subtitle file are based on 30 fps, NOT 29.97. This means that there are generally going to be fractional frame numbers in the .sub file. No harm done, I guess -- DVDA converts the frame numbers correctly back into 29.97 non-drop. It does mean, however, that the rounding bug is likely to show up at some point in any video.

Jeremy