muxman ignoring specified audio delay

[hdi20]

Muxman 0.15P refuses to apply audio delay of -224msec, needless to say, output is totally screwed and unwatchable. Has anyone encountered such a problem, and more importantly, how can I fix it?

[Sir Didymus]

Me never...

To fix relevant delays, you may want to try the delaycut application by Jsoto. This is a very nice tool.

However it could be interesting to understand the reasons of the failure.

Since audio delay is a myth, as mpucoder explains into a recent very nice article, your delay has been most probably introduced by some improper demuxing operation...

In case your audio asset is somehow corrupted or damaged, you may also try to use ac3fix (if it is ac3 audio...)...

[hdi20]

Let me explain in more detail. This is a backup of "The Patriot" (extended cut, PAL, R2). Since DVD Decrypter was unable to rip it I used DVDFabDecrypter (full disc mode). Then I used DVD Rebuilder to make it fit on dvd5. Rebuilded movie I demuxed with PgcDemux, added few subtitles and muxed it back with MuxMan, and this is where sync problems first appear.
Original movie is synced perfectly, so are decrypted and rebuilded ones. When checking audio delay with PgcDemux, it reports delay of -224msec in this three cases, and delay of 0msec after muxing. So I guess problem is caused either by MuxMan or PgcDemux.
Are there other programs (preferably freeware) with which I can demux and mux a DVD.

@Sir Didymus
I would much appreciate if you could post a link to mpucoders article.
thnx

[Guest]

I would much appreciate if you could post a link to mpucoders article. It's a members only feature at www.mpucoder.com. It'll cost you a minor $5 to get access to it and a lot of other very useful stuff. Well worth it for developers.

[mpucoder]

MuxMan achieves negative delay by first discarding as many audio frames as it can to reduce the value to less than one audio frame duration. Since 224 is a multiple of 32, the duration of one AC3 audio frame, the result is 7 frames discarded, but 0 delay.
Try multiplexing with the delay value at 0, you probably do not need to apply a delay

[Sir Didymus]

Details you provided are fundamental, I would say...

In addition to what suggested by mpucoder, you should take into account that it is very frequent, in titles like yours, the presence of leading void cells, in the same program chain of the main movie.

These cells are normally skipped through cell command(s). In this scenario it is absolutely sure that the straight usage of PgcDemux (in PGC mode) to extract the component assets will produce bad results, since the presence of "gaps", generated by the non-played leading cells, is not properly handled in the demuxing by PGC...

If you are in this situation, the easiest solution I suggest is to use PgcEdit to completely remove all of the initial "tiny cells" in the PGC of the main movie. Sometimes these cells have a different VOB ID respect to the cells of the movie. You may easily check, with the cell preview what is the "real" first cell of the title...

After removing these cells, while you are in PgcEdit, you may also want to apply:
DVD --> "Rebuild all time maps of DVD"
in order furtherly clean up your backup...

Then, you may use Pgcdemux and MuxMan in your process... ;)

Edit: concerning the applications you are using, no need to search for something better: your troubles are caused by the protection scheme of your title, not by the (excellent) tools of demuxing and authoring...

[hdi20]

I'm sorry I wasn't clear enough, but I'm doing main movie backup not full DVD backup. Would void cells matter in such a case? Plus, desynchronization appears approximately an hour in the movie, and at that particular moment a glitch in video can be observed. I noticed that after watching the whole movie. I point out once more, there is no glitch in rebuilded movie, it appears after demux/mux operation. Logic dictates that the fault is either in demuxing or muxing process (but then again, logic and computers don't always go hand in hand :-)

One more question: After decrypting, reauthoring (dvd shrink) and rebuilding could protection still have any effect?

[Sir Didymus]

I'm sorry I wasn't clear enough, but I'm doing main movie backup not full DVD backup. Would void cells matter in such a case?

Yes, it would, since these cells, normally, belongs to the same PGC of the main movie. Of course, this is not your case, as it turns out from information your add, one post after the other, in small pieces, while the discussion is progressing... :mad:

What it seems to me you are missing is that the demux operation extracts the assets from its container - the VOB files - LOSING the sinchronisation and time relationship (time stamps, clock references, ...), BOTH among the different assets AND inside the assets themselves.

So, it's not a fault of the tools, it depends on how the tools are used in the specific situation you are.

For example, if you are into a situation like this:

http://img228.imageshack.us/img228/6494/image1hr0.th.gif (http://img228.imageshack.us/my.php?image=image1hr0.gif)

There is a discontinuity (the layer break) in the movie between VOB IDs 2 and 3.

It's just an example, but in this case, if you demux the main movie by PGC, it is quite possible that troubles like the one you are reporting will happen, since the assets of the different VOB IDs will be (improperly, in this case) joined together by the demux operation.

Try to demux by VOB ID, if you are in such situation. You may then try to apply delaycut to the audio asset(s) of the second VOB, adding silence frames or cutting audio frames in order to resynchronise the playback.

MuxMan accepts file lists as audio and video assets, so it should be possible to "recompose" the main movie...