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

[CoNS]

@ blutach: Yes, well, I understand that this is the way VobBlanker works in its present form. What I'm suggesting is adding a new feature to VobBlanker. I know my first post is loooong, but try reading it again and you'll probably see what I mean... :)

[blutach]

@cons

IMHO, it is a feature of VobBlanker that there is a destination directory. As before, if you screw up, no problems and no need to try to resurrect the disk from a backup file.

Regards

[r0lZ]

I agree with CoNS: if the original files are moved to a backup dir before processing, if you screw up, there are still no problems: you just have to restore them. In the other hand, if everything went properly, you don't have to move the new files manually.
But this may be difficult to program, because jsoto will have to take care that the new files, in the DVD folder, will not match anymore what is currently displayed in the VobBlanker GUI and stored in the internal variables.

[CoNS]

exactly, that's why I suggested ending the process with some sort of a "Get VTS sector" function. Wouldn't that do the trick? How is it the same thing done in PgcEdit when you blank out a whole titleset?

[r0lZ]

IMHO, it's much much easier to replace a whole domain VOB by a blank VOB cell.

[mrslacker]

While the backup directory is on topic, I would like to suggest PgcEdit backups of the BUP files as well. That would make a copy-and-paste restore a bit easier. I know they are backups, it would just save some time.

To stay on this thread's topic, I prefer PgcEdit's backup method over the detination directory method of VobBlanker. VobBlanker adds a little extra work if you don't want it to process every VTS. That is, I have to correct VTS sectors manually after moving unaltered VOBs to the destination. The way PgcEdit works on the original directory simplifies everything. Could I just set the destination in VobBlanker to the source directory? Would VB leave the unprocessed files alone, while correcting VTS sectors? That's just the way I understand it. Thanks for clarification.

[r0lZ]

To restore the BUP files as well, just use the PgcEdit Restore Backup menu. Or restore them manually, then load and save the DVD again.

@jsoto: Sorry, I am squatting your thread. ;)

[jeanl]

Originally posted by mrslacker
While the backup directory is on topic, I would like to suggest PgcEdit backups of the BUP files as well. That would make a copy-and-paste restore a bit easier. I know they are backups, it would just save some time.

To stay on this thread's topic, I prefer PgcEdit's backup method over the detination directory method of VobBlanker. VobBlanker adds a little extra work if you don't want it to process every VTS. That is, I have to correct VTS sectors manually after moving unaltered VOBs to the destination. The way PgcEdit works on the original directory simplifies everything. Could I just set the destination in VobBlanker to the source directory? Would VB leave the unprocessed files alone, while correcting VTS sectors? That's just the way I understand it. Thanks for clarification.
I second that. I like to process DVD "in place" (I usually try to avoid processing vob files, other than replacing them by small ones), and that's just impractical in vobblanker...
Jeanl

[jsoto]

Well, I do understand CoNS feature request. I've never take it into account, because when you use VobBlanker you are going to modify a VOB, and for sure, rewritting it. In this case, the use of different physical drives is the optimum choice, and you cannot move files across different file systems.
In any case, for those users with only one drive, or in the case of a small VOB modification, CoNS's proposal has sense, so I'll keep it in mind. But do not expect it too early, I'm very busy at work now (due the end of the year).

jsoto

[jsoto]

@jsoto: Sorry, I am squatting your thread. Oh!. No problem at all. Friends are always welcome :)
jsoto

[CoNS]

Okay, jsoto, thanks for keeping it in mind! :p

[blutach]

It seems the users have spoken in a mini poll :)

One thing, @jsoto - yes, VobBlanker's processing is much faster if the output folder is on a different drive to the input folder, but if you have processed a big VTS (eg. yes, you guessed it, cut credits), then once processing is finished, you need to copy it over the the first drive anyway, which takes a few minutes. So, I don't use the different drive any more.

BTW: @rolz, In no way was I criticizing your product, which you know I am a huge fan of ;)

Regards to all

[jsoto]

but if you have processed a big VTS (eg. yes, you guessed it, cut credits), then once processing is finished, you need to copy it over the the first drive anyway You can copy the rest of VTSs (if they are small) over the second drive, or let VobBlanker to do it. This is my case, because I usually replace the main movie (with a reencoded one). Well, I usually replace the extras with a VCD/CVD resolution encoded ones too, so I'm practically rewritting the whole DVD...
jsoto

[blutach]

@jsoto - good idea, but, in my case, the other drive is my system drive, which I like to keep clean of data and has only 13Gb spare :)

Regards

[lark]

how about having it configurable to please everyone? ;-)

regards
t :)

[blutach]

@lark

It is configurable

[lark]

sorry, perhaps we are speaking of a different issue.
somehow i got that there was a request to have vobblanker either
1) write to another (selectable) directory (as it currently does)
or
2) write to the current (=source) directory, but make first a backup copy of files to be modified to another (selectable) directory

but as said, perhaps i've misunderstood something ;-)

regards
t :)

[CoNS]

Exactly, lark, that was what I was asking in the first place, see my above post about adding an extra feature.

[greath]

I am running Vobblanker 1.5.1.8 and it is having problems with Garfield The Movie DVD. Fox have made the IFO files for VTS_7 648KB and for VTS_8 over 8MB in size, and Vobblanker won't read them in as it says that VTS_7 IFO is too large. IFOEdit will open it and it shows that the PGC has thousands of entries in it that are each very short. Shall I send the IFO files to you?

[jsoto]

No, thanks.
Garfield has a VTS with 30.000 (yes, thirty thousand, close to the legal maximum) PGCs.

Try with VobBlanker 1.5.1.9 (experimental). G__ has been able to load it (it take a while...) in this version.

jsoto

[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?

[greath]

I've downloaded the experimental VOBblanker and will give it a go. I will also try PGCEdit to see what happens.

[jsoto]

@r0lZ,
G__ was also able to load it in PgcEdit.

I do not know what he did in terms of DVD authoring modifications.

jsoto

[r0lZ]

:)
I suppose that modifying the DVD is not a problem, as long as Tcl/Tk has enough resources to store it!

[jeanl]

Originally posted by jsoto

Garfield has a VTS with 30.000 (yes, thirty thousand, close to the legal maximum) PGCs.

Try with VobBlanker 1.5.1.9 (experimental). G__ has been able to load it (it take a while...) in this version.
jsoto
jsoto, is there a reason why vobblanker can't allocate ressources on the fly (i.e., is there a reason why you have to have a fixed maximum number of PGCs?)
I'm just curious ;)
Jeanl

[jsoto]

Only one:
I am (at least I was when I started to code VobBlanker) a newbie programmer and I've used fixed lenght arrays in the code (members of VobBlankerApp). Seems not easy to change this now, because there are a lot of lines of code...

If you have an idea about how to change this without too much effort, it will be welcome.

jsoto

[jsoto]

To clarify a little more. I have many arrays in the form

my_type My_variable[MAX_VTS][MAX_PGC];

jsoto

[jeanl]

Originally posted by jsoto
To clarify a little more. I have many arrays in the form

my_type My_variable[MAX_VTS][MAX_PGC];

jsoto
ahhhh! That's a good reason to declare them like that (the fact that they have 2 dimensions). This is a bit off topic, but a good compromise is to have 1 fixed length, and 1 "adjustable" one:

my_type *My_variable[MAX_VTS];

and somewhere in your code (probably when you load the DVD), you allocate the appropriate array:

My_variable[i] = new my_type[NumberOfPGC];

and you don't have to change the way to use the variable (My_variable[i][j] still works).

It's a bit of a complication because you have to delete your arrays at the end (or before you re-allocate them), using delete[];
We can take this off-line if you want to continue the discussion!
Jeanl

[blueboyec]

Jsoto,

I only see 1509 and 1510 but no 1519. Is there a new version out?:)

blueboy

[jsoto]

@jeanl
This is a bit off topic, but a good compromise is to have 1 fixed length, and 1 "adjustable" one: Seems this approach can do the trick. I'll give it a try when I find time... I'll keep you informed.

BTW, I'm already using "new" and "delete" for IFOs memory allocation.

@blueboyec
Sorry, my bad. It is 1.5.0.9. Version 1.5.1.9 does not exist.

jsoto

[CoNS]

A bug (?) in VobBlanker when blanking cells in VTSM:

I have a disc (Harry Potter 3 PAL), where I've used VobBlanker 1.5.1.0 to blank some PGCs inside a VTST, and also some PGCs and cells in PGCs in a VTSM. One of these cells was a part of the main menu, as it was a video that played 26 seconds right before the main menu buttons were shown. The cell itself had no buttons or cell commands.

I did all the blanking in one process with VobBlanker and afterwards everything looked fine in my software player. However, when I burned the disc, my standalone SONY player showed a black screen for 26 seconds where the pre-menu video used to be. Also, when I looked carefully playing the disc in my software player again, I noticed some large pixels appearing right before the cell with the main menu buttons was shown, but my software player didn't wait the 26 seconds like my standalone, as the pixelated frame was only visible in a flash.

I loaded the disc with PgcEdit and examined those PGCs and cells that I blanked. The above mentioned cell that turned out to cause the problem had it's still time set to 0, and as I said: No buttons, no cell commands.

Then I replaced the VOB ID and Cell ID by adding an extra blank cell at the end of the VOB using PgcEdit. Except the new VOB ID and cell ID everything looked exactly the same in PgcEdit.

And then it worked!

The long delay with the black screen was gone when I played it in my standalone player, and the glimpse with large pixels had also disappeared when playing it in my software player.

Can anyone explain this or point out some possible explanations for this? Is it a bug related to the blanking of a cell using VobBlanker?

[blutach]

@cons

Look at the last few days of the PgcEdit thread. I can give you further info, but, in short, I have found that VobBlanker reorders VOBIDs in PGC order and also blanks unreferenced VOBIDs, leaving "holes" in the menu (I am not at all sure whether these are a "DVD specs" problem though).

However, I wonder if this is related to your problem?

[CoNS]

@ blutach: Hmm, could be the case?

jsoto, what do you make of the case reported above by me and the discussion in the PgcEdit as referred to by blutach?

[jsoto]

@CoNS
Strange, but seems different to "reordering cells issue". The fact (if I've understood well) is that your SONY "plays" 26 seconds of a "blank/pixeled" frame. So it knows the original time: 26 seconds, but where is this data? . This is the question to answer, because duration time should be changed in cell and also in PGC. If not, it is a VobBlanker bug.
Could you send me the IFOs before and after VobBlanker processing?. Also, a project file to see what are you exactly doing will help. (Menu--> File---> Save project as) just before or after processing,

jsoto

[r0lZ]

It must be the PGC Still Time (ignored by software players, but not by Sony standalones.) The PGS Still Time is used exactly like a Cell Still Time, but only on the last cell of the PGC.

[jsoto]

Yes, it could be, but CoNS says he is blanking a cell ( a motion cell) so to have a PGC still time different to cero seems strange to me.

In any case, reseting PGC still time is not done in VobBlanker. (I'm clearing Cell still time in 1601, but not PGC still time)

jsoto

[r0lZ]

Yes. Strange, although not impossible. This is often the case of menu cells with an animated intro, followed by a last image with menubuttons, and a cell or PGC still time.

[CoNS]

jsoto, I'll p.m. you the .ifo files before/after blanking when I get home from work. I've deleted the original .vob files in order to free harddisk space, so I can't reconstruct the project file in VobBlanker?

But here's the scenario in details:

The problem I experienced, was that after blanking with VobBlanker 1.5.1.0, my SONY standalone showed approx. 26 secs. of black screen before the main menu appeared. My software player (MPC) went straight to the main menu, only showing a short glimpse with large pixels right before the main menu played.

The problem is obviously related to the first cell in PGC 1 in VTSM 1. I know this for sure, as the problem with both black screen for 26 secs. in my standalone AND the glimpse of large pixels in my software player disappeared when I used PgcEdit to append a new, blank frame at the end of the .vob file and set the VOB ID and CELL ID to this new frame for the cell in question.

PGC 1 in VTSM 1 contains 3 cells.

Originally the first cell had an approx. 26 seconds long animation/video sequence which was played right before the main menu appeared. This cell did not have any buttons. I blanked the cell in VobBlanker by doubleclicking VTST 1, which gave me the menu window showning VTSM 1. I selected PGC 1 and clicked "Cell" and marked the first cell out of the three for blanking. I didn't get any errors or warning when blanking.

In the same blanking process, I also blanked some whole PGCs within the same VTSM, and also a whole PGC in the VMGM. I haven't had any problems with these blanked PGCs afterwards.

Cell no. 2/3 and 3/3 in PGC 1 contains the main menu, which also has an animation (i.e. it's not only a still picture). Being a main menu, these two cells have ofcourse buttons. The difference between these two cells seem to be in the animation playing, otherwise they look the same. These two cells were left untouched when I blanked using VobBlanker, and they also played fine afterwards.

When I open the disc in PgcEdit after blanking (but before fixing it with PgcEdit), and show the details for PGC 1 in VTSM 1 in the PGC-Editor, the cell still time for all three cells are 0 and the PGC still time is also 0. So that's not the problem. The playback time and end time for cell 1/3 are both 00:00:00.12, which they should be after blanking.

Weird, huh?!

(The disc is disc 1 of Harry Potter 3 PAL with ENG DK NO audio and subs)

[jsoto]

Yes, weird!!
What I do not understand is why the DVD plays fine with a blank cell at the end of the VOB!
Mmmm, may be VobBlanker's blank cell is wrong...
Please send me the cell produced by VobBlanker (you can cut it with CutFile) and the one produced by PGCEdit.

Or may be you are able to see the differences in VobEdit: In the Nav pack look at SCR (byte 4), VOBU start PTS (byte 0x39) and Elapsed time (twice in the pack: bytes 0x45 and 0x423).

SCR and PTS can be an issue, because a blank cell has SCR=0 and a PTS close to cero, but the next one will have a SCR/PTSs values corresponding to 26 secs. But this should be the same in the case of PGCEdit produced cell!

The same applies to Elapsed time, but AFAIK, Elapsed Time is refered to the own Cell, so it starts from Zero in each cell.

jsoto

[CoNS]

I need a little help on providing the info requested! I'm not used to neither CutFile or VobEdit... :)

I have downloaded both programs, but in CutFile I'm not sure how to find the block numbers etc. for that cell.

And in VobEdit, I load the VTS_01_0.VOB but I don't know where exactly to look... :confused:

I think the easiest way would be to cut the cell using CutFile, if this can give you the desired info, and if you can tell me how to find the block values for my .vob.

Would the file be too large to send by p.m. if I'm including the .ifo files aswell?

[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...! :o 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)

http://www.iespana.es/jsoto/images/celltype.jpg

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?