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.

[eriksen76]

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

Maybe it will fix the problem.

Thanx but as I wrote a few posts ago, I am already using that version. Which Avisynth version are you using?

Maby that could be the error. Well actually Im kinda confused cause it has to be a program related with the rebuilding. Which one is that apart from DVDRB. Cause if I demux the mp2 and ac3 and reauther there are no problems at all???

Im confused.....

/Julius

[Trahald]

maybe jdobbs can comment but since RB is closed environment it can be more picky about input (sorta like the dvd players that have been skipping.. they expect input that is within certain parameters). other authoring apps are like an apex that will accept (actually HAVE to accept) anything remotely acceptable thrown at them and make the output work. its a generalization but its just to give an idea of the difference

[Fr4nz]

Originally posted by eriksen76
Thanx but as I wrote a few posts ago, I am already using that version. Which Avisynth version are you using?

Maby that could be the error. Well actually Im kinda confused cause it has to be a program related with the rebuilding. Which one is that apart from DVDRB. Cause if I demux the mp2 and ac3 and reauther there are no problems at all???

Im confused.....

/Julius

Avisynth 2.54 and 2.55 gave me no problem.

[eriksen76]

Originally posted by Trahald
maybe jdobbs can comment but since RB is closed environment it can be more picky about input (sorta like the dvd players that have been skipping.. they expect input that is within certain parameters). other authoring apps are like an apex that will accept (actually HAVE to accept) anything remotely acceptable thrown at them and make the output work. its a generalization but its just to give an idea of the difference

I think you're right. This evening I tryed to playback one of the RB-Created movies which had stutter in two scenes on my Pioneer and Jvc players. But guess what, their Sony Dvd player did not have any problems at all. Not any freezing either. Just perfect.

So the problem is/or has to be, that DVDRB's output somehow not is / or partly not is compatible with all dvd players. Encoding quality is perfect and sound also. No problems there.

But still the damn periodic stutter on my 2 standalones. Don't know what needs to be fixed to make it work, but lets hope Jdobbs can.

Very very strange that I can demux the output and create a new dvd which plays fine in all standalones. I have never before, until DVDRB, experienced any probs,skips or stutter on my standalone. Dvdshrink, other one-click program backups and downloaded movies all play fine.

...../Julius

[fritzdis]

Originally posted by 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.
First, I tried it with the small test disc I made, keeping the 1 audio track. I have now also tested it against a full length movie that had to be reduced to 61.8%. Both the small test disc and the full length movie still display dropouts.

For the movie, I removed 3 of the 4 audio tracks (one of the tracks I removed was DTS). I did not apply any pre or post processing to the title. I used the MPEG2DECdg.dll included in decodefix110mod.zip and dated April 24, 2004, 9:03:24 AM. The Avisynth version is 2.55 (build: Sep 1 2004 [16:49:49]), and the CCE version is SP Trial 2.67.00.27 (along with EclCCE 1.81).

[fritzdis]

Originally posted by jdobbs
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.
Is this still the case with the new version? If so, do you mean that DVD-RB assumes that the bitrate at every point in the video stream will be less in the reencoded file than in the original? There seems to be no guarantee that this will be the case, especially when the title only needs to be slightly reduced. My post about changing the vbr bitrate to 3000 on my test disc shows an instance where the reencoded file is less than half the size of the original file, yet there are points in the reencoded file where the bitrate is higher than it was in the original.

Originally posted by jdobbs
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.
I think that the case when no reduction at all must be done is not in any way fundamentally different from the case when limited reduction must be done. Obviously, I could be wrong about that, but I can't see what the difference between reduction to 99% and reduction to 100% would be (and DVD-RB should be able to do reduction to 99% even if there would be little reason to actually do it).

Also, for my test disc, the original is 141 MB, and the rebuilt title is 113 MB. This is because DVD-RB decides the original is interlaced, so it sets the max bitrate to 7200 kbps. Out of the three minutes of video, 1 minute is pure black video, which is encoded at almost 0 kbps. Assuming the rest of the video is encoded at the max bitrate, the overall bitrate would only be around 4800 kbps, rather than the specified 6087 kbps.

[gizzin]

jdobbs it was a couple cells into encoding a think the third. I was the whole disc nothing removed at all

[gizzin]

jdobbs, I also have 2 encodes of gang related. One i did one pass and kept everything and it didnt show any dropouts or blips. And one i did 7 pass and removed the other 2 languages with rebuilder bu this one did show dropouts. They were done with v59 so if you were to have these 2 couldnt' you find the problem? I've mentioned this before.

[jdobbs]

@fritzdis

No. It doesn't mean that. Why would the timecodes in the audio be dependent upon the video bitrate? The SCR can be used to determine where is should be so it gets presented within the correct period.

How about we leave the DVD-RB programming to me.

[fritzdis]

The point of my previous post was that if dropouts in my test disc could be "caused by the fact that it is actually growing (not shrinking) during recode," could this not happen on a more localized level? That is, even when the video as a whole shrinks during reencoding, a particular portion of the video could grow and somehow result in dropouts.

[jdobbs]

No, that isn't what I meant. If it is bigger in one place, but overall is smaller or equal it wouldn't make a difference because of buffering and the difference between the read time and the presentation time -- the Audio gets interleaved in the multiplexing and all is well. If however it gets so big (as a whole) that one or the other can't be inserted early enough so that it can be decoded and presented -- you can have a problem. On the original the authoring package would reject it, but since DVD-RB always makes it smaller I never added those checks -- I really don't have to.

There's more to it, but that's it in a nutshell. What I'm saying is that I've spent a lot of time and effort in making this work and work correctly -- and when I say something I really don't expect it to be questioned. The alternative is that I just won't comment at all any more.

[Oldeman]

I still have audio dropouts on three Toshiba players 3950, 4800,and 4900 sing DVD-RB .60 and Quenc .53.

Using 2 pass Quenc give awsome video. It appears to me that the audio /video sync is better with this version. On prior versions it would get horribly out of sync and audio would disapear completely now it seems to pulse, its hard to describe.

As before, I do not get the audio dropouts on my Apex 1500 or Philips DVDR75 or anything done with DVD-RB and Rejig.

[gizzin]

You gonna answer my questions jdobbs? or just keep ignoring

[jdobbs]

Attitude check [yours].... hmmm... yeah, ignore.

[glassvial]

Originally posted by Oldeman
I still have audio dropouts on three Toshiba players 3950, 4800,and 4900 sing DVD-RB .60 and Quenc .53.

Using 2 pass Quenc give awsome video. It appears to me that the audio /video sync is better with this version. On prior versions it would get horribly out of sync and audio would disapear completely now it seems to pulse, its hard to describe.

As before, I do not get the audio dropouts on my Apex 1500 or Philips DVDR75 or anything done with DVD-RB and Rejig.
Wow this thread has grown legs...

Have you tried QEnc .54? Also what version of avisynth are you using? Is what you're backing up PAL or NTSC?

[Oldeman]

I am trying to back up NTSC (NeverTheSameColor) R1 DVD. Using AviSynth 2.54 with DVD2AVIdg/MPEG2DECdg. Tried with/without dynamic bitrates, 1 and 2 pass.

Last time I tried Quenc .54 it died during the rebuild phase. I'm trying it again right now with one pass and .60b(?).

I'm been trying DVD-RB since about version .27(?); never had any trouble with Rejig as encoder.

I have Instant Copy, Ulead Movie Factory 2, Nero Ultra, DVDlab plus most of the freebies..etc. I usually use DVDDecrypter(rip), DeReMake(strip), and DVDShrinkfit), Pinniacle InstantDisk(burn).

System HP 3.0E P4, HP300I burner, WinXP with sp2. Usually burn DVD+R(Ricohjpnr01)4x media at 2.4x. I also burn a lot on my Philips DVDR75 standalone.

[Oldeman]

With Quenc .54 and one pass, I get buffer overflow error#3 during rebuild.
sigh....*&^&$%#

[dragongodz]

Oldeman - since you have a P4 use the mem-aligned version of avcodec. you can download that from the same web page as you got QuEnc 0.54. then you should be able to do 2 pass without it dieing.

[fritzdis]

OK, I'm going to make one last excessively detailed post on this subject. Unless I get an indication that the particular avenue I've chosen is worth pursuing, I'll let it rest after this.

I prepared my test disc with DVD-RB v0.60b, and then using RB-Optv0.15, I changed the Reduction from 100% to 50.2% and saved. I then encoded and rebuilt in DVD-RB and burnt the disc. There was one dropout in each of the final three 45 second chunks, and each was at the same relative position within its respective chunk. The dropout position is marked in blue on this (http://home.comcast.net/~fritzdis/50.2_Reduction.jpg) Bitrate Viewer screenshot of the second 45 second chunk.

Next, I prepared the original test disc again to a different folder. This time I changed the Reduction from 100% to 66.6%, encoded, rebuilt, and the disc had a pair of dropouts in identical relative positions in each of the final three 45 second chunks, as shown in this (http://home.comcast.net/~fritzdis/66.6_Reduction.jpg) Bitrate Viewer screenshot.

Finally, I prepared the original test disc to yet another folder, changed the Reduction from 100% to 85.5%, encoded, and rebuilt. The resulting disc displayed the same dropouts as in my initial description of the test disc (including those in the first 45 seconds), where I had left the Reduction at 100%. Here (http://home.comcast.net/~fritzdis/85.5_Reduction.jpg) is the Bitrate Viewer screenshot of the second 45 second chunk of the 85.5% Reduction file.

All three of these rebuilt discs were smaller than the original test disc.

The obvious assumption one could make when seeing those pictures is that the dropouts are in some way related to the bitrate of the video. Possible reasons that this assumption could be false include (but are not limited to) the following:
1. The use of RB-Opt in some way invalidates the results. This seems unlikely to me, and can hopefully be quickly decided upon.
2. The occurrence of dropouts at higher bitrate spots is coincidental, or (more likely) the higher bitrate is secondary to a more fundamental difference that occurs when encoding with a different average bitrate. This could be particularly difficult to prove or disprove.
3. The source is invalid. The use of pulldown.exe and the fact that DVD-RB decides that the video is interlaced makes me wonder if all the right flags got set. Other questions, such as whether the AC3s created by besweet could be in any way noncompliant, also remain. I have requested that Sir Didymus examine the original files with DVD Profiler, so hopefully he has the time and is kind enough to do so.
4. The artificiality of the video I created and then encoded with CBR (at a bitrate insufficient to handle to most complex parts of video) invalidates the results, at least in a practical, if not theoretical, sense. As far as I know, the material I provided to jdobbs is the only material that has allowed him to reproduce a dropout, so this possibility has to be considered.
5. I have configured something incorrectly or have used a combination of software that introduces errors. Independent rebuilding of the original files would help decide whether this is the case.

[Sir Didymus]

Originally posted by fritzdis
OK, I'm going to make one last excessively detailed post on this subject. Unless I get an indication that the particular avenue I've chosen is worth pursuing, I'll let it rest after this.

...
skip
...

3. The source is invalid. The use of pulldown.exe and the fact that DVD-RB decides that the video is interlaced makes me wonder if all the right flags got set. Other questions, such as whether the AC3s created by besweet could be in any way noncompliant, also remain. I have requested that Sir Didymus examine the original files with DVD Profiler, so hopefully he has the time and is kind enough to do so.

...
skip
...


That's right, I have available yours source files. Thank you. ;)
Only now I have some time to get a look at them...

Please consider that the already stated questions regarding the fact that their size is less than a DVD-R, and so about the necessity of using specific tuning of the cell bitrate, should be not underestimated...

I am afraid my spare time is very limited in this timeframe, but I will be happy of verifying your source with the profiler.

Regarding the usage of pulldown, please consider that I am from PAL land, so I am definitely not able to tell if it should be used or not...

Anyway I say again, I will post later the profiler output on your source files...

Cheers,
SD

[Sir Didymus]

@fritzdis

Here is the analisys of your SOURCE title.
In the attached archive, the error.jpg reports the synthesis of the whole profiler work, with error id's and relative occurrencies.

Giving a very quick look at the error logs, the most important reported ones are #1691, #1696, #1697.
Of course all errors are important, but #1000 are all MPEG errors...

Just as examples,
#1691 is a VBV buffer overflow;
#1696 is an error in the Vbv_delay value, leading to negative or zero time to receive all bits of previous picture;
#1697 reports that the actual bit_rate exceeds maximum bit_rate, as specified in sequence header and sequence extension.

In the same archive, the std buffer.jpg shows the real time occupancy of the std buffer. In this case, as you may see,
the figure is very good, since it shows that the system target decoder buffer is most time full (i.e. over 200000), but IT NEVER OVERFLOWS the limit [which is 237568]...

I will send to you, via PM, other more detailed log information, with the extensive description of all detected errors...

Cheers,
SD


P.S.

I should say that it seems that too many variables have been put in the process and, as you see, many errors are present in the source title...

So, please consider that using this specific source for trying to understand what is going wrong with DVD-RB may be not totally helpful for jdobbs, even if yours (and myselfs, and other kind testers) idea is to try to provide him with useful and supporting information...

Even original titles have errors, but at least, since they are available on the shelf, DVD-RB should try to cope with them, otherwise the backup of these originals would be precluded.

Even in the case of a completely error free source [and I state clearily, I will give full support to you, if you like, for improving the source], there is still the big problem that DVD-RB is assumed to be used for reducing titles larger than 4.700.000.000 bytes, so whatever errors we get in the rebuilt target, we will never be able to state the logical conclusion that something is wrong in DVD-RB...

I mean, maybe it should be better to base further analysis on original titles... What do you think about ?

[fritzdis]

Originally posted by Sir Didymus
Even in the case of a completely error free source [and I state clearily, I will give full support to you, if you like, for improving the source], there is still the big problem that DVD-RB is assumed to be used for reducing titles larger than 4.700.000.000 bytes, so whatever errors we get in the rebuilt target, we will never be able to state the logical conclusion that something is wrong in DVD-RB...
Do you think using RB-Opt to adjust Reduction makes any difference in what logical conclusion we can draw? I could of course take the three minutes of video and audio I have now and turn them into two hours, thus constructiing a title greater than 4.700.000.000 bytes, but distributing that source would then be too difficult.
Originally posted by Sir Didymus
I mean, maybe it should be better to base further analysis on original titles... What do you think about ?
The main reason I remain fixated on my test disc is that, as far as I know, it is the only material that has allowed jdobbs to reproduce dropouts, and it must be incredibly difficult for him to fix errors that don't even happen to him. [Edit: The other reason I'm fixated on my test disc is the striking correlation between bitrate and dropouts that seems apparent from the screenshots of the reencoded files done at different reductions. Results this "clean" may be hard to find without a controlled source.]

All of this may not matter though, since the source files display so many errors. At this point, I want to let jdobbs direct me as to whether any further testing could yield any helpful results.

[Sir Didymus]

Originally posted by fritzdis
Do you think using RB-Opt to adjust Reduction makes any difference in what logical conclusion we can draw?

No, I don't think it will change too much, beside it is an additional process/tuning/action added to the process, so it could make more difficult to state by sure if it is really relevant or not...

Originally posted by fritzdis

I could of course take the three minutes of video and audio I have now and turn them into two hours, thus constructiing a title greater than 4.700.000.000 bytes, but distributing that source would then be too difficult.

Totally agreed. It could help a lot for removing any additional intervention, once the source title is generated, but it will be very difficult to share it...

Originally posted by fritzdis

The main reason I remain fixated on my test disc is that, as far as I know, it is the only material that has allowed jdobbs to reproduce dropouts, and it must be incredibly difficult for him to fix errors that don't even happen to him. [Edit: The other reason I'm fixated on my test disc is the striking correlation between bitrate and dropouts that seems apparent from the screenshots of the reencoded files done at different reductions. Results this "clean" may be hard to find without a controlled source.]

Your work is really appreciated [at least I can say this for what is concerning myself]. Since in the last two days two DVD-B releases have been released, I suppose that they have been very useful also for jdobbs... But I'd better speaking just for myself...

Originally posted by fritzdis

All of this may not matter though, since the source files display so many errors. At this point, I want to let jdobbs direct me as to whether any further testing could yield any helpful results.
I say again, sometimes even original titles are showing plenty of errors, so please do not stop your tests just because of the reported errors; please follow the indications of jdobbs [if any will be given].

By the way, is anybody able to see the attachment I put on my previous post ? It is a zip archive of just 80KB, that for some mystic reasons seems to be not visible to me... And it should be there due to the bulletin is preventing me to attach it again to another post...

Cheers,
SD

[Oldeman]

In my last run whereby I reported dropouts, I discovered that I was not using .60b due to a browser cache issue.

I just finished a SUCESSFUL movie using DVD-RB .60b and Quenc .54 with memaligned avcodec. This movie plays without audio dropouts on my Toshiba players. This is a first for me with DVD-RB and Quenc.

My thanks to you M.JDobbs and to dragongodz for suggesting the P4 workaround (memaligned avcodec).

I will test a different movie to verify, but I think you might have a good fix on the audio dropouts. At least for some more players.

DVD-RB is a very complex effort, using pieces of other peoples software and trying to handle an almost infinite number of varibles (in the bastardizied dvds that are available) plus being hacked again by each user. Its amazing that it works at all.

Congrats JDobbs, don't be so hard on yourself. Just because a few of us are having difficulty with your fantastic software..

Its a noble cause and you're the MAN...:)

[fritzdis]

SD,
[Edit: Now I see the attachment]

[wmansir]

I approved your attachments, Sir Didymus.

In the future you can PM me when you post an attachment.

Also, you can host image (and .swf) files for free at:

http://www.imageshack.us/index.php

[eriksen76]

This is the info that is written on my scene where I get a dropout.
Could something below cause it. As you can see its for the hole title (V01000100001002. But I only see error after about 2 mins.

What does this mean???? : *samples_per_sec=44100
Is it downsampled or what?????? Thought it was 48000

Does everything look ok?

[item]
title=V01000100001002
aud_out=0
vaf_file=C:\DOCUMENTS AND SETTINGS\ ERIKSEN\SKRIVEBORD\D2VAVS\V01000100001002.vaf
aud_file=C:\DOCUMENTS AND SETTINGS\ ERIKSEN\SKRIVEBORD\D2VAVS\V01000100001002.mpa
file_focused=0
packet_size=2048
width=720
height=480
frame_rate_idx=1
cbr_brate=6000
vbr_brate_avg=3345
vbr_brate_min=0
vbr_brate_max=9000
seq_endcode=0
dvd=0
half_width=0
half_height=0
lum_level=0
aspect_ratio=2
gop_m=3
gop_nm=4
gop_hdr=12
seq_hdr=1
all_closed_gop=0
fix_gop_length=0
*samples_per_sec=44100
stereo=2
brate_idx=7
crc=1
progressive=1
alternate_scan=0
intra_dc_prec=2
aud_mode=0
tc_ref_frm=0
drop_frame=0
fix_vbv_delay=0
letter_box=0
pulldown_detect=0
offset_line=0
create_new_vaf=1
credits_tweak=0
credits_start=0x00000
credits_brate=1000
h_filter=0
h_filter_idx=8
dither=0
dither_max=8
qmat_idx=0
quality_prec=16
timecode=0x0000000
q_char_f=16
tc_offset=0
v_filter=0
v_filter_val=6
pict_name=
pict_type=3
pict_level=255
video_type=16
vid_file0=C:\DOCUMENTS AND SETTINGS\ \SKRIVEBORD\D2VAVS\V01000100001002.m2v
vid_file1=C:\DOCUMENTS AND SETTINGS\ SKRIVEBORD\D2VAVS\V01000100001002.m2v
vid_out=1
vaf_out=1
opv_q_factor=20
opv_brate_min=0
opv_brate_max=9000
vbr_bias=10
vbr_pass=5
use_filter=0
filter_val=6
non_linear=1
top_first=0
mpeg1=0
mpeg1_cps=1

[file]
name=C:\DOCUMENTS AND SETTINGS\SKRIVEBORD\D2VAVS\V01000100001002.avs
frame_first=0
frame_last=21826
encode_first=0
encode_last=21826

Julius

[robot1]

Originally posted by eriksen76
This is the info that is written on my scene where I get a dropout.
Could something below cause it. As you can see its for the hole title (V01000100001002. But I only see error after about 2 mins.

What does this mean???? : *samples_per_sec=44100
Is it downsampled or what?????? Thought it was 48000

Does everything look ok?

[item]
title=V01000100001002
aud_out=0
Audio is not encoded (aud_out=0), so it's not downsampled.

[fritzdis]

I've done two new tests with v0.62

First, I created a 5.29 GB dvd out of my test video. I then used DVDRB in one-click mode on that title and burned the result. There were dropouts in mostly the same places as my other tests (this time, I had reduction=79.8%, which is in between 2 of the previous tests I had done with small titles; those tests gave me better consistency in terms of dropout placement).

Next, I did a test that was suggested to me by robot1. With my small title, I ran the prepare stage. I used RB-Opt to set reduction to 85.5%. Then, in REBUILDER.ECL, I changed dvd=0 to dvd=1 (this is the DVD Compliant setting, right?). Then I encoded and rebuilt. The burned disc had the dropouts in exactly the same places as before (in fact, the dropouts seemed worse; that is, the duration of each dropout seemed slightly longer, but it could be my imagination).

If anyone thinks there are other tests I could run to more surely validate my results, let me know. The only thing I can think of is making a disc greater than 4.37 GB that DVDRB would decide needs to be reduced to about 85.5%. Then I could compare that result with my smaller test at 85.5%. I may do that overnight tonight.

[Sir Didymus]

Originally posted by fritzdis
I've done two new tests with v0.62

First, I created a 5.29 GB dvd out of my test video...



Hi, fritzdis...

Happy to ear this. In fact [I mean, just in my opinion] the relevance of testing DVD-RB on a title that is not fitting anymore on a DVD-R is now much improved...

Cheers,
SD