What is "Layer Br." in IFOEdit? (& sync problem)

[absinthe]

I have a disc of 4 TV episodes, all in a single VTS, with no menu. I want to reauthor without re-encoding, using DVDAuthor GUI, and add a menu.

None of which I have any problem doing ... except that somewhere in the demultiplexing process the audio (AC3) in the latter 3 episodes loses sync slightly with the video.

Now, if I "reauthor" the disc with DVD Shrink, reauthoring each episode into its own titleset, things stay in sync and everything works great. But DVDAuthor still doesn't want those VOB files, so I need to demultiplex. The odd thing here is that after demultiplexing these 4 titles (now each in a separate VTS via DVD Shrink and in sync just fine), the last 3 episodes still come slightly out of sync.

* I should stress that in all the above cases, no audio delay is indicated by whatever demultiplexing tool I use, be it DVD Decrypter or DGIndex.

Some other info:
-DVDAuthor makes me use ReStream to remove sequence end codes on my demultiplexed m2v files. Could something in this step be causing the audio to lose sync?

-Looking at the original disc's main title IFO in IFOEdit, in the PGC table there are "Layer Br" (layer breaks??) and a couple of other cells that are not a separate chapter. I've always wondered what these are, and could they be the culprits.

Sorry to be so long-winded, but there's something about audio syncing that I can just never wrap my head around. DVD Shrink is obviously able to figure it out and create newly reauthored VOB sets that are perfectly in sync and play fine, but then if I demultiplex those same VOBs, even though DGIndex (for instance) indicates no audio delay, the last 3 episodes come out of sync.

(Please also note that I realize there are other ways to reauthor/add a menu, which I am able to do, but I'm just playing with DVDAuthor GUI here and I really want to use that :)).

Ideas?

-abs

[r0lZ]

What IfoEdit (and PgcEdit) call Layer Break is the inverse of the Seamless Flag. It's not always the real layer break.
For a real layer break, the seamless flag must be off. If you shrink a DVD-9 to fit a DVD-5, the seamless flag must be turned ON where the old layer break was located, or the DVD will pause for a couple of seconds.
As it is not possible to know for sure the original location of the layer break, IfoEdit display the Layer Break message for each cell where it could be, ie where the seamless flag is OFF.

Normally, the layer break is not responsible of the audio delay, but maybe there is a bug in DVDAuthor...

[blutach]

To add to that, and if I'm not mistaken, IfoEdit and PgcEdit both identify any STC discontinuity as a "layer break". You will see this at the start of every title, for example. Of course, there is really only 1 true layer break in a DVD-9, using mid movie. In an episodic DVD, it might be between episodes.

Regards

[mpucoder]

Originally posted by absinthe
The odd thing here is that after demultiplexing these 4 titles (now each in a separate VTS via DVD Shrink and in sync just fine), the last 3 episodes still come slightly out of sync.
Are you trying to author them all as one title? If so each episode should be a seperate track/sequence/VobID - whatever the authoring program calls the object that becomes a new VobID - and non-seamlessly.
The problem is caused by slightly different durations for the audio and video in each episode. Only a non-seamless Vob joint can resynce assets like this. Otherwise the audio and video keep running, and whichever was shorter now falls behind.

[absinthe]

I have tried reauthoring both ways (separate VTS for each, and all as one title). I really don't care which, but it still doesn't matter if I demultiplex the original VOB set (one title) or use Shrink to separate them into separate titles, the latter 3 titles still come out of sync (and again, it's worth mentioning, in the latter case all four separate titles are in sync after running through Shrink, but when I demultiplex the last 3 are again out of sync).

Is there a way to do a non-seamless VOB join, like mpucoder mentions? I feel like this would do the trick.

On a side note, something about VOBs I don't understand: After demultiplexing, the m2v which should be about 2 hrs 51 min. in length (as the AC3 track is) reads as only 41 min. I'm assuming this is due to sequence end codes, but even after stripping those out with ReStream it reads the same. DVDAuthor seems stubborn about reauthoring video demuxed from VOB sets.

Also, I've been using DGindex to demultiplex as I find it easy, but is there a better way?

-abs

[absinthe]

No ideas? ProjectX does a good job of this with TS streams, and I'm looking through DVD Decrypter's options but I don't see anything that looks like "non-seamless" demuxing.

-abs

[jeanl]

The odd thing here is that after demultiplexing these 4 titles (now each in a separate VTS via DVD Shrink and in sync just fine), the last 3 episodes still come slightly out of sync.

This seems to indicate that the audio is slightly delayed at the start of each of the last 3 episodes, even though your demuxing tool tells you otherwise! To check (mpucoder correct me if I'm wrong) look at the first video pack in the VOB corresponding to episode 2, using vobedit, and write down the PTS value (presentation time) indicated at offset 0x17. Then find the first audio pack, and write down its PTS value. They should match!
If they don't match, then there is a delay between the audio and the video, and this delay is lost when you demux then remux. This could explain the problem. Now I have no idea why your demuxing tool indicates no delay between the two streams...
EDIT: My mistake! The video PTS should not be taken from the first I-frame, because its temporal sequence might not be 0 (it might not be the first image to display). It should be taken from the VOBU start presentation time

jeanl

[jeanl]

BTW what tool do you use to demux. PgcDemux should tell you the right AV delay...
jeanl

[absinthe]

Well, hello there jean :) Here's what I've done. VobEdit wouldn't give me A/V delay except for the first VOB because the following VOBs don't begin with NAV packs. So, with that in mind, I went ahead and reauthored the episodes with DVD Shrink (for experimental purposes). I then examined each of those VOB titles in VobEdit, and whaddaya know there is audio delay in the latter 3 VOB sets. Ta-Da! VobEdit gives me something like "video delay -1440." I assume that translates into a positive audio delay of 1440 msec (?).

Anyway, it's groovy info to have, but I still can't fix the problem without 'cheating' by using Shrink.

However ... on a lark I decided to try to open the original (unshrunk)VOBs in ProjectX. I had had great success solving a similar problem once upon a time demuxing a transport stream using ProjectX (which is what that app is made for). I didn't think ProjectX would process VOBs. But glory, hallelujah! ProjectX has nooooo problem taking a set of VOBs and demuxing into single m2v and ac3 files. And, the m2v reads as the correct length (just a few min. shy of 3 hours). NO demultiplexing tool I'd tried accomplished that as of yet. I'm betting the sequence end codes have been removed as well.

Anyway, I won't know for sure if this worked until I run it all through DVDAuthor, but I'm confident :D.

And jean, I'll look in PgcDemux as well. That's another tool I haven't tried.

But in the meantime, I think I'm going to get a LOT of use out of ProjectX in the future.

-abs

[jeanl]

It looks like you're on the right track.
Yes, I meant for you to open each individual episodes created by DVD shrink in separate VTS (you can only figure out the delay with the simple method at the start of the VOB or at the start of a non seamless cell I guess).
Great! I don't know project X but I'll check it out!

When you say a delay of 1440, is that what the File:GetAudioVideo delay menu returned? I have no idea what unit that reports. If you got it from subtracting the PTS times, then these are in 1/100th of a millisecond! (the PTS times are relative to a 100kHz clock). So your delay would be 14.40ms, hardly noticeable... I'm puzzled.
If you really want to find out, look at the PTS values in vobedit and post them here...
Jeanl
EDIT SORRY! My mistake, the clock is 90kHz, not 100kHz

[absinthe]

Jeanl,

VobEdit is a little confusing to me :). If if open the first VOB of the second title (VTS_02_1.VOB), and then do Edit>Get Audio/Video Delay, I get "Video-Delay: -1360".

If I click on the first video pack in the left pane (which is the second line), in the right pane I can see, at 0017: [0017] PES HeaderData 49 0 9 {snipped by abs}
header data details:
PTS 00155454
DTS 00144654Is that the line you mean?

If so, then in the first audio pack, there is a corresponding line
[0017] PES HeaderData 33 0 7 243 253 [21 00 07 f3 fd ]
header data details:
PTS 00129534Am I getting that right?

BTW, ProjectX demuxed and synced the files perfectly. Amazing tool! I'm gonna give PgcDemux a shot, too, just to see if that can get it done as well.

-abs

[jeanl]

Originally posted by absinthe
Jeanl,

VobEdit is a little confusing to me :). If if open the first VOB of the second title (VTS_02_1.VOB), and then do Edit>Get Audio/Video Delay, I get "Video-Delay: -1360".

If I click on the first video pack in the left pane (which is the second line), in the right pane I can see, at 0017: Is that the line you mean?

If so, then in the first audio pack, there is a corresponding line
Am I getting that right?

BTW, ProjectX demuxed and synced the files perfectly. Amazing tool! I'm gonna give PgcDemux a shot, too, just to see if that can get it done as well.

-abs
Yes, you got it right. These are the lines...
THe difference is:
00155454 - 00129534 = 25920
And that's 25920/90000 = 0.288s (288ms, very noticeable).
And since the audio's PTS is smaller than the video's, I would guess that in the out-of-sync version, the audio is ahead (early) of the video.

I don't understand how vobedit get is audio/video delay. PGCDemux will tell you the delay too. You should see whether it matches vobedit's or our own calculations.
EDIT: THis is probably wrong see my edit above. The video PTS should be replaced by the vobu start PTS (which you can read in the first nav pack).

Jeanl

[absinthe]

Well, PgcDemux as far as I can tell reports 0 audio delay. Go figure. Also, it doesn't seem to strip out sequence end codes because my demuxed file has a header or something that makes it register as only about 44 min. long (i.e. about the length of the first episode only). I'm remuxing the audio and video tracks with Muxman now, but I have a feeling they won't be in sync.

I tell ya, ProjectX is underrated. I don't even think people realize it works on VOB sets. It was created as a tool for demuxing transport streams. But wow, it will demux everything from a VOB set perfectly.

Only (minor) problem now is that my chapter times are a smidge off in the last 3 episodes.

-abs

[jeanl]

absinthe, PGCDemux demuxes PGC by PGC, it won't do the whole VOB! That's why it's shorter...
Also, if you tried on the complete VOB (instead of the individual episode) the probably won't be any delay, right (the first episode didn't have delay)...
Jeanl

[absinthe]

Originally posted by jeanl
absinthe, PGCDemux demuxes PGC by PGC, it won't do the whole VOB! That's why it's shorter...
Also, if you tried on the complete VOB (instead of the individual episode) the probably won't be any delay, right (the first episode didn't have delay)...
Jeanl No, the whole VOB set IS one PGC. Trust me, I've demuxed this puppy every way from Sunday :)

And I've always been demuxing the whole VOB set. That was the problem. The VOB set has already been reauthored by someone else, who apparently combined all 4 titles into one VOB/title/PGC. Every way I've tried to demux the whole thing has rendered the last 3 episodes out of sync ... until I tried ProjectX.

-abs

[jeanl]

absinthe, how do you know that! Did you look at the IFOs? YOu can't tell from looking at the vob if there's just 1 PGC (unless of course there's only 1 VOB/CELL ID but I doubt that... But I suppose you looked in PgcEdit and it says the whole thing is 1 PGC?
Can yu post the PGC info from PgcEdit?

Anyway, it looks like your problem is fixed so that's great!
Jeanl

[absinthe]

Originally posted by jeanl
absinthe, how do you know that! Did you look at the IFOs? YOu can't tell from looking at the vob if there's just 1 PGC (unless of course there's only 1 VOB/CELL ID but I doubt that... But I suppose you looked in PgcEdit and it says the whole thing is 1 PGC?
Can yu post the PGC info from PgcEdit?

Anyway, it looks like your problem is fixed so that's great!
Jeanl Oh yeah, it's all one PGC. When you load the IFO into PgcDemux, for instance, the drop down box only has 1 choice ... which is the 1 PGC :).
VTST 1 , 1 TTN 1 (2:54:53) Title 1 - Chapters: 24, Programs: 24, Cells: 32

********** pre commands:
[71 00 00 00 00 00 00 00] 1 Set gprm(0) =(mov) 0
********** post commands:
[30 01 00 00 00 00 00 00] 1 Exit
********** cell commands:



Playback time: 02:54:53.20 (at 25 fps)
PG Playback mode: sequential
PUOs: 0 (0x00000000)
NextPGCN: 0
PrevPGCN: 0
GoUpPGCN: 0
PGC Still Time: 0
Audio stream 1 status: 0x00008000 (stream=0)
Subpic stream 1 status: 0x80070700 (streams for 4:3=0, wide=7, letterbox=7, pan&scan=0)

Chap. Prog. Cell Type Layer Res- Still Cell Playback End Entry First Last Last VOB Cell
(PTT) Flags Break tric- Time Cmd. Time Time VOBU ILVU VOBU VOBU ID ID
ted. sector End Start End
-abs

[jeanl]

mm then that's strange that PGCDemux does not demux the entire thing! jeanl

[absinthe]

It does demux it all. But there are sequence end codes within it (and maybe other stuff, too ... I don't really know much about VOBs) which indicate its length as only the length of the first ep. It will play back the whole thing, though. I guess it's a matter of time codes buried in the headers somewhere. Project X seems to fix that too, though.

-abs