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