PgcDemux 1.2.0.4 is out

[Sir Didymus]

Hi Jsoto - well, just in case you have some "spare time"... :cool:
want to bring to your attention this thread:

http://forum.doom9.org/showthread.php?t=102383

The situation has been reported for a totally unprocessed title...

It happened to me too, in a couple of plain situations, and it is almost frequent when manually removing some protections in Sony titles.

The problem is that the reported A/V delay is "none" for all of the audio strams, but actually audio is present.

The radix of the trouble seems that in a given single PGC there may be present SCR discontinuities. This seems perfectly compliant, since VID changes and SCR discontinuities may be present in a title for many valid reasons, so the A/V delay in a given PGC may change during the PGC playback. Right ?

So do you think it should be possible to report (in the log file ?) the actual A/V delay every time a SCR discontinuity is detected ?

Cheers,
SD

[jsoto]

The radix of the trouble seems that in a given single PGC there may be present SCR discontinuities. This seems perfectly compliant, since VID changes and SCR discontinuities may be present in a title for many valid reasons, so the A/V delay in a given PGC may change during the PGC playback. Right ?
Right. You have to demux by VOBID in this case.
Well, I can add the option to detect SCR discontinuities (useful for blank cells detection), but I think you can have a non seamless playback without a SCR discontinuity.....
jsoto

[mpucoder]

So do you think it should be possible to report (in the log file ?) the actual A/V delay every time a SCR discontinuity is detected ?

Cheers,
SD
There are two ways to join vobs together, which is where you should be seeing SCR discontinuities, seamlessly or non-seamlessly.
In a non-seamless joint all the audio in the first VOBU belongs to that vob, and can be detected, without consulting the PGC, by checking the initial pts values of all streams. They will match vobu_s_ptm in a non-seamless joint, and the delay is zero. (when will the audio delay myth die?)

In a seamless joint there will be audio with pts values < vobu_s_ptm. These belong to the previous vob, and should not be demuxed with this vob (but should be demuxed with the previous - demuxing must look at the vobu following the end of a vob). This is where the negative delays come in. The only decision here is to which vob do the audio frames that cross vobu_s_ptm belong. Multiplexers such as Scenarist and Muxman use the minimum error method to determine when to switch audio during a seamless joint. This means the absolute value of the misalignment (assuming the audio is meant to be exactly in sync with the video) caused by the inability to pause or gap the audio for resync, is <= half the duration of one audio frame. So an audio frame that spans vobs belongs to the previous vob if (pts + duration/2) < vobu_s_ptm. From there you can either propagate the error by calculating a delay that will cause the next multiplexer to duplicate the misalignment, even in a non-seamless joint, or realize that the delay should be zero.
For seamless joints Muxman ignores the delay values. And if the original was demuxed by the method I explained above, the remux will be an exact replica.

[Sir Didymus]

You have to demux by VOBID in this case...


Yes, but demuxing by VOB ID is not always a solution:
I have some examples where the A/V delay (as reported by PgcDemux) is none for all of the VOB ID in a given title. This happen due to the presence of some blank cells without audio at the beginning of each one of the VOB...


Well, I can add the option to detect SCR discontinuities (useful for blank cells detection), but I think you can have a non seamless playback without a SCR discontinuity...


That's very kind and it will be absolutely appreciated...
Anyway let me focus a little more the reason and the content of the request...
The idea is not just to facilitate the detection (with the purpose of removal) of blank cells, nor to remove the SCR discontinuities [if they are present they should be there for some valid reason]...

It could be instead relevant to know [maybe in the log file ?] that in a given point of the demuxed streams the demuxer detected a cell non seamless joined to the previos. When this condition happen, it is IMHO important to let the user know:
- if in the cell some audio streams exist, and in case it does,
- the relative A/V delay, (it should be the differece between start presentation time of the first VOBU in the cell and the PTS value(s) of the first audio packet for each of the audio streams...)

@mpucoder
Thanks for your clarifications, I really understand it could be somehow boring to repeat some explainations on arguments already widely covered and discussed elsewere...

Your description of the situation related to the seamless joint is understood; what is not still clear to me, is what happen, in case of non seamless joint, in both of the situations when the first VOBU have audio, and when it have no audio.


In a non-seamless joint all the audio in the first VOBU belongs to that vob, and can be detected, without consulting the PGC, by checking the initial pts values of all streams.
They will match vobu_s_ptm in a non-seamless joint, and the delay is zero.
(when will the audio delay myth die?)


OK! - Let's destroy this stupid myth... :-)

Well, seriously... could you expand this a little bit more - suspect me simply not understanding what you mean... ?

Are you stating that in a seamless joint the pts of the first audio packet should be necessarily equal to vobu_s_ptm, and this condition should happen for all of the audio streams ?

So is it illegal to have no audio in the first VOBU of such a cell ?

And finally, when blanking a non seamless joined cell, by substituting its A/V content with some black I frames, without any audio content in it, are we introducing incoherences with this way of proceed ?

[mpucoder]

Maybe this will help. Vobs joined non-seamlessly are autonomous, that is there is nothing from one vob in the other. Each can stand on its own as a properly multiplexed video object. The audio from the first vob must end at the same time or earlier than the video. The player most likely will pause while it finishes one vob and starts filling the buffers with the next, hence non-seamless.

Seamless joints, due to the much shorter delay in the audio path from disk to decoder than the video, must put some of the audio from the first vob into the beginning of the second. This maintains the multiplex as if there were no joint at all, very similar to how cells are joined, and the player can continue without pause.

The audio delays exist for two reasons. The first has been corrected by Neuron2, and that was caused by dvd2avi not understanding the structure of a closed gop. That program dropped the B frames that display prior to the I frame, and so introduced a 2 frame misalignment, 67ms for NTSC, 80ms for PAL,

But the second reason persists today, and that is caused by the demuxing of seamless vob joints and cells. The demuxers, even PgcDemux, start demuxing with the first audio pack assuming that the first vobu is autonomous and contains nothing that does not belong logically to the vob. But in a seamless joint the first vobu contains the trailing audio of the previous vob. Since a typical AC3 seamless joint will have packs of audio with pts values around 12000 (all times in clock ticks), and the video pts anywhere feom 20000 to 37000, the delays are reported in a range of about -88ms to -280ms. These 88 to 280 ms of audio belong to the previous vob.
The result is that the first vob's audio runs out early, and the second gets a large negative dely (plus running out early if the next joint is seamless. No multiplexer can put this back together, and most, because there is insufficient audio, will refuse to make a seamless joint.

When I was testing MuxMan for seamless joints (version 0.17) I had to use a binary editor to move audio data from one file to the other to correct for this. 0.17 now has an alternative method where you demux the entire audio and specify in and out points (Start and Run Length) of the audio for each vob.

[mpucoder]

what is not still clear to me, is what happen, in case of non seamless joint, in both of the situations when the first VOBU have audio, and when it have no audio.
In a non-seamless joint, with or without audio in the previous vob, the next vob starts fresh, as if there were no vob before it. In fact you can join vobs from different multiplexers non-seamlessly.

Are you stating that in a seamless joint the pts of the first audio packet should be necessarily equal to vobu_s_ptm, and this condition should happen for all of the audio streams ?
Just the opposite, a non-seamless joint will have the audio (and video) begin at vobu_s_ptm.

So is it illegal to have no audio in the first VOBU of such a cell ?
I'm assuming you mean a seamless joint. It should have the trailing audio of the previous vob. It is possible to seamlessly join vobs with audio in one vob but not the other. In the case of audio in the first and no audio in the second only the first vobu after the joint will contain a little audio. In the opposite situation the second vobu will look very much like a non-seamless.

Another thing that must happen in a seamless joint, and is a telltale sign, is that no audio frames span the joint. That is the audio in the previous vob will most likely require padding as it cannot contain a partial audio frame. And the first audio in the new vob will start at an audio frame header (the offset to which will be 1)

I have been talking mainly about the audio as demuxers need to fix the way they work for audio. But in all cases the SCR and video delay are affected by the type of joint. The SCR is reset in both cases, but what it represents is different. In a non-seamless joint all time values are reset, and the decode starts fresh. In a seamless joint the SCR value of 0 is handled as if it were the next SCR value from the previous vob, and a difference is calculated. This difference value then affects ptm and pts values, so that they can be adjusted by the same amount. Here is an example:
The last SCR value of the vob preceding the joint is 5390713 and the vob's e_ptm is 5424651. Now in the next vob we must proceed as if scr 0 represents 5390713+147 (the transfer time of one pack) = 5390860. Since in all seamless joints (vob or cell) the vobu_s_ptm of one vobu is equivalent to the vobu_e_ptm of the previous our new vob's starting ptm must be equivalent to 5424651 but adjusted by the difference value, so 5424651 - 5390860 = 33791. This will be the new vobu_s_ptm, and the pts of the video.

And finally, when blanking a non seamless joined cell, by substituting its A/V content with some black I frames, without any audio content in it, are we introducing incoherences with this way of proceed ? No, as stated vobs joined non-seamlessly are independant of each other.

[Sir Didymus]

I see.


...Just the opposite, a non-seamless joint will have the audio (and video) begin at vobu_s_ptm.

This is the part I was looking for, and it is what I supposed. For a stupid typing mistake I wrote:
"Are you stating that in a seamless joint the pts of the first audio packet should be equal to vobu_s_ptm ..."
instead of "Are you stating that in a non seamless joint the pts of the"

But even with this misunderstanding, your comments are definitely clarifying.

I think I understand what is going on in case of seamless joints.

What I am still interested in is the presence of relevant holes (audio gaps) in a given program chain, created by the practice of blanking some unwanted cells from the PGCs.

When you say:

a non-seamless joint will have the audio (and video) begin at vobu_s_ptm.

this condition is clear, since the new vob is a totally fresh one. But exactely for this reason it may legally happen that the fresh vobu have no audio at all. Right ?

In this situation [presence of an audio gap at the beginning of a new vob or immediately after a SCR discontinuity] I just wanted to understand what a demuxing application should do for decoding the audio stream as a whole from the PGC, while keeping the audio in synch with the video.

Is this possible at all or maybe the only possibility is to decode the audio in chunks ?

Edit: forgot to thank you for the time you are putting into your appreciated and very useful "enlightening posts"...

[mpucoder]

The best thing for a demuxer to do if it encounters a gap in the audio is to inform the user, and suggest demuxing by VobID.

[jsoto]

Well, I knew pgcdemux was not doing everything OK when demuxing by VID or single-Cell, but I really don't have all the related knowledge... So, first of all, thanks mpucoder for sharing it with us.

So, what should be changed in pgcdemux?
If I understood well, this is the situation:

1.- Demuxing by PGC:
- Check on every Vob change if it is a seamless or a non-seamless joint. If it is a non-seamless, warn the user and recommend demuxing by VobID.
Question 1: Which will be better: trust the IFO (PGC playback table) or the Vob (using the algorithm of zero delay in audio, i.e.)

2.- Demuxing by VobID:
- Check if the previous or next Vob have a seamless or a non-seamless joint. I'm assuming previous/next in the file layout, not in the PGC position
Question 2: A seamless joint has to be always with the next VobID? , i.e. is it legit a seamless joint between VID=1 and VID=3 ? Seems the answer is yes in a multiangle/multistory..., so how to determine which one is "the next" or "the previous"? Note in a multiPGC VTS one Vob can be joint to two different vobs (in two different PGCs)

If the previous Vob is a seamless-joint...
Question3: Should pgcDemux discard the audio packs until the minimum error in terms of delay ones?

If the next Vob is a seamless-joint..
Question4: Should pgcDemux demux the audio packs in the next Vob until the minimum error in terms of delay?.
Question5: Again, how to determine "the next"? What to do in the case of a branch (a multistory , i.e., VobID=1 is splited into two branches, VobId=2 and VobID=3)

3.- Demuxing by CellID:
Mmmm, seems identical to VobID., taking into account all cells in the same VobID are seamless between them

jsoto

[Sir Didymus]

I'd really prefere it is a person ( - hem... THE person ? - ) with a much better knowledge on the subject to give some further contribution...

Anyway, this is my undestanding - and please forgive me in case it turns out, as it may easily happen, of me posting some silly arguments...

1.- Demuxing by PGC:
- IMHO the check of non-seamless joint should be performed at every cell. Look at the scenario where you use VobBlanker for blanking the first cell of a movie, substituting the whole cell with a single I frame, or another scenario where the first cell - production logo ? - is authored by purpose without audio. Here a non-seamless joint is generated and the demuxer looses the synch between audio and video. Maybe instead of suggesting to demux by VOB ID (it would not permit to recover the synch), it would be useful to place, in the log file, the information of the whole cell duration, in case it have no audio. Regard what to thrust, probably it would be nice to use the IFO for determining the playback order and to thrust the VOB (pts of audio and video packs) for calculating the time relationship between audio and video...


2.- Demuxing by VobID:
- Your Question 2 is crucial. This is maybe the reason why the only proper way of demuxing something by VOB ID is also to follow the PGC, for collecting the right cell sequence. Maybe in this case the GUI should be changed in order to get the PGC first and then to get the Vob ID and the cell sequence from there. The same should be made - if possible - for demuxing by cell-id: first it should be defined by the user the PGC, then the VOB-id, then the Cell-id...

- Your Question3: If the previous Vob is a seamless-joint AND the application is demuxing by VOB ID, the demuxer should discard the initial audio packs belonging to the previous VOB. In my understanding, if in the initial cell of the VOB some audio packs have pts which is less than the VOBU start time, these are by sure not belonging to the VOB, so they should be discarded...

- Regarding your Question4: IMHO, yes. For the same reason of the previous question - as perfectly explained by mpucoder - in demuxing by VOB ID, the search of the audio for the last cell in the VOB should extend to the following VOB in order to collect the last audio packs belonging to the VOB.

Question5: Same as Q2... by demuxing the VOB in a given PGC.

------------------------------------------------------------
To everybody reading - hey people, don't want you wrongly
assume from the above discussion, that PgcDemux have bugs.
It is the best demuxer all around. That's all.
The discussion is about improvements, and contributions on
the matter are welcome...
------------------------------------------------------------

Cheers,
SD

Edit: maybe, in the demuxing by PGC and VOBID, a possible solution in order to let the user cope with "cells without audio" is simply to have an option for demuxing the audio in chunks. When a cell without audio is encountered, a new chunk is started. This way, together with other applications like your "silence" and/or "delay cut" it should be possible to put together a new audio asset matching with the demuxed video... Well, let's see..

[mpucoder]

Well, I knew pgcdemux was not doing everything OK when demuxing by VID or single-Cell, but I really don't have all the related knowledge... So, first of all, thanks mpucoder for sharing it with us.

So, what should be changed in pgcdemux?
If I understood well, this is the situation:

1.- Demuxing by PGC:
- Check on every Vob change if it is a seamless or a non-seamless joint. If it is a non-seamless, warn the user and recommend demuxing by VobID.
Only if it appears that the audio will cause sync problems later on. Each vob should have sufficient audio for its video, so that the next vob starts within half an audio frame. Cases where a vob has no audio, or is more than half an audio frame short of the video duration, will cause sync problems if not demuxed by VobID. The last vob can be as short as it wants, as it will not affect any following vob.

Question 1: Which will be better: trust the IFO (PGC playback table) or the Vob (using the algorithm of zero delay in audio, i.e.) I would not trust the ifo, and in any case it is a matter of video duration vs audio duration.
2.- Demuxing by VobID:
- Check if the previous or next Vob have a seamless or a non-seamless joint. I'm assuming previous/next in the file layout, not in the PGC position
Question 2: A seamless joint has to be always with the next VobID? , i.e. is it legit a seamless joint between VID=1 and VID=3 ? Seems the answer is yes in a multiangle/multistory..., so how to determine which one is "the next" or "the previous"? Note in a multiPGC VTS one Vob can be joint to two different vobs (in two different PGCs)
You are correct, it is possible to have seamless joints between vobs which are not contiguous. The best way to determine this is to map out the playback flow of all the PGCs. Not an easy thing to do, but a huge feather in the cap of the demuxer which can. There are only 2 ways multiple paths will be seen, either by using cell blocks (they will be marked as an ILVU block) and multiple PGCs - eg PGC1 uses VobID 1, 2, 4 and PGC2 uses 1, 3, 4. Here both 2 and 3 are seamlessly joined to the tail end of 1. Either 2 or 3 can be used to retrieve the last few frames of 1. If you have trouble finding test cases MuxMan 0.17, which I believe you have acces to, can create multi-story vobs now. That would give you a controlled environment - make a multi-story from A/V streams, demux and compare.

If the previous Vob is a seamless-joint...
Question3: Should pgcDemux discard the audio packs until the minimum error in terms of delay ones?yes, they belong to the previous logical vob

If the next Vob is a seamless-joint..
Question4: Should pgcDemux demux the audio packs in the next Vob until the minimum error in terms of delay?.yes, after determining it is the correct vob

Question5: Again, how to determine "the next"? What to do in the case of a branch (a multistory , i.e., VobID=1 is splited into two branches, VobId=2 and VobID=3)I think I covered that above.

3.- Demuxing by CellID:
Mmmm, seems identical to VobID., taking into account all cells in the same VobID are seamless between themCells within a vob are joined in a different kind of seamless joint that is no different than any two adjacent VOBUs - ie cells can be made anywhere without remuxing (an important feature for editing DVD-VR recordings). However, you are right, audio from one cell will be found at the start of the next. Here, as in seamless vob joints, pts can be your friend. Every VOBU contains a starting ptm (vobu_s_ptm) that can be used to determine to which cell an audio frame belongs.

[Zeul]

Now thats an answer :D

[mpucoder]

Now that I have more time I read SD's post, and it raises an interesting question. My experience is from the authoring point of view, and the specs (as best we know them). Is it possible with VobBlanker or other tools to replace a cell that had audio with one with no audio? This is contrary to what an authoring program would do, changes in the audio layout can only occur at the vob level. If it is true, then that situation must also be detected and addressed, as SD pointed out. The simplest way I can think of is to check for gaps during the demux itself. This can be done by checking the pts of each pack, which should match exactly the previous pts + (number_of_frame_headers * audio_frame_duration)
Audio frame durations are:
AC3 2880
DTS 960
LPCM 150
mpeg 2160
Note that mpeg audio is trickier as it is does not use the private stream and therefore has no DVD specific header to give you the frame count, and vbr is allowed (so parsing is probably the only reliable way to count frames).

If, on the other hand, the cell is replaced with a still of the same duration as the old motion video, there is no problem. PgcDemux need not be aware of phantom frames (Philips term for a still held by means of the vobu_se_ptm and sequence_end) since there are 2 reliable places to get the video duration of a vob without examaning the video itself. One is vobu_e_ptm of the last NAV pack, which should match vob_v_e_ptm (offset 0x437) of all NAV packs in the vob.
And there is an interesting area following vob_v_e_ptm which handles audio gaps - these should not be a concern, though. Audio gaps can occur ONLY at seamless vob joints, and are used to adjust for the duration differences in multiple paths. Anytime there are multiple paths a different kind of demux will be needed. It may be possible to demux the primary path as a whole, but the alternate parts need to be demuxed seperately, and by VobID. This is how most multi-angle and multi-story DVDs are authored, as a contigous main movie + angles/alternate scenes.

[mpucoder]

------------------------------------------------------------
To everybody reading - hey people, don't want you wrongly
assume from the above discussion, that PgcDemux have bugs.
It is the best demuxer all around. That's all.
The discussion is about improvements, and contributions on
the matter are welcome...
------------------------------------------------------------
I totally agree, PgcDemux is the best demuxer I've used. But now we are working to make it even better by handling the tricky DVDs that result from multi-angle, multi-story, and copy protection schemes.

[jsoto]

Hi all


------------------------------------------------------------
To everybody reading - hey people, don't want you wrongly
assume from the above discussion, that PgcDemux have bugs.
It is the best demuxer all around. That's all.
The discussion is about improvements, and contributions on
the matter are welcome...
------------------------------------------------------------
I totally agree, PgcDemux is the best demuxer I've used. But now we are working to make it even better by handling the tricky DVDs that result from multi-angle, multi-story, and copy protection schemes.

Thanks. As you know, I had valuable help during the development ;)

Is it possible with VobBlanker or other tools to replace a cell that had audio with one with no audio? This is contrary to .... Yes it is possible, although not really recommended... Also it is possible to cut away part of a cell in a "brute" way. Both things can cause gap problems. Cuting is recomended only at the end or at the begining of the PGC, but ....
So, yes, I'll include some kind of audio gaps detection during the demuxing process.

Note that mpeg audio is trickier as it is does not use the private stream and therefore has no DVD specific header to give you the frame count, and vbr is allowed (so parsing is probably the only reliable way to count frames). I know, but, as in Dolby (32 msec frame) because of the allowed sampling rate is only 48K the frame duration is always 24 msec (2160 tics), isn't it? . But yes, in mpeg, seems parsing is the only way to go.

Well, guys, seems everything is covered and it's time to work on it.

jsoto

[Zeul]

It seems that a couple of numenu users have had a problem when demuxing by cell is required. I have finally managed to replicate the problem. From the GUI cell demux works fine, but from the c/l i can't get it to demux any cell > 1. The c/l i am using is:

-m2v -cid 1 2 -aud -nosub -nolog -menu -nocellt and then the ifo params

-cid 1 1 works, but nothing else.

Probably my useage :D

Zeul

[jsoto]

@Zeul
Mmm, at first view the cli is OK. So seems there is a bug.
I'll look into it.

@all
Do not expect a fast response in pgcDemx development, I'm working now in VobBlanker..

jsoto

[dirio49]

@all
Do not expect a fast response in pgcDemx development, I'm working now in VobBlanker..

jsoto

:thanks:

[jsoto]

It seems that a couple of numenu users have had a problem when demuxing by cell is required. I have finally managed to replicate the problem. From the GUI cell demux works fine, but from the c/l i can't get it to demux any cell > 1.

Try PgcDemux1205 (http://www.videohelp.com/~jsoto/temp/PgcDemux_1205_exe.zip)
(Stupid cut & paste bug in CLI mode demuxing by CID). Nothing more has changed, so I'm not going to announce it as a release....


jsoto

[Zeul]

Thanks jsoto - works perfect from cli now :)

[davemorell]

Hi there'

I would like to know is there a way to open single vob files in pgcdemux without an ifo file??? Because I have to cut out some cells from the original movie, I did this with VobBlanker 2.0.1.0 (extract cells from 25 to 45 into a single vob file, and vb not created an ifo file for this). I can do the same with vStrip 0.8f, but it does not creat an ifo file too.

Is there a way to create an ifo file for vob files? Or are there any other solution to 'cut out' (for example: through an ifo file) the first cells, and then pgcdemux will open it fine?

Greetings'

[r0lZ]

Use IfoEdit's Create IFOs function. See the IfoEdit homepage...

[davemorell]

@ r0lZ : thanks for the tip

Although I had some problems. I cut the cells with VB, with IfoEdit I made the IFO files successfully. Then I loaded into PgcDemux and I started demuxing process. At 40% I got a Finsih OK! message... Strange....

Then I tried DVDReMake and deleted the unnecessary cells. I tried to demux again but it also stopped at 40% with an error message "Error reading input, VOBU Unsynchronized", after a click I got Finish OK message too. I tried vStrip too but IfoEdit could not create an ifo file (not found any VOBU unit message).

Then I tried again, my last hope: dvd decrypter with ifoedit. I successfully made it the first time :) If I'm demuxing the video stream or/and the audio streams to elementary streams and direct streaming the subtitle streams into one vob file and make an IFO file with IfoEdit I had no problem, PgcDemux demuxed the sup or/and audio files fine. BUT! If I direct streaming video+audios+subs into one vob file..... PgcDemux stopped at 47% (not 40% beacuse I just keep two audio not four I think) with Finish OK! message. It's realy strange...

I hope the DD + ifoedit + pgcdemux method 1 will work for me. It will be nice if PgcDemux can make what DD does for me now (chapter/cell/stream selection). I'm wondering why the vStrip method not working, but it's another story :)

Greetings'

[r0lZ]

Hum... Seems it's a problem for jsoto!

[jsoto]

Trying to guess....

IIRC, VobBlanker extracts all the cells in only one big VOB. (Note this is not fully correct, a VOB file should not be higher than 1 GB).

PgcDemux does not support files higher than 2 GB

So, if this is your case....
- Extract the cells with VB in three or four files (splitting the job, selecting just some of the cells), naming them
VTS_01_1.VOB
VTS_01_2.VOB
VTS_01_3.VOB
VTS_01_4.VOB
- Create IFOs with IFOedit
- Run pgcDemux.

jsoto

[davemorell]

You are absolutely right :) I always let the ripping process to make one big vob file. I thought it will be easier for me, and for making the IFO files. It was a mistake, I was afraid of multiple files without an ifo file, and I never had to make this kind of things till today. But now I understand a little bit more how the multiple files work. Thank you for pointing this out :)

Don't yout think about, you can integrate VobBlanker, PgcDemux, DelayCut... into one massive VOB manipulating tool??? Because they are very close to each other? I know it is easier to maintain while they are seperate but if they works fine alone why not put all of them into a big one...maybe someday ;)

Greetings and keep up the good work!

[SlipGun]

Why would pgcdemux output files with a few cells missing in the middle (both the video and audio), when both the celltimes file and the log list all the cells in the PGC? I suspect this has something to do with interleaved cells, but don't know how to correct it.

[jsoto]

@SlipGun
Could you elaborate?. I don't understand well your question...
Does pgcdemux fail in a ILV DVD?
jsoto

[SlipGun]

No, it does not fail. The video stream and audio streams are just shorter than they should be. The DVD is Toy Story 10th Anniversary edition: ~80 minutes long, but the output is only about 70 minutes. I'm not sure which section is missing exactly, but the beginning and end are fine, so it's something in the middle.

[CoNS]

Does the main movie PGC have multiple angles (check if the "Angle" dropdown field in PgcDemux is activated)? If yes, it may be the problem...

[SlipGun]

Yes, it does in the original DVD. Although I stripped angles 2 and 3 with no problem and it plays fine.

[jsoto]

And how do you get 80 min length?
Could you check the duration of the PGC with pgcEdit?. It automatically checks the duration when you opens the PGC. Just load the DVD in pgcEdit and double click on your TTN in the left pane.
jsoto

[SlipGun]

The movie's 1:20:33 in pgcedit. The demuxed m2v is around 1:03:55 in PowerDVD - I don't know if the PowerDVD indicator is reliable.

I want to replace an audio stream, but when I tried doing running the remux (done with Muxman) through VobBlanker I got an error saying some cells would be blanked due to a mismatch. The resulting output was very undersized.

This may not be a pgcdemux problem and I may be doing something wrong, but I can't tell what.

[jsoto]

VobBlanker does not support multiangle...
Are you loading some kind of processed IFOs? May be the stripped angle ones?

jsoto

[SlipGun]

jsoto: I sent you the IFOs as you requested. However, I'm having the same problem again with a non-multiangle DVD. Muxman fails at cell 19 of 20 with the "non-existant scene" error. I have "include end time" unchecked. The demuxed files seem to be the right size (unlike what I earlier thought), so I think something else is the problem.

[jsoto]

I've got the IFOS, but I cannot see anything wrong on them.
Seems you have removed OK the angles and post-processed with FixVTS or VobBlanker.... (renumbering the VCIDs)

The only thing I've found is a small bug in PGCdemux. If the last cell is a multiangle-one, unchecking the "include end time" has no effect, unless you are demuxing the highest angle.

In your second DVD (the non-multiangle one), could you post the exact PGC duration (including the frames) (better the complete cell list with their durations) and the last rows of celltimes.txt?


I'll look into it deeply, but I'm lost...

[jsoto]

Could you check the length of the demuxed audio?. Load the files in delaycut (available in my sites) and you´ll get the duration.

I've reproduced a similar problem using FAT32 and a video file larger than 4 GB. Neither pgcDemux nor MuxMan output any errror/warning, but the video is truncated and the muxed DVD is 4 minutes shorter than the original.

Are you using FAT32?

jsoto

[SlipGun]

Thanks for the update ...

I just found the problem with the non-multiangle DVD.

VobID 1 contains the movie; VobID 2 is just 15 frames of blank video. The original IFO shows cell 1/7 to be 17 minutes long. I used IfoEdit to strip VID 2, and noticed that this value changed from 17 to 10 minutes.

So the running time is only 2:02, not 2:09 (the original DVD plays just fine - but clicking anywhere on the 7 "missing minutes" in PowerDVD's time slider takes me to cell 8).

I assume pgcdemux copies the celltimes from the IFOs, which would explain why Muxman errored out - the celltimes made the movie appear longer than it really is.

After I'd done this, the remux finished okay, as expected.

I tried doing a mock strip without removing VID 2 and noticed that it did not change the times, so this is the only way I know of how to fix the problem. I suspect Toy Story has the same issue - it has a 15-frame VID at the end which I'll try stripping later.

I'm on NTFS, btw.

[jsoto]

Ah! Thanks for the report back.

BTW, VobBlanker, even in keep mode, should recalculate the cell times....

jsoto

[SlipGun]

I went back to Toy Story: ran it through VobBlanker, demuxed, remuxed. The final output plays fine except for the chapter points which are slightly before where they should be. The muxman log shows:

Starting scene Segment_1_scn2 at 00:01:30:00, requested for 00:01:29:29

... and so on for all the scenes. Is there a workaround?

[jsoto]

Did you reencode the video?
If yes, you need to fix the chapters in the encoder, to be sure an I-Frame will be there, and to guarantee a closed GOP at the begining of the cell.

If not, the only thing I can imagine is the celltimes in IFO are not correct. Run vobblanker in keep mode or do a IFOedit's mock strip. Both procedures will recalculate the celltimes.

BTW, we are running out of topic... May be it is better to open a new thread.

jsoto

[CoNS]

jsoto, I'm trying to demux a main movie in order to add some custom made subtitles. The VTS containing the main movie has three PGCs.

When I check A/V delay in PgcDemux delay it says 0 ms. for all three PGCs, but when I demux PGC 2, the PgcDemux log file says Audio_1=35840 (see entire log file below).

Also, MuxMan and IfoEdit both choke on the demuxed files when I try to mux/author a new DVD.

Any idea what could be wrong?

[General]
Total Number of PGCs in Titles=3
Total Number of PGCs in Menus=1
Total Number of VobIDs in Titles=6
Total Number of VobIDs in Menus=1
Total Number of Cells in Titles=26
Total Number of Cells in Menus=1
Demuxing Mode=by PGC
Demuxing Domain=Titles
Total Number of Frames=294636
Selected PGC=2
Number of Cells in Selected PGC=23
Selected VOBID=None
Number of Cells in Selected VOB=None
[Demux]
Number of Video Packs=1895988
Number of Audio Packs=272928
Number of Subs Packs=0
Number of Nav Packs=19629
Number of Pad Packs=0
Number of Unkn Packs=0
[Audio Streams]
Audio_1=0x80
Audio_2=None
Audio_3=None
Audio_4=None
Audio_5=None
Audio_6=None
Audio_7=None
Audio_8=None
[Audio Delays]
Audio_1=35840
[Subs Streams]
Subs_01=None
Subs_02=None
Subs_03=None
Subs_04=None
Subs_05=None
Subs_06=None
Subs_07=None
Subs_08=None
Subs_09=None
Subs_10=None
Subs_11=None
Subs_12=None
Subs_13=None
Subs_14=None
Subs_15=None
Subs_16=None
Subs_17=None
Subs_18=None
Subs_19=None
Subs_20=None
Subs_21=None
Subs_22=None
Subs_23=None
Subs_24=None
Subs_25=None
Subs_26=None
Subs_27=None
Subs_28=None
Subs_29=None
Subs_30=None
Subs_31=None
Subs_32=None

[jsoto]

Really strange.... I'm using the same code to get the delay fro the button and when demuxing... :confused: :confused: Seems there is a bug, but I think it is related with someting "special" in your VOB/IFO...

Could you send me the IFO and the first cell of the PGC #2 ? (At least the first packs of the cell, including the first audio)
(i.e. extract the cell with VobBlanker, and cut it with Cutfile)
jesus_soto_viso at terra dot es

jsoto

[CoNS]

I'm experiencing something fishy with the a/v delay when demuxing a certain DVD with PgcDemux, and muxing with MuxMan.

I'm demuxing the main movie, which is located in VTS_02, PGC #2. PgcDemux' "Check a/v delay" button (and the log file) tells me there's a delay of -224 ms. So, when I mux everything back together (with a new custom made SUP file), I type in a delay of -224 ms in MuxMan...

BUT when I check the a/v delay of the newly muxed main movie PGC in PgcDemux, it says that there's no a/v delay!?! :confused: Anyone has a clue why?

[bigotti5]

Muxman starts audio never more than 1200 SCR ticks before video so muxman cuts off ac3 frames if you specify delays > -13ms.
One ac3 frame is 32 ms long so in your case 7 frames (7 *32 =224) are dropped and results in 0ms delay.
If you specify -226 ms you will get -2 ms delay, -222 ms will result in +2 ms.

[CoNS]

Ah, thanks for explaining, bigotti5. Makes sense.

[Annatasia]

I have a problem too. Mine AC 03 is out of sync. How can I fix this?

PgcDemux given.

Audio_1: 0x80 --> -1msec

I need to put a good delay in muxman, can someone help me?

thnx

[blutach]

Muxman should accept -1, although this is a strange number.

Regards

[manono]

Find out the amount of the delay and either enter it in Muxman (up to +/- 300ms) or get rid of it entirely using DelayCut. To find the delay I play a VOB using Media Player Classic Home Cinema (although other players also have the ability to adjust the delay) and use the +/- buttons on the keyboard to change the delay on the fly.

http://www.videohelp.com/tools/Media_Player_Classic_Home_Cinema

[xekon]

One quick question about PgcDemux. when you extract the streams from a vob you lose the PTS timestamps.

When you use PgcDemux to Demux "by VOB id" and you select the "Create a PGC VOB" for output. Does it demux the streams and put them into a VOB with new PTS timestamps, or are the timestamps saved/adjusted from the original vob timestamps?