MuxMan and "invalid" drop-frame slots in .sst files

[kumi]

@mpucoder:

How does your MuxMan software deal with invalid subpicture timecodes when importing .SSTs? For example: Importing an .SST into a NTSC/29.97 segment that contains a subtitle at 0:00:00.02 (as opposed to a valid timecode like 0:00:00.03).

Since MuxMan is generally rather "strict" about inputs (thank god), I'm assuming that MuxMan will automatically round up/down to the nearest valid frame. Can you confirm?

(This is the one last sticking point I have before my "adding subtitles" workflow is satisfactory. I've had some problems with invalid timecodes when muxing pre-prepared .SUPs into muxman, so I've now switched to using .SSTs. If muxman indeed does auto-correct, then I won't have to do any time-consuming testing with MaestroSBT's "Snap times to frames" function.)

Thanks so much

[mpucoder]

Neither of those timecodes is valid for an sst file. sst timecodes are in the form hh:mm:ss:ff, ie frames, not 100th's of seconds.

[kumi]

Oh sorry, I wasn't paying attention. But that was just an example, my question still stands about what muxman does with invalid sst timecodes.

[mpucoder]

Muxman does no range check on the values. The number of frames is computed as:
PAL 25*(3600*hh + 60*mm + ss) + ff
NTSC drop (1000*(30*(3600*hh + 60*mm +ss) + ff)) / 1001
NTSC non-drop 30*(3600*hh + 60*mm + ss) + ff

Since there is no range check 00:00:01:00 and 00:00:00:30 (for example) are equivalent for NTSC.

[kumi]

I appreciate the clarification. It's a very confusing subject for me.

As I understand drop-frame, every minute, xx:xx:xx;00 and xx:xx:xx;01 frames are skipped by the decoder, except for multiples of 10 minutes. That means that when I multiplex, .SST start/stop events in bold will be placed on dropped frames, right?
0002 00:00:13:00 00:00:16:04 Re-timed_0002.bmp
0009 00:02:16:00 00:02:19:02 Re-timed_0009.bmp
0107 00:13:32:03 00:13:33:00 Re-timed_0107.bmp
0114 00:13:51:13 00:13:54:00 Re-timed_0114.bmp

Please correct me if I'm wrong, but this sounds bad/illegal :) If the decoder doesn't playback a video frame, common sense dictates that it would skip any subtitle commands aligned to said frame.

So, if I edited such timecodes to align on non-dropped frames, all would be A-OK? Like so:
0002 00:00:12:29 00:00:16:04 Re-timed_0002.bmp
0009 00:02:15:29 00:02:19:02 Re-timed_0009.bmp
0107 00:13:32:03 00:13:32:29 Re-timed_0107.bmp
0114 00:13:51:13 00:13:53:29 Re-timed_0114.bmp

[mpucoder]

First of all, no frames are dropped, only certain timecode values are skipped. The frame counts that are skipped are frame 0 and 1 every minute except those evenly divisible by 10. So every 10 minutes 18 counts are skipped, and in one hour that amounts to 108 skipped values. There are 60*60*30000/1001 (107892.1079) frames in one hour (true framerate of DVD is 30000/1001 = 29.97002997...) and 60*60*30 (108000) values in one hour. 108000-108 = 107892

But drop-frame timecode is not the best to use for editing since it cannot be used for relative times, ie the time elapsed between two timecodes, or two arbitrary points in the timeline. Drop-frame timecode is an absolute timecode, developed for realtime use (ie broadcast). Non-drop, on the other hand, precisely describes a frame number or the difference between two timecodes, and is the preffered timecode for editing and authoring.

Muxman supports drop-frame timecode in the sst file only because Scenarist allows it, but nowhere else. All the timecodes contained in DVD structures are non-drop timecodes. The conversion from drop-frame to a frame number does not take into account the values that should be skipped, but instead applies a 1000/1001 ratio to the value. This is accurate in the long run, but can differ by as much as two frames over short periods of time. For example the drop-frame timecode of 00:00:33:11 represents frame 1001, there are no skipped values yet. But plugging in the numbers to the above equation gives you frame 1000.

So, if you use drop-frame timecode the subpictures will still appear, regardless of whether the timecode is a proper drop-frame timecode or not. But the timing may be as much as two frames early.

[kumi]

So, if you use drop-frame timecode the subpictures will still appear
Thanks for your informative post. I was totally off the mark... shouldn't be relying on blind assumptions.

if you use drop-frame timecode [...] the timing may be as much as two frames early.
When I time an .SSA (millisecond-based subtitle format) to the audio demuxed from an NTSC video, I have to convert the framerate of the .SST I later generate, either with 29.97-to-30 or 29.97-to-dropframe. Judging by your post, using the 29.97-to-30 conversion would not result in the potential 2-frame timing error. Would you say that's right?

I know your previous response probably contain enough information for me to answer my own question, but I really am having a hard time visualizing this. I apologize for my daftness.

[mpucoder]

Yes, convert time to non-drop if you can. Here's what I would recommend:
1) convert the time to milliseconds, ms = 3600000*hh + 60000*mm + 1000*ss + ff (ff is milliseconds)
2) convert this to the DVD frame number, fn = (ms*30)/1001
3) convert the frame number to non-drop timecode, ff = fn mod 30, ss = (int(fn/30)) mod 60, etc

I have an item on the todo list about timecodes and frame numbers (a unified syntax for mxp, scp, sst, and celltimes). Adding millisecond based timecode will also be added to that item.

[kumi]

Great, mystery solved :)

Thanks mpucoder.

[kumi]

Hmm, it's strange, even though my MaestroSBT-created .SST Tape_Type is NON_DROP:
st_format 2
Display_Start non_forced
TV_Type NTSC
Tape_Type NON_DROP
Pixel_Area (0 477)
Directory G:\HANGING GARDEN CUSTOM SUBTITLE PROJECT\OUTPUT SST - 4.3 CORRECTION\
Subtitle Re-timed
Display_Area (0 2 719 479)
Contrast (15 15 15 0)

...the subtitle items in my .MXP project are "drop":
{
File=G:\HANGING GARDEN CUSTOM SUBTITLE PROJECT\OUTPUT SST - 4.3 CORRECTION\\Re-timed_0001.bmp
Start=00:00:07:23 (233)
Forced Start=No
Time Code=NTSC drop
Duration=00:00:04:14
Origin=0,0
Display Area=0,2,719,479
Color 1(Pa)=ff0000 & & &
Color 2(E1)=0000ff & & &
Color 3(E2)=ffffff & & &
Color=1 1 1 2
Contr=0 15 15 15
}

[mpucoder]

I'll check into that. If the times did not get altered during the import then it is OK since mxp files always interpret times as non-drop, regardless of the time code declaration (it only distinguishes between PAL and NTSC)

[kumi]

Thanks for looking into it! I can upload my .SST and .SSA files somewhere, if you need them for testing.