Moving Chapters

[VRYK]

Many thanks for your reply.

< Just generate a celltime.txt file from part 1, but be sure to tick the "include end time" option>
I have checked the following options: "Include End Time”, “Output only chapter” and “Output frame numbers”. The CellTimes.txt dialog says not to tick "Include End Time" for Muxman or IfoEdit. Anyhow, for part I this gives 164427 (for part 2 the result is 276601). I take it that I should not copy the 276601 into the first CellTimes.txt file, but just use 164427 when re-muxing in Muxman.

< Also, note that the minimal duration of a cell is about 1/2 second. ,,,, it can confuse some players,>
I have a video whose first cell is a 12-frame blank. With the MPC player it plays for about 3 seconds, but with VLC for over 20 seconds ! I haven’t burned the video yet, but presume a standalone player will not be confused.

Re DelayCut. I input the audio stream created by PgcDemux - but since there is no reference to the videostream, how can DelayCut fix the AudioDelay which reflects an a/v syn relationship ?

After using DelayCut where can I check on the (new) Audio Delay value?

Incidentally, when re-muxing with Muxman, the progress bar was first green, but then turned to pink – does this indicate a problem ?
The Muxman log doesn’t show the Audio Delay.

Sorry for all the questions, but I’m still very much feeling my way in the DVD labyrinth.

Best wishes,

[VRYK]

Many thanks for your reply.

<The spec says the max audio delay is 300ms (one way or another)>
Does this mean the maximum "tolerable" (relatively imperceptible) delay (i.e. ca 1/3 second).

<So long as segment 2 is muxed properly, then there should be no issue>
I would be grateful if you could expand on this.

An admin question: I always use the "Quick" reply button; should I rather use the "Reply with Quote" button ?

Best wishes.

[VRYK]

The spec says the max audio delay is 300ms (one way or another). So long as segment 2 is muxed properly, then there should be no issue. Use delaycut as r0lZ says.

Regards

It looks like I just got an answer to my Admin question !! So here goes again:

<The spec says the max audio delay is 300ms (one way or another).>
Does this mean the maximum "tolerable" (relatively imperceptible) delay (i.e. ca 1/3 second) ?

< So long as segment 2 is muxed properly, then there should be no issue.>
I would be grateful if you could expand on this.

Best wishes.

[r0lZ]

It is true that you should normally not include the end time for muxman (as it crashes), but since here you are adding part 2 to part one, the end time of part one is the starting time of part 2. Of course, do not include the end time of part 2. (BTW, the pink highlight in the status bar is normal. It indicates that muxman is doing pass 2 of the mux.)

The minimum cell duration is a DVD-Video standard requirement, so if a cell is made of a single frame, it MUST be played during approx 1/2 second. The exact time depends of the video standard (PAL/NTSC).
The cell can also have a "still time" to force the player to pause at the end of the cell playback. (It's the case of most still menus without audio.) But the still time is not really a part of the playback.

Use the audio delay reported by PgcDemux to fix your audio stream with DelayCut. If you remove 472ms at the beginning of your audio stream, you should specify a delay of 0 in muxman, and that's the "perfect case". You may also have to shorten or lengthen the audio of part 1 so that it matches exactly the duration of the video stream.

A title properly authored should always have an audio delay of 0, but if you use a tool to cut your title at a certain point, you will almost always introduce a delay, because the duration of the video frames and the duration of the audio frames are not equal. The frame duration is 1/30 second (NTSC) or 1/25 second (PAL). I don't remember the duration of the audio frame, and anyway it is different for AC3, MPEG, etc... So, if you cut the cell, say, after 25 PAL frames, the cut is precisely at 1 second. The audio will be cut at the nearest frame, but not exactly at the same point. Hence the necessity of the audio delay.
The limitation at 300ms is due to the hardware buffer of the standalone players. They must be able to hold about 300ms or audio or video, but not more. Anyway, 300ms is theoretically sufficient to compensate the cut problem explained above. I don't know why your title has a greater delay. Seems it has been poorly authored or muxed.