VobBlanker 2.1.2.0 beta (now beta 13)

[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