Log in

View Full Version : DVD-RB RC4. Hide and Seek. DVD Shrink won't read DVD-RB output = not good...


JFerguson
4th August 2005, 19:15
Ok,

First, DVD-RB rocks! :) I've been using this program for about a month (after having used Big 3 occasionally) and I don't think I'll ever go back to Big 3.

Now, this movie. I know it's been a bugger, and I'm not sure we're getting a clean build, even with RC4.

It doesn't pass the "Shrink test". That is, if DVD Shrink cannot read it, then I generally take that to mean that something isn't quite right. In fact, I usually pass a backup (however done) through DVD Shrink at No Compression just to clean things up before burning it.

Also, one thing I've noticed with DVD-RB output passed through DVD Shrink -- a lot of times, Shrink doesn't make any changes to the .IFOs and that means that DVD-RB's output is clean, and I have not seen that with other processes. Like I said, this proggie rocks!

Ok, more about the problem...

DVD Shrink v3.2 does not like DVD-RB's output for VTS_08 (the movie). It gives this error:

"Invalid DVD navigation structure"

I've tried both correcting the IFO files and the NavPacks with IfoEdit and it doesn't help.

Anyway, I was wondering what the thoughts were on this - thanks!


p.s. - Some tips:

Use DVD Shrink v3.0b5 for narrowing things down with a "Shrink test". That version allowed you to still open DVDs by individual .IFO file.
If you like to filter whatever output through Shrink as a prereq to burning, and the output does not need compressing, then make sure you select "No Compression". If you leave it at "Automatic", DVD Shrink may apply some minimal compression, and in some cases clobber some video. This is a bug that goes way back to v2.3 or earlier, I believe.

JFerguson
4th August 2005, 19:17
Also, I did movie, menus, and some extras (selected blanking), if that matters...

jdobbs
4th August 2005, 19:38
That has been reported, it only happens with ILVU. Of course I take exception to the "Shrink test" -- because you are making the assumption that Shrink is right...

Interestingly the discs reported play fine on all players tested so far... but I'm still looking at it, I suspect something is wrong.

JFerguson
4th August 2005, 20:18
jdobbs,

Some more information:

Yes, Shrink could be wrong, but I've never seen an instance where DVD Shrink couldn't read a factory pressed disc (not sure about ArcCos media, though). It reads the pressed version of this title without issue.

I've run several ILVU titles through DVD-RB, this is the first one that I've seen unreadable by Shrink.

I've previewed the output, it looks like it's fine, but DVD players can be forgiving so it's hard to tell. And with the trouble this title's been giving, I just have to suspect, as you do.

Shrink makes this determination ("Invalid DVD navigation structure") pretty quick. Would this be an issue in the .IFO or .VOB?

jdobbs
4th August 2005, 21:40
I'm not sure. I'm looking into it.

JFerguson
4th August 2005, 23:08
Ok, cool. Meanwhile, I'll dump the IFOs for the factory and rebuilt versions and see if anything looks suspicious.

jptheripper
4th August 2005, 23:21
oh just to let you know, big 3 backups of the questionable sort rarely are openable in shrink.

here is a thread on it

http://forum.doom9.org/showthread.php?t=74712&highlight=big+shrink

JFerguson
5th August 2005, 01:23
oh just to let you know, big 3 backups of the questionable sort rarely are openable in shrink.

here is a thread on it

http://forum.doom9.org/showthread.php?t=74712&highlight=big+shrink

Yep, have known that for a long time!

JFerguson
5th August 2005, 05:27
Ok, I dumped the IFOs. I don't see too much out of the ordinary, but then again, I'm no expert. Big difference in the VTS_C_ADT table, though, for what its worth. I've zipped them up here:

link to file (http://www.filefarmer.com/gobshopper/stuff/DumpedIFOs.rar)

jdobbs
6th August 2005, 20:50
I fixed it. It was an off-by-one error in the IFO's C_ADT table that happens to the End Address of the last ADT entry for an ILVU cell. Since it is off by one in the negative direction it plays ok -- but Shrink does notice it when it loads the table, and kicks out this error.

The "big difference" in the C_ADT table you mentioned is just the result of the decision as to how many VOBUs are included in each ILVU unit.... I use two, but some packages use more. It's kinda' programmer's choice... whatever will work best in most situations.

I'll get an interim version out soon with the fix included.

SpazzHH
6th August 2005, 21:59
I fixed it. It was an off-by-one error in the IFO's C_ADT table that happens to the End Address of the last ADT entry for an ILVU cell. Since it is off by one in the negative direction it plays ok -- but Shrink does notice it when it loads the table, and kicks out this error.
Thanks soo much for taking your time on this. Sorry it had to come up.

jdobbs
7th August 2005, 00:13
Thanks for all the feedback... it ain't done till it's right.

JFerguson
8th August 2005, 15:19
Cool! Thanks, mister! :)