VobBlanker save log message.

[nomorecoasters]

Just came across this when i used vobblanker 2.1.0.0, just wondered what it meant and why ive never had it appear before?
The line in 'red' :)

=========== VIDEO MANAGER FINISHED ===========


PostCommands changed into Precommands in 7 PGCs of a total of 10

Finished. No Errors, 0 Warnings

[r0lZ]

It means that it has modified the commands of the blanked PGCs so that they are not played anymore, and you will normally not see the short black video when the PGC is called. You can turn this option off if you want.
BTW, it's the same technique than the Kill Playback function in PgcEdit.

[nomorecoasters]

You can turn this option off if you want.


What does turning it off do/what dont i see anymore the black screen?

Also its just that this time the message was in red and ive just done another film and it does show it but in blue writing :D

[r0lZ]

It is in red because only 7 PGC/10 were modified. This means that you may still see the black tiny cell in 3 PGCs. 3 PGCs were not modified because, in some cases, it is not safe to do the command modifications.

There are many informations on the kill playback method here at D9. Use search.
Briefly: the method is to copy the post commands at the end of the pre commands, and change the original BREAK pre-commands to GOTOs to the first added pre-command. This way, the pre-commands are executed normally, but instead of continuing with the playback of the video, the post commands (now pre-commands) are executed immediately. In the original post-commands, there is normally a jump to another PGC. This jump is therefore now executed before the PGC has been played, and the navigation continues normally.

Turning this option off has obviously the effect that the playback of the tiny black cells will occur.

[jsoto]

In fact, it is Orange (= Warning). Red is used in Errors.

jsoto

[voo_doo99]

You two are such a good supporting tag team :D, which prompted my question about synergy between PgcEdit and VOBBlanker: If I did a menu/title Kill Playback and chose to remove the cells in PgcEdit then I called up VOBBlanker, would VoB blank the menu/title cells automatically upon processing [without my intervention]?.
From old habits, I always did my blanking first and then openned in PgcEdit for validation/modification. Maybe, it makes more sense to do it the other way. :)

[r0lZ]

My method is to use PgcEdit first. (sorry Jsoto!;))

I usually blank the whole titlesets with the PgcEdit function. It's really fast.

Then, I use the Vob/Cell IDs remapping and the remove cell functions in the PGC Editor to remove or replace the cells I don't want with tiny black cells. (Take care however: you should not remove the cells when a title or menu is called with jumps to specific cells, chapters or programs! But, of course, you can safely reassign them.) Finally, I process the modified titlesets with VobBlanker, to strip out the unreferenced material from the VOB files. This method is less efficient that blanking with VobBlanker, though, but let you do interesting things such as reusing the same cell for all credits in an episodic DVDs, or the same menu cell when several cells with the same contents are used (which is very common.)

Anyway, it is sufficient to use VobBlanker to remove the unreferenced material.
FixVTS can also be used to do that, but Jeanl told me that you can have problems with the FF/Rew functions if you remap or delete only some cells in a PGC. If you remove all cells of the PGC or replace them with a tiny one, FixVTS can be used safely.

[jsoto]

My method is to use PgcEdit first. (sorry Jsoto!;))
don't worry, I use pgcEdit after.. ;)
But, in some (many) cases I use pgcEdit before and after VobBlanker...
I like the ability of pgcEdit to reuse some cells (I use it mainly in menus not authored as LUs)

But I blank/replace with VobBlanker...

Finally , I like to customize navigation with pgcEdit.. i.e. start with main menu, hide buttons, create a new button to access to the trailers not accesible from the menu (usual in FOX DVDs..)

FixVTS can also be used to do that, but Jeanl told me that you can have problems with the FF/Rew functions if you remap or delete only some cells in a PGC. If you remove all cells of the PGC or replace them with a tiny one, FixVTS can be used safely.
Mmm, may be jeanl was wrong here.... FF/Rew VOBU_SRI & SYNCI pointers always point inside the cell, so deleting/inserting cells should not have any FF/Rev problem...
jsoto

[r0lZ]

AH!? Good news!
But then, how does it works when the user uses rew or ff over a cell boundary? Does it mean that the operation is stopped and relaunched on the prev or next cell?

[jsoto]

I think the settop uses the Cell Elapsed Time, present in the nav pack and the playback time in the IFO, but not sure what it exactly does...

jsoto

[jeanl]

Mmm, may be jeanl was wrong here.... FF/Rew VOBU_SRI & SYNCI pointers always point inside the cell, so deleting/inserting cells should not have any FF/Rev problem...
jsoto
jsoto is right, I was wrong... The pointers do have to point within the current cell, so cutting an entire cell has to effect on them. But, for ILVUs, I wonder if that's the case too...
EDIT: Well I checked on polar express, and the VOBU_SRI pointers still point within a given cell, but possibly across an ILVU. For example, at the boundary between 7/1 and 8/1 (2 ILVUs) the pointers in the last navpacks of 7/1 jump over 8/1 to the next part of 7/1... So if FixVTS is used to keep only 1 angle, then the VOBU_SRI pointers will be wrong and you won't be able to fast forward (at least where there used to be ILVUs).
Jeanl

[r0lZ]

OK, thanks for the clarification.

So, voo_doo99, it is safe to remove/remap any cell except ILV/Angle cells in PgcEdit, and then use FixVTS to remove them from the VOB files.
Currently, VobBlanker has the same limitation.

[dirio49]

jsoto is right, I was wrong... The pointers do have to point within the current cell, so cutting an entire cell has to effect on them. But, for ILVUs, I wonder if that's the case too...
EDIT: Well I checked on polar express, and the VOBU_SRI pointers still point within a given cell, but possibly across an ILVU. For example, at the boundary between 7/1 and 8/1 (2 ILVUs) the pointers in the last navpacks of 7/1 jump over 8/1 to the next part of 7/1... So if FixVTS is used to keep only 1 angle, then the VOBU_SRI pointers will be wrong and you won't be able to fast forward (at least where there used to be ILVUs).
Jeanl


so does that mean that there will a newer version to fix this bug and with new features?:D

[jeanl]

so does that mean that there will a newer version to fix this bug and with new features?:D
:D :D :D
A new version of what?! Precisely, this means that there is no bug in FixVTS! That's the good news! Except of course if you deal with ILVUs in which case all bets are off! I'll try to fix that in the near future...
Jeanl

[jsoto]

Ooops. Yes, I forgot the ILV case... Well, VobBlanker currently fixes them if the VTS is ILV-ed. And for angles too, but you need to previously remove the angles in the IFOs...

jsoto

[r0lZ]

... but you need to previously remove the angles in the IFOs...
You mean remove the cells, the ILV and angle flags, and the First ILVU End value, right? Is it something more to do?
Also, is it possible to selectively remove some angles, but leave several angles in place?

[jsoto]

You mean remove the cells, the ILV and angle flags, and the First ILVU End value, right? Is it something more to do?[quote] Yes. And to properly modify program table (angles should be in the same program, but the cell number now is lower in the following cells) Ah!, you need to modify also VIDEO_TS.IFO to change the number of angles of the PGC to one.
Note VobBlanker will de-ILV the cells and recreate from scratch the VTS_C_ADT table.

[quote]Also, is it possible to selectively remove some angles, but leave several angles in place? No, sorry. Currently VobBlanker clears all ILV pointers, so you cannot keep more than one angle. BTW, you have to check "Fix VOB SYNCI/SRI pointers in Titles", because VobBlanker does not know the pointers are not valid..

May be you can add a simple macro in pgcEdit to keep an angle?
jsoto

[dirio49]

:D :D :D
A new version of what?! Precisely, this means that there is no bug in FixVTS! That's the good news! Except of course if you deal with ILVUs in which case all bets are off! I'll try to fix that in the near future...
Jeanl


A feature to remove angles all together(fix the ifo and the rest) .:D :D
if you are bored :p

P.S. I know ifoedit can do this but as you said it has a bug, it clears the cell commands.;)

[r0lZ]

May be you can add a simple macro in pgcEdit to keep an angle?
jsotoMay be! Seems easy...

Last question: is it needed to remove the angles in all PGCs of the domain or of the whole DVD, or is it feasible on a per PGC or VTS basis?

[jeanl]

May be! Seems easy...

Last question: is it needed to remove the angles in all PGCs of the domain or of the whole DVD, or is it feasible on a per PGC or VTS basis?
Don't use FixVTS then, because the sri pointers are not updated... I will add that in the next version, but for now that would be unsafe! Use vobblanker!!! :)
jeanl

[jsoto]

Last question: is it needed to remove the angles in all PGCs of the domain or of the whole DVD, or is it feasible on a per PGC or VTS basis? Per VTS. VobBlanker can currently skip a VTS (if it still has angles), but it cannot skip a PGC, it writes the whole VTS...

jsoto