VobBlanker 2.1.2.0 beta (now beta 13)

[jsoto]

beta4 link
http://forum.doom9.org/showthread.php?p=901980#post901980
beta5 link
http://forum.doom9.org/showthread.php?p=902056#post902056
beta6 link
http://forum.doom9.org/showthread.php?p=903080#post903080
beta7 link
http://forum.doom9.org/showthread.php?p=903536#post903536
beta8 link
http://forum.doom9.org/showthread.php?p=903803#post903803
beta10 link
http://forum.doom9.org/showthread.php?p=915433#post915433
beta12 link
http://forum.doom9.org/showthread.php?p=918451#post918451
beta13 link
http://forum.doom9.org/showthread.php?p=920788#post920788


New beta, please report back.. (I almost forgot how to program ;) )

VobBlanker_2120b1 (http://personales.ya.com/jsoto/tmp/VobBlanker_2120b1_exe.zip)


Added: One Sequence Title PGC checking
Improvement: TMAPTI is always created from scratch. Entries are created to all PGCs even the Non one-sequence-title-PGC ones, Only the ones shorter than one sec (usually dummies) will be empty.
Improvement: The messages detecting pointers mistmatch now show the detailed list of cells
Improvement: TMAPTI entries accuracy improvement.
Changed: VobBlanker asks for log file saving before closing the log window
BugFix: TMAPTI end byte was not always the last byte of last entry
BugFix: Deleting ADT & ADMAP menus tables in menus (when deleting all the cells) IFO was not compressed, and ADT & ADMAP title tables were not moved to previous sectors


jsoto

[laserfan]

Changed: VobBlanker asks for log file saving before closing the log windowThanks for this, I think tho that this is an Improvement! ;)

[BigCondor]

Hi, jsoto,
Thanks for your wonderful program, it helps us to solve many problems especially I like the feature of replacing titles.
Just some suggestions for your future release, can you save the locations of the input directory, output directory and other directory(most likely the one uses to replace) separately? It will help us to save some time each time we make some adjustments, thanks!

[kumi]

A BIG thanks for your TMAPTI fixes :thanks:

[Video Dude]

:thanks:

[blutach]

Let me add my thianks for all your great efforts jsoto!

Regards

[r0lZ]

Me too! Another battle won: TMAPTI!

[naiden_99]

Nice to see you're back. jsoto.

Thanks for this new version.

Saludos y gracias.

[movies27]

is there any fixes for the message "reached end of vob to early"?

[jsoto]

No....AFAIK, there is no bug in vobBlanker when this message pops up. The message is indicating a corrupt input material..

jsoto

[blutach]

Crash in new beta. Appears to happen when rebuilding time map. I was splitting a disk. The time map was in a not one seq title, if that helps (it, in fact, was the menu, consisting entirely of BOVs).

IFOs and project file sent to you jsoto.

Here's the errors:

http://img98.imageshack.us/img98/4667/11132006161420wv9.pnghttp://img98.imageshack.us/img98/623/11132006161427ej0.png

Most definitely, there are only 20 PGCs.

Regards

[jsoto]

The bug is because your original TMAPTI did not exist, and I removed the protection of VobBlanker (because VobBlanker now should be able to rebuild the table even in this case) w/o fixing completely this case.

(As you know) Fixed.


Most definitely, there are only 20 PGCs.
Ooops. IIRC I didn't fix this.

jsoto

[blutach]

No it still reports num PGCs incorrectly but fixes itself :)

Regards

[outsiders71]

Crash in new beta. Appears to happen when rebuilding time map. I was splitting a disk. The time map was in a not one seq title, if that helps (it, in fact, was the menu, consisting entirely of BOVs).

IFOs and project file sent to you jsoto.

Here's the errors:

http://img98.imageshack.us/img98/4667/11132006161420wv9.pnghttp://img98.imageshack.us/img98/623/11132006161427ej0.png

Most definitely, there are only 20 PGCs.

Regards

Came across this bug when trying to blank Hannibal.

[blutach]

jsoto is aware of this and it will be fixed in the next beta.

Regards

[jsoto]

VobBlanker_2120 beta4 (http://download.videohelp.com/jsoto/betas/VobBlanker_2120b4_exe.zip)

Changelog versus beta 1


Added: 32KB GAP: If configured, VobBlanker guarantees the gap creating (if needed) an empty menu of 32KB, made by one unreferenced blank cell and padding packs. This allows the user to burn with Nero using the 32KB gap trick
Added: Default folders configuration (output, input and auto-save)
Changed: VobBlanker automatically saves the log and project files if auto-save folder is configured.
Improvement: A big one: VobBlanker is almost three times faster when input and output folders are in the same hard drive. (i.e checking "Use Input folder")
BugFix: report of a wrong # of PGCs (TMAPTI) in log file
BugFix: crashes in beta 2


jsoto

[r0lZ]

Great!
Added: 32KB GAP:)
Improvement: A big one: VobBlanker is almost three times faster when input and output folders are in the same hard drive. (i.e checking "Use Input folder")How did you this magic!?

[jsoto]

32KB GAP: I know some of you don't like Nero, but there are many people used to it...

Speed increase:
VobBlanker was much more faster reading from one HDD and writing in other different HDD. It works reading one pack (2048 bytes) modifying if needed and writing the pack.
I perfectly know MS-windows is not too optimized in sharing accesses to HDD so what I did is to "write" the packs in memory in a big buffer ( 8 Mbytes ), and when the buffer is full, I write the whole big buffer in one shot.
In this way, VobBlanker reads pack by pack, and when it has 4000 packs in memory, writes 8 Mbytes of data.

I've did some tests and 8 MB is the optimum size (at least with my HDD)

jsoto

[Sir Didymus]

Improvement: A big one: VobBlanker is almost three times faster when input and output folders are in the same hard drive. (i.e checking "Use Input folder")



:scared:

I see no reasons to be so happy about this... I mean, as a consequence I am realising that all of the times I used this option (that was very frequent in my last two years of usage of VobBlanker) I spent (more or less) two third of my time for purposeless activities, right ?

...sigh...

;)

[jsoto]

You should send your complaints to Bill G. ;)

Can anybody check if the improvement is also so significant in Linux?.

jsoto

[blutach]

:scared:

I see no reasons to be so happy about this... I mean, as a consequence I am realising that all of the times I used this option (that was very frequent in my last two years of usage of VobBlanker) I spent (more or less) two third of my time for purposeless activities, right ?

...sigh...

;)No, SD! You got a chance to drink some much needed coffee!

Thank you jsoto! Testing now.

Regards

[bourtzovlakas]

I got a problem with beta4...
I ripped a movie with RipIt4Me 1.5.7.0, in Movie+Menus mode...
I processed the output with beta4, with "Create 32k gap" option on...
Other than that, default settings....

The output of VobBlanker is not acceptable in Shrink....

Attached is the logfile and screenshot from Shrink error...

[jsoto]

Sorry guys, I did not test deeply enough the speed improvement (I was testing in my disk #2 only with a small VOB of 0,5 GB).. Seems there are other important factors

These are the times I get fully processing one DVD-5 (keep mode):
disk#1: MAXTOR 6Y160P0 (PATA, 7200rpm 8 MB cache)
disk#2: SEAGATE 380021A (PATA, 7200rpm 2 MB cache)
RAM: 1GB

Note:O.S. installed in disk#1

Test 1a: From disk#1 to disk#1:
beta 1 5:10
beta 4 3:57
Test 1b: From disk#1 to disk#1:
beta 1 5:33
beta 4 4:10
Test 2: From disk#1 to disk#2:
beta 1 3:27
beta 4 4:18
Test 3: From disk#2 to disk#1
beta 1 5:25
beta 4 5:07
Test 4: From disk#2 to disk#2
beta 1 12:25
beta 4 5:51

So, in general, beta 4 is faster (although I have one case where it isn't ), but the effect is terrific in my last test (disk #2 to disk #2) using the older disk.

jsoto

[jsoto]

I processed the output with beta4, with "Create 32k gap" option on...
Other than that, default settings....

The output of VobBlanker is not acceptable in Shrink....

Attached is the logfile and screenshot from Shrink error...

True. I forgot to update the last pack pointer in the VOB...
The DVD can be played, because the cell is unreferenced, but the VOB is not correct, so shrink complains..
Quite similar to the new protection schemes...

jsoto.

[dirio49]

Also pgcedit complains

---------------------------
PgcEdit: Load NAV pack
---------------------------
Error loading NAV pack from
"E:\HARRY_POTTER_SORCERERS_STONE\VIDEO_TS\VTS_02_0.VOB"
at sector 5 (in file):
Nav Pack identifier not valid.
The VOB file *may* be CSS encoded:
You cannot edit a CSS encoded disc!
Or the VOB doesn't match the IFOs:
Try to do a mock strip with IfoEdit.

Skip remaining 'Bad Nav Pack' error messages
for the current domain?
---------------------------
Yes No
---------------------------

[jsoto]

But VobBlanker does not complain ;)

VobBlanker_2120 beta5 (http://download.videohelp.com/jsoto/betas/VobBlanker_2120b5_exe.zip) fixes the Nav pack

BTW, I'm not completely sure if the previous VOB was really a bad one. (just curious)
Say , the VOB is made of a blank cell of 5 packs, and 11 padding packs. In the nav pack (the 1st one), the last sector pointer of the VOBU was 4, meaning the padding packs are not part of the VOBU.
What dvdshrink and pgcedit were expecting is another nav in pack #6 (or the end of the file), but this pack is a padding one.

so the question is:
Can be padding packs which do not belong to any VOBU?

BTW, Nero complains if the last sector of last cell in VTSM_C_ADT table does not match with the VOB size, so it does not accept padding pads out of the last cell. But Nero is not a reference....


jsoto

[dirio49]

jsoto

Generated a TMAPTI table with same # of sectors than original

what does it mean?

Beta 5, works.
thanks for the quick fix.

[blutach]

Quite similar to the new protection schemes...

jsoto.
I hope SONY DADC do not hire you jsoto!!! :D :D :D

Regards

[outsiders71]

jsoto:

Thank you for giving us the freedom to modify our DVD backups as we see fit. Your program is seriously the best when it comes to DVD backup.

I wanted to request some suggestions for further builds:

1) It would be nice to be able to blank all selected VTS menu items in one click instead of having to go and individually remove them. So what I'm suggesting is in the right click menu could you add "Blank Menu Items" underneath Blank?

2) Final total file size of the project.

Thank you for reading.

[r0lZ]

so the question is:
Can be padding packs which do not belong to any VOBU?

BTW, Nero complains if the last sector of last cell in VTSM_C_ADT table does not match with the VOB size, so it does not accept padding pads out of the last cell. But Nero is not a reference....PgcEdit needs also a perfect match between VTSM_C_ADT and the VOB size, for some of its functions (involving the creation of a new VOB cell.) It's the simplest way to check if the VOB and IFO files are synchrinized. Of course, that doesn't mean that padding packs outside of any VOBU are illegal, but as I have never seen that in commercial DVDs and as Shrink complains, IMO, it is probably better to create an independent VOBU with the padding packs, or to include them in the first dummy VOBU.

Also, have a look here (http://forum.imgburn.com/index.php?showtopic=2627&st=0). 32K for the gap might be insufficient.

[blutach]

That link that r0lZ just provided is in the ImgBurn (www.imgburn.com) beta team members forum and most will not be able to access it. In it, I mused whether 32k gaps was sufficient.

My conclusion is that 32k is fine for the inner track (this is also bourne out here (http://forum.doom9.org/showthread.php?p=830613#post830613)). But I wonder if on the outer tracks, where almost 3 times more data is held than on the inner ones, whether 96k may not be the best (on the basis of getting maximum physical separation between the IFO and BUP in the case of a radial scratch).

As well the size of the IFO matters. For example, when a 32k gap is added to a VIDEO_TS.IFO of 36k, it would make the BUP exactly on the same place on the disk as VIDEO_TS.IFO, except 1 track out. We get the advantage of a different ECC block, but no physical separation. A radial scratch would make the BUP useless.

So, my thoughts are that to decrease risk, we need track separation as well as ECC separation (and physical separation if possible - ie, having the BUP on the other side of the disk). On this basis, I think something like a 256k gap might be useful. So, jsoto, I wonder whether the 32k in more settings can be user configurable (in lots of 32k to 256k)?

Regards

[r0lZ]

That link that r0lZ just provided is in the ImgBurn (www.imgburn.com) beta team members forum and most will not be able to access it.Oh, yes, I forgot that. Sorry guys!
But blu has brilliantly resumed the thread.

[jsoto]

On this basis, I think something like a 256k gap might be useful. So, jsoto, I wonder whether the 32k in more settings can be user configurable (in lots of 32k to 256k)?
I can do it, but ..how a normal user can select the value? Even more, if as you say, the best value depends on IFO size and the physical position of the IFO, the best option should be to include an algorithm in the code. But this is not easy to me, I do not know the final IFO size (it is still not created) when VobBlanker creates the unreferenced menu.
May be the best practice to protect the ifos is to do a zip (or a new folder) with all of them (including BUPs if you want) and store the file/s as normal file/s in other folder of the DVD. The player will be unable to play from them, but you'll be able to recover the DVD and burn it again.
Using the 32KB (or improved) trick, you'll be aware about the scratch/s when the player cannot play, meaning both, IFO and BUP, are corrupted, so the DVD can not be easily recovered. Storing the IFOs as regular files in other folder, you'll have another chance, even if the settop does not play.

jsoto

[jsoto]

jsoto:
1) It would be nice to be able to blank all selected VTS menu items in one click instead of having to go and individually remove them. So what I'm suggesting is in the right click menu could you add "Blank Menu Items" underneath Blank?

You can do it using multiple selection. Can't you?

Also, there are some shortcuts in the main menu:
Menus-->Blank transition PGCs
Menus-->Delete transition PGCs

Note: Transition PGC means a PGC w/o buttons

jsoto
2) Final total file size of the project.

It is already there....
VobBlanker shows in size box:
Initial : The initial size of the DVD
Final: The final size of the DVD
Process: The amount of MB to be processed.

jsoto

[jsoto]

jsoto

Generated a TMAPTI table with same # of sectors than original

what does it mean?

Beta 5, works.
thanks for the quick fix.

Don't worry about this. It is just a trace, useful for debugging.

From 2.1.2, TMAPTI is built from scratch, and its final size (also, in sectors) could be larger or shorter than the original one. If the final # of sectors is different from the original IFO, the IFO has to be compressed or enlarged, "moving" inside the IFO the following tables: VTSM_C_ADT, VTSM_VOBU_ADMAP, VTS_C_ADT and VTS_VOBU_ADMAP.

There is a minor bug in beta5 (caused by the addition of the default folders...)
Output folder is not recovered from a project file. Fixed in next beta

jsoto

[blutach]

@jsoto - re gaps

My first thoughts were also that it would be very messy - what would be the correct size of the dummy VOB compared to where it is on the disk? So, my thoughts drifted to dividing the DVD up into 3 zones - an inner (32k), middle (64k) and outer (96k). My calcs show that this should work well for getting the IFO and BUP located roughly opposite each other in the inner and outer zone, but I am not at all sure for the middle. I need to do some more work on this and get back to you.

That is why I have thought that if you can't for sure get the files away from each other and avoid a radial scratch, then maybe do what the studios do - increase the size of the dummy menu and at least give separation by a number of tracks.

Regards

[Drinken]

To increase the chances of a sucessful restore of the dvd in case of scratches/rot I would use dvdisaster (http://www.dvdisaster.com/) and create ECC files which can be stored on some other kind of media.

[Sir Didymus]

My conclusion is that 32k is fine for the inner track (this is also bourne out here (http://forum.doom9.org/showthread.php?p=830613#post830613)). But I wonder if on the outer tracks, where almost 3 times more data is held than on the inner ones, whether 96k may not be the best (on the basis of getting maximum physical separation between the IFO and BUP in the case of a radial scratch).


I don't know if it could turn out as useful for the discussion, but some times ago I wrote a little xls table where it is described an analitical solution to find the position (distance in mm from the center of the DVD and angular remainder - e.g. the angular displacement, in radiants) of a given data item in a single side DVD. Here it is:

http://www.sendspace.com/file/0bjnur
Edit - updated the link. Two xls sheet are present in the archive, one for SL and one for DL...

The extension of the formulas to DVD +R DL is not immediate (but also it is not exaggerately complex): apart the channel bit lenght, changing from 0,0001333 mm. to 0,0001467 mm., the most important factor is that it should be introduced the discontinuity of the layer change at the layer break position, changing the main equation adopted:

Ro = R1 + (Teta * Track Pitch) / (2 * pi)

Which is used for the first layer, where R1 is the minimum radius of the data area, i.e. 24 mm., to a new one:

Ro = R2 - (Teta * Track Pitch) / (2 * pi)

That start being valid immediately after the layer break transition, arising when the level of the data area is at the radius R2...

Cheers,
SD

Edit: Just to raise interest to this xls sheet, using it, it can easily be observed that 32K of data, are corresponding to 3,43 radiants (...you know, half a turn is 3,141592...) at the inner part of the DVD and to 1,45 radiants at the outmost side...

Edit2: Changed slightly the above formulas, to improve readability;
In addition, from the same worksheet, it is also easy to observe that:

--> 59 KB of data is the track lenght in the inner radius (24 mm of radius from the disc center); the storage of half track is 29 KB
--> 142 KB of data is the track lenght in the outern radius (58 mm); half track takes 71 KB

These values are exactely in the same order of magnitude of average IFO files...

I mean, << hei blu, respectfully speaking... :-) >>, I am not completely convinced of the concept of making a better separation of the data in a disc, other than by placing them in a different ECC block of 32K, through the calculation of the gap size generating 3,14 radiants of displacement respect to the IFO file...

This concept would assume that the whole size of an IFO file takes less than a half a track in the disk, that - most time - does not apply, and - some times - could sadly have the effect of making the BUP file nearer to the radially scratched area...

Most probably, the concept of providing a significant track separation between IFO and BUP is the safest one, but it's not evident how many tracks of separation should be ensured in order to improve reliability - after all 256K gap is providing just four tracks of separation in the inner radius, and only one in the outern...

Edit3:

May be the best practice to protect the ifos is to do a zip (or a new folder) with all of them (including BUPs if you want) and store the file/s as normal file/s in other folder of the DVD.

Fully agreed... This would provide the maximum track separation, since in the UDF file system these contents would be placed at the end of the data area, after the VIDEO_TS content... However, if the (single side) disc is quite full, this will place the zip folder in the outern part of the disc, which is sometimes reported as being the most affected by reading troubles. For DVD9 that should be OK, but I would prefere <<hem... take care, I am not speaking serously...>> not zipping the files - or better zipping them separately, one by one - and placing these zipped backups, separated by 32K gaps, alternating IFO and BUP... :cool:

[jsoto]

32Kgaps
I've seen I didn't take into account the titles VOB size, so VobBlanker is creating the unreferenced menu even if the main VOBs are enough to guarantee the 32K gap...

I think I'm going to change how and when the gaps are created in VobBlanker, to be able to know the final sizes of the files involved in order to have a better control of the process.

jsoto

[techmule]

Is the split Cell feature stable now!!!

I know it was released earlier, but just wondering ???

[jsoto]

@techmule
It was stable in release 2.1.1. I didn't test it in 2.1.2, but I didn't touch this part of the code...
May be I broke something unintentionally?

jsoto

[Robotik]

jsoto,

let me point out first how your program (along with MenuShrink & PgcEdit) gave me creative freedom with backing up dvds. now i can almost completely re-author dvds using these very programs, so thank you for that.

as for a suggestion/request: every now and then i come across titles that need re-chaptering (sometimes a whole movie comes in one cell!). i use VobBlanker to split the cell and split the resuting cells again and again until i have the desired number of cells, which is quite time consuming.
is it possible to include splitting cells to multiple parts? it would be a really useful feature.

thanks a lot,
robotik

[blutach]

@Robotik - consider ChapterEdit

http://www.digital-digest.com/~blutach/ChapterEdit.zip

Regards

[alxtorrentazos]

Is the split Cell feature stable now!!!

I know it was released earlier, but just wondering ???

Sorry techmule, but splinter cell:double agent isn´t stable yet , even with the latest patch from ubisoft 1.01 :p
BTW, u all are talking basic chinese for me, but, I want to say a big THANKYOU to jsoto for your great work :D
Alx

PS, sorry about the bad joke ;)

[bigotti5]

@blutach

Would not consider Chapteredit for PAL DVDs.
It creates incorrect entries for BCD (Cell elapsed time, 0x45 in each NAV pack) in VOB and VTS_PGCITI based on 30 fps.

[windyfir]

How do you use Vobblanker to make multiple cuts in one processing. I have been cutting 5 minute commercials out of TV movies (cut: end of one cell, blank 5 cells, and start of last cell) and would like to take out five or six groups like this in a single pass. I have been doing this in the pre/cut window.

[outsiders71]

You can do it using multiple selection. Can't you?

Also, there are some shortcuts in the main menu:
Menus-->Blank transition PGCs
Menus-->Delete transition PGCs

Note: Transition PGC means a PGC w/o buttons


Both options apply to EVERYTHING. I was talking about removing the SELECTED.


It is already there....
VobBlanker shows in size box:
Initial : The initial size of the DVD
Final: The final size of the DVD
Process: The amount of MB to be processed.

jsoto

Oh wow...I've never seen that box! I just found it now LOL. Sorry about that!

[jsoto]

How do you use Vobblanker to make multiple cuts in one processing.
You have to process by Cell, not by PGC.
Double click on the PGC and the cell list will open. Select a cell and blank or cut it. Only one cut per cell is allowed


Both options apply to EVERYTHING. I was talking about removing the SELECTED.

You can do a multiple selection in Titleset list. Just use the usual Windows way: control+click for one additional item or shift+click for "select until here"). After, right click and , in the popup menu, select "blank". May be this is not what you're asking for?
jsoto

[canuckerfan]

when a scene is snipped short in vobblanker, is the audio removed as well?

[jsoto]

when a scene is snipped short in vobblanker, is the audio removed as well? Do you mean converted to still or cut?
VobBlanker can convert to still with audio or without audio. When cutting cells, the audio is also cut more or less in the same amount (it is done in a brute way, GOP by GOP).
jsoto

[jsoto]

I didn't see the edits of Sir Didymus until now, but it is too late :p :p


This concept would assume that the whole size of an IFO file takes less than a half a track in the disk, that - most time - does not apply, and - some times - could sadly have the effect of making the BUP file nearer to the radially scratched area...

I disagree. When you really need the physical separation, it is because the titles are very short (or inexistent, like in VIDEO_TS) and also you do not have menus or they are too small. That means a very small IFO (8, 10 or 12KB) much more smaller than the 29KB of a 1/2 turn

So...
VobBlanker now has a smart GAP creation feature..
Using Sir Didymus formula (currently only for DVD-5) VobBlanker calculates the position of the IFO in the DVD and adjusts the start of the BUP just (n+1/2) turns, and also guarantees 32 KB minimum

Say a VIDEO_TS.IFO of 8KB (to be converted to 12 KB after the processing)
The optimum size of the menu is 29KB -12KB = 15KB, but adding one turn to be more than 32 KB
15KB+59KB= 74KB.

VobBlanker_2120b6_exe.zip (http://download.videohelp.com/jsoto/betas/VobBlanker_2120b6_exe.zip)

Added: Smart GAPs between IFOs and BUPs
Added: VobBlanker can adjust sectors without processing the DVD.

jsoto
PS: Be careful, I've changed a lot of code yesterday too late at night....

EDIT: Nobody complains!! 29-12=15. I've to return to school....

[Robotik]

@Robotik - consider ChapterEdit

http://www.digital-digest.com/~blutach/ChapterEdit.zip

Regards

thanks, Blutach, i know chapteredit, and sorry to say this, but it's not my favourite tool.

thanks anyway

[blutach]

@Robotik and bigotti5 - Thanks for the info - will take account of that.

@jsoto - thanks for smart menu size! Will test when I have some time.

@SD - sorry not to have responded - will get back ASAP but I think we are all getting onto the one page anyway.

Regards

[zacoz]

Added: Smart GAPs between IFOs and BUPs
Added: VobBlanker can adjust sectors without processing the DVD.
Thanks for the recent work on one of my favourite DVD tools jsoto. (Even though I've been letting all my DVD tools collect dust lately :o ).

Was unsure whether to ask here or in DVD-RB forum, but am I right in thinking that the method used to add the Smart GAPs would be erased by processing through DVD-RB Pro.

I currently tend to follow the path of DVD Decrypter --> PgcEdit --> VobBlanker --> DVD Rebuilder Pro --> PgcEdit (for 32K gap and ISO generation) --> Imgburn.

[Sir Didymus]

I didn't see the edits of Sir Didymus until now, but it is too late

That's good... LOL, It means that you did not get all of the added bla, bla, just focusing on the useful content, i.e. the xls table...


I disagree. When you really need the physical separation, it is because the titles are very short (or inexistent, like in VIDEO_TS) and also you do not have menus or they are too small. That means a very small IFO (8, 10 or 12KB) much more smaller than the 29KB of a 1/2 turn...

You made a point, which is absolutely convincing; I missed it...
So, let me retract my objection, & thanks for the clarification!
@blutach: OK --> you are right!


VobBlanker now has a smart GAP creation feature...

There are some considerations to make in order to extend the GAP creation feature to DVD DL:
1. First of all you have to know in advance, in the VobBlanker session, if your final project is going to be burned as a DVD-SL or as a DVD-DL. That's normally not known in advance, since only the user knows what is the final target for the VobBlanker project.
2. In case of a DVD DL, you need to know in advance the position of the Layer Break transition. Is there any manner to know precisely this information ?
3. Maybe the easier way to cope with DL is to consider the layer change as a "strong" discontinuity... I mean, I know that four ECC blocks are added to allow for some refocusing and resynching time at the layer change, but I don't know if it is proper to assume this linear distance as the single parameter involved to physically link data between L0 and L1. Assuming not to know precisely this parameter have the advantage of making very simple the formulas, but imposes the constraint of assuming totally unrelated the positions of the data of L0 respect to the data of L1. That means, for example that both IFO and BUP of the same VTS should not be on different layers. I think it's acceptable, but it should be taken into accont... Do you agree ?

Under this assumptions, if I am not wrong, the calculations for a DL should be something like (putting it in this form, instead of a xls sheet, for an easier eventual future reference...):


#define channel_bit_lenght_DL_mm 0.0001467
#define pi_grec 3.14159265358979
#define track_pitch_mm 0.00074
#define min_radius_data_area_mm 24

double user_data_size_MB;
double layer_break_transition_MB;
double layer_break_transition_mm;
double user_data_size_bit;
double recording_size_bit;
double linear_size_mm;
double a, b, c, delta;

double teta_rad;
long track_nr;
double ro;
double ang_rem_rad;

sample_formula_for_locating_a_data_item_on_a_DL_disc() {

// input user_data_size_MB;
// input layer_break_transition_MB;

// in case user_data is in L1, the formula is used twice
// first for finding the layer_break_transition in mm.
// then for finding the final radius and angle...

if (user_data_size_MB < layer_break_transition_MB) {
user_data_size_bit = user_data_size_MB*1024*1024*8;
} else {
user_data_size_bit = layer_break_transition_MB*1024*1024*8;
}

recording_size_bit = user_data_size_bit*1209/512;
linear_size_mm = recording_size_bit * channel_bit_lenght_DL_mm;

a = track_pitch_mm / (4 * pi_grec);
b = min_radius_area_data_mm;
c = -linear_size_mm;
delta = sqrt (b*b -4*(a*c));

teta_rad = (-b + delta)/(2 * a);
track_nr = int(teta_rad/(2*pi_grec));

ro = min_radius_data_mm + (teta_rad * track_pitch_mm) / (2 * pi_grec);
ang_rem_rad = teta_rad - track_nr* (2 * pi_grec);

if (user_data_size_MB >= layer_break_transition_MB) {
layer_break_transition_mm = ro;
user_data_size_bit = (user_data_size_MB-layer_break_transition_MB)*1024*1024*8;

recording_size_bit = user_data_size_bit*1209/512;
linear_size_mm = recording_size_bit * channel_bit_lenght_DL_mm;

a = -1 * track_pitch_mm / (4 * pi_grec);
b = layer_break_transition_mm;
c = -linear_size_mm;
delta = sqrt (b*b -4*(a*c));

teta_rad = (-b + delta)/(2 * a);
track_nr = int(teta_rad/(2*pi_grec));

ro = layer_break_transition_mm - (teta_rad * track_pitch_mm) / (2 * pi_grec);
ang_rem_rad = teta_rad - track_nr* (2 * pi_grec);
}

// output ro and ang_rem_rad;

}

// The math on the basis of the formula:

// When user_data_size_MB is 0, this is corresponding to the minimum radius of 24 mm., and the resulting teta_rad is = 0.
// For DL discs, user_data_size_MB max for any L0 or L1 = 4075, corresponding to the maximum radius of 58 mm.,
// teta_rad = 288657, turning outwards for 45960 turns...
// 1. user_data_size_bit, recording_size_bit and linear_size_mm are calculated starting from the input value
// (user_data_size_MB); for DL discs, also the layer break position, in MB should be known in advance...
// 2. In the calculation following constant values are used: min_radius_area_data_mm, pi_grec, track_pitch_mm,
// channel_bit_length_mm
// 3. The math used for the calculation uses the formula (for L0): Ro = R1 + (Teta * Track Pitch) / (2 * pi)
// defining the distance from the center (Ro) corresponding to a given angular value, in radiants (Teta);
// integrating respect to Teta, we get the formula expressing the length of a segment of the data area (Linear Size)
// as a function of Teta:
// Linear Size = Teta * R1 + (Teta*Teta*Track Pitch / (4 * pi))
// 4. The formula used for L1 is: Ro = R2 - (Teta * Track Pitch) / (2 * pi), where R2 is the radius, in mm,
// corresponding to the layer change; in this case the equation to solve is:
// Linear Size = Teta * R2 - (Teta*Teta*Track Pitch / (4 * pi))
// 5. A, B, C e delta are the positions to solve the corresponding second degree equation(s): A x*x + B x + C = 0
// 6. Of the two possible solutions of this second degree equation, the negative one is always (obviously) discarded.
// 7. The position --> recording_size_bit = user_data_size_bit*1209/512, is quite synthetic and nice,
// involving physical parameters of the DVD structure...


Nice to observe that, due to the different channel bit length respect to SL, for DL discs
// 54 KB of data is the track lenght in the inner radius (24 mm)
// 129 KB of data is the track lenght in the outern radius (58 mm)

Cheers,
SD

Edit
Promised...
I wont edit it any more...
You will live with my poor English and lack of synthesis... ;)

[r0lZ]

That means, for example that both IFO and BUP of the same VTS should not be on different layers. I think it's acceptable, but it should be taken into accont... Do you agree ?
Impossible, as the IFO must be before the VOB files, and the BUP after, and the LB will probably be somewhere inside the VOB files. However, it should be possible to place the LB between 2 titlesets in very rare occasions.

[Sir Didymus]

OK. You don't agree... :(

In this case I need some clarification about about what is physically happening at the layer break transition: do you know if the distance of four ECC blocks is a constant ? I mean, do you know what is the physical linear distance between the last byte of L0 and the first byte of L1 ?

4 ECC blocks are 128KB, corresponding, for example, at the outern radius, just a little bit less than a complete turn. Can we assume this as a reference paramenter ?

[blutach]

@SD et al - I use the following forumlas for calculating linear bit density:

DVD5 - 3,750 bits per mm (0.2667 micrometres data bit length)
DVD9 - 3,400 bits per mm (0.2934 micrometres data bit length)

(These numbers are consitent with Taylor who says there are 2,800 bytes in 6mm of a DVD5).

The rest is 2 x pi x r, and using the inside track starting from 48mm, it is of circumference 150.8mm = 69kb of user data.

The outside track is at 116mm, and holds 167kb of data.

These numbers differ from yours SD.

Regards

[mpucoder]

You could go crazy with this.
Isn't the bit density different on the 2 layers?
What about the case where the bup and ifo are at the same radius and angle, but different layers - a scratch could render both unrecoverable

[Sir Didymus]

Hei Blu! Ciao!

Well, no...
Yours (and Taylor) numbers appear as different...
But they are the same...
Considering the 2:1 recording modulation, the channel lenghts I used in the formulas are exactely the same as your references. Also the diameters you are reporting (48 mm and 116 mm) are the same than saying that the inner radius is 24 mm and the outern is 58...

Since the rest is 2 * pi, the size differences you notice should necessarily be related to the kbits and KB... IMHO...

Edit OK. I did not resist to edit this one...

:p

Especially taking the nice opportunity that in Australia people at this time is supposed to sleep...

:o

I think I found the mistake in your data: it's not related to kbits and KB...

It is that (contrarily to what you say), the values you obtain are based on physical recording capacities, not taking into account the mapping between user data and physical data. If you include the additional data to store in the disc, i.e. sector ID and ID error detection (at sector level) and the ECC error correction codes (at ECC block level), your values should be reduced by the factor 4836/(2048*4) making them matching with mine... Note that in my xls sheet this factor is shortened in the factor 1209/512, to take into account the 8:16 EFMPlus modulation...

[Sir Didymus]

You could go crazy with this.
Isn't the bit density different on the 2 layers?
What about the case where the bup and ifo are at the same radius and angle, but different layers - a scratch could render both unrecoverable

Hi!

Why the linear bit density should be different on the 2 layers ?
The bit channel length is referred as being the same in the (few) reference I have...

The point of ifo and bup at the different layers is exactely the question raised by r0lz...

If there is a way to know the physical distance from the last byte of L0 and the first byte of L1, then also this situation can be faced... Otherwise we are forced to apply (if useful) any model we build up to the two layers separately, without applying any "geometrical" protection to the single IFO and BUP of the VTS where the LB transition arise. But all of other IFOs and BUPs can still be protected...

[mpucoder]

I was just asking, not up on this. I do know that scratches are unlikely to render two blocks unrecoverable unless the scratch is severe, in which case probably lots of blocks are unrecoverable. The damage that I've seen seems to be either minor or severe with no middle ground. People either treat the disks properly and have a minor accident, or they use them as frisbees.

ifo and bup on different layers is common, many movies have the layer break within the movie itself, which means the ifo is on layer 0 and the bup is on layer 1. What I was asking about is having them at the same physical location so that damage would possibly render both layers unrecoverable at that spot.

But is it worth going crazy about? how much improvement in recovering from real-life damage will there be?

[Sir Didymus]

Infact. No objection from my side to use the common sense and to comply with the practical experience.

I am even more radical on this: personally I am convinced that in order to provoke readability troubles, scratches should be very sharp, and that most probably the whole topic of the disc cleaning and protection is someway overshoot. After all, the laser beam diameter, at the disc surface is ~ 1 mm., being focused ~ 0.5 mm below. So I think the probability that any "small" defect at the surface level can provoke readability troubles is in general very little...

IMHO when you protect discs from temperature, humidity, light and dust, the care is complete...

However, since I did the original calculations for opposite purposes (the initial idea was to intentionally create a radial damage to a disc, in a specific position of the DVD, authored with an unreferenced VTS, mimiking some "oriental" protections :cool: ) I thought it was nice to give a contribution, with the theory already cooked...

All the best,

;)

[jsoto]

I currently tend to follow the path of DVD Decrypter --> PgcEdit --> VobBlanker --> DVD Rebuilder Pro --> PgcEdit (for 32K gap and ISO generation) --> Imgburn.
That is why I've added the ability to adjust sectors (with or without smart GAP creation) without processing the DVD in VobBlanker (just like pgcEdit or IFOedit does). Note the sectors adjustments without smart GAP creations, also checks if the menu is unreferenced and if it is the case, deletes the menu.

1. First of all you have to know in advance, in the VobBlanker session, if your final project is going to be burned as a DVD-SL or as a DVD-DL. That's normally not known in advance, since only the user knows what is the final target for the VobBlanker project. Previous answer applies.


In any case, I've to confess I'm not too convinced about this feature, and I really coded it for fun, and also to improve how some things related with sectors adjustments are done internally in VobBlanker. Now, I can code any kind of algorithm you want very easy, I have under control all the parameters like IFO size VOB size, etc.

But dual layer..., the probability to have the BUP and IFO exactly in the same position and different layer is very very low... in fact, it is 2*IFO_size/4,2GB, so we're talking about something less than 10e-4 (so, you have to be worried if you have 10.000 DVDs :p )


jsoto

[r0lZ]

I agree. The discussion about gaps becomes more and more theoretical, and I guess of little practical use!

[blutach]

@mpucoder - I think the discussion is more relevant to SL, as we tend to burn dual layer disks with the files intact (I say tend to).

@SD - I considered this myself (about 8/16 and headers, sync bytes, ECC sectors etc - and yes, it was late :D), and am not sure I agree. On that basis, my numbers are out by a factor of 2.4x (=1209/512 as you say).

I also agree totally with what mpucoder says about handling your disks properly. A scratch that makes the IFO bad is likely to make the video bad too (so you may not wanna keep it anyway). AND this is a backup - if you screw up, make another (unless it is original footage, in which case, you should have a few backups). As well, there is also marsoupilami's ISOPuzzle for data recovery.

Regards

[jsoto]

VobBlanker_2120b7_exe.zip (http://download.videohelp.com/jsoto/betas/VobBlanker_2120b7_exe.zip)

BugFix: Blank cell in GAPs was corrupted
BugFix: Adjusting sectors in input folder with a VTS selected failed (The menu was opened by tiny, and failed to be deleted/moved).

Sorry, I should test the betas better...cell corruption was really an ugly bug

jsoto

[setarip_old]

The recent posts to this thread, regarding gaps and their theoretical importance seem to be a rehash of the many of the postings in this thread:

http://forum.doom9.org/showthread.php?p=597833#post597833

Unless I'm misunderstanding the post, it appears that "r0lZ" now shares my previously stated opinion (in the thread I've referenced, as well as an earlier thread) by stating:I agree. The discussion about gaps becomes more and more theoretical, and I guess of little practical use!

[kumi]

I find those cheap resurfacing gizmos do a fantastic job at curing physical surface scratches.

[r0lZ]

Unless I'm misunderstanding the post, it appears that "r0lZ" now shares my previously stated opinion (in the thread I've referenced, as well as an earlier thread) ...
I agree only partially. The 32K gaps are really a very useful improvement, as many read errors are caused by extremely tiny scratches or media defects, and that can be successfully recovered by the players by using the BUP instead of the IFO. After all, it's why there are BUPs on the DVD, right? Putting the IFO and BUP in the same ECC block is therefore a stupidity.

However, if you use your DVD as a Frisbee, or if you burn it with a cigarette, the gaps are certainly not sufficient to guarantee that you will recover the data. And calculating the position of the IFO and BUP on both layers of a DL so that they are not at the same place is certainly an exaggeration. As Jsoto said, this case will certainly be extremely rare. And it's on that idea that I agree. On the other hand, when VIDEO_TS.VOB doesn't exists and the 32K gaps technique is not used, the VIDEO_TS.IFO and BUP files will almost certainly share the same ECC block, and any little defect will totally ruin your backup, That's unacceptable. If those files can be even more protected by enlarging the gaps, that's certainly a good thing.

[Sir Didymus]

The recent posts to this thread, regarding gaps and their theoretical importance seem to be a rehash of the many of the postings in this thread:

http://forum.doom9.org/showthread.php?p=597833#post597833


I hope you are not including my posts among the "rehashed" ones...

I can guarantee that the underlying math, method and formulas I used are original - AFAIK.

Concerning the relevance and the usage you make of the theory - that's up to you: if you think it may be useful to precisely locate a given data item on a radial and (relative) angular position in a DVD-VIDEO, for whatever purpose you like, you are free to use it, if you don't think so, don't use it...

Bye,
SD

Edit @r0lz - I don't want to appear as a "theoretic" person. The approach I tend to use is always practical, whenever possible.

Said this, first you say the theoretical discussion is becoming of little practical use, then you say:

If those files can be even more protected by enlarging the gaps, that's certainly a good thing.


Please take what I say in a totally friendly and respectful manner, but there is no way to enlarge the gaps if you don't know how to enlarge them... Am I wrong ?

[blutach]

I think its fair to say that we here at Doom9 very much enjoy theoretical discussions that hopefully result in practical outcomes.

Maybe this is more so for us here in IFO/VOB Editors for we are blessed with an incredible talent pool, many of whom like to push the boundaries.

Regards

[r0lZ]

Please take what I say in a totally friendly and respectful manner, but there is no way to enlarge the gaps if you don't know how to enlarge them... Am I wrong ?
No, you're right. I think only that pushing the limits too far is probably useless. For example, trying to avoid putting the IFO and BUP on the two layers of a DL DVD so that they are not at the same place is almost useless, as this situation will probably never happen naturally, unless you make a special DVD just to test that!

Anyway, like blutach, I like those theoretic discussion very much. It's how we learn, thanks to this wonderful forum.

[blutach]

@jsoto

Sad to say, there is a bug somewhere in Beta 7. I ran a DVD thru it, with the new auto gaps on. Menus were made, but the project won't load in DVD Shrink (Programming Error - Exception Occurred) although it loads fine in DVD Remake Pro (http://www.dimadsoft.com/dvdremakepro/index.php).

As DVD Shrink loads all the VTSs OK, I think it must be VIDEO_TS.IFO. However, the Verifier doesn't give any real errors. I'll email you the before and after IFOs of my home made test DVD.

The only thing I can see is the last sector before the stuffing packs are not of full length (0x01d6 instead of 0x07ec)

Regards

[Sir Didymus]

...For example, trying to avoid putting the IFO and BUP on the two layers of a DL DVD so that they are not at the same place is almost useless...


That's totally agreed, and hem... [I did some further enlightening reading on the matter :scared: ] is most probably impossible to obtain...
;)

Into these nice lectures [...well really boring commands & format specifications...] it is also guaranteed that the radial position of the last ECC block of L0 is the same of the first ECC block of L1. This means that, apart the xls sheet, whose information and applicability to SL discs is double checked and verified, also what I posted regarding DL should work...

In other terms, you can - if you want, obtain any relative angular displacements between IFOs and BUPs in the two separate layers L0 and L1, but you can say nothing about the angular displacements if the two files belong one to L0 and the other to L1. Only radial positions can be evaluated in this case...


Anyway, like blutach, I like those theoretic discussion very much. It's how we learn, thanks to this wonderful forum.

Cool! For a moment I had the feeling to be left alone among the ones liking theory... And this forum is really amazing...
Cheers,
SD

[zacoz]

Cool! For a moment I had the feeling to be left alone among the ones liking theory...
From someone who understands just a minute fraction of the theory discussion that gets going from time to time - keep it up. While most of it goes over my head, the little snippets that that do make sense to me have helped me learn more and try out different things from a users perspective that I otherwise would not have.
And this forum is really amazing...SD :goodpost: I am continually amazed at how knowledgeable, humble and helpful everyone here is.

[blutach]

@zac - it's hard to humble after the start to the 1st Test, mate :D

(sorry for being so OT)

Regards

[jsoto]

The only thing I can see is the last sector before the stuffing packs are not of full length (0x01d6 instead of 0x07ec)

That's correct. The blank cell is made of 5 sectors, the last one not completed, and it is filled with a padding stream. Rest of the packets are only padding streams, no info at all on them.
May be VIDEO_TS.IFO is corrupted...
Anyway, if VIDEO_TS.VOB and VTS_xx_0.VOB are not too large, please send them to me.
No need the files. I'm able to reproduce the problem

jsoto

[jsoto]

Sad to say, there is a bug somewhere in Beta 7. I ran a DVD thru it, with the new auto gaps on. Menus were made, but the project won't load in DVD Shrink (Programming Error - Exception Occurred) although it loads fine in DVD Remake Pro (http://www.dimadsoft.com/dvdremakepro/index.php).

As DVD Shrink loads all the VTSs OK, I think it must be VIDEO_TS.IFO. However, the Verifier doesn't give any real errors. I'll email you the before and after IFOs of my home made test DVD.

The only thing I can see is the last sector before the stuffing packs are not of full length (0x01d6 instead of 0x07ec)

Regards
When loading a single VTS in DVDShrink, it loads the title domain but not the menu domain, so loading a VTS in shrink does not guarantee a good menu.

But seems to me the issue is in shrink, not in VobBlanker (however, I'll change it...). Please do the following test and let me know:
- Open the DVD in pgcedit
- Create a new menu (empty) on each VTS (in your IFOs, not needed in Video Manager, it already has PGCs in menu domain)

You can do the dummy PGCs creation in pgcEdit after or before running VobBlanker's smart GAPs creation, it should be the same.

If, after that, the DVD is correctly loaded by shrink, means shrink does not like unreferenced menus w/o a PGC in menu domain (even a dummy one). In other words, if there is a menu file, shrink needs a VTSM_PGCI_UT table.

Could you confirm my hypothesis? (It works to me using your IFOs with blanked title VOBs)

AFAIK this restriction does not exist in the standard, but you never know...

jsoto

[blutach]

Will do and revert jsoto. May be a bit busy today but will get back to you :)

Regards

[jsoto]

I've done some tests again and my conclusion is:
If there is a menu file, shrink needs a VTSM_PGCI_UT table.
The table can be completely empty (even w/o PGCs), but the pointer to the table (offset 0xd0 in a VTS IFO) cannot be zero

Mmm... I'm not so sure this table is optional... may be your IFOs are not fully according the standard...

jsoto

[blutach]

I've done some and this is a solution:

Make it completely unreferenced. Zero out 0xc0, d8 and dc of VMGM/VTSI_MAT. It loads fine then (IFO sizes need altering, but maybe easiest is to just never put these tables in to begin with - just use the VOBs as "filler").

In fact, it loads fine wqith just 0xd8 and dc zeroed out.

Regards

[jsoto]

But Nero complains... (curious, pgcEdit doesn't complain, seems, because the VTSM_C_ADT is empty, menu VOB is not scaned)

Try VobBlanker_2120b8_exe.zip (http://download.videohelp.com/jsoto/betas/VobBlanker_2120b8_exe.zip)

It creates the table (with "0" LUs ) but it should work

jsoto

[Robotik]

hi,

sorry to bother you with requests, when you are busy with debugging, but is it possible to have sound in cut / split preview? it would help a lot with finding the best position to cut / split.
even if it is too messy to add something like a button / menu to choose from the available streams, just enabling the first available sound would be better than none

thanks in advance and best regards,
robotik

[Sir Didymus]

I've done some tests again and my conclusion is:
If there is a menu file, shrink needs a VTSM_PGCI_UT table.
The table can be completely empty (even w/o PGCs), but the pointer to the table (offset 0xd0 in a VTS IFO) cannot be zero

Mmm... I'm not so sure this table is optional... may be your IFOs are not fully according the standard...

jsoto

According to the Philips Verifier (if you thrust on what it reports... :p ), if the VOB menu is present also the VTSM_PGCI_UT table should exist... In case it is missed the reported error is:

>>> [DVD] ERROR 4214 (ref. DVD-3 4.2.1 / BP 200):
ERR_DVD_VTS_NO_VTSM_PGCI_UT
When Menu-VOBS exist, VTSM_PGCI_UT should exist as well.
(VTSM_PGCI_UT_SA>0).

Beta 8 fixes it...
Taking the opportunity to thank you for your work on VobBlanker (in general) and on release 2120 specially...
;)

[blutach]

I confirm Beta 8 made a VIDEO_TS.VOB (72kb unreferenced), which loaded into DVD Shrink and DVDRMP without issue.

Have not calculated whether 72k is "correct" but we can discuss your algorithm later.

Thank you jsoto!

Regards

[Sir Didymus]

...Have not calculated whether 72k is "correct" but we can discuss your algorithm later...

It will be a pleasure... :)

In the meanwhile... I have some nice argument in favour of the algorithm... One is the following: as you can see playing a little bit with the xls sheet, it starts from 24 mm. (of radial distance from the center of the DVD) accumulating MB, in a "blind" manner around the disc, with the single constraint that the tracks are spaced by 0,74 micrometers. If you enter in the table the value of 4482MB, which is the max size for a DVD-5, you obtain that after 11 kilometers and 834 meters of travel, you arrive exactely (well, almost exactely...) at the radius of 58 mm., which is the limit of the data area for DVDs...

[blutach]

@SD - Maybe I am blind and have had more than one glass too many but please direct me to the "XL Sheet".

And I agreee - the data area is from 48-116 diameter - that is the spec.

With thanks.

EDIT: Finally found it on page 1, not to worry. Confirms drinking habits of downunder DVD'ers. :D

Regards

[jsoto]

@blutach
This is the algo:
If VIDEO_TS.IFO final size is 16 KB after the processing...
The optimum size of the gap is 29KB -16KB = 13KB, so the starting point of both files (IFO & BUP) will be separated by 29KB (1/2 turn), but adding one turn to be larger than 32 KB
13KB+59KB= 72KB.


@Robotik
but is it possible to have sound in cut / split preview? it would help a lot with finding the best position to cut / split.
It is really difficult... jeanl is the developer of DVDpreview. To have sound in DVDPreview is a nice feature, but really difficult

even if it is too messy to add something like a button / menu to choose from the available streams, just enabling the first available sound would be better than none
I'm sure the track selection is not the problem...

jsoto

[r0lZ]

Jsoto, I have a little suggestion.
In your Cut, Split and Still functions, can you add a button to return to the start, end or cut point automatically, and update the preview? That will be useful to quickly verify the cut points before launching the process.

Also, as most of the time the Cut cell feature is used to create a new chapter, i think you should enable the Create New Program and Chapter options by default.

[blutach]

@r0lZ - a lot of the time people cut the credits or the crap from the start by working in the single cell without making a new program/chapter.

Regards

[r0lZ]

Right, but I refer to the Split cell feature. If you cut a cell, it's probably to add another chapter, no?

BTW, I have yet another suggestion. When cleaning a DVD recoreded by a standalone recorder, you often need to remove the ads in the movie. That's easy with VobBlanker, but if you want also to add chapters, you need to do it in another pass. Since the ads are often placed at a natural place for a chapter, it will be good if the user can do both operations at the same time: cut the add, and create a new cell (+optionally a program and chapter) at that position.

[jsoto]

Jsoto, I have a little suggestion.
In your Cut, Split and Still functions, can you add a button to return to the start, end or cut point automatically, and update the preview? That will be useful to quickly verify the cut points before launching the process.I'll take a look

Also, as most of the time the Cut cell feature is used to create a new chapter, i think you should enable the Create New Program and Chapter options by default.Cut feature has four modes:
a) Cut from the start to a selected point
b) Cut from a selected point until the end
c) Cut between two selected points
d) Keep between two selected points. (Mix of a & b simultaneously)
IMHO, in modes a) b) and d) you do not need an additional chapter/program, but in mode c), may be...
In fact, mode c) is the most dirty cut. I'm fixing the elapsed time in the cell, but, currently I'm not fixing PTSs and SCR (I can't because next cell can be seamless joined), so the cut has a discontinuity in SCR and PTS. What I should do at least is to create a new cell and mark in the PGC a non-seamless join. Other possibility is to fix SCR and PTS in the whole VOB, but seems risky.
I'll think on it a little bit more..
jsoto

[jsoto]

Right, but I refer to the Split cell feature. If you cut a cell, it's probably to add another chapter, no? Ah!. You're asking for a simple default...I think you're right, I'll change the default.
BTW, I have yet another suggestion. When cleaning a DVD recoreded by a standalone recorder, you often need to remove the ads in the movie. That's easy with VobBlanker, but if you want also to add chapters, you need to do it in another pass. Since the ads are often placed at a natural place for a chapter, it will be good if the user can do both operations at the same time: cut the add, and create a new cell (+optionally a program and chapter) at that position.
Already answered in my previous post
jsoto

[r0lZ]

Thanks.

And yes, I was talking of cut mode "C".

[CoNS]

jeanl is the developer of DVDpreview. To have sound in DVDPreview is a nice feature, but really difficult
There's support for Ac3 decoding is in the DVD2AVI preview code already, but it's not hooked up when playing.

Dark Avenger has succeeded in hooking up this feature in the DVD2AVI code, which is used for his freeware MPEG2Cut tool. It's available at the website http://mitglied.lycos.de/darkav/ in the "Download" section. Source code is there, too. :)

It would be really cool to have sound in the preview in PgcEdit, VobBlanker and DVDSubEdit, which are all based on jeanl's modification of the DVD2AVI preview.

[Robotik]

It is really difficult... jeanl is the developer of DVDpreview. To have sound in DVDPreview is a nice feature, but really difficult
I'm sure the track selection is not the problem...


thanks for the reply, i didn't know i was asking something difficult... anyway keep up the good job, VobBlanker is a masterpiece!

[dirio49]

jsoto

with latest beta the preview does not work.
at least for me.
i did not do the bov scan.

pgcedit can preview the movie just fine.

[blutach]

I confirm this bug. :)

Regards

[jsoto]

jsoto
with latest beta the preview does not work.
at least for me.

I confirm this bug. :)
Which one?
Tiny preview?
Normal preview dialog?
Displaying Menus?
Displaying Titles?
Is "Do not use Overlay" checked or not?

All of them work for me... :confused:

jsoto

[blutach]

Tiny. And it seems like it's on that Test DVD I sent you - where there's no menus, just a DVD Shrink re-authored DVD.

Another DVD I just ripped with menus seems OK.

Regards

[jsoto]

What does the tiny show at the bottom?
"Nothing loaded"?

jsoto

[blutach]

Yes.

Regards

[jsoto]

Yes.

And, did you select a PGC in Titles domain w/o displaying anything?
jsoto

[blutach]

@jsoto

As usual, I am stupid and embarrassed. :)

Regards

[dirio49]

Sorry, :o
Mea Culpa :) :)

[techmule]

Jsoto, excuse me for coming out of the blue and making this comment, but does this beta integrate "del_angles" rather than being a separate tool ??

[jsoto]

@blutach & dirio49.
Don't worry. Better in this way, no bug, no need to work on it.

Jsoto, excuse me for coming out of the blue and making this comment, but does this beta integrate "del_angles" rather than being a separate tool ??No, it isn't integrated. You have to run del_angles, and after that, VobBlanker
May be I can think on it for a future build..

jsoto

[CrisCr0ss]

does it support ILVU streams? I have Independance Day where i want to remove the Theatrical edition and maintain the special edition. If not will VobBlanker ever support ILVU streams?

[jsoto]

VobBlanker is not able to produce ILV streams, but it is able to handle ILV input.

So,
if you have a multiangle VTS and you want to delete all angles except one, run del_angles first, and then , run VobBlanker processing the VTS in KEEP mode. VobBlanler will de-ILV all the VOBUs and the selected angle will be converted to a normal PGC.

If you have a multi-story, not multiangle, use first PGCEdit (*), to delete the unwanted stories (the unwanted PGCs), and then process the VTS in KEEP mode. Again, the PGC will be converted to a normal one.

(*)How to delete the unwanted PGCs in pgcEdit:
a) If they are the last ones in the VTS, just use "delete last PGC in domain"
b) If not, open the PGC editor (double click on the PGC) and remove all cells except one, using remove cells. (You have to keep one cell). Blank the remaining cell

EDIT:
If you want to keep more than one ILV PGCs, then you cannot process this VTS with VobBlanker, but you can process other VTSs in the DVD. Just mark the ILVed VTS in SKIP mode, which means do not process this VTS.

jsoto

[godfreydanials]

I was running VB 2.1.1.0 with no problems. I then upgraded to WinDVD 8 Player. It installed DirectX runtime and Visual C++ Redistributable Package for X86.

Then my preview window in VobBlanker stays black and does not show the movie. I upgraded to VB 2.1.2.0 beta 8 and had the same problem.

I have now removed WinDVD 8 Player and the Visual C++ Redistributable Package for X86. I did not find an uninstall for the DirectX Runtime. My preview is working again.

Are you aware of any problem with the Visual C++ Package?

[jsoto]

Are you aware of any problem with the Visual C++ Package?
No, first notice...
Did you test PgcEdit's preview?
jsoto

[r0lZ]

You should also try the "Do not use overlays" option.

[zacoz]

I can't recall or find by searching, whether discussion has occurred regarding having VobBlanker save the log file automatically. Unless I'm missing something it needs to always be done manually, and of course I keep clicking "Close" then :rolleyes: - I forgot to save the log file AGAIN !

[blutach]

If it goes "meep meep", there's little need mate (except to see what you've done I guess).

Regards

[jsoto]

I can't recall or find by searching, whether discussion has occurred regarding having VobBlanker save the log file automatically. Unless I'm missing something it needs to always be done manually, and of course I keep clicking "Close" then :rolleyes: - I forgot to save the log file AGAIN !
From beta4, all you have to do is to configure the auto-save path (see main menu->paths). If it is configured, your log and project file will be automatically saved when quiting or when closing the log window (so, you'll have your logs except if VobBlanker crashes...)

jsoto

[zacoz]

@jsoto :thanks: (doh, just realised I haven't actually installed the recent betas)

@blu Stretching myself a bit with the processing I'm doing atm, so would like to have the logs to look back on if testing end product comes up with issues.

[blutach]

@jsoto - thanks for the info. Is the log "additive"? Or does the next run replace the old one?

Regards

[jsoto]

@jsoto - thanks for the info. Is the log "additive"? Or does the next run replace the old one?
Regards
It overwrites. File names are:
VobBlanker_log.txt
VobBlanker_project.ini

jsoto

[blutach]

Thanks - would you consider an additive log which cuts off at say, 5,000 lines, deleting all lines after the 5000th?

Regards

[blutach]

@jsoto - found a bug when stripping subtitles - all info sent to you.

Regards

[jsoto]

0x20 substream is used in track 0 and track 17. You have selected to keep track 0, but to remove track 17.

To avoid this problem, I've added a check and now an error pops up asking the user to confirm the selections

jsoto

[blutach]

Very rare case and thanks for the warning :)

Perhaps users may not want to keep both tracks with lots of gaps in between (for possible player compatibility reasons). Or when they cycle with the remote having to click again to get off.

I wonder whether VobBlanker (http://jsoto.posunplugged.com/vobblanker.htm) shouldn't take stream 17 out of the IFOs while leaving stream 1 and 0x20? This is the behaviour of many other stream strippers (eg DVD Shrink).

Regards

[jsoto]

Perhaps users may not want to keep both tracks with lots of gaps in between Second track (#17) can be easily removed from the IFOs with pgcEdit.


I wonder whether VobBlanker (http://jsoto.posunplugged.com/vobblanker.htm) shouldn't take stream 17 out of the IFOs while leaving stream 1 and 0x20? This is the behaviour of many other stream strippers (eg DVD Shrink).

Seems the best option...I'll look into it, but I'll keep the warning anyway.

jsoto

[blutach]

OK thanks :)

Regards

[Robotik]

hi, i have another idea to improve this fantastic piece of software, it's a minor one, but might be helpful/more confy for users. it's dealing with deleted folders. currently when the folder i last used got deleted/renamed, browse button takes me to "My Documents". so every time i finish a project, write it on dvd and delete it (as i suppose most of us do), i have to find my dvd folder again.

could it be something like when the last used folder doesn't exist, it takes you to it's parent dictionary, again if it doesn't exist, just go one level up, until reaches the root of the actual drive? (e.g. as in PgcEdit)

i know it doesn't sound like a big deal, but it would save a few minutes every day.

thanks and kudos,
robotik

[blutach]

Good idea!

Regards

[jsoto]

Always asking for improvements... :D (better than bug reports) :D..

Well, this is what MS-Windows does when calling a Open or Save As dialog:


1.- If lpstrFile contains a path, that path is the initial directory. Otherwise, lpstrInitialDir specifies the initial directory.
2.- If lpstrInitialDir is NULL and the current directory contains any files of the specified filter types, the initial directory is the current directory.
3.- Otherwise, if the application has used an Open or Save As dialog box in the past, the path most recently used is selected as the initial directory. However, if an application is not run for a long time, its saved selected path will be discarded.
4.- Otherwise, the initial directory is the personal files directory of the current user.
5.- Otherwise, the initial directory is the Desktop folder.


What VobBlanker currently does is to fill lpstrInitialDir with the input path (if you've already loaded a DVD) or with a user's default path (you can configure it in Main menu--> paths). If you haven't configured this default path, lpstrInitialDir will be NULL.
VobBlanker does not save automatically the folders used in previous sesions, it is MS-Windows who does it, and applies the #3 in the list. Note the same folder is used by MS-Windows in all cases, (i.e load project file and browse VIDEO_TS.IFO)

I'd prefer to do not save many keys more in the Registry, currently there are a few....

So, is it enough for you the "default user input path"? (available in 2.1.2.0, latest betas)

Note: Remember you can also open the DVD in two other ways:
- using drag&drop, on the main dialog or on the icon
- right click on VIDEO_TS.IFO and, from pop-up menu, open with VobBlanker. First time you have to select VobBlanker (and pgcEdit, dvdshrink, IFOedit) from a list, but, afterwards, you have all the proggies in a secondary popup menu (BTW, this is my personal preferred option)

jsoto

[blutach]

So, perhaps to do what Robotik wants, simply ensure you have all your DVD projects in subfolders of a main folder (eg C:\Projects) and configure a default input path to that folder? It seems so.

Regards

[r0lZ]

Jsoto, I know that Windows stores the default path for each app in the registry. Maybe you can perhaps read that key (I don't remember which key it is, but I can find it easily), and force the parent if that folder doesn't exist any more...

Robotik, maybe it's an idea to submit to Bill Gates! ;)

[Robotik]

I'd prefer to do not save many keys more in the Registry, currently there are a few....

So, is it enough for you the "default user input path"? (available in 2.1.2.0, latest betas)

fair enough. i didn't realise there is a default user input path.
BUT now i have looked into it, (and i can't get very technical here, i'm not a programmer,) pgcEdit and dvdshrink browses for a folder in the open dialog, and not for VIDEO_TS.IFO, which is perfectly logical, as VIDEO_TS.IFO defines a DVD folder.
and the open folder dialog seems to do just what i have requested. is there a reason VobBlanker rather browses for VIDEO_TS.IFO?

regards and thanks,
robotik

[Robotik]

@r0lZ
I told Bill last night, but he said he'd rather have another drink ;)

[r0lZ]

PgcEdit keeps the last opened folder in its config file (for several dialogs, like Open DVD, Import functions, ...) And of course, I have programmed myself the stuff to find the first parent available if the saved path doesn't exist any more. (Easy to do in Tcl! :))

BTW, at the request of several users, in PgcEdit, it is also possible to browse for a file in the DVD folder, with the standard Open File dialog rather than the Open folder dialog. It's an option, off by default.

[jsoto]

and the open folder dialog seems to do just what i have requested. is there a reason VobBlanker rather browses for VIDEO_TS.IFO?

Not really,... although a DVD cannot be opened (even in pgcEdit) if VIDEO_TS.IFO is not reachable

There are two standard dialogs in MS-Windows
- CFileDialog-> Class used to create a dialog to Open /save a file
- SHBrowseForFolder--> procedure to search for a folder

You can see an example of both in VobBlanker's browse buttons (input uses CFileDialog and output uses SHBrowseForFolder)

BTW, a folder is also accepted when drag&drop, so the code to accept the folder is there. Just a matter of which method of both do you like more...

Anyway, I'll take a look on MRU (MostRecentUsedfiles) implementation in C++..but seems I have to code the menu manually...
I'll look into it after finishing the improvements requested by r0lZ in cutting inside a cell.

EDIT:
Let me insist: I'm really happy with right click on VIDEO_TS.IFO. I can open the DVD with the tool I want. Nobody is using this method?

jsoto

[r0lZ]

I'll look into it after finishing the improvements requested by r0lZ in cutting inside a cell.Thanks! :)

Let me insist: I'm really happy with right click on VIDEO_TS.IFO. I can open the DVD with the tool I want. Nobody is using this method?Yes, I use it often. And the CLI syntax is also useful to launch VobBlanker from another tool such as RipIt4Me or PgcEdit. :)

[dirio49]

That is nice too. I use it sometimes

[kmac61]

If you set your file association for .ifo to vobblanker then you can just double click. It also seems to open quicker

[blutach]

I like Drag and Drop and also have VobBlanker (http://jsoto.posunplugged.com/vobblanker.htm) as a shell item from PgcEdit and RipIt4Me (http://www.ripit4me.org/).

Regards

[BigCondor]

I have never launch VobBlanker thru right-clicking an ifo.

[Robotik]

me neither, even though it would be obvious, as i open most of my other stuff with double click/right click. hm. i can't understand myself.

[President]

Thank's, Jsoto!

Can you add a checkbox like "Split files in 1 Gb" into dialog of save several cells to one VOB.

[jsoto]

Can you add a checkbox like "Split files in 1 Gb" into dialog of save several cells to one VOB. I'll put it in the TODO for nexts betas... beta 10 is already online.

jsoto

[jsoto]

VobBlanker_2120 beta10 (http://download.videohelp.com/jsoto/betas/VobBlanker_2120b10_exe.zip)

Changelog versus beta 8


Added: Most Recent Files menus added. One for DVDs and other for project files
Added: Option to split the cell in two when "cutting inside" a cell
Added: Buttons to go to cut points in preview
Added: Warn the user if a substream is selected to be stripped and kept simultaneously.
Added: Registry keys to control (using regedit) HDD buffering and MRU lists size. Defaults are "do HDD buffering" and 8 files per list
Changed: When stripping, if the same substream is selected to be kept and stripped (in different tracks) VobBlanker will not remove the stream from the VOB
Changed: Numbering of subs and audio tracks from 0 to n-1 instead of 1 to n.
Changed: Default when splitting cells: add program/chapter
BugFix: Menu stream Attributes were not cleared when deleting a zero bytes menu.
BugFix: VTS substreams list was wrong in the case of more than 8 subs
BugFix: The warning if a cut was going to create orphan subs was not always issued.
BugFix (I hope): SMART GAPS were not created in case of a 18KB IFO.


Registry keys are located at key node
HKEY_CURRENT_USER\Software\jsoto's tools\VobBlanker

jsoto

[blutach]

I confirm the 18k smart gap bug has been repaired for VIDEO_TS.VOB. A new unreferenced 62k VOB has been created :) I have emailed you about some other concerns I have about smart gaps.

Also confirm nice warning when 2 tracks share streams IDs. Importantly, in this case, the stream is now no longer stripped, however no streams seem to be actually stripped except the unreferenced one (I deliberately changed stream 11 from 0x800a0a00 to 0x80000000 to test this feature) :(

See original and final below:
http://img157.imageshack.us/img157/7703/orig1lm6.png http://img81.imageshack.us/img81/6536/final1bx2.png

Project ini is attached.

As well, time map creation may still not be 100% but I'm sure it is not badly out, if at all. From the VobBlanker log:

VTS 01: Processing IFO (Titles)
Looping into Title PGCs and cells
PGCN Pointer: Pointing Next PGCN to itself in PGC 1
PGCN Pointer: Pointing Prev PGCN to itself in PGC 1
PGCN Pointer: Pointing Next PGCN to itself in PGC 2
PGCN Pointer: Pointing Prev PGCN to itself in PGC 2
Processing TMPATI table
Added 1594 entries in TMAPTI of PGC 1
NOTE: PGC: 2 is too short. No entries in TMAPTI are created
Added 0 entries in TMAPTI of PGC 2
Generated a TMAPTI table with same # of sectors than original
Building VTS_C_ADT table
Filling VTS_VOBU_ADMAP table
VTS 01: Processing IFO (Ending and writting)


PgcEdit time map verify function reports as follows:

VTST 1 , 1 TTN 1 (1:46:19) Title 1 (sequential title)
1593 x 4 seconds = 1:46:12 ; ********** WARNING! **********

VTST 1 , 2 TTN 2 (0:00) Title 2 (sequential title)
Empty Time Map.

Regards

[r0lZ]

Great changelog, Jsoto!

I like especially:


Added: Option to split the cell in two when "cutting inside" a cell
Added: Buttons to go to cut points in preview
Changed: Default when splitting cells: add program/chapter
BugFix: Menu stream Attributes were not cleared when deleting a zero bytes menu.

;)

[jsoto]

Quite strange....Strip works to me in a quick test I've done
Could you mail me a complete report (IFOs after and before, complete log and project files)?.

TMAPTI:
PGC1: I can ghive you more details with the complete report, but sounds strange. I'm adding frames, not seconds, so it should be completely accurate calculation. Also there is a mistmach between the # of entries reported (Vobblanker reports 1594 written and pgcEdit reports 1593 ) .

PGC2: I think there is no error at all. It's a sequential title, but blanked, so less than one sec. Should it be one entry pointing to "the" VOBU #1?. I think it has no sense...

[jsoto]

Great changelog, Jsoto!

I like especially:

BugFix: Menu stream Attributes were not cleared when deleting a zero bytes menu

;)

Sorry,
BugFix: Menu stream video Attributes (specifically PAL and MPEG-2 bits) were not cleared when deleting a zero bytes menu.

Audio and subs streams were cleared...

jsoto

[blutach]

Will send emails and no, PGC2 is not the issue, just the # of entires in the TMAPTI for PGC1.

Regards

[r0lZ]

And who is wrong? PgcEdit or VB?

[jsoto]

And who is wrong? PgcEdit or VB?
A new run worked well. Streams have been stripped and pgcdit check on TMAPTI was OK, so there are two (or three) options:
- Blutach. (never sleeps...)
- Blutach's PC. (running out of space...)
- VobBlanker, an uncontrolled and non-repetitive bug.

According blutach report, VobBlanker is running in input folder, so seems like the VOB files have not been moved, so the streams appear as no-stripped, and TMAPTI is not correct. But no error is reported in logfile... :confused: :confused:

EDIT: Definitively, something happened when moving files...
Original IFO has 1593 entries in TMAPTI (this is the one wrong). Voblanker outputs 1594 as reported and pgcEdit asks for 1594 too...

PgcEdit and VB improve the compliance of the originals...(at least in TMAPTI)

EDIT2: I'm wondering if blutach was the culprit....
Modifying the subpicture stream to one already used in the IFO is enough to show 0 MB in dvdshrink.
So seems the second screenshot is just the same original DVD with the IFO modification, and nothing more...

jsoto

[blutach]

I'm also wondering if blutach is the culprit (or his machine anyway).

I had 2 rips of this DVD on my hard drive - one for testing, one being edited. When I came to open the one I was actually working on in PgcEdit, it reported all sorts of errors that indicated it was actually opening the IFOs of the other one! I needed 2 restore backups to get me back to where I should have been. Mrs Tach was distinctly unimpressed with the quality of sound coming from the computer room :D

I checked my VB project file and logs and it was fine as far a input folder is concerned. I can not remember manually moving IFOs - but I must have and placed them in the wrong folder.

Anyway, I will keep monitoring this and see if it happens again.

(Insert red faced emoticon here).

Regards

[jsoto]

Don't worry, you've detected many bugs and always do an appreciated work in beta testing...

May be OT, but be careful with the Recent file lists. In theory, when the complete path is not shown (only the file name is shown) it is because the application is running in the same folder... But there is a small bug and if the current folder changes (although I do not know how it can happen), the menu list is not updated, so the user will be confused.

I've changed the code an now the path never is hidden.

jsoto

[blutach]

Might have been it. I do remember re-opening from that menu once.

Thanks for the nice words. :)

Regards

[r0lZ]

PgcEdit and VB improve the compliance of the originals...(at least in TMAPTI)Well, I wonder if a single missing entry in TMAPTI is always an authoring error. In many commercial DVDs, a blank, tiny chapter is added at the end of the movie to be able to jump to the end of the movie with the remote. Most of the time, that blank cell is skipped via a cell command when the title is played normally until it ends. Therefore, it is possible that the tiny cell is deliberately not included in TMAPTI, as it is not really a cell pertaining to the movie.
Anyway, including it in the table should be harmless.

[mpucoder]

From what I've seen there are two ways of calculating one second of NTSC. Some authoring programs use 90090 ticks (30 frames) and others use 90000 ticks (one second)

[jsoto]

Here is a new beta...., but I did not have too much time to test it, and I've modified some critical parts, so may be I've introduced some bugs. If it is the case, the IFO will be seriously corrupted and the DVD will not play at all, so you'll notice it.

VobBlanker_2120 beta11 (http://download.videohelp.com/jsoto/betas/VobBlanker_2120b11_exe.zip)


Changelog versus beta 10


BugFix: VB was not creating VTSM_C_ADT if it was cleared due a bad authoring
Changed: MRU lists do not hide current folder in file paths


jsoto

[dialysis1]

I just tried beta 11 with X-Men 3, The Last Stand. Nothing fancy. Just stripped some languages and blanked some trailers.
No complaints from DVD Shrink, PgcEdit or PowerDVD.

[jsoto]

Thanks for the positive feedback
I'll do more tests this weekend...

jsoto

[techmule]

hmmm time for a RC1, good work done.

[jsoto]

Yet another beta
VobBlanker_2120 beta12 (http://download.videohelp.com/jsoto/betas/VobBlanker_2120b12_exe.zip)

Changelog versus beta 11


Added: Splitting extracted file in 1 GB files in Cell extraction, selected by a Customized CFileDialog
Changed: CFileDialog management changed internally. (No more assertion failures in Debug mode)
BugFix: Sometimes, cutting Cells an extra Nav Pack was written.
BugFix: Using Megabuffer was producing shorter VOB files than the maximum allowed
BugFix: Loading a DVD or a project from Most Recent Files was not clearing Tiny preview
BugFix: "Cut inside" w/o splitting failed when saving/loading a project. This bug was introduced in latests betas.


Not too much, but I spent a lot of time in CFileDialog, trying to customize it, the places bar was disappearing...At the end it is a problem of Windows and VC++ versions. And you need to create your own class to customize the dialog in VC++6.

BTW, do you know you can customize, using Registry keys, which places are going to be displayed in the CFileDialog (in all applications)?. See
http://download.videohelp.com/jsoto/images/placesbar_keys.jpg


jsoto

[r0lZ]

BTW, do you know you can customize, using Registry keys, which places are going to be displayed in the CFileDialog (in all applications)?. See
http://download.videohelp.com/jsoto/images/placesbar_keys.jpgYou can also customize those locations with Tweak UI (http://www.microsoft.com/windowsxp/downloads/powertoys/xppowertoys.mspx) (a free "Power Toy" by Microsoft.)

[jsoto]

You can also customize those locations with Tweak UI (http://www.microsoft.com/windowsxp/downloads/powertoys/xppowertoys.mspx) (a free "Power Toy" by Microsoft.)Curious tool...In the case of places bar, it updates the registry, that's all, but much more firendly than using regedit.

jsoto

[r0lZ]

Basically, TweakUI is just a GUI over some hidden features of Windoze. Some of them are really useful!

[President]

Yet another beta
VobBlanker_2120 beta12
Added: Splitting extracted file in 1 GB files in Cell extraction, selected by a Customized CFileDialog
First:
Great! Thank's a lot for this feature! :thanks:

Second:
Sorry for your wasted time:(. I am not a programmer. I don't know a best place for that checkbox (from the point of view of programmer). I just proposed to add that possibility to VobBlanker. It seems to me a File saving dialog window is logical best place. If it's so difficult you may add this checkbox anywhere: to the Preferences or to the Cells window. It's not a point. Anyway, if you made it in the standard File dialog window already... don't recast it ever:). This works good. Thank's one more.
(sorry for my English).

[laserfan]

You can also customize those locations with Tweak UI (http://www.microsoft.com/windowsxp/downloads/powertoys/xppowertoys.mspx) (a free "Power Toy" by Microsoft.)Omigosh--the cool things you learn by following you smart guys around! Thanks!

[jsoto]

First:
Sorry for your wasted time:(. I am not a programmer. I don't know a best place for that checkbox (from the point of view of programmer). I just proposed to add that possibility to VobBlanker. It seems to me a File saving dialog window is logical best place.
Not to worry. I spent time, not wasted it. Even more, I (usually) enjoy it. I was just talking about some obscure things in MFCs, and how they can complicate your life.
Now, I know how to customize a CFileDialog (in the right way w/o loosing the places bar) even using an old compiler like VC6. But I've read that in Vista CFileDialog's look & feel changes again... Seems it is time to upgrade my compiler.

jsoto

[gonwk]

Hi JSoto,

THANKS A BUNCH for a great program and the "Holidays Present" ... beta12 ...

Q: Where would I download beta12 from?:confused:

I went to your main home page and your directory index and I can not find it!?!?!?

btw, on your web page still showing "16 May 2006" as the latest update!?!?!

THANKS & MERRY XMAS!
G!

[Rippraff]

Q: Where would I download beta12 from?:confused:
Take a bit more concentrated look on the same page where you are, just a few posts above. :D
Did you find it (http://forum.doom9.org/showthread.php?p=918451#post918451)? :)

Cu Rippraff

[gonwk]

Hi Rippraff,

I would have sworn I must have just driven by it "Frantically" ...

Thanks Mate! & Happy Holidays!

G!:o

[techmule]

I dont know if jsoto noticed it or not since I myself noticed it today in 2.1.1.0. there is a typo in the preview window, once you select a PGC in the titleset. It says "Titles PCG's preview"

Perhaps its already corrected in the beta!!!.

[jsoto]

Perhaps its already corrected in the beta!!!.No, it wasn't.
jsoto

[BigCondor]

There might be some problem with the b12 version.

I try to merge back 2 discs previously splitted by DVDFab. There are 24 cells in the first disc and 28 cells in the second disc. After merging, the resulting DVD can not be opened by DVD Shrink with invalid data in VTS_01_7.VOB(the last vob).

Then I open the merged dvd in b12, the following message was shown:-

VTS 01: Detected 27 cells in PGCs not referenced in C_ADT
Using PGC initial and ending pointers...

A FullScan is recommended.

List of Cells:

VTS01, PGC 001, Cell 26
.
.
.
.
VTS01, PGC 001, Cell 52

So, only the first (cell 25) of the replacing cell is alright.
Then I do a fullscan but the same message appears.

Then I extracted the cells and replace with 2.1.1.0b1, everything works fine.

I even tried b12 to replace the vobs extracted from 2.1.1.0b1 but it didn't work. So obviously there is something wrong with the replacing and fixing up.

Note: there is an error when opening the second disc:-

Referenced Menu empty or does not exist in VTS01

[jsoto]

@BigCondor
Could you please send me:
- the IFOs before (two disks)
- VobBlanker project file (and log file if available)
- IFOs after

jesus_soto_viso at terra dot es

thanks
jsoto

[BigCondor]

@jsoto

Files are sent, thanks a lot!

[jsoto]

VobBlanker_2120 beta13 (http://download.videohelp.com/jsoto/betas/VobBlanker_2120b13_exe.zip)
Changelog versus beta 12

BugFix: Replacing/blanking reused cells sometimes did not work.


@BigCondor
Could you check it?

It was a strange and difficult one. The bug was there in previous versions, 2.110 also failed in debug mode and what I do not understand is why 2.110 release version does not fail, although it can be, because the bug came from an unitialized boolean value in reused (blanked or replaced) cells.

jsoto

[BigCondor]

The version works, thanks for the bugfix.

Btw, can you do an auto increase of vobs during replacement?

For example, in this case, I have to replace cell 25 to 52. After inputting the first cell #25, the program ask me to input the next cell and the vob for cell #25 is shown and I have to type 26 in the space. If the program automatically increase the value by one then I only have to press enter to accept the value. Since there are 28 cells to replace there may be a chance of mixing up the value during replacement.

Thanks and merry Christmas to you!

[jsoto]

Btw, can you do an auto increase of vobs during replacement?
OK. Done

[President]

2jsoto
Thank you for the new beta and for the bugfix. :thanks:

[blutach]

Small issue with Not one-seq calc.

VobBlanker (http://jsoto.posunplugged.com/vobblanker.htm) is saying TTN2 is not 1-seq, where I can't see that it shouldn't be. PgcEdit marks it as 1-seq.

http://img19.imageshack.us/img19/9286/12252006202848gr9.png http://img19.imageshack.us/img19/6672/12252006202925uq3.png

Regards

[jsoto]

@blutach
IFOs, please. Seems this time one of the two has to be wrong...

jsoto

[blutach]

On the way mi amigo!

Regards

[r0lZ]

Seems this time one of the two has to be wrong...
Indeed!

PgcEdit is somewhat relax with that. I do NOT consider a title as not-one_sequential if it has the Next, Prev or GoUpPGCN link pointing to itself. I consider only the Random/Shuffle modes, and the multi-PGCs Titles as not-one_seq.
But maybe there is a bug somewhere...

[blutach]

Indeed, the Prev and NextPGCN are pointing to themselves in the Final IFOs (new ones sent to you jsoto and r0lZ). Other titles also have this set and do not attract this warning from VobBlanker (http://jsoto.posunplugged.com/vobblanker.htm).

I recall some discussion here from bigotti5 about not 1-seq.

Regards

[jsoto]

VTS10, PGC1 is pointing to itself ( Previous PGCN=1 and Next PGCN=1). VobBlanker does not complain in this case
But this is not the case of VTS12 PGC 2. Really strange, both pointers (next and prev) are pointing to PGC 1, but PGC1 belongs to Title 27 and PGC2 belongs to other Title (#28). Seems an authoring error.

VobBlanker checks if the pointers are different from 0 and point to a different PGC. That means the PGC cannot be One_seq_title_PGC.

I think a PGC cannot have pointers to other PGCs belonging to different titles. Can anyone confirm it?

jsoto

[Sir Didymus]

I think a PGC cannot have pointers to other PGCs belonging to different titles. Can anyone confirm it?


On what I know, different titles belongs to different domains, and a PGC cannot link directly from a given domain to a different one...

IMHO, the prime reason for the existance of dummy PGCs in the VTSM domains is exactely to enable this type of connections...

[r0lZ]

I think a PGC cannot have pointers to other PGCs belonging to different titles. Can anyone confirm it?I believe it's right. This has been confirmed several times, by knowledgeable ppl like mpucoder or bigotti.

VobBlanker checks if the pointers are different from 0 and point to a different PGC. That means the PGC cannot be One_seq_title_PGC.That's what I should do also, but since it is theoretically illegal to point to another Title, I do not check the Prev/Next/GoUp pointers at all. I check only if there are several PGCs in the same Title. Hence the difference in the error messages.
PgcEdit should check a little bit more for this kind of authoring errors, but it's not easy. Anyway, it's in my todo list...

On what I know, different titles belongs to different domains, and a PGC cannot link directly from a given domain to a different one...Having several Titles in the same domain is possible and frequent. But it is true that you cannot link to another domain or VTS.

[blutach]

So, on the basis that PGC2 points to PGCN 1 (possibly incorrectly), it should be not-1-seq. @r0lZ thank you for adding this to your to do list. @jsoto - sorry for troubling you.

Regards

[Sir Didymus]

Having several Titles in the same domain is possible and frequent. But it is true that you cannot link to another domain or VTS.

Well, the important point is that a definitive answer - "no" was given to the question about the possibility to directly link between two different titles..., and that some valid reasons were provided to blutach to complain on the head of the authoring house that produced the DVD... :angry:

However, I always supposed that the reason for such constraint was that always different titles belong to different title domains...

That is also coherent with the definition of domains given by DVD Demistyfied... I just checked...

Are you positive you are not referring to a given VTS system space ? I agree that it is possible and frequent to have multiple titles (with their different TTs domains) belonging to the same VTS system space...

[r0lZ]

Well, it is possible to jump from one title to another one directly if they are in the same VTS (for example with the JumpVTS_TT command), but anyway, you cannot do that with the Prev/Next/GoUpPGCN links and their associated VM commands, as they must point to the same TTN.

I'm not sure I use the same terminology. For me, a Title domain includes all Title PGCs of the same VTS. (They are labelled "VTST N" in PgcEdit.) Therefore, it is possible to have several Titles in that "domain".
As I have never read DVD Demistyfied, I might be wrong. What are its definition of VTS system space, Title Domain and TT domain?
If a Title Domain includes only the PGCs belonging to the same Title (or TT), then I need to reformulate my answer.

[Sir Didymus]

Well, it is possible to jump from one title to another one directly if they are in the same VTS (for example with the JumpVTS_TT command), but anyway, you cannot do that with the Prev/Next/GoUpPGCN links and their associated VM commands, as they must point to the same TTN...


Yes, this is perfecly in agreement with the definition itself of the link and jump instruction groups. Quoting another "heavy book" (DVD Authoring & Production by R. La Barge):
- The Link instruction group includes navigation commands that transfer control within the current domain, and can be included in the Pre, Post, Button, and Cell command areas.
- The Jump instruction group includes navigation commands that transfer control outside the current domain, and can be used in the Pre, Post, Button, and Cell command areas.

Well, about the terminology, I was just using TT as an abbreviation for "Title"... :rolleyes:

Here some figures from DVD Demistyfied defining domains, system spaces and transitions between domains...

http://img19.imageshack.us/img19/4272/domaindefinitionkg7.th.gif (http://img19.imageshack.us/my.php?image=domaindefinitionkg7.gif)

http://img82.imageshack.us/img82/5525/spacesdefinitionzr2.th.gif (http://img82.imageshack.us/my.php?image=spacesdefinitionzr2.gif)

http://img147.imageshack.us/img147/3987/domaintransitionsjc2.th.gif (http://img147.imageshack.us/my.php?image=domaintransitionsjc2.gif)

I am quite familiar about the topic in these actual (holy ?) days, since I am writing a little command line wrapper for MuxMan, and the organisation of segments into the proper domains is exactely what is jeopardising the "Christmas nice atmosphere" in the family ... :p


...For me, a Title domain includes all Title PGCs of the same VTS...

Mhhh... This is what I consider a subset of a VTS system space...
For me a title domain includes all PGCs (maybe including dummy ones...) belonging to the same title...

[r0lZ]

OK, thanks. So, you were right, and I must say:
Having several Titles in the same VTS is possible and frequent.
But you know that, of course.

BTW, this "Spaces" terminology is, IMO, even more confusing.
And thanks to your last figure, I've learned also another thing: apparently, you cannot use a JumpSS from the VMGM to the VMGM, but you can do it from a VTSM to itself!
Why should it be simple when it can be complex?!

[bigotti5]

Yes, different titles in one VTS are different domains
Page VI3-17 (3.3.3)
Title Domain (TT_DOM) ... The TT_DOM is constructed by TT_PGCs of which PGCIs have the same VTS Title number.
and take a look at the commands:

Link -> transfer between same domain
Jump(Call) - > transfer between different domains

from title to title (in same VTS) you have to use JumpVTS_TT

@Sir Didymus

System Space = consists of "Menu space" and "First Play Domain"
Menu Space = consists of "LUs of VMG" and "VTSM Domains"
Title domain is not part of "System space"

[Sir Didymus]

Totally agreed. I am using the term "VTS system space" to designate the "VTS space". It's just a lapsus: I can not avoid to associate (each one of...) these spaces with the term of "system"...

However, I totally agree: the "VTS system space" is something that does not exist. The "VTS space" is collecting the domains of the menus and all titles belonging to the same VTS, and the title domains are not part of the "System Space". That's totally clear to me. The pictures posted above are also clear enough on the matter, I hope...

Cheers,
SD

[blutach]

I think the "system space" is another one of those redundant terms, which can be adequately addressed by either menu domains (including VMGM) or title domains.

Happy holidays all

Regards

[Robotik]

apparently, you cannot use a JumpSS from the VMGM to the VMGM, but you can do it from a VTSM to itself!
holy scheisse! does this mean that all the JumpSS commands i used to navigate within the VMGM are illegal? what should i use then? LinkPGCN?

[r0lZ]

I suppose so! And yes, LinkPGCN is valid.

[Robotik]

thanks for the quick response

[jsoto]

I do not understand why to do the things so complex... some transitions can be done, other not, but, at the end, you can do them using other command or, at least , creating another dummy in VMGM.
So, which is advantage to make it so complex?

I'm lost in space... :D

jsoto

[mpucoder]

holy scheisse! does this mean that all the JumpSS commands i used to navigate within the VMGM are illegal? what should i use then? LinkPGCN?No! it is legal to use JumpSS from VMGM to other VMGM PGCs

[President]

No! it is legal to use JumpSS from VMGM to other VMGM PGCs
And to itself too, I suppose. I don't found any restrictions to use this command to link to itself PGC.
Your site. (http://www.mpucoder.com/Muxman/mxp/cmd4.shtml):)
DVD-Replica site. (http://www.dvd-replica.com/DVD/jumpss.php)
Another page in DVD Demystified.
http://img412.imageshack.us/img412/3623/1qj6.th.jpg (http://img412.imageshack.us/img412/3623/1qj6.jpg)
A DVD Demystified, it seems, have a some misprints. Once more example:
http://img241.imageshack.us/img241/2443/2qr0.jpg

[Sir Didymus]

...
And thanks to your last figure, I've learned also another thing: apparently, you cannot use a JumpSS from the VMGM to the VMGM, but you can do it from a VTSM to itself!
Why should it be simple when it can be complex?!

So, at the end it isn't complex... It's just totally wrong... :scared:

Apologise for posting the mistake...

And a big thanks to mpucoder and President for pointing it out...

Sigh.. after destroying some confidence we may have had on some sw verification tools, we are making now nice progresses, discovering bugs also in the old "reference" books...

Well, using "we", but I speak of myself, of course... :o

Cheers,
SD

[Robotik]

No! it is legal to use JumpSS from VMGM to other VMGM PGCs

goodie then! [relieved] thx!

So, at the end it isn't complex... It's just totally wrong... :scared:
Apologise for posting the mistake...


personally i'm rather happy that all my dvds are all right! moreover, we all learn from our (and each other's) mistakes.

also, it's good to see that my demi-gods are human after all :)

[[Tobi]]

@ jsoto

Is there already a new beta ?
I have not read everything and do not know what is changed or not. The beta 13 crashes, with a certain constellation which I have found on different DVDs.

The last what in the process log stands is the following:

WARNING: nuPGCs was different from the value stored VTS_TMAPTI 2. Fixed
Note: PGC 1 is too short. No entries in TMAPTI are created
Added 0 entries in TMAPTI of PGC 1


Then the VobBlanker crashes and quits itself.

[jsoto]

;922121']@ jsoto
Is there already a new beta ? No, I was just finishing the help file modifications to do a full release.
;922121']The beta 13 crashes, with a certain constellation which I have found on different DVDs.

The last what in the process log stands is the following:

WARNING: nuPGCs was different from the value stored VTS_TMAPTI 2. Fixed
Note: PGC 1 is too short. No entries in TMAPTI are created
Added 0 entries in TMAPTI of PGC 1 Could you send me the details? (IFOs before and project file.) Please specify which is the VTS that make VobBlanker crash

jsoto

[SYL]

I would like to congratulate you for this job, VobBlanker is very good, I’ve being using a lot version 2.1.1.0 and used beta 8 and 10 one or two times with out any problem, and thank you for it be totally free.

I would like to make some suggestions although being in the final phase of the update, in the “CELL in TITLE” and or in “PGCs in Selected TitleSet” modes you would show the final size and the initial size too, for the case we cut some part of the cell, like the credits, or strip some audio streams, for example.

In the “CELL PREVIEW/ CUT MODE” you would put the quantity of Mega Bytes as the slider is running, not only the Sector(lba).

In the initial and final size of the DVD it would be good to put the difference between the final size and the size of a DVD5, and this size would be edited by the user having a default value like 4464 MB in DVD Shrink.

I notice that we can’t strip streams and cut cells from a same PGC on the same process. Is it possible?

Thank you for the attention and this opportunity to interact with the users to improve this wonderful software. Keep going doing better with VobBlanker, we thank you a lot.
Have a great 2007.

[jsoto]

@[Tobi]
Thanks for the files. I've fixed the bug in the final release version

@SYL
Welcome to the forum.
I'm just releasing 2.1.2, but I'll keep in mind your suggestions.
But, no, it is not possible (and it will not be) to cut+strip in the same VobBlanker process.

jsoto

[SYL]

Thanks for the quick answer,

I have another doubt, when I begun to use VobBlanker I used to rip the DVDs just with DVD Decrypter and on some movies there were a delay to start the title menus and or the root menus, having the warnings, studios intros and some extras blanked, bigger than the original ones. When I passed to use RipIt4me it didn’t happen till now. Is it due to RipIt4me removes tiny cell, useless menu cells, etc?
Does the new function “Adjust Sectors” makes something like this?

Thank you.

[jsoto]

I have another doubt, when I begun to use VobBlanker I used to rip the DVDs just with DVD Decrypter and on some movies there were a delay to start the title menus and or the root menus, having the warnings, studios intros and some extras blanked, bigger than the original ones. When I passed to use RipIt4me it didn’t happen till now. Is it due to RipIt4me removes tiny cell, useless menu cells, etc?.I have very few experience with RipIt4me, but I can explain you how VobBlanker works:
- Blanking mode (Cells): VobBlanker does not delete the cells. They are replaced by a blanked one, and because it is non-seamless linked, the playback time (0.4 secs) is increased by the player to empty the buffers, and so on. This extra-time can be very different, depending on the player (a SW player, like PowerDVD is almost instantaneous)
- Blanking mode (PGCs): The cells are blanked, and the playback time is reduced to zero if the postcommands can be converted to precommands. If not (because there are cell commands, i.e) the complete PGC is played, all cells are blanked, but it can take some seconds...
- Deleting mode (PGCs): Only available in Menus domain. In this case the cells are really deleted, so the playback time is reduced to zero.

Other alternative is to use pgcEdit's "KillPlayback". The method is only a little bit more powerful in "automatic mode", but with user intervention (you can see the commands, the potential problems and decide what to do), sure you can bypass the playback of the PGC.

Does the new function “Adjust Sectors” makes something like this? Not at all. Adjust sectors is done as part of the normal VobBlanker processing, but in this new version two things have changed:
a) you can do it w/o processing the DVD
b) the new "Smart GAPs" creation feature, which put the files IFO & BUP in the optimum physical an d logical distance.

jsoto

EDIT:
Forgot to mention the amazing "Jump to PGC upon DVD insert" feature of pgcEdit: Absolutely recommended.
You can blank all the unwanted stuff, and finally, using this macro, the playback of the DVD will start exactly where you want, w/o any problems of blanked/bypassed cells.