VobBlanker 1.5.1.0 is out: A tool to blank, cut or replace titles and Menus

[jsoto]

OK.
You need to find the starting and ending sector of the Cells. Due they are Menu Cells, you will find the info (using IFOEdit) in VMGM_C_ADT table (if VIDEO_TS.VOB) or in VTSM_C_ADT (if VTS_XX_0.VOB).
So, locate your Cell in the table (using CellID and VObId), and write down the starting/ending sectors. Because they are blank cells the total number of sectors should be 5 , let's say
endsector=inisector+4;

Now, you can "jump" (there is a button in the bottom-left) in VobEdit to the ini sector. The inisector MUST be a Nav pack. Click on the pack (inn the left side of Vobedit) and in the right side you will see the pack contents, where you will find the addresses I've referenced in my previous post

To cut the cell, just write in Cutfile the values inisector (Initial block) and endsector (End block), keeping the block size of 2048 (default). Press OK and you're done. The output file should be a 10 KB one.

Please zip the cells and the IFOs and send them to me.

jsoto

[blueboyec]

jsoto,

I see that at DVDhelp you have released 1.6.0.1. but it is not mentioned here. Is this correct?


blueboyec

[jsoto]

VobBlanker 1.6 has its own thread:
http://forum.doom9.org/showthread.php?s=&threadid=86437

jsoto

[CoNS]

The start and end sector values in IfoEdit are in hex.

Are the sector (block) values in CutFile also in hex or are they in decimal?

EDIT: Oops, didn't see at first that IfoEdit has BOTH the decimal AND hex values...! I got it now. Expect a pm with the files in a few minutes, jsoto!

[jsoto]

Thanks, I've got them.
At first view I was unable to see a reason...
But, I've found a possibility.
Second Cell in root menu is marked as STC discontinuity in PGCEdit IFOs, but not in VobBlanker ones

Did you do a IFOEdit mock strip on menus in PGCEdit files? I believe a IFOEdit's mock strip fixes this...
Or... may be PgcEdit changes this bit in the PGC when blanking out a cell?
@r0lZ, could you confirm this?

VobBlanker is not doing that, and I believe we can consider this is as bug.

So, please change the cell type in IFOEdit from 8 to 10 and try again. (You have to burn a new media, I hope your settop is able to read DVD+-RW)



jsoto

[CoNS]

Yep, changing it from 8 to 10 makes it work!! (seems the same upon playback as when fixed with PgcEdit)

Good job!

(and no, I haven't anywhere in the process done a mock strip of the menu PGC in IfoEdit. That goes for the version fixed with PgcEdit, too)

Should the cell type only be changed from 8 to 10 in the following cell (cell 2/3)? How about cell no. 3/3, which also is marked as cell type 8?

[r0lZ]

Originally posted by jsoto
Second Cell in root menu is marked as STC discontinuity in PGCEdit IFOs, but not in VobBlanker ones

Did you do a IFOEdit mock strip on menus in PGCEdit files? I believe a IFOEdit's mock strip fixes this...
Or... may be PgcEdit changes this bit in the PGC when blanking out a cell?
@r0lZ, could you confirm this?

Yes. I set the SCR Discontinuity flag on the blanked cell and the following cell, if the VOB/Cell ID is not contiguous. I had the feeling that this is required, to avoid to have two cells too far in the VOB be played seemlessly.

BTW, your 'reordering' method when writing VOBs may cause the same problem, when some cells are reused.


Note: This flag is called SCR Discontinuity by Mpucoder (and me), and STC discontinuity by Derrow. Who is right?

[jsoto]

to avoid to have two cells too far

This is a potential problem, but I believe this is not the case. (It is a small size menu, and even more, VobBlanker Cell is closed to the following one, but not PGCEdit one)
I'm thinking in the "logical" problem. We have blanked out a 26 seconds cell, so the system clock has to be resynchronized. Probably the settop is waiting until SCR or PTS gets the value indicated in the second (not blanked) cell

jsoto

[jsoto]

@r0lZ
About your note...

What does the flag mean?
A discontinuity in SCR (System clock)
A discontinuity in Presentation Time (PTS) ?

Probably the discontinuities are always togheter...

jsoto

[CoNS]

So what's the conclusion to all this in lay men's terms?

[jsoto]

Sorry CoNS, for any reason, I didn't see your post. Great to know we found it!
The conclusion is clear:
There is a bug (omission ) in VobBlanker. I've to modify the Cell type in the own cell (it is discontinous with the previous) and in following one when blanking/replacing cells (and also when cutting PGCs in the middle of a Cell, may be I'll solve some problems in this way)
jsoto

[blutach]

@jsoto

Can this SCR issue be at all related to the issues I have been having when cutting PGCs?

BTW: How does this flag work. I see PGCs with different values here for each cell (soemtimes 8, others 2 and others 10) and no idea what they all do (although pgcedit has an explanation of the bit settings).

Can anybody explain?

Regards

Originally posted by r0lZ
30.000 PGCs!!!
I wonder if PgcEdit is able to handle so many PGCs, and how long it takes to load them. Someone has tried it?

This bunny (or is that 'cat' seeing as we are talking Garfield) tried it (R4 PAL). About an hour to load (P3-500 384MB). I also got 10 minute pauses at times while editing. The slow bit is saving DVD at the end. I've now been "Writing VTS 6 IFO" for about 12 hours with 97-99% CPU Load - No idea whether the finish is in sight.

Now torn between scrapping this editing (as I'm only skipping warnings etc) and just back it up without any editing (just small amount of shrinking).

......As I type this it just finished. So this goes down as the longest PGCEdit I've ever done - about 14 hours start to finish.

[r0lZ]

Hum! I'm not proud!
But take in mind that PgcEdit is written in an interpreted language, without pointers and the like. It's difficult to speed it up.
However, I wonder why it is so slow to save the DVD. Maybe I'll found a way to shorten the save duration...
Another thing I may try in the future is to buy Tcl/Tk Pro package. It's a little bit expensive, but it has a bytecode compiler, a profiler, and some other useful tools. I just need some more donations...

Wouldn't worry....there's not too many around with 30,000+ PGC's. Must have been a painful one for them to build in the first place.

Donation coming your way shortly...been meaning to for a while for the programs I've settled into using frequently.

[r0lZ]

Yet another "IFO file too big" issue: http://forum.doom9.org/showthread.php?t=105580

[frank]

Originally posted by r0lZ
30.000 PGCs!!!

A new way of stupid copy protection!

[jsoto]

Originally Posted by frank

A new way of stupid copy protection!

No, It isn't. It is a kind of game made with DVD...., very poor BTW. This is an old thread and the DVD is Gardfield.

Copy protection methods are always oriented to protect main movie, because there are many many people happy with movie-only backups, and the main movie is the content to be protected..

jsoto