dropouts

[gizzin]

Jdobbs is it possible by removing audio streams with rebuilder could actually cause audio dropouts?

1pass w/analysis i kept everything, no dropouts
7pass i removed 2 audio streams, dropouts

[gizzin]

is it possible also than in 1 pass mode the scr fix works and in multipass it doesnt?

[gizzin]

oh yea. jdobbs i got the good encode of gang related (1pass), and the bad one (7pass). If you want these files would they help at all?

[fritzdis]

Originally posted by gizzin
is it possible also than in 1 pass mode the scr fix works and in multipass it doesnt?
By using scr.exe posted by jsoto in the SCR thread, you can determine whether the scr fix did or did not work on the files you did in multipass mode. For me, files created in multipass mode are free of those scr problems, but I still have dropouts. I will be trying 1 pass mode, though, to see if I get a dropout-free disc as you have reported.

[glassvial]

Did you try a 1 pass job and removing audio tracks just for comparison?

[fritzdis]

I did a 1-pass encode with only the 5.1 AC3 kept, and the dropouts were still there. In fact, they seemed worse. I'm hesitant to do a 1-pass with all the audio kept because this particular DVD has a DTS track, which other posts have indicated could be a problem.

[glassvial]

Ok, good, I have an idea. Try taking the audio out with another program (ie, shrink) and try it again.

Edit: I mean take the audio out with another program and do another 1-pass (saves time)

[fritzdis]

Ok, the movie I've done has 3 5.1 AC3 streams and a DTS stream. I have done just the first chapter of the movie in the following ways:

a) Multipass, 1 AC3 kept
b) 1-pass, 1 AC3 kept
c) 1-pass, 1 AC3 kept, opv min bitrate=1000, opv max bitrate=7000
d) 1-pass, all audio kept
e) 1-pass, all audio , opv min bitrate=1000, opv max bitrate=7000
f) 1-pass, 1 AC3 kept with IFOEdit prior to preparing with DVD-RB

a, b, and f display dropouts in mostly the same places. d is screwy because the total bitrate exceeds DVD standards. c and e are almost dropout free, but still have dropouts in two spots. After demuxing the original M2V and the M2V from c and stripping RFF flags with pulldown.exe, I used Bitrate Viewer to look at the two spots where dropouts still occurred in c. It looks like the rate of change of the bitrate of the M2V from c is significantly steeper at these spots than the rate of change of the bitrate in the original M2V. I think this was mentioned as a possible cause of problems in earlier discussions about the dropout problem, but I don't know what was decided. Does DVD-RB rely at all on the original distribution of audio packets in determining where to place those packets in the new file?

Here are screenshots of the approximate places where dropouts occurred:
Original Spot 1 (http://home.comcast.net/~fritzdis/Original_1.jpg)
New Spot 1 (http://home.comcast.net/~fritzdis/1PassLimitedTo7000_1.jpg)
Original Spot 2 (http://home.comcast.net/~fritzdis/Original_2.jpg)
New Spot 2 (http://home.comcast.net/~fritzdis/1PassLimitedTo7000_2.jpg)

I don't know how reliable using pulldown to strip out RFF flags and then viewing in Bitrate Viewer is, since the frame count of the two files is different by 19 frames, but I didn't want to use Bitrate Viewer on the VOBs because the way it handles telecined material wouldn't allow me to find the spots where dropouts occured (plus it calculates those bitrates differently).

[fritzdis]

So I have too much free time, because this is what I did:

(I think this one is important, so please take the time to read it if you can)

I captured snow from my TV tuner that doesn't have anything plugged in to it. I saved that capture as an uncompressed AVI, Test.avi. I then fed the following AVS script into CCE:

--
AVISource("Test.avi").AssumeFPS(23.976).BilinearResize(720,480)
a=Trim(0,5)
FiveSeconds=a+a+a+a + a+a+a+a + a+a+a+a + a+a+a+a + a+a+a+a

Black=FiveSeconds.BlankClip(length=120)

a1=Black
a2=FiveSeconds.Letterbox(160,160,240,240)
a3=FiveSeconds.Letterbox(0,0,240,240)
a4=FiveSeconds
a5=FiveSeconds.Letterbox(0,0,240,240)
a6=FiveSeconds.Letterbox(160,160,240,240)
a7=Black
a8=FiveSeconds
a9=Black

b=a1+a2+a3+a4+a5+a6+a7+a8+a9

b+b+b+b

ConvertToYUY2
--

This creates a clip where every 5 seconds, the complexity of the video switches suddenly, with some changes being more drastic than others, and each degree of changing occurring in both "directions" (getting more or less complex). I repeated a 45 second chunk 4 times to get it big enough for DVD-RB to rebuild it, and it's a good thing I did because it allowed me to verify the consistency of the results I saw.

I encoded this AVS script with CCE in One Pass CBR mode at 6000 kbps to the file Test.mpv. Using pulldown.exe, I turned this 23.976 fps file into a 29.97 fps file, Test.mpv.m2v. I then created a WAV file from a loop of a ringing sound, Test.wav. With BeSweet, I turned that into a 448kbps AC3 (apparently, a 2-CH one, though I set it to 5.1, I guess it doesn't interpolate for you), Test.ac3. With Scenarist, I authored Test.mpv.m2v and Test.ac3 into a single Title and compiled. I played the DVD in IFOEdit, and it played perfectly. I burned the DVD, and it played perfectly on my standalone.

Next, I rebuilt the DVD with DVD-RB using multipass mode (3 pass / 1+2). I played the rebuilt DVD in IFOEdit, and it played perfectly. I burned the DVD, and in my standalone, it had dropouts at some of the points where the video switched suddenly. Particularly, it had dropouts at those points where the video suddenly got more complex, while those points where the video suddenly got less complex seemed unaffected.

Since the video repeats in 45 second intervals, here are screenshots from Bitrate Viewer of 45 second chunks of Test.mpv (http://home.comcast.net/~fritzdis/CBR.jpg) (each 45 second chunk is basically identical), the first 45 seconds of V01000000001001.m2v (http://home.comcast.net/~fritzdis/MultipassVBR-1st45.jpg), and the second 45 seconds of V01000000001001.m2v (http://home.comcast.net/~fritzdis/MultipassVBR.jpg) (which is basically identical to the third and fourth chunks of V01000000001001.m2v). I have highlighted the dropout spots in blue, and I have also highlighted in red an area that to my surprise did not display a dropout (I highlighted these areas on the original as well for reference; the original does not display dropouts). Finally, in purple, I highlighted an area where an inconsistent dropout occurs. The dropout occurs if I play the disc from the beginning, but if I rewind back over it, then play that area again, the dropout does not occur. However, if I rewind back before the first blue (consistent) dropout, then the purple (inconsistent) one does occur. All of the blue dropouts occur whether I play from the beginning or rewind back over them. Also, note that the blue dropout in the first 45 seconds occurs at a slightly different point (relative to the 45 second chunk) than the first dropout in each of the other 45 second chunks. The very first dropout occurs after I see the video change, while the other ones occur immediately before I see the video change. Some of these details may not matter, but I want to be sure I'm as thorough as possible since this stuff could be the key to the dropout problem.

If someone could provide space, I would like to upload the original and/or the rebuilt ISOs I made for people to test (having other people rebuild from the original would be the best may to see if the dropouts occur consistently at the same points with different versions of programs). Of course, there should be no reason why people can't create the files themselves, and doing so might provide further evidence of a consistent problem, but it would need to be done cautiously so as not to overload the issue with other possible sources of a problem. At the very least, I want to make sure jdobbs has a chance to examine the issue.

Finally, a couple of notes:
DVD-RB decided the clip was interlaced. I don't know if this was pulldown's fault, and I don't know what effect that could have on my result. I do know that because of this, DVD-RB set vbr_brate_max=7200 (9000 * 0.8). I did not change this as I could not see how it could undermine my results as long as the dropouts occurred in the final product.
I did not try 1-pass mode because I worried that if the wrong part(s) of the video were chosen to analyze, the chosen Q value would be impossible to achieve in the most complex parts of the video without going above the max bitrate, and I was unsure what effect this might have.
Because of the way I prepared the assets, I do not know if the DVD I made with Scenarist is non-compliant in any way. I don't think it really affect the issue because of the exact and consistent nature of my results.
In CBR.jpg, you may notice that the number of frames is twice the number of frames displayed in MultipassVBR.jpg. This is because i accidentily loaded Test.mpv.m2v (to which pulldown had been applied) first, and the frame count did not reset when I loaded the next file (Test.mpv).

I'm sorry that this post was so long-winded, but I'm so sure that the root of (at least some of) the dropout problems are within reach that I had to be exacting and thorough.

[fritzdis]

Hahahahaha.

I knew I'd find people to give credit to if this turns out to be the miracle solution we've all been waiting for (OK, maybe that's a little overly optimistic):

Originally posted by Noah
Can you determine if the stutters correspond to any characteristic of bitrate? Maybe a very low bitrate or a wild swing in bitrate
Originally posted by DDogg
Older players with low xX drives have a problem dealing with the heavy near instant bitrate bitrate ramp caused by complex scenes like the ones mentioned in Revolutions.
Originally posted by DDogg
Can all/any/some players go from near 0 bitrate to one of those rates is a few hundredths of a second? CBR should not exhibit any of these problems.

[TheSeeker]

I wonder if playing with the VBR Bias setting from within DVDRB would have any effect on the dropouts? If the dropouts truly are caused by bitrate spikes then raising the vbr bias a little or a lot should theoretically have SOME effect on the dropouts.

[fritzdis]

Originally posted by TheSeeker
I wonder if playing with the VBR Bias setting from within DVDRB would have any effect on the dropouts? If the dropouts truly are caused by bitrate spikes then raising the vbr bias a little or a lot should theoretically have SOME effect on the dropouts.
I tried setting the VBR Bias to 50 on the file I created and it seemed to have no effect. However, in the file I created, the complexity of the video changes so instantaneously, that CCE probably has no choice but to change the bitrate quickly.

[TheSeeker]

I heard someone say that the more passes that you do within cce the flater the bitrate spikes become. I wonder if you jacked the vbr bias up real high and did 5 or 6 passes if that would do anything. But that really isnt a solution, but I suppose if we can effect the dropouts in this way we could be a little more sure that they ARE caused by sudden spikes.

[fritzdis]

What's not clear to me is whether VBR bias has any effect when CCE detects a scene change. I'm going to try the first chapter of the movie I mentioned with VBR Bias at 75 to see what happens.

[fritzdis]

Well, there are still dropouts with VBR Bias set to 75, but Bitrate Viewer also still shows bigger swings than in the original, as you can see here (http://home.comcast.net/~fritzdis/Bias75Multipass.jpg), which seems to correspond to Spot 2 listed in my post above.

[TheSeeker]

It almost seems that in your case anyways that the vbr bias settings are not doing anything. Sure you have the SP version of CCE and not Basic?

[fritzdis]

Yeah, it's definitely SP. If it were basic, I think it wouldn't even work at all with CCE Options set to CCE SP.

[glassvial]

It was also suggested that AVISynth was the culprit, have you tried the last few versions (like, 2.55 and backward) and run a quickie encode job to see what happens?

[jdobbs]

@fritzdis

Excellent analysis. Very interesting. Please read you PM.

Thanks,
jdobbs

[jdobbs]

Is anyone getting this error using CCE Basic, or is this problem limited to SP?

[lamster]

Originally posted by jdobbs
Is anyone getting this error using CCE Basic, or is this problem limited to SP?

I'm getting stutter using QuEnc 0.54 (and previous versions as well).

Also, one of the movies I've tried experimenting with a lot is Master of Disguise. There's a spot near the beginning where they do a freeze-frame for about 10 seconds. I can hear the stutter in the voice while there's nothing moving on the screen. I would think that there wouldn't be any bitrate spikes at this point?

(I'm not trying to detract from fritzdis's excellent analysis; just trying to provide a little additional data.)

[fritzdis]

Originally posted by lamster
Also, one of the movies I've tried experimenting with a lot is Master of Disguise. There's a spot near the beginning where they do a freeze-frame for about 10 seconds. I can hear the stutter in the voice while there's nothing moving on the screen. I would think that there wouldn't be any bitrate spikes at this point?

(I'm not trying to detract from fritzdis's excellent analysis; just trying to provide a little additional data.)
That's a very interesting and important piece of information. I got pretty caught up in the idea that if I could specifically design a file to create dropouts, then the cause of dropouts should be easier to pinpoint. While I still think that is a valid idea, there's nothing that precludes other circumstances (not present in the file I created) from also causing dropouts.

I think the most important thing right now is to see whether other users would experience the same dropouts with the same source. I've sent jdobbs the original files and am currently sending the rebuilt files, so he can take a look at them, but since these dropouts can be player specific, he may not be able to verify them. Though I would prefer to have these files put somewhere that anyone who wants could download and test them, I would be willing to personally upload to anyone who has seen dropouts in the past to test them.

[jdobbs]

@fritzdis

One consideration I've discovered in this test. Because the original source is so small, DVD-RB tries to allocate as much bitrate as possible and you end of with (of course) a 100% representation of the video.

DVD-RB assumes it is only being used when making material smaller and uses the original timecodes (only slightly adjusted) from the audio source to determine where to insert on rebuild. It's possible (but I haven't proven it to my own satisfaction yet) that may make this test invalid. You may have identified a problem that only occurs when trying to run DVD-RB on a DVD that will already fit on a DVD-5. Which, of course, shouldn't be done.

That doesn't mean I can't use this to help find the problem -- but it does mean I may be looking at the wrong problem.

At least with your source I was able to repeat an audio dropout.

[Sir Didymus]

Originally posted by fritzdis
So I have too much free time, because this is what I did:

...
skip
...

I'm sorry that this post was so long-winded, but I'm so sure that the root of (at least some of) the dropout problems are within reach that I had to be exacting and thorough.

:p
excellent work fritzdis!!!

If you are able to upload the files (orig and rebuilt) on a suitable ftp server, I'd like too to get a look at them...

I have available a profiling tool (DVD-Verifier) and I'd like (as obviously everybody want) to try to understand what happens about this dropout condition...

Clearily, as precisely stated by jdobbs, the work of CCE in your tests is unconstrained, since the title is very little, but I think that the arguments you are proposing should be investigated, at least in order to TRY to face the problem...

Since you have scenarist, maybe you have some more spare time ;) for trying to gather evidence that the fault [IN YOUR TEST] is due to the encoder alone, excluding that the muxing engine in DVD-RB has failures, or that the problems are on both....

I am just proposing to demux again the video content from the rebuilt test disk, and making a new authored title, with the original audio, using your authoring tool....

I think that if the title play fine this would demonstrate that the encoding performed by CCE is not faulty... I am right ?

Cheers,
SD

[jdobbs]

Just a heads-up. I've found something interesting using fritzdis source files.... I may be onto a fix!

[jdobbs]

You make a good point Sir Didymus. If you can reauthor with Scenarist using the M2Vs that DVD-RB uses and it comes out ok -- that should show the problem is in DVD-RB.

Frankly I'm pretty sure it is... CCE has been pretty air-tight up until this point.

One concern I've had for a long time, though, is Cinemacraft's redefinition of the "DVD Compliant" setting on CCE Basic that forced me to stop setting it. They've made it so it resizes the video and changes it's frame rate without asking. Before that point the main reason for using it was outlined in their manual:

"Bitrate limitation In the DVD standard, the maximum bitrate of Video ES is limited to 9.8 Mbps. In the MPEG-2 VIDEO international standard (ISO/IEC 13818-2), the size of an individual picture is limited using the concept of “VBV (Video Buffering Verifier)”. In the concept of VBV, a stream having a 9.8 Mbps bitrate can create GOP which has a size equivalent to a maximum of 11 Mbps. This perfectly conforms to the MPEG-2 VIDEO international standard (ISO/IEC13818-2), but whether it conforms to the 9.8 Mbps restriction of DVD depends on interpretation. If DVD complient is selected, instantaneous bitrate in GOP units is controlled to be a maximum of 9.8Mbps. During VBR operation, 9.8 Mbps is always written to the sequence header regardless the specified maximum bitrate. 9.8 Mbps is the maximum bitrate allowed under the DVD standard. 9.8 Mbps is used here because in the case of the VBV model in VBR, bit allocation planning by the encoder becomes more flexible as the maximum bitrate becomes higher, therefore higher image quality can be achieved." (CCE SP v2.50 manual)

[eriksen76]

Hi this is my first post at the forum but I've read just about all the articles regarding Dvdrebuilder which is a program I use alot.

Sadly I also have some dropouts during playback on my JVC and Pioneer standalone. No problems on my PS2 though. (I mainly encode pal movies!)

I have tryed using different settings, CCE versions and all the Dvdrebuilder versions made. But I still get the same errors in the same place on the same movies......

Currently I use Avisynth 2.5, CCE.SP.v2.67.00.27.RETAIL and RB 0.59

But I just tryed to extract the M2V file and the AC3 from the RB authored stuff. Then I loaded the two files with Dvdmaestro and compiled a "movie only".

Guess what: NO PROBLEMS AT ALL!!!

So my conclussion: Something is going sligthly wrong with DVDRB when rebuilding the encoded stuff.

Maby thats the conclussion you guys already have drawn, but I just want to backup on your statement.

Hope this was of any help

Thanx for all your support

/Julius

[Sir Didymus]

@eriksen76

Welcome on board, Julius...

Let's wait for jdobbs updates...
Everybody really hope good news are approaching...

There is to say that this trouble of dropouts is really a source of headaches not only for jdobbs but also for alot of other kind people...

Cheers,
SD

@fritzdis
Just to add some further investigastions (or confusion ???) to the topic, i did some verification on the real time occupation of the video elementary stream STD buffer, using 0.59, for one of test titles I am using. In the attached images, the x axis is the time, and the y axis is the STD buffer occupation (in bytes). There is to say that the limit of the buffer is 237568...

[jdobbs]

Cool analysis. Actually it's not too bad...

[fritzdis]

Originally posted by jdobbs
@fritzdis

One consideration I've discovered in this test. Because the original source is so small, DVD-RB tries to allocate as much bitrate as possible and you end of with (of course) a 100% representation of the video.

DVD-RB assumes it is only being used when making material smaller and uses the original timecodes (only slightly adjusted) from the audio source to determine where to insert on rebuild. It's possible (but I haven't proven it to my own satisfaction yet) that may make this test invalid. You may have identified a problem that only occurs when trying to run DVD-RB on a DVD that will already fit on a DVD-5. Which, of course, shouldn't be done.
I have just run a test where I manually changed vbr_brate_avg from 6087 to 3000 in REBUILDER.ECL. I did not change anything else, including Reduction=100.0 in REBUILDER.INF, because I wasn't sure what effect changing anything else might have. After encoding and rebuilding, the DVD again plays perfectly on my PC. This time, when I burned the DVD and played it on my standalone, some of the dropouts were gone. In the first 45 second chunk, there were no dropouts at all. In each of the next three 45 second chunks there was one dropout. That dropout is shown in blue in this (http://home.comcast.net/~fritzdis/3000VBR.jpg) Bitrate Viewer screenshot of the second 45 second chunk. For some reason, the screenshot of the original CBR file which I provided above is on a different scale than the screenshots of the VBR material, so this (http://home.comcast.net/~fritzdis/CBRonSameScale.jpg) Bitrate Viewer screenshot of the CBR file on the same scale should be used to compare to the VBR file. I have again marked in blue the spot where the VBR file displays a dropout. It is clear from those screenshots that the only remaining dropout occurs when the bitrate of the VBR file exceeds the bitrate of the CBR file. However, I have marked in red another spot where the bitrate of the VBR file far exceeds that of the CBR file. For me, no dropout occurs at the spot marked in red (and in the previous VBR file done at 6087 kbps, no dropouts occurred at any of the three similar spots). I do not know exactly what conclusion to draw from this information.

I also demuxed the m2v from the first rebuilt title (the one done at 6087 kbps) and reauthored another disc in scenarist using that m2v and the original ac3, and the DVD played perfectly on my PC and on my standalone.

[jdobbs]

Please wait until I get the next version out. I appreciate the help, but I think you may be wasting your time. I'm pretty sure I've found the source of the dropout problem and I'm working on it.

It isn't related to bitrate... it is related to illegal SCR/PTS values. CCE is NOT to blame for this, DVD-RB is.

[fritzdis]

Originally posted by jdobbs
Please wait until I get the next version out. I appreciate the help, but I think you may be wasting your time. I'm pretty sure I've found the source of the dropout problem and I'm working on it.

It isn't related to bitrate... it is related to illegal SCR/PTS values. CCE is NOT to blame for this, DVD-RB is.
Thanks for the update and clarification. Illegal SCR/PTS values sure sounds like a more logical source of dropouts than any bitrate oddities. I'll eagerly await the next version.

[jdobbs]

I've fixed it and am testing now. It wasn't as easy to fix as I thought at first. This one was a bitch to find -- but was definitely causing some obvious timing errors in the audio stream.

[FilipeAmadeuO]

When do you plan to introduze the seamless brenching suport ??
In the version 0.60 ?? It would be great !! I´m waiting for it a long time :)

[jhmac]

I think the bug fixes are more important than adding new features at this time...

[jdobbs]

So do I. Seamless branching takes a back seat to fixing errors.

[jdobbs]

The new version (v0.60) is available here (http://forum.doom9.org/showthread.php?postid=546727#post546727). I think this is an important set of fixes and would recommend upgrade.

[fritzdis]

I'm very sorry to report that the new version did not eliminate the dropouts in my test disc. I rebuilt the test disc from scratch, and the dropouts were identical to the dropouts seen with v0.59.

jdobbs,
How many occurrences of the illegal values would you guess should have been fixed in my disc? I ask because when I do a file comparison of the rebuilt VOB from v0.60 and the rebuilt VOB from v0.59, this is what I get:

C:\Documents and Settings\Administrator>fc /b "N:\Test\v060\RBTESTv060\VIDEO_TS\VTS_01_1.VOB" "N:\Test\Working\RBTEST\VIDEO_TS\VTS_01_1.VOB"
Comparing files N:\TEST\V060\RBTESTV060\VIDEO_TS\VTS_01_1.VOB and N:\TEST\WORKING\RBTEST\VIDEO_TS\VTS_01_1.VOB
00000007: 00 04
00000008: 04 94
00000009: 01 AD
0000040A: 00 92
00000807: 04 09
00000808: 94 25
00000809: AD 59
00001007: 09 0D
00001008: 25 B6
00001009: 59 03
00001807: 0D 12
00001808: B6 4C
00001809: 03 57
00002007: 12 16
00002008: 4C DD
00002009: 57 03
00002807: 16 1B
00002808: DD 6D
00002809: 03 AF
00003007: 1B 20
00003008: 6D 04
00003009: AF 03
071E9C12: 0F 0E
FC: N:\TEST\V060\RBTESTV060\VIDEO_TS\VTS_01_1.VOB longer than N:\TEST\WORKING\RBTEST\VIDEO_TS\VTS_01_1.VOB

This indicates that only a few spots at the beginning and end of the file are changed, so unless illegal values early in the file propogate further down the line, the dropouts are being caused by whatever problem was there before, right?

[eriksen76]

Yup same errors here as well.

Tryed the two movies I have been testing all the time.

1)Friday the 13th part6 (PAL)
2)The Scarlet letter (NTSC)

The same problem at the same place. Still no probs on my computer, nore on my PS2.

With both movies it seems that it happens when the camera changes, such as when a man trying to kill Jason in his grave stabbing him 10 times. Dropout comes.

With the other movie. A man is jumping in the water and water splashes, and thats where the drop out is.

But nice try anyway, I think we're getting closer.

/Julius

[robot1]

@eriksen76
Just to be sure, have you done the backup from scratch (running the prepare phase)?

[eriksen76]

Originally posted by robot1
@eriksen76
Just to be sure, have you done the backup from scratch (running the prepare phase)?

Yes I did it from the very beginning. I did a 2 pass CCE encode

/Julius

[jdobbs]

@fritzdis

Can you outline, step by step, exactly what you did to test this? Are you testing against a full length movie? What audio tracks are you keeping? Did you do any pre or post processing? Versions? I spent 12 hours on this yesterday, scanning files, scanning code, writing testing routines, and testing output. I have only been able to force an audio dropout once -- and this fixed that one.

Make sure you test it on discs other than the test disc -- that one, I believe, is caused by the fact that it is actually growing (not shrinking) during recode.

The number of changes per disc is small... if it had been a big problem there would be more than a handful of people experiencing it.

I'm crestfallen.

[gizzin]

when i try to encode with 7pass cce it only does 1.

[gizzin]

oh ya i forgot i also got a error #3 buffer overflow while trying a encode. v60

[jdobbs]

What version of MPEG2DEC3DG.DLL are you guys using? Is it the one from decodefix110mod.zip dated 4/24/2004? I've gotten reports from others that the ones from decodefix.zip and decodefix100.zip caused the problem and it went away with this one. The version number, apparently, when viewed from explorer looks the same on all three.

[eriksen76]

Originally posted by jdobbs
What version of MPEG2DEC3DG.DLL are you guys using? Is it the one from decodefix110opt.zip dated 4/24/2004? I've gotten reports from others that the ones from decodefix.zip and decodefix100.zip caused the problem and it went away with this one. The version number, apparently, when viewed from explorer looks the same on all three.

I'm using "decodefix110mod.zip" 24. april 2004, 09:03:24
Is that the one you are refering to??

I've never heard of decodefix110*opt*.zip
Is the *opt* version different, or did you write *opt* instead of *mod*?

In my setup I give dvdrb the path to MPEG2DEC3DG.DLL in my plugin directory but I also place a "tick" (or what its called) in the small window. Could this cause the error that I do so???

Currently I'm using AviSynth_255.exe. Have tryed the previous versions as well. I'm using the default install.

Please reply, and I will make another test

TIA

/Julius

[jdobbs]

Yep, missprint, you have the right one.

[jdobbs]

Originally posted by gizzin
oh ya i forgot i also got a error #3 buffer overflow while trying a encode. v60 Have you ever gotten it before? Are you removing content with some other package before running DVD-RB?

[eriksen76]

Originally posted by jdobbs
Yep, missprint, you have the right one.

In my setup I give dvdrb the path to MPEG2DEC3DG.DLL in my plugin directory but I also place a "tick" (or what its called) in the small window. Could this cause the error that I do so???

What about the "tick" thing - Could that be the error.
If you PM me with an "adress" I can upload the clip where it goes wrong. Maby that makes it easier for ya.

/Julius

[Fr4nz]

Originally posted by eriksen76
I'm using "decodefix110mod.zip" 24. april 2004, 09:03:24
Is that the one you are refering to??

I've never heard of decodefix110*opt*.zip
Is the *opt* version different, or did you write *opt* instead of *mod*?

In my setup I give dvdrb the path to MPEG2DEC3DG.DLL in my plugin directory but I also place a "tick" (or what its called) in the small window. Could this cause the error that I do so???

Currently I'm using AviSynth_255.exe. Have tryed the previous versions as well. I'm using the default install.

Please reply, and I will make another test

TIA

/Julius

Hey julius use the MPEG2DEC3 version that is here: http://forum.doom9.org/showthread.php?threadid=74308

Maybe it will fix the problem.