Lockup with Reefer Madness segment - R1

[SpazzHH]

Well, I've finally run into one I can't do. I'm using RB Pro 1.03, DGDecode 1.10, and Avisynth 2.55. Have reripped the disk many times with different programs(all seem successful because the ripped files play fine, eliminating that as a problem). However in the Main Movie title set(VTS_1), the resulting file for V01001100001012.AVS, can't be opened by any program(including RB segment viewer) without that program crashing. Any encoder that attempts the file, just sits there and does nothing. I've even tried Nan's build of DGDecode with the same result. I've tried no preprocessing, preprocessing, even mock strips with VobBlanker, all with the same result. I've opened the .avs file with notepad and see nothing wrong that I can tell. All other segments play and encode fine. Anyone with any ideas or suggestions?

TIA, Spazz

[Guest]

It could be a known problem with DGDecode. But it should affect only random navigation and not linear decoding from the start. It might be worth looking into because it is on that exact movie that the bug was discovered and fixed. See here:

http://forum.doom9.org/showthread.php?t=102599

There's a bug in handling of some field structure clips. It's fixed in version 1.4.6 beta 2 of DGMPGDec.

http://neuron2.net/dgmpgdec/dgmpgdec146b2.zip

Unfortunately for you, DVD-RB can't use the newer versions of DGMPGDec. You'll have to do it the old-fashioned way.

Please let me know if you still have a problem trying to process this movie using DGMPGDec 1.4.6 beta 2.

[SpazzHH]

Thank you Sir for the quick reply.

[Pasqui]

@SpazzHH
I had such an issue in the past as reported here (http://forum.doom9.org/showthread.php?p=705336#post705336).
After the rebuild phase, the first segment was inserted where the segment hanged the encoder.
It seems that kofude also had a similar problem as described in this post (http://forum.doom9.org/showthread.php?p=730739#post730739)

[SpazzHH]

I can confirm that the problem is with DGDecode 1.10. If I change the trim value to the one frame previous, as in the other reported threads, playback is fine. What will leaving the one extra frame in the output do when it comes time to rebuild?

[magic144]

as a sidenote question for jdobbs,

in light of this possibility cropping up in other disks,
is DVD-RB going to (eventually) support newer versions of DGDecode?

[jdobbs]

It isn't common... and I don't think it is or will be enough of an issue to worry about -- but to answer your question, yes, it will support higher versions at some point.

[magic144]

cheers, that's good and reassuring to know - I've never seen this problem myself, so it must be reasonably rare :-)

so Donald or Jerry,
is there a workaround for using DVD-RB on a case like this (perhaps this is THE only such case!) - can you do something manually (edit a/some file(s))? - what are the implications of this "changing the trim points by one frame" fix in the AVS file-in-question? what is the "old fashioned way" to which Donald was alluding?

[Guest]

I can't help you with DVD-RB. I've never used it.

The "old-fashioned way" means using all the tools directly and not through DVD-RB.

But I'm not convinced this is the problem I fixed in beta 1.46b2. That affects only random navigation, which isn't typically used for a straight encode.

If someone can give me a VOB that won't work in DGMPGDec unless trimmed, then I can figure out what is going on.

[Pasqui]

@neuron2
For me, using DGIndex 1.4.1 solved the hanging I was experiencing with DGDecode 1.1.0