VobBlanker 'replace' function & ILV cells

[kumi]

For various reasons, I'm trying to "De-ILVU" a VTS, by removing ILV cells, demultiplexing the PGC, multiplexing it into an ILV-free titleset, and replacing the original DVD's PGC with VobBlanker.

But when I open the original DVD in VobBlanker, I get this warning:

There is at least one ILV Cell.
The VTSs containing these cells have been marked as SKIP. You can process them, but playback problems can appear in all PGCs originally containing ILV cells except the first one.

That's got me head-scratchin'... in what circumstance(s) is it safe to replace a PGC (with ILV cells), with a PGC that does not contain ILV cells?

EDIT: I forgot to mention that my DVD was originally multistory. Now it is "unistory", meaning that the 2nd title with ILV cells was deleted and the unreferenced cells stripped with FixVTS. The DVD now has only 1 PGC with references to ILV cells. In case that matters.

[Sir Didymus]

Hi kumi!
It seems you are facing the most relevant (partial) limitation of VobBlanker...

PgcEdit have a nice function for deleting unwanted angle(s) from a pgc...

A different possibility is to use del_angles (a tool written by Jsoto); see:

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

In both cases, after removing the ILVU parts, the pgc replacing with VobBlanker is always possible, and perfectly working...

Cheers,
SD

Edit.
Reading better your post I realise I did not answer to your question in blue...
IMHO, using VobBlanker, it is never safe (maybe I am wrong, but I think it is not possible at all) to replace PGCs containing ILV units: it should only be possible to skip these PGCs...

[kumi]

Oh dang... thanks for reminding me about the PgcEdit Delete Angles function! :)

When I press it, a warning pops up:

PgcEdit can remove the ILV information from the cell table.
However, do it ONLY if you know what you are doing!
Be sure to delete all other ILV cells (or PGCs).
Then process the Domain with VobBlanker WITH the option "Fix always VOB SYNCI/SRI pointers in Titles".

Remove the ILV flags and First ILVU End values now?

This sounds exactly like what I want: I have deleted all other ILV cells (and PGCs), so I should be good to go :)

[r0lZ]

Right! Go on!

[jsoto]

You can process them, but playback problems can appear in all PGCs originally containing ILV cells except the first one.

Uh!. I have to change this message. It's not true anymore from 2.0...

Deleting the unwanted story (removing the cells in IFOs with pgcedit or del_angles) is completely safe.
Blanking the unwanted cells should also be safe, but it is a little more dirty.

..VobBlanker WITH the option "Fix always VOB SYNCI/SRI pointers in Titles"...
Not needed anymore. From latest release (2.1.1.0), VobBlanker detects the ILV VOBUs and FIXES the pointers in these cells but not in the non-ILV ones, so running w/o the option is also OK, and will take less time.

jsoto

[kumi]

Bless you jsoto :)

Blanking the unwanted cells should also be safe, but it is a little more dirty.

So, by extension, it should also be "safe but dirty" to replace unwanted PGC/Cells in your software?

[jsoto]

So, by extension, it should also be "safe but dirty" to replace unwanted PGC/Cells in your software?
In the case of ILVs, replacing cells is not safe.

Take a look to a multistory VOB layout. It looks like


PGC_1 (program chain): [Title(TTN): 1] [01:51:50.23 / 25 fps] (Programs: 32) (Cells: 106)
(uses VOB-IDs: 2,3,4,6,7,8,10,11,12,14,15,16,18,19,20,22,23,
24,26,27,28,30,31,32,34,35,36,38,39,40,42,43,44,
46,47,48,49,51,52,53,55,56,57,59,60,61,63,64,65,67,
68,69,71,72,73,75)
[Ch 01] [Pg 01] [Cell 01] [V/C Id: 2/ 1] : time: 00:01:54.20 / 25 fps
[Ch 02] [Pg 02] [Cell 02] [V/C Id: 2/ 2] : time: 00:02:33.00 / 25 fps
[Cell 03] [V/C Id: 2/ 3] : time: 00:02:47.05 / 25 fps
[Cell 04] [V/C Id: 3/ 1] : time: 00:00:04.20 / 25 fps
[Cell 05] [V/C Id: 4/ 1] (IlVu) : time: 00:01:04.09 / 25 fps
[Cell 06] [V/C Id: 4/ 2] (IlVu) : time: 00:00:04.20 / 25 fps
[Cell 07] [V/C Id: 6/ 1] : time: 00:00:24.11 / 25 fps
[Ch 03] [Pg 03] [Cell 08] [V/C Id: 6/ 2] : time: 00:03:14.15 / 25 fps
[Cell 09] [V/C Id: 7/ 1] : time: 00:00:04.20 / 25 fps
[Cell 10] [V/C Id: 8/ 1] (IlVu) : time: 00:00:01.23 / 25 fps
[Ch 04] [Pg 04] [Cell 11] [V/C Id: 8/ 2] (IlVu) : time: 00:00:11.12 / 25 fps
[Cell 12] [V/C Id: 8/ 3] (IlVu) : time: 00:00:04.20 / 25 fps
[Cell 13] [V/C Id: 10/ 1] : time: 00:05:19.05 / 25 fps
[Ch 05] [Pg 05] [Cell 14] [V/C Id: 10/ 2] : time: 00:03:08.17 / 25 fps
[Ch 06] [Pg 06] [Cell 15] [V/C Id: 10/ 3] : time: 00:01:05.22 / 25 fps
…………………

PGC_2 (program chain): [Title(TTN): 2] [01:51:05.06 / 25 fps] (Programs: 40)
(Cells:2,3,5,6,7,9,10,11,13,14,15,17,18,…………..
[Ch 01] [Pg 01] [Cell 01] [V/C Id: 2/ 1] : time: 00:01:54.20 / 25 fps
[Ch 02] [Pg 02] [Cell 02] [V/C Id: 2/ 2] : time: 00:02:33.00 / 25 fps
[Ch 03] [Pg 03] [Cell 03] [V/C Id: 2/ 3] : time: 00:02:47.05 / 25 fps
[Cell 04] [V/C Id: 3/ 1] : time: 00:00:04.20 / 25 fps
[Cell 05] [V/C Id: 5/ 1] (IlVu) : time: 00:00:12.22 / 25 fps
[Ch 04] [Pg 04] [Cell 06] [V/C Id: 5/ 2] (IlVu) : time: 00:00:45.01 / 25 fps
[Cell 07] [V/C Id: 5/ 3] (IlVu) : time: 00:00:04.20 / 25 fps
[Cell 08] [V/C Id: 6/ 1] : time: 00:00:24.11 / 25 fps
[Ch 05] [Pg 05] [Cell 09] [V/C Id: 6/ 2] : time: 00:03:14.15 / 25 fps
[Cell 10] [V/C Id: 7/ 1] : time: 00:00:04.20 / 25 fps
[Cell 11] [V/C Id: 9/ 1] (IlVu) : time: 00:00:01.23 / 25 fps
[Ch 06] [Pg 06] [Cell 12] [V/C Id: 9/ 2] (IlVu) : time: 00:01:31.19 / 25 fps
[Ch 07] [Pg 07] [Cell 13] [V/C Id: 9/ 3] (IlVu) : time: 00:00:11.12 / 25 fps
[Cell 14] [V/C Id: 9/ 4] (IlVu) : time: 00:00:04.20 / 25 fps
[Cell 15] [V/C Id: 10/ 1] : time: 00:05:19.05 / 25 fps
[Ch 08] [Pg 08] [Cell 16] [V/C Id: 10/ 2] : time: 00:03:08.17 / 25 fps
[Ch 09] [Pg 09] [Cell 17] [V/C Id: 10/ 3] : time: 00:01:05.22 / 25 fps
………………..




That means VOBIDs 4 & 5 are interleaved and the same in VOBIDs 8 & 9.

PGC1 uses VOBIDs 4 & 8 , and PGC2 uses VOBIDs 5 & 9
So, when the settop is playing PGC1, VOBIDs 4 and 8, it has to skip (doing small "jumps" with the laser, or reading them faster) the VOBUs belonging to VOBIDs 5 & 9. These small jumps are limited in size by the specs to a specific amount.

After VobBlanker process (Keep mode) the VOB file layout will be

[V/C Id: 2/ 2]
[V/C Id: 2/ 3]
[V/C Id: 3/ 1]
[V/C Id: 4/ 1]
[V/C Id: 4/ 2]
[V/C Id: 5/ 1]
[V/C Id: 5/ 2]
[V/C Id: 5/ 3]
[V/C Id: 6/ 1]
[V/C Id: 6/ 2]
[V/C Id: 7/ 1]
[V/C Id: 8/ 1]
[V/C Id: 8/ 2]
[V/C Id: 8/ 3]
[V/C Id: 9/ 1]
[V/C Id: 9/ 2]
[V/C Id: 9/ 3]
[V/C Id: 9/ 4]
[V/C Id: 10/ 1]
[V/C Id: 10/ 2]
[V/C Id: 10/ 3]


VOBIDs 4 &5 are NOT ILVed , nor 8 & 9.
So, now, when the settop is playing PGC1, at the end of VOBIDs 4 and 8, it has to skip VOBIDs 5 and 9. But now the VOBUS are not interleaved, so the jump is the whole VOBID, probably out of specs to be seamless. This usually produces a discontinuty (small freezing) in the player. The right way to author in this case is to flag as non-seamless the joins between VOBIDs 4 & 6 and 8 & 10 in PGC1.
If you want to keep the seamless join, one solution is to blank the VOBIDs 5 & 9, so the jump sure will be enough small, but a more clean solution is to remove completely the cells 5/x and 9/x (using previously pgcEdit)

The same applies in the case of replacing cells.

But, note we're talking always about ILV material. If there are no ILV at all, VobBlanker is safe and clean in all supported actions. (Well, cutting a cell/title has some brute/dirty procedures, but this is out of scope, and it is usual when cutting a VOB, also with other more proffesional tools).

jsoto

EDIT: some typos

[r0lZ]

From latest release (2.1.1.0), VobBlanker detects the ILV VOBUs and FIXES the pointers in these cells but not in the non-ILV ones, so running w/o the option is also OK, and will take less time.I'll change the message in PgcEdit's Del Angles function. Thanks for the reminder!

[kumi]

@jsoto: Ok, great explanation :) I'll be ready next time a Angle/Multistory DVD crosses my desk!

Thanks