PDA

View Full Version : #0004 error with a DVD9.. how to fix it?


nyt
12th January 2005, 01:06
Hi,
I encoded several movies successfully with dvd-rb 0.69. However, I hit a #0004 overflow when rebuilding a specific title (TexAvery DVD1). I tried to use QuEnc instead of CCE 2.67, not better. CloneDVD2 also fails to encode it, but it's no problem for DVDShrink/dvd2one. Should using dvdshrink with no compression suffice to fix the error to allow DVD-RB to compress it?
TIA and kudos for making such a great tool!
PS: I just noticed that one episode is split in two m2v, at the same percentage it fails..

nyt
12th January 2005, 02:36
sorry for the self-reply.. I found a bad frame probably due to a read error. Feature request: to skip such frames without crashing ;)
I'm now onto finding how to get rid of it, which is a different issue!

dannyv
12th January 2005, 20:43
Originally posted by nyt
sorry for the self-reply.. I found a bad frame probably due to a read error. Feature request: to skip such frames without crashing ;)
I'm now onto finding how to get rid of it, which is a different issue!

Its actually not a new issue with RB and cce 2.67. Its most likly a corrupt single frame. I found that replacing the cell with the original source frame resolved the problem.

Read this post starting with my postings about a quarter way down the page.

http://forum.doom9.org/showthread.php?s=&threadid=75168&perpage=20&pagenumber=6

It may help.

jdobbs
12th January 2005, 21:36
I think what I may do is encode all single frames in CBR and see what effect it has on this...

@dannyv

Could you do an experiment for me? In one of the offending sections, could you edit the mode in REBUILDER.ECL and change it to CBR and see if it fixes the problem? Thanks. If it does it may be an easy fix.

dannyv
12th January 2005, 21:50
Originally posted by nyt
sorry for the self-reply.. I found a bad frame probably due to a read error. Feature request: to skip such frames without crashing ;)
I'm now onto finding how to get rid of it, which is a different issue!

@nyt

Please save your original project files (The files you riped from the original disk). If jdobbs comes up with a solution I would like you to run the project again to confirm its fixed.

dannyv
12th January 2005, 22:39
Originally posted by jdobbs
I think what I may do is encode all single frames in CBR and see what effect it has on this...

@dannyv

Could you do an experiment for me? In one of the offending sections, could you edit the mode in REBUILDER.ECL and change it to CBR and see if it fixes the problem? Thanks. If it does it may be an easy fix.

Would that be encode_mode=1 in rebuilder.ecl

Or

mode=0 in rebuilder.inf

jdobbs
12th January 2005, 23:38
I believe in 2.67 CBR would be "video_type=1". If it is 2.67.0.27 or above you will changing it from "video_type=16" or for older versions "video_type=4"

vmode=1 is what it was for version 2.50.

You gotta love the consistency in CCE settings, God bless their souls...

nyt
13th January 2005, 01:07
@dannyv
Ok I will keep the files for a while. Btw my bad frame caused the ripper to split the chapter into 2 m2v, and it's the first frame of the 2nd segment. It's probably an I frame because the 2 following are not looking good either (but better than a big nothing like the 1st one is).
IMHO the decoder should correct garbage when it hit some, outputting invalid frames is a bug me thinks. Since a new dgdecode.dll is around the corner it's time to ask for a fix!

dannyv
13th January 2005, 04:36
Originally posted by jdobbs
I believe in 2.67 CBR would be "video_type=1". If it is 2.67.0.27 or above you will changing it from "video_type=16" or for older versions "video_type=4"

vmode=1 is what it was for version 2.50.

You gotta love the consistency in CCE settings, God bless their souls...

Well its back to the drawing board.

I'm using cce 2.67.00.09

Used the item.ecl containing the corrupt segment and here are the results

video_type=1 default RB value produces corrupt file
Video_type=4 produces no file at all and no error
video_type=16 produces same corrupt file as video_type=1

Now for the intresting part regarding rebuilder.ecl.

All the corrupt segments are video_type=1 seg_endcode=1
All the good segments are video_type=4 seg_endcode=0

The rest of the [item] and [file] sections with the exception of the min/max bitrate and start/end frames are identical.

If you encode the corrupt segment with video_type=4 and seg_endcode=0 it does not produce an m2v file at all and cce does not give any errors.

I also want to note. If you play the corrupt segments avs file in mplayer it plays a blank (black) frame for almost 10 seconds but the original sourse segment only plays for a fraction of a second. Now I'm not sure if this is because the problem is occuring across vob boundries and the second part of the segmet on the second vob is corrupting but I'll leave that up to you to determine.


Let me know if I'm on to something here or am way off base.

jdobbs
13th January 2005, 11:52
This may have been asked, but what happens when you open the AVS file directly with Windows Media Player... something is wrong..

Are you positive you are using the most recent DGDECODE.DLL? Download it again and overwrite... this is exactly what you may have seen on some early versions.

dannyv
13th January 2005, 15:44
Originally posted by jdobbs
This may have been asked, but what happens when you open the AVS file directly with Windows Media Player... something is wrong..

Are you positive you are using the most recent DGDECODE.DLL? Download it again and overwrite... this is exactly what you may have seen on some early versions.

As mentioned in the above post:

If you play the corrupt segments avs file in mplayer it plays a blank (black) frame for almost 10 seconds but the original source segment only plays for a fraction of a second (I confirmed this again last night after a fresh rip and encode). The corrupt m2v file will not play and errors in mplayer.

I'm a little confused by your request. I opened and played the avs through media player classic. Did you also want me to try and play the avs in the actual windows media player?

I am using the most current dgdecode from 06/07/04 which I obtained from the doom9 downloads last week. In fact last week I informed wmansir that his link to the file was dead in the install thread and he pointed it to the dgdecode on doom9 but just to make sure all bases are covered I will download dgdecode and overwrite my existing file and try again.

jdobbs
13th January 2005, 22:29
I think this may be a DGDECODE issue... as I remember seeing it once, but I thought it had gone away. Have you tried it with mpg2dec3dg.dll?

Sorry to have you jumping through hoops and asking repeated questions. I've been multitasking a lot lately.

dannyv
13th January 2005, 22:36
Originally posted by jdobbs
I think this may be a DGDECODE issue... as I remember seeing it once, but I thought it had gone away. Have you tried it with mpg2dec3dg.dll?

Sorry to have you jumping through hoops and asking repeated questions. I've been multitasking a lot lately.

Ask anything you want of me. I want to get this resolved as badly as you do.

I did try it with the mpg2dec3dg.dll and got the exact same results.

Testing the AVS file through media player classic, is that the same as testing it through the built in windows media player and do you still want me to test through windows media player?

jdobbs
14th January 2005, 00:08
Testing the AVS file through media player classic, is that the same as testing it through the built in windows media player and do you still want me to test through windows media player? It should be the same... I'm trying to figure out why it is seeing 10 seconds of info, I'm wracking my brain trying to remember why this sounds so familiar.

casperse
15th January 2005, 20:45
I just got the same in Troy.
Using DVDrebuilder v.0.69 & CCE SP 2.67.00.27.

The encode is finished and it give this error in the rebuild fase :confused:

I will try to look for errors in the segments.

dannyv
15th January 2005, 20:50
Looks like i'm going back to cce 2.50. The 3 series that I did I just got a chance to watch and there full of audio dropouts. they have 5 - 6 audio dropouts per episode. looks like I'm going to have to redo them in 2.50.

jdobbs
15th January 2005, 20:57
As I've mentioned in the past -- if you can afford $58, you can't go wrong with CCE Basic. It is exceptionally dependable. I think a lot of these hacked versions of CCE just have problems.

casperse
15th January 2005, 22:18
Hmm Just did a Rebuild of the files (Encoded From 0.69) with DVDRebuilder 0.62 and the MPEG2Dec3dg.dll file and that worked no #0004 Error :D
Havent seem all the movie yet but that segment that failed in the rebuild is working and so far no Drop Outs! :D

EDITED: I tried it whit rebuild 0.69 again this time using the MPEG2Dec3dg.dll (Same one I also used with 0.62) it didnt work!

dannyv
16th January 2005, 06:46
Desided to give cce basic a try and so I downloaded the test drive version. Installed it as usual pointed eclecc to the cce exec. Set up RB pointing cce basic to the eclcce. Did the prepare stage then encode and the cce window pops up and after about 30 seconds I get a cce error " error 0 unable to find cce window". I also configured rb to launch cce directly and get "this is not a cce ecl file". I found one post stating that cce basic trial will not work with eclcce is this true? or am I doing somthing wrong. I would hate to waste $58 to find out that cce basic still gives me an error 9. Anyone care to venture a guess as to whats wrong?

jdobbs
16th January 2005, 10:58
There has been some strange behaviour reported from the CCE Basic Trial. For one thing, unlike the other trial packages -- I think it has a limit as to how much it will encode... you also have to make sure you do the PREPARE with the same version with which you try to encode. CCE Basic's ECL format is a little different.

I use retail version 2.69.1.10 in my testing and it works exceptionally well.

As for whether you will get any errors -- it depends on the cause, I guess. I don't get any. I also don't get errors with SP v2.50.1.0, if that's the one you are using.

casperse
17th January 2005, 08:57
Originally posted by casperse
Hmm Just did a Rebuild of the files (Encoded From 0.69) with DVDRebuilder 0.62 and the MPEG2Dec3dg.dll file and that worked no #0004 Error :D
Havent seem all the movie yet but that segment that failed in the rebuild is working and so far no Drop Outs! :D

EDITED: I tried it whit rebuild 0.69 again this time using the MPEG2Dec3dg.dll (Same one I also used with 0.62) it didnt work!

jdobbs: is there any danger to during a rebuild with version 0.62?
So far I have not seen anything wrong with this film.

jdobbs
17th January 2005, 14:00
I wouldn't recommend doing it on a regular basis, as there have been a lot of improvements in the rebuilding engine since then.