Muxman, HC Encoder, pulldown, duration, madness

[Schwartzvald]

Original files are a 23.976 fps FFV1 AVI and accompanying wav. Referenced the video in an Avisynth script with Avisource. Opened the script in HC Encoder, and encoded progressive with pulldown flags, as recommended.

m2v seems fine. Ran it through DGIndex, and it looks like it should look when it is muxed onto DVD. Duration: 1:27:55:00

Ran the audio in an Avisynth script as well, through Behappy, into AC3. Played it back, same duration as video: 1:27:55:00.

Opened the m2v and ac3 in Muxman. It reads both files as having a duration of 1:27:49:24.

So... it's subtracting 1/1000 off the duration. I assume it's a timecode or framerate conversion.

Muxing results in a DVD with the shorter runtime, and less frames-per-second. Screwing with duration in Muxman results in a DVD that... doesn't play back.

I'm really not sure what the heck is going on here. I've flipped a lot of settings, read quite a few forum posts, and have made zero progress. Every program I have, except Muxman, reads the correct duration on the files.

I've lost my mind over this, it's just... gone. Anger has replaced sanity. I really don't know what to do. I thought I was doing this by the book, but I seem to have screwed up somewhere.

Help is appreciated.

[mpucoder]

You're seeing the difference between drop-frame timecode and non-drop-frame timecode. DVDs use non-drop, which at 29.976 results in an apparent loss of 1/1001 in time. It isn't really lost, and the first DVD you made (with the shorter duration) is correct.
Drop-frame timecode adjusts the time every 2002 frames to account for the difference between 29.976 and 30 fps by jumping ahead 2 frames. This causes the timecode to catch up with real time. But DVDs use the simpler non-drop which does not make that adjustment.

[Schwartzvald]

Okay, between this post, wikipedia and some dvd documents, I think I understand, now. Please correct me if I am wrong:

23.976 and 29.97 are framerates. If I divide total frames/framerate, I will get duration in seconds, every time.

Timecode is a reference for editing and synchronization. It is under no obligation to match the time on a clock. It says, "this frame I'm displaying is at this timecode". Nothing more.

Drop-frame timecode was invented to make timecode match the time on a clock, by throwing away numbers as it counts. In drop-frame timecode, 1;27;55;00 = 1 hour, 27 minutes, and 55 seconds of duration.

My software DVD player is displaying NDF timecode, not actual duration. When I hit 1:27:49:24 in NDF timecode when playing the DVD, 1 hour, 27 minutes and 55 seconds of real time have elapsed.

I have new questions, in hopes of further understanding this:


I understand why Muxman is doing it, but why is my software DVD player showing me timecode? Wouldn't it make more sense to do a little math and display duration?

Would footage actually encoded at 30 frames per second (not 29.97) have NDF timecode that matches duration?

Also, a somewhat related question: I'm multiplying my 24p chapter frame numbers by 1.25 for Muxman (as mentioned elsewhere). This seems to line up my numbers with the detected NDF timecode in Muxman. Is this the correct course of action?

Thanks.

[MrVideo]

But DVDs use the simpler non-drop which does not make that adjustment.

Not true. You can use either. I've authored all of my DVDs using DFTC. Added chapters using DFTC.

[MrVideo]

23.976 and 29.97 are framerates. If I divide total frames/framerate, I will get duration in seconds, every time.

Ya, that is true.

Timecode is a reference for editing and synchronization. It is under no obligation to match the time on a clock. It says, "this frame I'm displaying is at this timecode". Nothing more.

True and not true....

Drop-frame timecode was invented to make timecode match the time on a clock, by throwing away numbers as it counts. In drop-frame timecode, 1;27;55;00 = 1 hour, 27 minutes, and 55 seconds of duration.

Correct. The DFTC was needed so that edited video could actually be aired, as it has to match the clock on the wall. If NDFTC was used for a 2 hr show, it would actually run long, not fitting within the 2 hrs.

I understand why Muxman is doing it, but why is my software DVD player showing me timecode? Wouldn't it make more sense to do a little math and display duration?

Damn good question, to which I do not have an answer. It might because the MPEG-2 video was encoded using NDFTC?

Would footage actually encoded at 30 frames per second (not 29.97) have NDF timecode that matches duration?

30 fps video cannot have DFTC, so it must be NDFTC. No one does true 30 fps video, at least not in 480i.

Also, a somewhat related question: I'm multiplying my 24p chapter frame numbers by 1.25 for Muxman (as mentioned elsewhere). This seems to line up my numbers with the detected NDF timecode in Muxman. Is this the correct course of action?

Correct, 23.976 x 1.25 = 29.97, which is what the DVD output MUST be. This also explains the NDFTC, since 23.976 doesn't have DFTC.

[Schwartzvald]

Well, thanks to you both, I am pretty sure I have seen the light of understanding.

I took my Criterion Hidden Fortress DVD, and made a "Force Film" d2v from the main movie VOBs to check the actual real-time duration (frames/23.976). Answer, 2:18:51.

I took the same DVD, and played back the main movie PGC on a hardware LG Blu-ray player. Brought up the info. Sure enough, next to the little clock, 2:18:43. So even the hardware player reports duration in NDF timecode.

I now believe that reporting NDF timecode is the standard used when playing back a DVD, whether it is in hardware or software. Like mpucoder said, it's "simpler". And with most movies clocking in at under 2 hours, NDF timecode is only skewed a few seconds from actual duration.

I am beginning to understand what Muxman is doing, and why. It seems the most compliant method of authoring.

My old questions have been answered. Sanity returns, somewhat. I hope to continue to learn more about timecode and it's relation to DVDs and Blu-ray, and how players generate the timecode the user sees during playback. It's confusing to me, but also a bit fascinating.

At least I know my DVDs are now authoring properly. Time for snazzy menus.

[mpucoder]

Most authoring programs can understand DFTC, including MuxMan using Scenarist scripts. It was dropped from the native script and GUI due to its imprecise nature. There is a standard for which frame numbers get dropped, and if all encoders followed the standard frame accurate positioning would be no different than with NDFTC. But not all encoders do, leading to seemingly random positioning errors of 2 frames. (positioning is what we call finding the first frame of a clip)

But the DVD itself will use NDFTC. This appears in the program chains and NAV packets. Any timing information in the video stream, although useful to the authoring program, is ignored by the player. Most often the timecodes in the video are not related to the point in time of the program (for example using +1 hour time is common, a throwback to tape systems which required back-timing and pre-roll. Since there is no negative time 1 hour is added to the timecode so cueing can take place. For example using a transport that needs 30 frames to get up to speed would cue the beginning to 0:59:59.00) Or the time in the video could be wallclock time of the shoot. And then there is multi-story in which segments can be added or removed making the timestamps in the streams useless.

So, because all the time information, including time maps for seeking, are in NDFTC for NTSC most (if not all) players use and display these times.

[Schwartzvald]

Thanks, that explains a whole lot, and not just about DVD timecode. I've been editing for years in Avid, untrained by my technically inept instructors, and I never quite understood why it insisted on starting TC with +1 hour or +30 frames. Now I do.

I think I should ask questions here at more often, rather than scouring the internet for scraps.

[MrVideo]

While there isn't negative time, if you use 0:00:00:00 as the starting point of a program, the time before the start, if you set it :30:00 before, would be 23:59:30:00. That 23 hours probably got to a few people so to get to that leading zero hour, 0:59:30:00 was used.

The 23 hour thing didn't bother me, so I would edit my Umatic tapes with bars/tone that started in the 23 hr so that the program start was at all zeros.