Anyone know of a *VOB-level* demux app that shows audio time delay?

[newbee51]

I've got a serious problem remuxing a modified ac3 audio file back in with the original video and subpictures AT THE VOB LEVEL. The remux application I want to use is MuxMan 0.18.8 (the GUI version).

The thing is, MuxMan only works at the *VOB* level, but all of the demux apps I've found work at other levels such as the *IFO* level (such as ReJig, which would be ideal if I could figure out how the "file level" demuxing works, but it's much too complicated for me to figure out, so I'm forced to use the IFO mode).

The end result is that the files I demux at the IFO level cannot be synchronized during MuxMan's remux, because MuxMan only deals with VOBs.

Now, I've found one such VOB-level demux app, Vobrator. But it produces a bewildering array of output files when I select VTS_01_1.VOB to be demuxed. Here is the list:

thing.vob(vob005-bd-80).ac3
thing.vob(vob005-e0).m2v
thing.vob(vob005-bd-20).spes
thing.vob(vob005-bd-21).spes
thing.vob(vob001-e0).m2v
thing.vob(vob002-bd-80).ac3
thing.vob(vob002-e0).m2v
thing.vob(vob003-bd-80).ac3
thing.vob(vob003-e0).m2v
thing.vob(vob004-e0).m2v


Now, in my case it seems like I probably want the largest of these files:

thing.vob(vob005-bd-80).ac3
thing.vob(vob005-e0).m2v

But there are three main problems with Vobrator's output:

(1) It splits the VOB into all the individual VOB IDs, which only increases my synchronization problems with MuxMan,

(2) Vobrator gives no indication of the audio delay correction! I desperately need that information,

(3) MuxMan can't mux all those sub-VOBs together with the original VTS_01_1.VOB.


So let me end this with a specific question: Does anyone know of an ideally easy-to-use VTS_01_1.VOB-level demux app that, like ReJig, produces only a single ac3 demuxed output file AND shows the audio correction delay?

TIA!

[manono]

The end result is that the files I demux at the IFO level cannot be synchronized during MuxMan's remux, because MuxMan only deals with VOBs.

I guess I don't understand this because Muxman works with elementary streams (audio, video, subs, cells) and produces vobs. It doesn't deal with vobs at all, in the sense that it doesn't take vob input. It does, however, allow you to set a delay (up to +-300 ms). And you can do away with the delay entirely using DelayCut. Therefore, using Muxman, perhaps together with DelayCut, the audio can be synchronized during the remux. If you know the amount of the delay. And even if you don't know the amount of the delay, you can figure it out easily enough.

So, how did you demux in the first place? And what was your source? If the source was a DVD, then when demuxing, if you used the right app, you should have been able to discover the amount of the delay. Unless, maybe, you're working with one of the newer DVDs with newer protection, and you didn't decrypt properly to begin with.

Does anyone know of an ideally easy-to-use VTS_01_1.VOB-level demux app that, like ReJig, produces only a single ac3 demuxed output file AND shows the audio correction delay?

Open your vob(s) in DGIndex and go File->Save Project. The AC3 is demuxed by default and will show you the delay in the name of the file.

[Soopafresh]

2nd vote for DGindex

[newbee51]

(quoting me) The end result is that the files I demux at the IFO level cannot be synchronized during MuxMan's remux, because MuxMan only deals with VOBs. (end quote)

I guess I don't understand this because Muxman works with elementary streams (audio, video, subs, cells) and produces vobs. It doesn't deal with vobs at all, in the sense that it doesn't take vob input.

That's what I thought, too, but the author of MuxMan has corrected me on this point. You see, I was having problems with underflow errors when using MuxMan to remux previously demuxed separate video, audio, and subpicture streams. When I reported these problems to MPUcoder on his site's forum, he told me that the solution to my problem was to use MuxMan's internal VOB input and demuxing capability by demuxing/extracting just the audio (the only stream I need to modify), then re-muxing it back with MuxMan using the original VOB set instead of trying to remux all three individual streams into a new VOB set. And except for the problem I discuss in my OP, that worked just as I'd hoped. So MuxMan will accomodate me ideally as long as I first demux at the VOB level instead of the IFO level.

It does, however, allow you to set a delay (up to +-300 ms). And you can do away with the delay entirely using DelayCut. Therefore, using Muxman, perhaps together with DelayCut, the audio can be synchronized during the remux. If you know the amount of the delay. And even if you don't know the amount of the delay, you can figure it out easily enough.

What I had been doing is using ReJig to demux the audio stream, which very neatly and easily determines and corrects the time delay, and even embeds the delay factor in the output stream's filename. But as I indicated, ReJig demuxes at the IFO level, which turns out to be minutes (not milliseconds) out of synch with the main VOB set, and for the only now obvious reason that the IFO includes VTS_01_0.VOB while MuxMan starts with VTS_01_1.VOB (and it's not really feasible, or at least easy, to do otherwise). So, with luck, DGIndex will fill the role I need.

So, how did you demux in the first place? And what was your source?

The source was a commercial movie DVD which I transferred to disk using AnyDVD and ISOBuster. And I used ReJig to demux it, which seemed to work ideally until I discovered this IFO vs. VOB discrepancy.

If the source was a DVD, then when demuxing, if you used the right app, you should have been able to discover the amount of the delay. Unless, maybe, you're working with one of the newer DVDs with newer protection, and you didn't decrypt properly to begin with.

Well, ReJig perfectly determined and corrected the audio delay, but from an IFO rather than the main VOB set. And AnyDVD is truly astonishing -- it handles any and all encryption techniques with aplomb.

Open your vob(s) in DGIndex and go File->Save Project. The AC3 is demuxed by default and will show you the delay in the name of the file.

Outstanding! You've been an enormous help. I'll give DGIndex a try and report back. Thanks!

[manono]

When I reported these problems to MPUcoder on his site's forum, he told me that the solution to my problem was to use MuxMan's internal VOB input and demuxing capability by demuxing/extracting just the audio (the only stream I need to modify), then re-muxing it back with MuxMan using the original VOB set instead of trying to remux all three individual streams into a new VOB set.

That's interesting. I've never encountered the problem myself, although I've read about it. Say someone has demuxed and just wants to edit some subtitles before remuxing with the untouched AC3 and M2V. I have read of instances of underflow errors preventing the remux.

So, can you describe this "internal VOB input", or point to a link where it's described? And what I'd also like to know, although you may not know the answer, is how Muxman's demuxing is different or better than the job done by apps like PGCDemux or ReJig.

By the way; you might try demuxing with PGCDemux, and see if you get those same underflow errors when remuxing. Hit the "Check A/V Delay" button to find the delay. It'll also allow you to demux only the audio, if you wish.

[Soopafresh]

Very useful information and goes a long way towards explaining some of the sync errors that people experience when transcoding DVDs.

[newbee51]

(quoting me) When I reported these problems to MPUcoder on his site's forum, he told me that the solution to my problem was to use MuxMan's internal VOB input and demuxing capability by demuxing/extracting just the audio (the only stream I need to modify), then re-muxing it back with MuxMan using the original VOB set instead of trying to remux all three individual streams into a new VOB set. (end quote)

That's interesting. I've never encountered the problem myself, although I've read about it. Say someone has demuxed and just wants to edit some subtitles before remuxing with the untouched AC3 and M2V. I have read of instances of underflow errors preventing the remux.

That's exactly what I experienced, at any rate. MPUCoder mentioned that what can (and apparently does) happen is that the subtitles/subpictures can somehow end up trying to be remuxed all at one time, leading to the underflow errors because of the resulting very high bitrates (or something to that effect). Here are MPUCoder's words verbatim (and in full):

It is possible, with incorrect timing information, for MuxMan to attempt to mux all the subpictures at the same point. This can set off a chain reaction of underflows.

Also, with version 0.18 it is not necessary to demux all your assets, MuxMan can internally demux from vob files. So only those assets which you are changing need to be seperately demuxed.

So, can you describe this "internal VOB input", or point to a link where it's described?

I'm afraid that's all the information I have. I have not been able to find any documentation for MuxMan version 18.x.

And what I'd also like to know, although you may not know the answer, is how Muxman's demuxing is different or better than the job done by apps like PGCDemux or ReJig.

You are correct in your supposition that I cannot provide any more information than has already been brought out. All I know from direct user-level experience is that ReJig appears to works only at the IFO level and that PGCDemux produces an extracted ac3 audio file with very different delay information than other tools, which therefore I don't trust. I don't recall right now if PGCDemux otherwise allows VOB-level demuxing.

In closing for now, I'd just like to add that it appears based on preliminary evidence that DGindex does what I need. Unfortunately, I can't tell for certain: I'm in the middle of a long series of problems with my new SuperMicro motherboard (I'm on my third one!), and one of the major problems I'm having is that they don't recognize my AuzenTech sound card. Thus, I'm unable to determine with any finality whether DGIndex will suit my needs at this time.

[newbee51]

Very useful information and goes a long way towards explaining some of the sync errors that people experience when transcoding DVDs.

Using MuxMan, I presume?

[Soopafresh]

I have used Muxman many times, but I was alluding to the IFO vs VOB method of determining sync offsets.

[newbee51]

I have used Muxman many times, but I was alluding to the IFO vs VOB method of determining sync offsets.

Ah, I see. Yes, it would seem to expain a lot. Certainly at least when the audio and video are out of synch by a considerable margin, measured in seconds or minutes as opposed to milliseconds, if not other situations.