Pictures >= 500

[Esc]

I get a message saying "Too many pictures per GOP (>=500)". Does that mean there is no way for me to rip this DVD?

[neuron2]

The DVD spec does not allow more than 18 pictures per GOP:

http://en.wikipedia.org/wiki/MPEG-2#MPEG-2_on_DVD

Where is this VOB coming from and how are you ripping it? If you want to put a VOB fragment on my ftp site I'll look at it.

ftp.neuron2.net
user: guest@neuron2.net (enter it just like that)
pwd: guest

[Esc]

The DVD is anime Ruin Explorers.
I ripped it using DVD Decrypter 3.5.2.0. And then tried to... I am not sure what exactly DGIndex is doing. Looks like indexing to me. :D Anyway, I was creating a d2v file when I got that message. I narrowed it down to a certain Cell ID. I am not experienced with vStrip at all. But it was the only tool that popped in my mind. So I sorta guess-found the set of options that was giving me the right slice of the DVD. It still was 175 Mb. Then I asked it to split output by Cell Id and got me 4 VOBs. One of them was 8 kb and 3 others represented 3 Cells. Now if you load 2 of them they produce the same error. If you run them separeately - no error. I guess, something is wrong with the first one. It is not closing properly or something.
Looks like I have found my solution - split them and run separately. But probably you still would like to have a look. So I rar-ed down those 2 VOBs and now uploading them to you. The name of the file is gop500.rar and it's gonna be there by 2 PM Central.
It's big, 80+ Mb. But it can't be helped, I'm afraid. I could strip out the audio, I guess. But I doubt it makes a significant part.

[neuron2]

Thank you, I will have a look.

[neuron2]

Here is a snapshot of TAK's output for the first VOB. The left pane shows the structure of the end of the stream. The right pane shows the content of the highlighted picture coding extension.

http://neuron2.net/misc/bad_vob.jpg

You can see that the stream has field structure but it finishes up with just the top field of the last frame! This is not too cool. It confuses DGIndex about the field polarity in the second VOB and he stops counting GOP entries correctly because of that, leading to the long GOP abort.

Did you cut this VOB? I'm guessing you did. Does this happen with the uncut VOB? If so, I'll send you the TAK tool and instructions about how to run it to see the end of the VOB.

I'm going to have to think about what to do about this. I tried just resetting the Second_Field to 0 when a new file is loaded but the extra field is still there and messes up DGDecode. I may be able to find a solution. But if it is just because you cut it badly, I may not consider it worth the effort. I'm going to the pool now and will think about it during my swim.

[neuron2]

I used a hex editor to chop off the orphaned field and then everything worked OK (after I fixed a different bug in field structure handling). Those are the weirdest damn VOBs I've ever seen.

[Esc]

Originally posted by neuron2
Did you cut this VOB? I'm guessing you did. Does this happen with the uncut VOB? If so, I'll send you the TAK tool and instructions about how to run it to see the end of the VOB.
Exactly the same thing happens with the uncut VOB.
Since I am no professional at this question I want to avoid any ambiguity. I used Decrypter on the DVD in ifo mode. Decrypted the whole movie. The movie was listed twice. I gussed that meant 2 angles and I decrypted both of them separately. They have different video on exactly the portion that causes trouble - the end titles. And the problem is present on both of the angles.
If you give me (a link to) that tool and instructions how to use it, I'll check what I have.
I appreciate the great job you've done with DGIndex and I am willing to help with the further development if possible.
Originally posted by neuron2
I used a hex editor to chop off the orphaned field and then everything worked OK (after I fixed a different bug in field structure handling). Those are the weirdest damn VOBs I've ever seen.
Welcome to the world of anime DVDs -- the most unloved bastards created by the coders forever banned from the movie industry. You should see how they can screw the telecining! :D

[neuron2]

@Esc

My position is that you had an illegal VOB (field structure with an orphaned field at the end). I can tell you how to fix it with a hex editor, but that's as far as I'm willing to go.

Open the VOB in a hex editor such as Hedit. Go to the last byte of the file. Then search back to a picture header (00 00 01 00). Then search back to the previous pack header (00 00 01 BA). Then delete everything from that pack header to EOF.

[len0x]

I have a follow up to this. In some cases new DVD protection schema arccos does this (i.e. putting illegal stuff into vobs deliberately). I have a report that one of such movies "The Forgotten" generates the GOP error with RC3.

I wonder if its possible to ignore such GOPs instead of just stop processing vobs?

[neuron2]

I might make a utility to preprocess the VOB. But I need access to the failing VOB(s) for testing.

[len0x]

I'll see what I can do :)

[Esc]

How much of the VOB do you need? All DVD? One gigabyte sized VOB? Or some other cut from it?

[neuron2]

The smallest piece of the VOB that still shows the problem.

[Esc]

It's on your ftp. Gop500.vob. Cut out with vStrip as usual.

[len0x]

I'm upping a small (40Mb) vob from the movie Forgotten that has this issue. Should be done in 12 min.

*Edit* done.
*Edit2* Although I'm not sure that if the vob is not completely corrupted in this case as I'm not able to play it normally at all...

[neuron2]

Tony, your VOB is just junk. How did you mangle it up so badly?

Esc, that looks like the same one I examined before. It had an orphaned field. Was that DVD arccos protected? If it's just a one-off authoring error, I'm not bothered because you can fix it as I described.

My understanding is that a recent version of DVDDecryptor rips arccos OK.

So what are you guys asking me to do?

[neuron2]

@Esc

OK, your gop500.vob is different from the last one. Here is the parsing of it. Note the GOP in the middle of the left pane. Again, a required bottom field is missing.

http://neuron2.net/misc/gop500.jpg

I'll see what I can do about this.

[len0x]

Originally posted by neuron2
Tony, your VOB is just junk. How did you mangle it up so badly?


It was produced with Vob cutter from full vobs ripped by DVDDecrypter(not by me though). I have a feeling that cutting tool did that, so I'll wait until I manage to get hold of full DVD and then will check it out myself.

[bourtzovlakas]

About the "Forgotten" R1 DVD....
I did another rip with DVD Decrypter, and everything is working fine, with DGindex...
Since the problem is not reproducible, i assume that something borked the first rip in Decrypter...

[neuron2]

Here's the full analysis of Esc's gop500.vob...

The stream starts out with field pictures: top, bottom, top, bottom, etc. At the fade cut, a GOP is emitted with just a single top field, and the next GOP is top, bottom, top, bottom, etc. The TFF flag is 0 throughout this period, but that has no meaning for a field picture (but see below). Then later, the stream switches to frame pictures, with TFF set to 1. The progressive_sequence flag is 0 throughout the VOB.

The orphaned field is ILLEGAL MPEG2 and it has severe consequences. First, it gets the Second_Field variable out of sync with the stream and messes up frame counting, leading to the GOP length error. I can "fix" that by resetting Second_Field to 0 at each GOP header, but that doesn't fix the decoding. After the orphan, the decoder is expecting a bottom field and runs into a frame picture instead. That just blows it up. If this VOB plays OK on a DVD player then there is some lucky side effect or intentional recovery designed for this. I need to think about how the decoder can recover from this. But if this is just a one-off problem with an illegally authored DVD, I'm not going to bother with it. If more instances come up, then I will devote some time to it.

But it does expose one interesting fault in DGDecode (which doesn't help here). DGDecode picks up the field order by looking at the TFF bit of the first frame of the stream. But that is wrong, because the TFF bit has meaning only for frame pictures. DGDecode needs to wait for the first frame picture with progressive_sequence equal to 0 before picking up the field order from the TFF bit. This will cause a problem only when the stream starts with field pictures, has frame pictures later on, and is top field first (bottom field first is OK because DGDecode erroneously always sets BFF in this case).

Bottom line: Unless more of these crop up, it's not worth the effort and risk to the stable code base.

[Esc]

Just FYI, I've got Decrypter 3.5.2.0 which is the last known to me. The cut was made with vStrip.
And thanks for your time!

[niamh]

I've just got one like this myself. :(
Cheap DVD bought at a discount store, it took me the whole night to get it decrypted, with a lot of read sector errors (I have others that do that too). The VOB seems to play fine on TCMP at least.
DGindex preview produces blocks wherever the gop error is.
I'll upload some after work if you want.
Or should I take it to LightningUK?

Most of the DVD that won't decrypt properly that I have are from a company called Hollywood DVD, and I'm not sure if they use terribly cheap media, or do they have some sort of copy protection, which, seeing the level of the movies they're releasing (VHS transfers of terribly bad Z forgotten 80's movies) seems far fetched. But I own cheapos from other companies, and these decrypt+d2v with no issue.
All of them are out of the box, and not scratched that I can see.

[iNFO-DVD]

slightly off subject, but as ARccOS was mentioned, I still haven't been able to get my hands on one. I know which region 1 dvd's have it but anyone known which region 2 [UK] dvd's have ARccOS, if I know I can pop down tesco and get one to mess with.

Cheers...

[neuron2]

Please have LightningUK comment on this before I get involved. Thank you.

[niamh]

well 2 of the same comapny got decrypted fine today, so I gather it's poor media. I'll find a way, thanks for the reply :)

[SeeMoreDigital]

Well here's a weird one!

Over the last few days I've been experimenting with muxing Mpeg2 streams into the .MP4 container...

Anyway, it was quite a surprise to discover that DGIndex is able to accept such files: -

http://img157.echo.cx/img157/1952/dgindexmp4demux1wi.gif

Although it can't de-mux them ;)


Cheers

[dorine13]

I get a message saying "Too many pictures per GOP (>=500)". Does that mean there is no way for me to rip this DVD?
I've got the same message.
After reading this tread I do understand that it happened due to bad ripping.
Could it be repaired somehow?
Could somebody give me a link to the program TAK, that neuron2 used for analyzing VOB structure? I tried to find it myself, but most of links in the Google leads to TAK (audio lossless compressor).

[SeeMoreDigital]

Unfortunately I do not have access to original DVDs, it was downloaded.Nobody on this forum will be able to help you, as your post is in violation of rule 6.

[dorine13]

Nobody on this forum will be able to help you, as your post is in violation of rule 6.
Thank you for your prompt answer, it was really helpful.
By the way, "downloaded" does not necessarily mean "illegally obtained copyrighted content".

[neuron2]

Thank you for your prompt answer, it was really helpful.
By the way, "downloaded" does not necessarily mean "illegally obtained copyrighted content". Please read the announcement in the Newbies forum. We do not help with downloaded DVDs.

[dorine13]

Please read the announcement in the Newbies forum. We do not help with downloaded DVDs.
I've read, now it was really helpful. I see that it is the policy. No problem.

[dorine13]

Could somebody point me to the site of the program TAK, that neuron2 used for analyzing VOB structure? I tried to find it myself, but most of links in the Google leads to TAK (audio lossless compressor).

[neuron2]

Could somebody point me to the site of the program TAK, that neuron2 used for analyzing VOB structure? I tried to find it myself, but most of links in the Google leads to TAK (audio lossless compressor). You are continuing to discuss this VOB's processing when you've just been told not to. Therefore, rule 6 strike issued.