Log in

View Full Version : Error? Message when rebuilding


rcubed
25th November 2007, 08:29
Jdobbs this is probably a question you can address.

In an attempt to keep it generic, I have the following probem. When processing certain rips of a DVD with DVD-Rebuilder (Pro) it produces messsages as follows (cut from DVD Rebuilder log):

- Updating NAVPACKS for VOBID_04
SOURCE IS CORRUPT: VTS_06 VOBID: 05/CELLID: 01 was not found in the VOB.
SOURCE IS CORRUPT: VTS_06 VOBID: 05/CELLID: 02 was not found in the VOB.
SOURCE IS CORRUPT: VTS_06 VOBID: 05/CELLID: 03 was not found in the VOB.
SOURCE IS CORRUPT: VTS_06 VOBID: 05/CELLID: 04 was not found in the VOB.
SOURCE IS CORRUPT: VTS_06 VOBID: 05/CELLID: 05 was not found in the VOB.
SOURCE IS CORRUPT: VTS_06 VOBID: 05/CELLID: 06 was not found in the VOB.
SOURCE IS CORRUPT: VTS_06 VOBID: 05/CELLID: 07 was not found in the VOB.
- Updated VTS_C_ADT.
- Updated VTS_VOBU_ADMAP.
- Updated IFO: VTS_06_0.IFO
- Updating TMAP table...
- Correcting VTS Sectors...

This occurs in multiple VTSs.

Using ignore allows one to bypasses this error and the resultant DVD appears to play properly. Is this an acceptable procedure (i realize it may be unorthodox). Note the VTSs can be corrected with PGCEdit, but this is a time consuming process and subject to errors on my part. The structure of the source DVD is deliberately corrupted. I can supply addition information off line if required.

BTW I've been really happy with the quality of rebuilds I get with DVD Rebuilder, I normally use the HC Encoder to encode. I've tried with my copy of ProCoder Express, but it doesn't seem to work well. I second the vote that re encoding a DVD gives better results that transcoding with Shrink. I've notice pixilation in some cases with Shrink (on small items of detail) that don't show up when done with Rebuilder.

Thanks in advance,

rcubed

blutach
25th November 2007, 08:53
Looks like you got a mismatch between the IFOs and VOBs. This can be fixed with FixVTS (www.videohelp.com/~FixVTS) or VobBlanker (http://jsoto.posunplugged.com/vobblanker.htm) with little or no effort.

It probably play "properly" because the DVD may not actually play a cell in that VTS (due to structure protection).

Regards

rcubed
25th November 2007, 22:44
Looks like you got a mismatch between the IFOs and VOBs. This can be fixed with FixVTS (www.videohelp.com/~FixVTS) or VobBlanker (http://jsoto.posunplugged.com/vobblanker.htm) with little or no effort.

It probably play "properly" because the DVD may not actually play a cell in that VTS (due to structure protection).

Regards

Blutach,
Thanks for your reply. I appreciate the time you take to help out us newbies. This one has been driving me nuts. I have tried cleaning the rip with just FixVTS, but that doesn't seem to help. Vob Blanker complains about several things when the files are loaded. Interesting enough RipIt4Me with all the cleaning options used seems to clean it up, but that option may not work in the future.

I also have used PGCEdit to remove cells that appear to be causing the problem, but that is rather hit or miss on my part due to my limited knowledge of internal DVD structure, I'm doing research now, but as one of my programmer friends used to say "It's hhhhhhhhhhaaaaaaaaarrrrrrrrddddddd" (in a whiney voice) :D

I have included the examples from PGC edit for the rip that fails and the one from RipIt4Me, as well as the messages from VobBlanker. I also agree that it will probably play properly, but wasn't sure how Rebuilder actually handles this. Any additional comments would be appreciated.

rcubed

blutach
25th November 2007, 23:56
If RipIt4Me has cleaned things up, why are you worried? Does DVD Rebuilder (http://dvd-rb.dvd2go.org/) work now? Let the future take care of itself.

In VobBlanker (http://jsoto.posunplugged.com/vobblanker.htm) do a full scan (Alt-F) and process.

And your PGC edits MAY not be quite correct, as cell 1 has been eliminated. Assuming this is the entry point of the title, it plays and executes cell command 2. That may set a register and play something else (if no register is set before the title starts playing in earnest, then you can freely remove the tiny cells). Use trace mode to see which cells are actually played. In any event, according to the diagram, that is VTS2 and DVD Rebuilder (http://dvd-rb.dvd2go.org/) complains about VTS 6.

That's about all I can really say on this one.

Regards

rcubed
27th November 2007, 01:13
If RipIt4Me has cleaned things up, why are you worried?
Regards

Blutach,
Back with questions one more time.

The example I gave from PGCEdit was typical of what one sees in the VTSs including the one I didn't post for VTS 6.

When I blanked all the cells that DVD Rebuilder was complaining about, using VobBlanker the DVD would re encode properly. After thinking about your comment removing the cells with PGCEdit in fact would possibly remove commands necessary for the DVD to function correctly I tried blanking them. If I understand the "blanking" process correctly, the cells are replaced with a substitute that in this case appears to correct the corrupt source cells issue, or is this in conjunction with the additional processing that VobBlanker causes the VOBs and IFO to be corrected. Does blanking leave intact the cell commands that were present so if needed the DVD will play properly in all cases.

I tried tracing the path using the trace option in PGCEdit, but I got wrapped around the axle - confused is probably a better word.

Is there another way to determine which cells should be blanked rather than making two passes with DVD Rebuilder? If there are guides or other info on the net that will help with the process can you direct me to them. :stupid:

Also on the Alt-F operation in VobBlanker, should there be any messages during or when this processing is done? I tried it and there were no messages, and the result w/o blanking the cells failed to re encode.

The reason I'm asking is that one of these days RipIt4Me won't work on a DVD and then what does one do? Besides it's got my interest up. Who ever wrote RipIt4Me was apparently one smart individual probably why the "powers that be" got on his act.

Thanks again for your kind help and responses.:thanks:

rcubed

blutach
27th November 2007, 04:26
Well, you are kinda answering the question yourself. Blank tiny cells in DVDRB and you can be sure they will be replaced with MPEG2 compliant cells (7kb of vid).

The PgcEdit trace isn't all that hard - just put a breakpoint on the PGC you are interested in (Ctl-Shift-T). Start trace mode and click Run. Then when you get to your PGC, step through it command by command and see which cells play and which commands execute.

The reason the tiny cells remain is probably because they are played or a cell command jumps out of the PGC. Normally, they are eliminated by the ripper.

Regards

rcubed
27th November 2007, 05:49
Well, you are kinda answering the question yourself. Blank tiny cells in DVDRB and you can be sure they will be replaced with MPEG2 compliant cells (7kb of vid).
Regards

Blutach,
I think you misunderstood. I was blanking them using VobBlanker not DVDRB. As far as I can determine, the resolution on what you can blank in DVDRB does not go down to the same cell level that VobBlanker allows, or am I missing something? The individual cells in question seemed to be more easily identified in VobBlanker.

Also I'm still unclear as to what does the Vobs Full scan do in VobBlanker, and will any messages be generated during the process?

I'm getting a little more comfortable with trace in PGCEdit. It's been a long time since I've tried to use it.

Thank you for your patience, since I got older my skull seems to be a lot thicker and prevents info from getting in as fas as it used to 30 or 40 years ago. :D

Thanks,

rcubed

P.S. Tried blanking cells in DVDRB, although I'm still not clear on which cell is which. Probably need some help on notation for cells in Preview/Edit window. I blanked all the short ones. I'll post when it's done re encoding.

No go. See attachments. The VobBlanker widow shows the cells and the blanking selected. The DVDRB window only shows No individual cells for VTS 1? Help!!!!!!! How does one accomplish the same thing in DVDRB?

blutach
27th November 2007, 09:02
Well, the VobBlanker screen tells you the reason here. VCID 2/1 thru 2/7 are not compliant. They are only 1 pack (2048 bytes). These are the ones you blank in DVDRB's segment editor. But, according to DVDRB, these cells don't appear in the VOB ... the ripper has not removed them from the IFO structure. In this case, the rip is bad.

In general, anything you want to blank in DVDRB, just click in the little "Blank" box. No 3rd party apps are really necessary.

Regards

linx05
27th November 2007, 10:59
Well, the VobBlanker screen tells you the reason here. VCID 2/1 thru 2/7 are not compliant. They are only 1 pack (2048 bytes). These are the ones you blank in DVDRB's segment editor. But, according to DVDRB, these cells don't appear in the VOB ... the ripper has not removed them from the IFO structure. In this case, the rip is bad.

In general, anything you want to blank in DVDRB, just click in the little "Blank" box. No 3rd party apps are really necessary.

Regards
But Fengtao says (http://club.cdfreaks.com/1940628-post8.html) it is DVD Rebuilders fault? Who is right? I would think it would be the rippers duty to clean the crap out.

blutach
27th November 2007, 11:45
It is the ripper's duty to clean it out. You can't expect DVDRB to make up for poor source material.

And no way a cell of 2k is legit. No wonder DVDRB complains. Anyway, how hard is it for the ripper to put a proper blank in there? It is trivially easy.

Quoting mpucoder's site:

The VOBU
The next higher logical structure is called the Video OBject Unit, or VOBU. Each VOBU starts with a NAV pack and contains approximately half a second of the program. The size of the VOBU is determined by the video coding unit called a Group Of Pictures (GOP). A VOBU will contain one or more complete GOP, as needed. The last video pack in each VOBU is padded if needed with either a padding stream or stuffing bytes. Audio and subpictures with DTS values within the same range of values as the video are included in each VOBU. Audio is not padded until the end of the cell, therefore audio frames can span VOBUs.

The Cell
Cells are the next higher logical structure, containing any number of whole VOBUs. Their length and placement is entirely arbitrary and depends on the overall organization of the program (movie). Chapters, multiple angles, titles, and even how the "prev" and "next" buttons on a remote act all dictate the placement of cells. So a cell contains at least 1 VOBU. On this basis, Fengtao is mistaken.

However, a countrary view is given here (http://www.dvd-replica.com/DVD/cella.php). On this basis, a navpack alone is OK. If this is so, then obviously the VCID in the VOB should match that in the IFO.

However, I have never seen a cell without ANY video at all. As I said, it's trivially easy to make a blank.

Regards

linx05
27th November 2007, 14:24
Ah ok. Thanks for the explanation. It's frightening how much you guys know about this stuff!

You might like to post this in one of those threads on CDFreaks. I would but Fengtao has a penchant for deleting or editing my posts :mad:

rcubed
27th November 2007, 22:03
Ah ok. Thanks for the explanation. It's frightening how much you guys know about this stuff!

You might like to post this in one of those threads on CDFreaks. I would but Fengtao has a penchant for deleting or editing my posts :mad:

Blutach,
I second that. I don't like having to put you in the middle, but you seem to be the only one that has sufficient knowledge to address this issue and at least willing to have a discussion on the topic. I appreciate it. You've always been willing to share your considerable knowledge with those of us who are less knowledgeable.

I think part of the problem may lie with the pathfinder method that is being used. I tried it on the afore mentioned disk and looked at DVDFab log. It claims it removed all but a few of the cells found offending by DVD Rebuilder. I suspect the ones that it missed weren't actually in the path (i.e. never played). The interesting thing is that DVDFab earlier versions did in fact fix the problem and yielded a clean rip.

Doesn't removed imply updating other info in the structure to actually remove the cells? See following log dump.

Here's a portion of the log from DVDFab


Disc type: Video DVD
Disc region: 1
Volume name: RATATOUILLE
Video standard: NTSC
Layer 0 size: 2097520 sectors (4096 MBytes)
Layer 1 size: 2097520 sectors (4096 MBytes)

CSS (Content Scramble System) protection is removed!
RC (Region Code) protection is removed!
RCE (Region Code Enhancement) protection is not found.
APS (Analog Protection System) protection is removed!
UOPs (User Operation Prohobitions) protection is removed!
Structure protection (ARccOS, RipGuard, etc.) is removed!
2 fake vts protections are removed!
34 potential bad sector protections are removed!
Invalid PGCs protection is not found.
Invalid CELLs protection is removed!
Invalid VOBUs protection is removed!

PathPlayer is enabled!
Unplayable cell (vts:1 title pgc:1 cell:3) is removed!
Unplayable cell (vts:1 title pgc:1 cell:4) is removed!
Unplayable cell (vts:1 title pgc:1 cell:5) is removed!
Unplayable cell (vts:1 title pgc:1 cell:6) is removed!
Unplayable cell (vts:1 title pgc:1 cell:8) is removed!
Unplayable cell (vts:2 title pgc:1 cell:2) is removed!
Unplayable cell (vts:2 title pgc:1 cell:3) is removed!
Unplayable cell (vts:2 title pgc:1 cell:5) is removed!
Unplayable cell (vts:2 title pgc:1 cell:6) is removed!
Unplayable cell (vts:2 title pgc:1 cell:15) is removed!
Unplayable cell (vts:3 title pgc:1 cell:2) is removed!
Unplayable cell (vts:3 title pgc:1 cell:3) is removed!
Unplayable cell (vts:3 title pgc:1 cell:5) is removed!
Unplayable cell (vts:3 title pgc:1 cell:6) is removed!
Unplayable cell (vts:3 title pgc:1 cell:16) is removed!
Unplayable cell (vts:4 title pgc:1 cell:3) is removed!
Unplayable cell (vts:4 title pgc:1 cell:4) is removed!
Unplayable cell (vts:4 title pgc:1 cell:5) is removed!

Is it worth it to post this information and ask Fengtao?

Question: What is the function of the Access Restricted Flag in those cells? Can this be used as an aid in finding cells that need to be corrected (I'm assuming the setting of the cells to blanks in VobBlanker is a valid correction method).

Question: Why don't these cells cause problems with transcoders?

Thanks again for your inputs and help.

rcubed

rcubed
28th November 2007, 17:01
Jdobbs,
Looks like this is an issues about cells that just contain NavPacks.

Apparently there are two schools of thought as to whether or not these are a permitted structure. Again my knowledge is insufficient to judge one way or the other. One "unofficial" spec I have seems to imply it is allowed, I think it's the same one Blutach quoted earlier in one post in this thread.

Fengtao is not interested in fixing the problem on his end. :mad: Is there something you can do in Rebuilder to help. Or is there some other structure issue that makes this difficult or not practical?

If this is an isolated incident unique to this DVD, then it may not be worth it for anyone to take the time to correct. But I suspect this is the beginning of another perverted attempt to thwart backing up DVDs.

I really like Rebuilder and think it is a terrific tool. I use it exclusively now and never transcode. :D

Thanks for any comments and or help

rcubed

blutach
28th November 2007, 21:00
Three things:

1. Fengtao is a member here and can discuss it if he wishes to.

2. This seems to be an issue regarding decrypting - well, at least a certain decrypter. Interesting as it is, I can not "get in the middle" of such an issue.

3. For the moment, I'd not use DVD Fab. There are alternative solutions that work.

Regards

blutach
28th November 2007, 21:04
As for the access restricted flag, a search here will turn up the following (and several other posts):

http://forum.doom9.org/showthread.php?p=843776#post843776
http://forum.doom9.org/showthread.php?p=783618#post783618

Regards

rcubed
29th November 2007, 06:09
Three things:

1. Fengtao is a member here and can discuss it if he wishes to.

2. This seems to be an issue regarding decrypting - well, at least a certain decrypter. Interesting as it is, I can not "get in the middle" of such an issue.

3. For the moment, I'd not use DVD Fab. There are alternative solutions that work.

Regards

Blutach
1. As I pointed out Fengtao doesn't seem to be interested in discussing it. Which is his right.

I'm going to shelve it for the time being and get back to doing other things. :D

2. I can appreciate your not wanting to get in the middle of things, and I wouldn't expect you to or ask you to. It's not really your issue. I do appreciate your taking the time to discuss as much as you have.

3. I agree. I will continue to use alternative solutions that do work.

Thanks for the link about the restricted flag. That explained it very well. I looked in my unofficial DVD standard manual and couldn't find it. I don't remember if I had an electronic copy somewhere if so I can't find it at the moment. I would have done a text search on the electronic one. It is generally a lot better than my poor old eyes and brain working on a hard copy. A lot faster and more accurate too ;)

Again thank you for the time you've taken on this. :thanks:

Cheers,

rcubed

blutach
29th November 2007, 06:59
NP rcubed. I did make a post on CDF, but have said all I'm going to say there on the matter.

Always happy to help.

In the short term, if you must use Fab, I'd ensure you had compliant MPEG2 video attached to the cells. Others posters on CDF seem to have reported that VobBlanker can assist in this regard.

Regards

linx05
29th November 2007, 11:12
Thanks for the posts blutach. It's much appreciated.

rcubed
29th November 2007, 21:23
NP rcubed. I did make a post on CDF, but have said all I'm going to say there on the matter.

Always happy to help.

In the short term, if you must use Fab, I'd ensure you had compliant MPEG2 video attached to the cells. Others posters on CDF seem to have reported that VobBlanker can assist in this regard.

Regards

Blutach,
Yes I have been able to "fix" the DVDFab rip by putting blank cells in the offending cells using VobBlanker. This produces a "compliant DVD" that DVDRebuilder is happy with. Not to belabor the point ( or should it be belabour :p ) , but there appears as you pointed out two schools of thought on what a compliant DVD is. My vote is with what VobBlanker produces.

My problem was in trying to determine which files should be blanked. I was using the list of files that DVD Rebuilder was complaining about to do the blanking. Laziness on my part, since it involved Rebuilding the DVD twice. Plus I was trying to save paper, since I needed to print out the log to keep track of the list - green is in these days. I was hoping to find a one step solution, no big thing since from my experience to date this only happens on the one DVD.

One another note, I'd forgotten you're in down under territory. You must be getting ready to enjoy summer. Up here in the north in the good old USA we're facing winter, which now as I'm older isn't nearly as much fun as it was 20-30 years ago. I now notice joints I didn't even know I had. ;) So think of us poor slobs when you're out surfing. Also have you managed to steal the title yet? " Not quite as big a bastard as Shamus. Hoping to improve" :D

Thanks again!!

rcubed

setarip_old
29th November 2007, 22:14
@rcubed

Hi!

Despite your concern about its FUTURE effectiveness, you should consider using RipIt4Me as your ripper of choice - and, in doing so, you'll be assured of a "proper" rip.

As of now, there are VERY FEW DVDs (Primarily, "New Line Home Entertainment" new releases) that RipIt4Me cannot properly process...

blutach
29th November 2007, 23:03
LOL rcubed. Sadly, my very good friend Shamus (also an Aussie but from up north) will cling to that title for some time to come yet.

I think you have in this thread what you need.

Regards

rcubed
30th November 2007, 01:10
@rcubed

Hi!

Despite your concern about its FUTURE effectiveness, you should consider using RipIt4Me as your ripper of choice - and, in doing so, you'll be assured of a "proper" rip.

As of now, there are VERY FEW DVDs (Primarily, "New Line Home Entertainment" new releases) that RipIt4Me cannot properly process...

Yep that continues to be the one of choice for me. I start with it if it doesn't work I try others. Works almost all the time. I think I had maybe one or two in the last several months that it wouldn't handle. RipIt4Me was a really nice piece of work. To bad the powers to be got on its developer's act. Nuff said about that.

Thanks again.

rcubed

rcubed
30th November 2007, 01:11
LOL rcubed. Sadly, my very good friend Shamus (also an Aussie but from up north) will cling to that title for some time to come yet.

I think you have in this thread what you need.

Regards

As you said you need to try harder:sly:

Cheers,

rcubed

metal07
1st December 2007, 01:41
Despite your concern about its FUTURE effectiveness, you should consider using RipIt4Me as your ripper of choice - and, in doing so, you'll be assured of a "proper" rip.

As of now, there are VERY FEW DVDs (Primarily, "New Line Home Entertainment" new releases) that RipIt4Me cannot properly process...

It is not so "FUTURE" now as I believe studios in particular New Line will expand this usage as per the recent Hairspray DVD.

setarip_old
1st December 2007, 03:29
@metal07

Hi!

As I previously stated (and you've now repeated), thusfar, "New Line" is the primary, if not sole, major studio using this annyoying protection scheme (that includes, among other things, fake directory listings for: multiple .VOBs, outrageously large .IFOs and mismatched .BUPs).

Only time will tell if other studios will jump on this already-failed "bandwagon" and apply this type of protection.

In the meanwhile, RipIt4me continues to perform admirably, with that one exception...

rcubed
1st December 2007, 05:39
@metal07

Hi!

As I previously stated (and you've now repeated), thusfar, "New Line" is the primary, if not sole, major studio using this annyoying protection scheme (that includes, among other things, fake directory listings for: multiple .VOBs, outrageously large .IFOs and mismatched .BUPs).

Only time will tell if other studios will jump on this already-failed "bandwagon" and apply this type of protection.

In the meanwhile, RipIt4me continues to perform admirably, with that one exception...

setarip,
You said it all.

rucbed

blutach
1st December 2007, 11:24
Seems Fab has come out with an option regarding removing useless cells in 4.1.0.6 Beta to allow it to be compatible with DVD Rebuilder (http://dvd-rb.dvd2go.org/).

See http://club.cdfreaks.com/f116/dvdfab-4-0-1-6-beta-233060/

Regards

rcubed
3rd December 2007, 06:42
Seems Fab has come out with an option regarding removing useless cells in 4.1.0.6 Beta to allow it to be compatible with DVD Rebuilder (http://dvd-rb.dvd2go.org/).

See http://club.cdfreaks.com/f116/dvdfab-4-0-1-6-beta-233060/

Regards

All,
According to the tests I've run with 4.0.1.6 Beta, the problem is still present. See DVDFab 4.0.1.6 Beta #36 over at CDFreaks.

rcubed

r0lZ
3rd December 2007, 11:15
The Access Restricted flag is a good indication that the cell is protected, but some cells with that flag are usually played (and therefore are legal.)

The protection works by skipping some unreadable cells.

For example, imagine a DVD with 3 protected cells at the beginning of the movie PGC.
Cell 1 might be played, and have the access restricted flag, and a cell command that jumps to cell 3. Cell 2 is therefore skipped, and cell 3 is played immediately after cell 1. Cell 3 has also the access restricted flag, but no cell command. Therefore, cell 4 (the real beginning of the movie) is played after cell 3.
The access restricted flag is necessary on cell 1 because otherwise the user could press the Next button when the cell is playing, In this case, the cell command is skipped, and therefore, cell 2 is played, causing a crash of the player.
The access restricted flag is necessary on cell 3 as well, as if the user presses the Prev button during its playback, cell 2 could also be played.
The access restricted flag is not necessary on cell 2 (protected) as that cell is never played, but it is usually set anyway.

Of course, that's only a simple example. To make things more complicated to understand, there are usually a lot of tiny cells and cell commands. Some of them are protected, and others are played. There might be protected cells at the end of the movie as well. And the cell commands contain fake or real conditions so that they are not always executed. And the cell commands can jump elsewhere in the DVD (usually in the post commands of the current PGC) where there are commands that jump back to a specific cell of the protected PGC.

Unfortunately, due to this complexity, it is impossible to describe an universal method to remove the bad cells. But short cells in chapter 1 or at the end of the movie, especially when they have the access restricted flag, can usually be removed. Use the preview to find where the movie starts and ends really, and the trace to understand how to fix the navigation. As blutach said, some cell commands might be necessary so that the navigation can continue normally. Therefore, removing the tiny cells without fixing the navigation before can be dangerous.

Of course, to do a movie-only backup, you don't need to fix the navigation. It is only necessary to remove the tiny cells at the beginning and end of the movie, and all cell commands. The navigation will be remade from scratch anyway. (DVDShrink is a good tool to do that. You can use it with "no compression" if you prefer to use DVDRB to compress the movie.)

rcubed
3rd December 2007, 19:05
roiz,
Thanks for the explanation. I suspected there wasn't an all inclusive "easy" way to determine what should be removed. Is previewing the cells in VobBlanker and if they don't appear to have any "useful" video in them then blank them. If I understand correctly, that will maintain the commands in the cells in case they are needed, or can blanking also remove them?

Thanks for you input.

rcubed

r0lZ
3rd December 2007, 19:22
Blanking cells should not modify the commands.

However, note that blanking a whole PGC can modify the pre-commands to skip its playback completely. (It's an option that you can turn off anyway.)

rcubed
3rd December 2007, 19:37
Blanking cells should not modify the commands.

However, note that blanking a whole PGC can modify the pre-commands to skip its playback completely. (It's an option that you can turn off anyway.)

Thanks,
That was quick.:cool: I noticed that there were warnings when one had blanked everything, now I understand it better. As I mentioned in the other thread I'm still struggling to get my arms around all the things in a DVD :o

One other question what does the check all Vobs full scan option do (i.e. will it fix things or just give the user warnings if problems are found)? If I remember correctly VobBlanker may not look at the Vobs until it starts processing the data, is this a way to do it before hand?

Thanks in advance.

rcubed

r0lZ
3rd December 2007, 20:21
Honestly, I don't remember exactly what this option does. And I think I have never used it. But you should not need it.

blutach
3rd December 2007, 22:02
It goes thru the DVD and checks the various IFO tables against each other and rebulds them where necessary.

Regards

blutach
4th December 2007, 09:08
Interested readers can note mpucoder's opinion about the legality of the ripped DVD here (http://forum.doom9.org/showthread.php?p=1072433#post1072433).

Regards

hallway
9th December 2007, 02:27
I just ran into this same error with Ratatouille. It was ripped with DVDFab 4.0.1.6 (beta), main movie *only*, and then ran FixVTS against it. I got no errors during the encoding process. Here's the status log, rebuild portion only, with a bunch of redundant entries removed (no errors in any of them):

==========================================
[19:38:26] Phase III, REBUILD started.
- Copying IFO, BUP, and unaltered files...
- Processing VTS_01
- Reading/processing TMAP table...
- Rebuilding seg 0 VOBID 1 CELLID 1
(snip)
- Rebuilding seg 34 VOBID 1 CELLID 35
- Updating NAVPACKS for VOBID_01
(snip)
- Rebuilding seg 86 VOBID 2 CELLID 52
- Updating NAVPACKS for VOBID_02
SOURCE IS CORRUPT: VTS_01 VOBID: 03/CELLID: 01 was not found in the VOB.
- Updated VTS_C_ADT.
- Updated VTS_VOBU_ADMAP.
- Updated IFO: VTS_01_0.IFO
- Updating TMAP table...
- Correcting VTS Sectors...
- Building ISO Image...
==========================================

I'm not going to burn this one but will try and mount it with Daemon Tools and see if it plays. I suspect it won't but one of the earlier posts said the DVD does play okay.

Edit: Rebuild reports processing okay now.

blutach
9th December 2007, 04:28
Long and the short of it is that this is nothing to do with DVDRB.

Regards

hallway
9th December 2007, 06:45
Shouldn't this 2-page thread be moved to a more appropriate area then ?

rcubed
15th December 2007, 06:45
To all,
The latest release of DVD Fab (4.0.2.0 Beta) fixes the issues I was having with Ratatoulle. I did a complete rip with pathplayer on and did not delete or modify any VTSs. The resultant rip processed without errors in DVD-RB Pro. The rip plays with Roxio DVD Max 2.0 on my PC and the re encoded rip from DVD-RB written to a RW played ok on my Sony stand alone. :)

We should all thank Fengtao, for taking the time and effort to address and fix the problem. :)

rcubed