little prob (i think)

[jojo15]

Hi,

my problem is, i have this DVD (on my hd), but one of the vobs has no filesize (0 kb), thanks to this, my standalone won't play the dvd,
i tried opening it in DVDRemake to maybe get another structure out of it (someone suggested it), but it won't open....
anyone know what i can do?
thnx a lot in advance!

[2COOL]

Originally posted by jojo15
my problem is, i have this DVD (on my hd), but one of the vobs has no filesize (0 kb), thanks to this, my standalone won't play the dvd,I doubt this is the root of your problem as there are many commericial DVDs with 0KB VOBs. Obviously, you didn't use Nero to burn because you would've gotten the infamous warning of less the 2 KB files. You must've done something with your edits. So what did you do?

[CoNS]

Yep, a 0 KB vob may cause trouble. Weird, though, that it's your standalone that complains. Usually it's the burning program (in particular Nero) which gives you a warning when burning, but the disc should play fine anyway in the standalone.

Usually the 0 KB vobs are empty menu vobs which come from the original disc. This makes it even weirder that your standalone would choke on it. Are you sure that's the prob with the disc in question?

The correct way to delete the 0 KB vobs is explained here, originally posted by r0lz (I think!):

If you want to be sure to remove all references to a 0 bytes menu VOB, then load the DVD in PgcEdit, right click on any PGC of the menu, and select Blank Out All Menu PGCs. Select the first option: Completely Remove The Menu VOB File.

Note that if there are already no references in the IFOs, the dialog will not be opened. Instead, you will have a simple Yes/No request, asking if you want to remove the VOB. Answer Yes.

Repeat this procedure for all menus with empty VOBs, and finally save the DVD.

Nero should not complain anymore.

[r0lZ]

If you want to properly remove the 0 bytes VOBs with PgcEdit, see here (http://forum.doom9.org/showthread.php?s=&threadid=86241#post577621).

[EDIT: CoNS posted his answer just before me! :(]

[CoNS]

hehe, beat ya to it, r0lZ :D

[mpucoder]

There are a number of things that can hint that there is, or should be, a VIDEO_TS.VOB or VTS_xx_0.VOB. If present without the file a player could go nuts.

First of all, if it is empty it should not be mentioned in the ifo or any file system - ie remove it and all references to it.

If there is no VIDEO_TS.VOB:
VIDEO_TS.IFO location 0xc0 to 0xc3 should be 0 (indicates location of vob)
VIDEO_TS.IFO locations 0xd8 to 0xdb should be 0. If not it means you have a cell address table for the vob (which has to be removed).
VIDEO_TS.IFO locations 0xdc to 0xdf should be 0. If not it means you have a VOBU address map for the vob (also needs to be removed)
VIDEO_TS.IFO locations 0x100 to 0x1ff should all be zero except location 0x100 IF PAL, in which case it should be 0x10 (to agree with the rest of the video attributes tv system).
And all menus listed in all LU must have number of programs and number of cells = 0.

The same is true for any titleset, but the ifo file is obviously the one for that titleset.

[r0lZ]

@mpucoder

The method used by PgcEdit when removing the menu VOB do exactly what you describe, except that it leaves the Stream Attributes definition as they are (at address 0x100-0x1FF) [EDIT: partially wrong. See later]

Are you sure it is important to reset them as well? I've never had problems with this. A player should not use that information if it has no cells to play, no?

Anyway, it's easy to fix, and I will do it in the next version.

[2COOL]

@r0lZ

How about PgcEdit doing a 0 KB VOB scan check during loadup? Just to make us more aware that they exist.

[r0lZ]

Well, it does the check when saving the DVD (to calculate the VTS sectors). Do you want a warning when the DVD is saved? It's a little bit difficult to add it when loading.

[2COOL]

Originally posted by r0lZ
Well, it does the check when saving the DVD (to calculate the VTS sectors). Do you want a warning when the DVD is saved?Hmmm...the earlier the better but any warning on this matter is good.

[mpucoder]

@rolz - it never hurts to be thorough. If there's one thing I've learned about computing devices is even the least likely event will occur - sometime. That, and the word "should" never applies.

I listed these things mainly so that anyone having this problem, as jojo15, can look to see if there are hints of a vob file. I was fairly sure PgcEdit was doing these things :)

[jojo15]

Well, someone else has the same dvd, and the same standalone as i have, so i presume i will get an error also, because he got one.
But i could also risk the coaster...

Edit: i just tried to burn with Nero, and it gives an error indeed, but it can be skipped, so should i give it a try?

[2COOL]

r0lZ and CoNS already gave you the fix so that Nero doesn't complain.

[jsoto]

Originally posted by mpucoder
VIDEO_TS.IFO locations 0x100 to 0x1ff should all be zero except location 0x100 IF PAL, in which case it should be 0x10 (to agree with the rest of the video attributes tv system). Exactly the same situation in VobBlanker as in PgcEdit. I'm not clearing these values....
But I don't understand well the suggested value in location 0x100. Why 0x10 in PAL and not, let's say, 0x1X?. Even more, why not the original values? I can understand why it is better to clear audio and subs values but I'm unsure about video...

jsoto

[r0lZ]

OK. PgcEdit 0.4.8 will display a warning if there are empty VOBs in the menu domains. (2COOL: the warning is displayed when loading the DVD :))
Also, it clears the menu stream attributes when the user remove the VOB with the Blank Out All Menu PGCs function.

@mpucoder: it leaves the PAL/NTSC flag at offset 0x100 unchanged. However, I have found that on ALL PAL DVDs I have tested, when the menu VOB is missing, the flag is ALWAYS 0 (NTSC)!

Note: I was partially wrong in my previous post: the number of audio streams (at 0x102) and the number of subpic streams (at 0x154) were resetted to 0, but not the video, audio and subpic attributes.

[blutach]

I have a simple DVD made essentially with BlankVOB and PgcEdit (PAL). Only VOB is a 10K VTS_01_1.VOB

Looking at VIDEO_TS.IFO's VMGM_MAT table, it is exactly as mpucoder says, except at byte 0x100 it is 0x5e00.

Doesn't seem to be an easy way to get it to 0x0000 either (at least not with IfoEdit).

Regards

[mpucoder]

It doesn't really matter what the other bits are as long as bits 5-4 match the values of vobs with video. The only program that actually cares about this is Philips Verifier.
Probably clearing the number of streams is enough, but, again, Philips Verifier will complain if any unused fields are non-zero.

[2COOL]

Originally posted by r0lZ
OK. PgcEdit 0.4.8 will display a warning if there are empty VOBs in the menu domains. (2COOL: the warning is displayed when loading the DVD :)):thanks:

[jojo15]

Thnx @ all,
with your help i fixed it and it works now!

[r0lZ]

Originally posted by mpucoder
It doesn't really matter what the other bits are as long as bits 5-4 match the values of vobs with video. The only program that actually cares about this is Philips Verifier.
Probably clearing the number of streams is enough, but, again, Philips Verifier will complain if any unused fields are non-zero. However, as I said before, most commercial PAL DVD are authored with NTSC in this field.

Also, libdvdread (mainly used on Linux platform) reports such authoring errors (when a value should be 0 and is not) as warnings in stderr.

[mpucoder]

However, as I said before, most commercial PAL DVD are authored with NTSC in this field.

I realize that, and I don't think it's an error myself. But lately people have been turning the Philips Verifier loose on everything, and it will call that an error.

If you don't mind posts like this (http://forum.doom9.org/showthread.php?s=&postid=591364&highlight=5607#post591364) (look for error 5607 and 5777)

[r0lZ]

OK. So, I must assume most professional DVD authoring software, used by the majors in the DVD industry, are not fully standard compliant. The question is therefore: is it the standard, or the ability of the players to deal with little errors that must be taken into account?

Another point: do you know a good burning software (to burn or to generate an ISO) that will automatically add the gaps between the IFOs and BUPs?
(See here (http://forum.digital-digest.com/showthread.php?s=&postid=221944))

[mpucoder]

Originally posted by r0lZ
OK. So, I must assume most professional DVD authoring software, used by the majors in the DVD industry, are not fully standard compliant.
You could say so, or that there is more than one way to interpret the standard. I haven't seen it, but those who have tell me it's every bit as clear as ISO 13818-3 :) This is just a minor thing that will not bother a DVD player.

My old burner came with RecordNow Max (by Veritas, but now sold by Sonic) that would honor the gaps placed there by the authoring software. I don't know of any that re-allocate to that scheme. Ages ago I devised a test for burners to see if they honored the gaps - maybe you'd like to use it?

[blutach]

@mpucoder

Thanks for your input and advice on this.

Am I wrong but when a Get VTS Sectors is done, it assumes all sectors are packed tightly, irrespective of the (potential) need for the gaps where VOBs are small in size?

Would it be safer, therefore, when blanking a VOB, for the blank to be not less than 32K?

I don't suppose it matters much unless you need to access a BUP (and this would presumably be in the case of an error on the disk). If the IFO can be read, then there's no problem, correct?

That test software would be useful, for sure.

Regards

[mpucoder]

The gap only matters for VIDEO_TS.VOB (unless you have a vts with not only no menu, but no video. The bup file follows the last vob file)
And I believe IfoEdit does pack down.

The test wasn't software, it was sets of files that you burn and then view. I'll look them up.

[blutach]

I guess that's the issue. After blanking out whole titlesets and their menus, only 10k "stubs" are left. These are, as you are aware, just a NAV pack and 4 video packs.

Am I missing something?

[r0lZ]

@mpucoder:
How exactly do you 'prepare' a DVD to leave gaps between IFO and BUP files? What pointer should be modified?
I have made a lot of tests (for example by forcing the VOB start sector to be higher than needed) without success.
Maybe I'll find the trick in your test files...

[mpucoder]

It's done by moving the "last sector of ifo" up (offset 0x0c). I've repackaged the tests into one zip (used to be 2) and taken the work out of making the no_gap version. You can download them from http://www.mpucoder.com/doom9/burner_gap_tests.zip
note: these have an 8k VIDEO_TS.VOB

[r0lZ]

Thanks!

[mpucoder]

That should be "last sector of VMG" or "last sector of title set" (offset 0x0c)

[r0lZ]

Yes. It's only a question of terminology.

[EDIT: removed a stupid question here]

The TitleSets starting sectors in VMG_TT_SRPT must be changed, too.

[mpucoder]

You're right. I did this so long ago I forgot (and I had been awake for 28 hours)

[2COOL]

Originally posted by mpucoder
You're right. I did this so long ago I forgot (and I had been awake for 28 hours) I hope that's not a sign of wear and tear. :(

[r0lZ]

Thanks to mpucoder, PgcEdit 0.4.8 will have an option to set the VTS Sectors so that the IFO and BUP files will be separated by at least 32KB (16 sectors).

Nero 6 is not able to keep the gaps as they are defined in the IFOs, but it will do a 'standard' Get VTS Sectors on the IFOs before burning them. Not verry good, but not so bad.

ImgTools Classic will do a good ISO image, keeping the gaps.

I will try to test some other burning programs...

[blutach]

Does anyone know if ImgTools classic is the "imagemaker" in DVD Shrink?

And what about IfoEdit's "Disk Image" function? Might that work?

Regards

[r0lZ]

Originally posted by blutach
Does anyone know if ImgTools classic is the "imagemaker" in DVD Shrink? I don't think so.
ImgTools Classic is in fact a frontend for mkisofs.exe, which is a Windows port of the Linux mkisofs, needing cygwin1.dll to operate. (CygWin is a small, shell only, Linux emulator for Windows.)
Anyway, as DVDShrink rebuilds the DVD, even if you don't strip or shrink anything, it does its own Get VTS Sectors. It is therefore useless for creating an ISO with the gaps added by PgcEdit.

[r0lZ]

Originally posted by blutach
And what about IfoEdit's "Disk Image" function? Might that work? Unfortunately, the first thing IfoEdit do when you launch his Disk Image function is a Get VTS Sectors. So, it is not suitable too.

[blutach]

@rolz

That's too bad for DVD Shrink and IfoEdit users.

Have you tested PgcEdit 0.4.8 with a disk that has many small VOBs?

Regards

[r0lZ]

Not yet. I am trying some DVD burner softwares.

For now, there are only 2 programs doing the job correctly, keeping the gaps:
- ImgTools Classic (not ImgTools Burn), but, as you know, it must create an ISO.
- Stomp's RecordNow MAX 4.50.

[jsoto]

I believe it's more simple (and compatible with all burning SW) to use a >32 KBytes menu VOB filled of unreferenced material. What do you think?

jsoto

[r0lZ]

Yes, it's a solution. But difficult to implement if you have already a small VOB, with referenced material. You should append enough data to pad it to 32K.

Also, note that 32K is too much. The exact size of the VOB must be at least 32K minus the size of the IFO file. [EDIT: WRONG: the vob must be at least 32K]

[mpucoder]

You mentioned Stomp's RecordNow Max, which is what I have on one burner (and it does keep the gaps). What about the newer RecordNow Max put out by Sonic, does it retain that ability?

btw - Stomp only marketed the product (oem), it was made by Veritas (after they bought it from Prassi). Sonic recently bought Veritas.

[r0lZ]

I cannot try Sonic's RecordNow, because they don't have a trial, downloadable version. Only screenshots and a small description. But I suppose it works, too.

[blutach]

Originally posted by jsoto
I believe it's more simple (and compatible with all burning SW) to use a >32 KBytes menu VOB filled of unreferenced material.Originally posted by r0lZ
Also, note that 32K is too much. The exact size of the VOB must be at least 32K minus the size of the IFO file. You might recall that I suggested that these VOBs be 32K. As far as I can tell, it doesn't have to be the difference, there just has to be 32k or more between the end of the IFO and the start of the BUP. If this is the case, no gaps are needed, yes?

It shouldn't be difficult to generate a blank VOB with 32K. We can make a 10k one now, so, just add 11 more video packs (4 are there already).

What does everyone think?

Regards

[jsoto]

I was thinking in append to VIDEO_TS.VOB just 4 blank cells, say VID=32767 and CID 252 to 255. This will add 40 Kbytes to the whole DVD (negligible, I think). What I'm not sure if these cells have to be listed in ADT and ADMAP tables... or just can be there absolutely unreferenced... Unreferenced material usually is listed in these tables, (but not in any PGC)

jsoto

[mpucoder]

Wouldn't it be simpler to repeat the gop (as Blutach suggests) several times? You know if they are not referenced some user will strip them out.
there just has to be 32k or more between the start of the IFO and the start of the BUP
That should be "32k or more between the end of the ifo..."

[r0lZ]

Correct. I have edited my previous post, at the top of this page.

[r0lZ]

Originally posted by jsoto
I was thinking in append to VIDEO_TS.VOB just 4 blank cells, say VID=32767 and CID 252 to 255. This will add 40 Kbytes to the whole DVD (negligible, I think). What I'm not sure if these cells have to be listed in ADT and ADMAP tables... or just can be there absolutely unreferenced... Unreferenced material usually is listed in these tables, (but not in any PGC)

jsoto Well. I don't like this solution, because PgcEdit must have the internal variables initialized for all VOB IDs, including missing ones, upto the highest ID it finds. So, if the last VOB ID is 32767, I will have to create a lot of variables to fill the gap between the real last VID and 32767. Of course, it's a limitation in PgcEdit. The method is not necessary bad...

[jsoto]

OK, only one cell repeating the GOP or ....
how about using padding packs?. You do not need to reference them in the IFOs, so it's really easy to implement ...
And you can adjust exactly the number of sectors you want...

I'm talking about 0x1be packs, but I've to confess I do not know them very well...

jsoto

[mpucoder]

The video_rm files I have use a different fill if there is nothing in the pack. They use stream bd, substream ff. (video_rm has a similar problem with filling up space).
Looks like this:
normal pack header with SCR
00 00 01 BD 07 EC 81 00 00 FF ... FF

[jojo15]

So..
i tried to burn again with Nero, but still get the error,
i think it's because "VTS_02_0.vob" was the 0 kb file,
but now there are still these files, which i think cause the error:
"VTS_02_0.bup", "VTS_02_0.ifo" and "VTS_02_1.vob".
But i don't know if i fixed it correctly with PGCEdit.
This is what i did:
I opened the DVD with PGCEdit,
then i got this list which named a VMG, VMGM's, VTSM 1's, VTST 1's and a VTSM 2 and a VTST 2.
Then i right-clicked the VTSM 2 (because there is a 2 in it, i think it has to deal with VTS_02....), and used the "Blank out all Menu PGC's" option.

Am i doing something wrong, or am i not fully fixing it?

Thnx for help in advance!

[blutach]

Originally posted by mpucoder
That should be "32k or more between the end of the ifo..." Sorry - post edited.

@rolz Does this have implications for the way you have implemented the "gap" in PgcEdit's 0.4.8's Save function?

[blutach]

Originally posted by jojo15 (Jan 11)
Thnx @ all, with your help i fixed it and it works now! Originally posted by jojo15
So..
i tried to burn again with Nero, but still get the error, i think it's because "VTS_02_0.vob" was the 0 kb file, but now there are still these files, which i think cause the error:
"VTS_02_0.bup", "VTS_02_0.ifo" and "VTS_02_1.vob".
That is not good news jojo15. I thought you had it working :( . What did you do differently from 2 days ago?

What you describe about blanking all menu PGCs in PgcEdit is fine, except there were no menu PGCs to blank!

This is strange behaviour from Nero - it usually accepts these 0 byters without problem. Have you read this thread? You might want to use PgcEdit's new save function and make an image with ImgTools Classic, which has a back end burn to DVD Decrypter.

Regards

[jojo15]

First,
these 3 files i mentioned, are not 0 kb files, to make that clear.
Second, which new save function do you mean (1. a save function was added or 2. there's a different way of saving or a different way to save?)

[blutach]

@jojo15

There is a new Beta version of PgcEdit out which incorporates a new option to save with gaps (which might enable your standalone to work).

I would expect it to be released soon but you might PM rolz for a copy. Like all Betas, it must be considered a bit experimental, until release.

After saving the project, you can use ImgTools Classic (v0.91.4) to make an ISO (www.coujo.de), which can also burn using DVD Decrypter.

Regards

[jsoto]

Hi guys
I did some tests with this padding pack:


[Pack Header]
[0000] Pack identifier (start code) 442 [000001ba]
[0004] SCR (System clock reference) 68 0 4 0 4 1 [44 00 04 00 04 01 ]
SCR 00000000.000
[000a] Program Mux Rate: 25200 (1260000 BPS) (10080000 bps) 1 137 195 [01 89 c3 ]
[000d] Pack stuffing length: 0 248 [f8]


[Padding Stream]
[000e] Padding Stream start code 446 [000001be]
[0012] Length 2028 [07ec]
[0014] Padding Frame 255 255 255 255 255 .....


Well, Nero complains if there is no at least one Nav pack (and its reference in ADT table) in the VOB. So we have to use at least one (referenced or unreferenced) cell. So the strategy could be:
- If there is already one cell (used in a PGC), but the VOB is too small, just add padding packs at the end. I believe you have to adjust the last sector of the cell in the IFO...
- If there is no menu, generate one blank cell (VID=1; CID=1) and add the required padding packs. Reference the cell in ADT table and its VOBU in ADMAP one.

@mpucoder
The video_rm files I have use a different fill if there is nothing in the pack. They use stream bd, substream ff. (video_rm has a similar problem with filling up space).
Looks like this:
normal pack header with SCR
00 00 01 BD 07 EC 81 00 00 FF ... FF
Is this your padding pack?

[Pack Header]
[0000] Pack identifier (start code) 442 [000001ba]
[0004] SCR (System clock reference) 68 0 4 0 4 1 [44 00 04 00 04 01 ]
SCR 00000000.000
[000a] Program Mux Rate: 25200 (1260000 BPS) (10080000 bps) 1 137 195 [01 89 c3 ]
[000d] Pack stuffing length: 0 248 [f8]

[Private Stream 1]
[000e] Private Stream 1 start code 445 [000001bd]
[0012] Length 2028 [07ec]
[0014] PES Header data content flags 33024 [8100]
PES scrambling control: 0
PES priority: 0
data alignment indicator: 0
copyright: 0
original or copy: 1
PTS exist?: 0
DTS exist?: 0
ESCR flag? 0
ES rate flag: 0
DSM trick mode flag: 0
additional copy info flag: 0
PES CRC flag: 0
PES extension flag: 0
[0016] PES HeaderData length 0 [00]

[0017] Stream ID 255 [ff]


"video_rm": What does it mean?. Do you mean files from a DVD video_recorder?

jsoto

[r0lZ]

Originally posted by blutach
Sorry - post edited.

@rolz Does this have implications for the way you have implemented the "gap" in PgcEdit's 0.4.8's Save function? No. It was only an error here. The gap must be 32K minus the size of the VOB (was IFO). Obviously, if the VOB is used to fill the gap, the VOB must be at least 32K.

[mpucoder]

@jsoto - yes to all. Video_rm is the DVD compliant mode for a video recorder, unlike VR mode. Whenever a recording ends the recorder has to fill the ECC block with something and allocate it. Theoretically with rw media that's not necessary, the block could be read-modified-rewritten. But it's a lot simpler to do the same thing for both types of media.

[jojo15]

I also have this movie in ISO already (got it that way) but i mounted it and copy'd the vobs and all to my hdd to be able to fix the problem,
because i hear beforehand there was this 0 kb vob in it.
Should i try to burn it using the original ISO then?

[CoNS]

hehe, this thread is called "little prob (i think)", and has around 60 replies already!! :)

[2COOL]

Exactly 60 with this needless post. ;)

[blutach]

How OT are we? Sorry jojo15.

Fascinating thread though.

(Sorry for yet another mindless post by me)