My solution to DVD-RB Video Stuttering Issues

[lab-one]

I found it odd that some users are NOT having stuttering issues. In my experience with computers and software, I generally find that if it works one place but not somewhere else...then there is something wrong with the somewhere else. The fact that others were not having the issue also bothered me because I was getting great results except for that one issue.

So, I started looking at my local environment and started to find things that I felt were potentially conflicting. For example, because I have used a lot of different back-up software in the past I found that I had 3 versions of AVISynth installed. This was mostly due to GordainKnot and all of the applications required to do a DVD to AVI back-up. I found more than one version of decomb and more than one version of mpeg2dec3dg.dll also.

First thing I did was uninstall all of the DVD back-up software on my machine. This included all Gknot apps and all DVD-RB apps. The only thing I didn't remove was DVDShrink, because I forgot. Then I went into the registry and cleaned up all leftovers from these apps.

Second, I reinstalled all DVD-RB related apps into a central directory, as suggested in the DVD-RB Installation Instructions (http://forum.doom9.org/showthread.php?s=&threadid=74308). Before, all apps were scattered around my pc.

Third, just for kicks, I disabled Norton AV Auto-Protect when installing and doing the back-ups.

As of lastnight, I was able to back-up 2 of the movies that stuttered prior to my system changes:

Veronica Guerin
Matrix Revolutions

I've seen on the forum that there have been problems with Matrix revolutions. I find it interesting that I have absolutely no problems, never receive buffer errors or any errors at all when I do back-ups with DVD-RB, yet others do when backing-up the same movie. Lastnight, while sleeping, I did a 1:1 back-up of Kill Bill with .36. Woke this morning to a completed job and no errors. I viewed the working directory via windvd and everything looks great. This evening I will burn the disc and see what it looks like on my standalone.

Wrapping this up, this seems to be a solution for ME. I am not suggesting that everyone has a mess of stray .dll's on their systems or that anyone without knowledge of the Windows Registry should go mucking around in it. However, if you do have a lot of different applications that are DVD related that you are not using, it may be worth a shot at cleaning up and reinstalling.

As of now, I am thrilled to death that the stuttering is gone. Everything else looks awesome and coming from DVD to AVI and then DVD to DVD via DVDShrink....I'm blown away by the output from CCE.

@jdobbs, thinks for all of the work on this. Once I get paid again, I'll be sending another donation your way.

Edit: Forgot, the problem where rewinding jumped to a chapter doesn't occur in the 2 back-ups now either.

[Joergen]

The Norton-bashing is one of the classics of computing. I seriously doubt disabling norton would help anything. I too have NAV 2004 installed and running and it doesnt cause any problems for me.

[lab-one]

I agree. I never disable my AV. I just happened to look at the icon and think what the hell and disabled it. However, I am going to try another tonight with it enabled just to make sure.

[quantum]

First, I think it's very interesting you were able to clear your stuttering problems. That could indicate for jdobbs that it is not an issue with dvdrb.

Second, of the things you mentioned that you did, the most interesting to me is the avisynth reinstallation and the mpeg2dec3dg. Can you give the filesize in bytes of your good version, and do you still have the prior version?

While it would be a lot of work, it would be great if you could figure out how to cause it and stop it repeatedly. For instance, maybe you were really using mpeg2dec3 instead of mpeg2dec3dg or something along those lines.

In any case, good news and a welcome post.

[Joergen]

I (still) think jdobbs should include a CRC check for all the 3rd party stuff to make sure everything is as it should. Or maybe a series of short video clips and an internal test-routine to see if the output is what it should. Like DirecX "did you see a spinning cube.. well, did it stutter, huh, did it???" ;)

[lab-one]

Unfortunately I am at work right now and can't answer your questions until this evening.

However, I did have both mpeg2dec.dll and mpeg2dec3dg.dll installed in the AVISynth plugin directory and found both in other directories related to the GKnot apps.

Also, I did not keep the old versions to use as reference...should have, I suppose.

As far as seeing if I can figure out exactly what the offending app may be, I set a restore point prior to doing anything. I might do a system restore and remove items individually and see what happens. However, that would take a week probably to burn and make changes and burn and make changes perpetually until done. Not sure that I have the time or patience for that...

[lab-one]

@joergen

"did you see a spinning cube.. well, did it stutter, huh, did it???"

Haha! Fine idea.

[jdobbs]

@lab-one,

Having looked at every line of code more than once in the past few days digging for something that looks like it might be stutter-causing -- and having grayed considerably in the process -- and having absolutely no luck in repeating it... I'm starting to lean in your direction. I haven't given up yet, but I'm running out of rabbit holes to go down.

[Joergen]

Well, I've not had any probs with DVD-RB since the chapter-audio-gap in 0.27, and I've also never installed any tools that use the DVD2AVI, mpeg2dec etc combinations on their own. So it might well be that an unclean system is at fault for some of the problems.

And I only ever choose CCE 2.66, remove DTS (which btw requires you to click on some language twice and then save cause you cant save before that) 3 passes, working path D: and grey layout (;)) in DVD-RB.

[DDogg]

lab-one, great post, but I think that people may think they need to do something other that download the proper mpeg2decdg.dll (see the stickies for link) and enable "Add to avs file" in the RB setup with the proper path to where you put it. No registry entries can then influence it. Did you have that checked? (Just to verify)

What does come to mind is what would happen to those that do not have "Add to avs file" checked and have both mpeg2dec.dll and mpeg2decdg.dll in their plugin directory? No offense, but that it kinda nuts :) I would think each one is activated by the "mpeg2source" statement in the AVS. Frankly, I don't really understand how it would even work. Maybe Wilbert might know.

Personally, I wonder if much of these problems would go away if DVD-RB would insist the exactly named mpeg2decDG.dll be in a sub directory of dvd-rb and do a crc check like Joergen suggested. It just would not work without the right version - period.

[lab-one]

I did have it checked actually. So, I'm not pointing the blame at mpeg2dec3dg.dll. I just happened to notice that there were multiple instances of the file on my computer. I thought about that too as I cleaned up my mess. I don't know what made the difference. I haven't an explanation. I just know that 2 of the 5 movies that skipped during playback and hung during rw/ff don't now. I am going to keep trying others to see if it's just a fluke or not.

*shrugs*

[jdobbs]

I'm seriously thinking about making people install MPEG2DEC3DG.DLL in the DVD-RB directory and it won't run until you do. I may just get rid of the "path" and force the line that points to the one in that directory in every AVS. And the only way you can change it is to edit every AVS. That way I can be sure I'm not chasing snipe as people (and other software packages) start playing around with defaults.

[luphy]

That's a good idea jdobbs considering your target audience for this program....noobs like me! :D

Not sure about the copyright issues with that dll, but maybe make it even easier and have the exact version you want people to use in your zipped download.

[quantum]

I think before getting overly focused on this issue it would be nice have some confirmation it really is a cause of stuttering. I think I'll try to replace mpeg2dec3dg.dll with an older version and see what happens.

[DDogg]

quantum, I hear what you are saying but jdobbs solution takes care of some other potential housekeeping and support issues. Support is going to get tough if this program takes off like D2S did. Believe me, I've been there. Having hard text logs would be another helpful thing.

[jdobbs]

Originally posted by quantum
I think before getting overly focused on this issue it would be nice have some confirmation it really is a cause of stuttering. I think I'll try to replace mpeg2dec3dg.dll with an older version and see what happens. I agree -- but after several days of testing and debugging, I need some hard evidence that it is DVD Rebuilder also... because I simply cannot repeat this, and when lab-one cleaned his environment it went away. I want this fixed too. But if I could also spend the next 2 months trying to find it -- only to see it isn't there. I'd like a little assurance that I'm not spinning my wheels.

I will say that I found and fixed what I believe to be an error in 0.38 that may have an effect. But I think its minor.

If the stuttering is my code, my best guess is that it may be related the audio "drift" someone mentioned a while back. Somewhere in the standards or write-ups I read that standalone players are supposed to use the video clock as the baseline and audio as secondary -- and when there is a mismatch the video takes priority. But when playing back on PCs it is reversed (I'm guessing because they sometimes can't keep up with the video rate). That's the reason you see video skipping so often in cheap PC player codecs.

I'm conjecturing that some of the more sensitive players might be using PC based algorithms and may respond to audio/video inconsistencies by giving priority to the audio -- and causing video stutters. The start of a new cell may be the place to "sync"

But... I haven't been able to find any inconsistencies. I've even run entire side-by-side runs between my output VOBs and the originals and the PTSs match bit for bit (as they should when you have the same number of frames and rffs).

[lab-one]

Never meant to create a debate over mpeg2dec3dg.dll, hence the title of my thread "My solution to DVD-RB Video Stuttering Issues". I have no idea what fixed it. However, at my best guess by looking at the threads, at least 60% of the users are not having the problem.

I just finished watching Kill Bill Volume 1. Again, no stuttering, ff/rw work fine. Seek works fine. Audio is fine.

DVD Decrypter (rip)
DVD-RB .37
ECLCCE 1.8b
CCE 2.50
Image Tool Classic (iso)
DVD Decrypter (burn)

I also noticed that the speed at which CCE now encodes went from an average of 1.6 to 2.3. This was noted with both DVD-RB .36 and .37.

Finaly....Uma has a great ass.

[jdobbs]

Originally posted by lab-one
Finaly....Uma has a great ass. [/B] Sometimes a quality encode is very important.:)

[quantum]

I just tried to reproduce the stuttering by replacing mpeg2dec3dg with an older mpeg2dec3 and I had no stutter on my Pioneer standalone. But I believe you needed a bad encode and a particular player to manifest the issue so I may have missed with the player.

In any case, who's left with stuttering? Considering lab-one was able to cure it with, presumably, avisynth cleansing, then it's reasonable to assume the few others who are left might be able to fix it this way as well.

Anyone left with stuttering should follow lab-one's steps in this thread and chime in here with the results. Anything we can do to help jdobbs on this is good for the cause.

[Sir Didymus]

1. DVD-R Version: 0.38
2. Encoder being used: CCE-SP 2.66
3. Using eclCCE? Y, 1.8b
4. Bug encountered:

Chapter stutter.


I authored (with IfoEdit) a new title using just the first five chapters of Donnie Brasco, PAL, R2, in order to speed up the encoding and burning time. The problem is just perceivable in my standalone player, that is a Medion DVD player. It seems to me that the stutter is reduced respect to earlier releases of DVD-RB, but it is there. No doubts about.

The stutter is present at all chapter changes.
It is a pause of one or two frames.
It seems to me the audio is perfect.

As previously reported, I also noticed that in the display of the player, if you play the title normally, both the chapter number and the time elapsed is correct; if you play backward through the chapter breaks, the chapter number is not updated and the time elapsed shows a value that is affected by the following error (in bold the right value to show):


Chapter nr ... Start ... End ... Time showed in backward play through the previous chapter
........1 ........ 0:00 ... 5:30 ... n.d.
........2 ........ 5:30 ... 12:39 . 10:59 = (5:30 - 0:00) * 2 + 0:00
........3 ........ 12:39 . 14:14 . 19:48 = (12:39 - 5:30) * 2 + 5:30
........4 ........ 14:14 . 17:45 . 15:49 = (14:14 - 12:39) * 2 + 12:39
........5 ........ 17:45 . 23:25 . 21:16 = (17:45 - 14:14) * 2 + 14:14

The encoded frames, showed by CCE, are right for all chapters; the overall quality of the encoding is beautiful, so I do not think it is a problem of bad encoding...

Regarding the environment clean up proposed by lab-one, please note that I have just a single AviSynth installation on my machine, Version 2.54, build: Jan 26 2004 [09:28:02] and regarding mpeg2dec3dg.dll, I had already cleaned up my environment. Actualy just two instances of this dll are present (one in the plugins dir of Avisynth and one in the dir of Dvd2Avi, and they are both the same file); no instances of mpeg2dec3.dll are present.

I did'nt perform a radical removal of antivirus and of all other applications present om my PC, but in a couple of days I will have available a new PC without any software installed, where I will just first set up DVD-RB and test it alone.

[jdobbs]

@Sir Didymus

Thanks for the detailed report. As for the stutter, would you guess it happens for 1 frame, 2, more? Also, does it include an associated audio stutter -- or just video?

Thanks.

[DrVenkman]

I get pretty much the same error as Sid Didymus.

The pause is for about 2 frames I think, one when the chapter actually changes and then another one a frame or so later. The audio is unafected and just plays as normal. When you rewind through the chapters the display on the DVD doesn't change, so RW from Chapter 3 to Chapter 2 makes no difference on the player, it just says your still on chapter 3.

However, this only happens on 1 of my players - a cheaper one I might add. But my Panasonic player and PowerDVD play with no problems what so ever.

[Sir Didymus]

@jdobbs

Little consideration: since the trouble of the stutter seems to be very limited, as it happens just to few people, please forget the problem; for what concern myself I will be very happy of destroying my standalone player (literally, I am not joking: maybe its time to change my "toaster").

Regarding your question:
The stutter is just in the video.
The audio is perfect.
It is present at all chapter changes.
It takes just one or two frames.
It is very difficult to judge if it is one or two, but it is by sure no more than that little.

I am now planning to check if the problem is related to CCE or if it is present also using ReJig and QuEnc.

In case it happens just with CCE SP 2.66 I also would check what happen with a different (TRIAL) version of CCE.

Tomorrow I will have these checks done...

[RB]

A random thought ... when using CCE, the M2V time code is reset to 00:00:00:00 at the start of every cell/chapter after remuxing. Maybe some players have trouble with this clock reset and think it's a playback discontinuity/layer break? Would be interesting to see whether continously increasing the GOP timestamps during remuxing across all cells makes any difference...

[jdobbs]

Originally posted by RB
A random thought ... when using CCE, the M2V time code is reset to 00:00:00:00 at the start of every cell/chapter after remuxing. Maybe some players have trouble with this clock reset and think it's a playback discontinuity/layer break? Would be interesting to see whether continously increasing the GOP timestamps during remuxing across all cells makes any difference... RB!!! You are really good! That makes absolute sense -- and the GOP Start Code extension timestamps in the cells are being reset to zero. I don't know if this is it, but it is definitely the best possible candidate I've heard for chapter stutter yet. I'm off to research it.

[Joergen]

Ooh.. I salute thee RB! That should explain why some players like WinDVD will skip to the beginning of a chapter when rewinding cause they prolly look at the timecode to see where they're at.

[jdobbs]

Well I'm going to put in the code and see what happens... but my confidence is dropping. I went through some original DVD's -- and it doesn't seem to be consistent. In the sections of one original I examined it looks like the GOP Start code is "00:00:00:00" on every GOP while another is starting at one hour and then sequencing through...

[Sir Didymus]

That's funny...

Encoding with ReJig the stutter is not present...

But the anomalus display of chapter and time is still there...

Rewinding through the chapters breacks the chapter number doesn't change and the time displayed is affected by the same error already reported...

Nevertheless, I say again, with ReJig no stutter is present in the video.

[jdobbs]

Originally posted by Sir Didymus
That's funny...

Encoding with ReJig the stutter is not present...

But the anomalus display of chapter and time is still there...

Rewinding through the chapters breacks the chapter number doesn't change and the time displayed is affected by the same error already reported...

Nevertheless, I say again, with ReJig no stutter is present in the video. That's good to know. That means I can rule out the authoring as the cause of the stuttering problem, since it is independent of the encoding method. It seems, then, to point back to the encoded stream.

[Fr4nz]

Originally posted by Sir Didymus
@jdobbs
[CUT]
Regarding your question:
The stutter is just in the video.
The audio is perfect.
It is present at all chapter changes.
It takes just one or two frames.
It is very difficult to judge if it is one or two, but it is by sure no more than that little.

I am now planning to check if the problem is related to CCE or if it is present also using ReJig and QuEnc.

In case it happens just with CCE SP 2.66 I also would check what happen with a different (TRIAL) version of CCE.

Tomorrow I will have these checks done...

I noticed something similar to this stuttering some time ago, when I demuxed directly with DVDecrypter the m2v stream and played it back with Windows Media Classic player.

Then I used VobEdit to demux the m2v stream and it played correctly.

[lab-one]

I do not have any of the problems with how time is being displayed on my standalone now. RW/FF both work fine...

[HarryM]

I back-up 3 movies (PAL edition) with DVD-RB for the present.

Every one with another version of DVD-RB (+ CCE 2.67). At intervals of 2 weeks.


The first and second movie is good, but the third is stuttering on desktop DVD player.
The first 10-15 minutes is good (smooth motion, etc.), but after it is strongly stuttering (choppy motion). I encoded this movie again and again (three times), with another (older) version of DVD-RB, but stuttering is still causing.

Interestingly, I test simple shrink this problematic DVD with "DVD Shrink" - all is OK... :mad:

[jdobbs]

Okay to all. The debate is hopefully over. I think I found the cause of the stutter. But since I could never repeat it I'll have to wait until I post it and it gets tested. Right now I'm running a job with the new version to make sure I haven't caused any other issues with the fix.

@RB

Thanks again, dude. If this is the fix, you were on the right track. DVD-RB was setting the GOP time stamp, restarting at 0 for each CELL, as I was rebuilding. But as I was researching to see if this could be the source of the problem, I found a different bug. The first GOP of every cell was being timestamped as if it were a continuation of the previous cell by mistake (it was using a frame counter and rff counter to determine the timestamp that had not yet been reset). And then the second through n GOP would be set as if the CELL had started off at 0...

I can see how this could conceivable confuse a player, and even cause the time display error when rewinding through chapters. But whether it fixes the problem is yet to be seen. It just seems odd that a player would depend on this value when it has better ones to use...

I've also modified the code so the timestamp increments through the entire VTS... I'll see if that has any affect when I play back the test disc I'm creating.

[jdobbs]

Originally posted by HarryM
I back-up 3 movies (PAL edition) with DVD-RB for the present.

Every one with another version of DVD-RB (+ CCE 2.67). At intervals of 2 weeks.


The first and second movie is good, but the third is stuttering on desktop DVD player.
The first 10-15 minutes is good (smooth motion, etc.), but after it is strongly stuttering (choppy motion). I encoded this movie again and again (three times), with another (older) version of DVD-RB, but stuttering is still causing.

Interestingly, I test simple shrink this problematic DVD with "DVD Shrink" - all is OK... :mad: I don't think what you are seeing is related to the "stutter" discussed in this thread.

[Sir Didymus]

Originally posted by jdobbs
Okay to all. The debate is hopefully over. I think I found the cause of the stutter. But since I could never repeat it I'll have to wait until I post it and it gets tested. Right now I'm running a job with the new version to make sure I haven't caused any other issues with the fix.

@RB

Thanks again, dude. If this is the fix, you were on the right track. DVD-RB was setting the GOP time stamp, restarting at 0 for each CELL, as I was rebuilding. But as I was researching to see if this could be the source of the problem, I found a different bug. The first GOP of every cell was being timestamped as if it were a continuation of the previous cell by mistake (it was using a frame counter and rff counter to determine the timestamp that had not yet been reset). And then the second through n GOP would be set as if the CELL had started off at 0...

I can see how this could conceivable confuse a player, and even cause the time display error when rewinding through chapters. But whether it fixes the problem is yet to be seen. It just seems odd that a player would depend on this value when it has better ones to use...

I've also modified the code so the timestamp increments through the entire VTS... I'll see if that has any affect when I play back the test disc I'm creating.

I confirm.
As it as already reported Xitrum in another thread, the stutter problem is fixed.

I tested release .40 with CCE, paying lot of attention to be sure about what happened, and I am very happy, and it is a pleasure to say that it plays perfectly. There is no doubts on the matter. Video is perfect and audio is perfect across chapter boundaries.

I just ask DrVenkman, who noticed the same problem, if he is also getting positive results (i.e the solution) of the stutter trouble with release .40

A minor, and (I suppose now) very low priority residual effect is that the display in the player is still showing the mistaken chapter and the bad time values when rewinding through chapter breaks...

But again, I am very happy now.

Thanks a lot jdobbs, you are great.

[jdobbs]

Originally posted by Sir Didymus
A minor, and (I suppose now) very low priority residual effect is that the display in the player is still showing the mistaken chapter and the bad time values when rewinding through chapter breaks...
Does this mean the rewinding problem has changed in some way? I don't remember a mention of a mistaken chapter before.

[HarryM]

Originally posted by jdobbs
I don't think what you are seeing is related to the "stutter" discussed in this thread.

Maybe not, you're right.

I seeying a "choppy" motion in cca 1/3 movie, beginning and finish of movie is OK. Only on desktop DVD player.
Cause unknown - a uncorrect mastering of original DVD-video disk possibly?

[quantum]

@jdobbs: Two different sources report success. Considering how few remaining stutterer's were left, I think it's fairly safe to say you put this one behind you. Another piece of fine work :cool:

[Sir Didymus]

No, no, I say again it is a minor problem, affecting JUST THE DISPLAY OF THE PLAYER WHEN YOU REWIND THROUGH CHAPTER BREAKS:

In the display of the player, if you play the title normally, both the chapter number and the time elapsed is correct; if you play backward through the chapter breaks, the chapter number is not updated and the time elapsed shows a value that is affected by the following error (in bold the right value to show):


Chapter nr ... Start ... End ... Time showed in backward play through the previous chapter
........1 ........ 0:00 ... 5:30 ... n.d.
........2 ........ 5:30 ... 12:39 . 10:59 = (5:30 - 0:00) * 2 + 0:00
........3 ........ 12:39 . 14:14 . 19:48 = (12:39 - 5:30) * 2 + 5:30
........4 ........ 14:14 . 17:45 . 15:49 = (14:14 - 12:39) * 2 + 12:39
........5 ........ 17:45 . 23:25 . 21:16 = (17:45 - 14:14) * 2 + 14:14

I don't now it is useful to know, but I noticed also that in the original title the cell timestamp (looking at it with vobedit, and checking the navpacks corresponding to the start of each cell) is reset to 0 at every new cell...

[jdobbs]

Originally posted by Sir Didymus
No, no, I say again it is a minor problem, affecting JUST THE DISPLAY OF THE PLAYER WHEN YOU REWIND THROUGH CHAPTER BREAKS:

In the display of the player, if you play the title normally, both the chapter number and the time elapsed is correct; if you play backward through the chapter breaks, the chapter number is not updated and the time elapsed shows a value that is affected by the following error (in bold the right value to show):


Chapter nr ... Start ... End ... Time showed in backward play through the previous chapter
........1 ........ 0:00 ... 5:30 ... n.d.
........2 ........ 5:30 ... 12:39 . 10:59 = (5:30 - 0:00) * 2 + 0:00
........3 ........ 12:39 . 14:14 . 19:48 = (12:39 - 5:30) * 2 + 5:30
........4 ........ 14:14 . 17:45 . 15:49 = (14:14 - 12:39) * 2 + 12:39
........5 ........ 17:45 . 23:25 . 21:16 = (17:45 - 14:14) * 2 + 14:14

I don't now it is useful to know, but I noticed also that in the original title the cell timestamp (looking at it with vobedit, and checking the navpacks corresponding to the start of each cell) is reset to 0 at every new cell... The SCR is restarting at 0 or the GOP timestamp?

[Sir Didymus]

@jdobbs

hem..., sorry, hem...,
it is the cell elapsed time that (obviously) is reset to 0 at every new cell...

The first Navpack of the first cell in the title has the following info:

VOB ID 1
CELL ID 1
SCR 00000000.000
CELL ELAPSED TIME 00:00:00.00 / 25 fps

The first GOP of the first cell in the title has the following info:

SCR 00000146.085
GOP bit flags / time stamp 00:59:59.16


The first Navpack of the second cell in the title has the following info:

VOB ID 1
CELL ID 2
SCR 29682249.042
CELL ELAPSED TIME 00:00:00.00 / 25 fps

The first GOP of the second cell in the title has the following info:

SCR 29682395.128
GOP bit flags / time stamp 01:05:29.14

[Sir Didymus]

In the vob produced by DVD-RB 0.40 there are little differencies respect to the original (just posted...).

The encoded frames in the first cell are 8248...

Here is what happen with RB 0.40

The first Navpack of the first cell in the title has the following info:

VOB ID 1
CELL ID 1
SCR 00000000.000
CELL ELAPSED TIME 00:00:00.00 / 25 fps

The first GOP of the first cell in the title has the following info:

SCR 00000146.086
GOP bit flags / time stamp 00:00:00.00


The first Navpack of the second cell in the title has the following info:

VOB ID 1
CELL ID 2
SCR 29692800.042
CELL ELAPSED TIME 00:00:00.00 / 25 fps

The first GOP of the second cell in the title has the following info:

SCR 29692946.086
GOP bit flags / time stamp 00:05:29.23

[RB]

Wow, looks like the stuttering problem is fixed. Glad I could help. Congratulations, jdobbs! :)
Originally posted by jdobbs
I've also modified the code so the timestamp increments through the entire VTS... I'll see if that has any affect when I play back the test disc I'm creating.
Maybe for full perfection, you could account for "timestamp resets" present in the original. IOW, whenever there's a "reset" in the timestamp in the original (most likely tagged as "Layer Break" in IFOEdit), reset your timestamp to start counting from the value in the original.

[jdobbs]

Originally posted by RB
Wow, looks like the stuttering problem is fixed. Glad I could help. Congratulations, jdobbs! :)

Maybe for full perfection, you could account for "timestamp resets" present in the original. IOW, whenever there's a "reset" in the timestamp in the original (most likely tagged as "Layer Break" in IFOEdit), reset your timestamp to start counting from the value in the original. There doesn't seem to be any rhyme or reason for the resets, and they don't count as layer breaks or discontinuities. As I mentioned earlier, I looked a recent NTSC movie and every single GOP had a timestamp of zero.

I think the stuttering wasn't caused by the reset to zero, but the fact that the first GOP wasn't zero, but the second went "back in time"...

[wmansir]

I didn't notice anything wrong with the clock/timer on my last test,which I think was with .40, however I didn't notice it was correct either. I did notice that my player was acting buggy. I wanted to check out a stutter that happened about 8-10 seconds after a chapter point. So I was was FF/RW around the area and all of a sudden it jumped to the next chapter. I though perhaps I had hit the wrong button by accident, but then it happened again, several times. I'm not going to say it was definitely a build issue because, like I said, the media died on the next rewrite ten minutes later. So it could easily have been a burn issue.

OT rant:
I hate not buying media in bulk, but I don't know exactly what RW media my burner likes (even this Verbatim +RW that came with the drive did like burning over 4GB and now it's dead after 10 rewrites tops) so I only wanted to get a few DVD+/-RW. I went to my local Walmart tonight and all they had for RWs were 3-packs of Memorex for $12. After jdobb's suggestion I was prepared for $10, but I'm not paying $4 a disc when I can get better discs for almost $1 in bulk. So I went to Staples, the only other place I know of that sells them locally. They were even worse, only having 5-packs of Sony for $25. I also noticed they had 25 packs of TDK for $100! What is this, 2002?

After looking around I finally placed an order with Rima.com for a 10 pack of Ritek +RWs for $15 + $6 ground. I haven't ordered from them before but they have excellent marks at resellerratings.com. I can't wait for them to get here because that darn stutter is the only thing keeping me from actually using DVD-RB as a primary backup method. So I would like to make some tests to confirm that bug is dead. Plus I really want to be able to test out BOV and Multi-angle once jdobbs starts working on them.

[jdobbs]

Originally posted by wmansir
I didn't notice anything wrong with the clock/timer on my last test,which I think was with .40, however I didn't notice it was correct either. I did notice that my player was acting buggy. I wanted to check out a stutter that happened about 8-10 seconds after a chapter point. So I was was FF/RW around the area and all of a sudden it jumped to the next chapter. I though perhaps I had hit the wrong button by accident, but then it happened again, several times. I'm not going to say it was definitely a build issue because, like I said, the media died on the next rewrite ten minutes later. So it could easily have been a burn issue.

OT rant:
I hate not buying media in bulk, but I don't know exactly what RW media my burner likes (even this Verbatim +RW that came with the drive did like burning over 4GB and now it's dead after 10 rewrites tops) so I only wanted to get a few DVD+/-RW. I went to my local Walmart tonight and all they had for RWs were 3-packs of Memorex for $12. After jdobb's suggestion I was prepared for $10, but I'm not paying $4 a disc when I can get better discs for almost $1 in bulk. So I went to Staples, the only other place I know of that sells them locally. They were even worse, only having 5-packs of Sony for $25. I also noticed they had 25 packs of TDK for $100! What is this, 2002?

After looking around I finally placed an order with Rima.com for a 10 pack of Ritek +RWs for $15 + $6 ground. I haven't ordered from them before but they have excellent marks at resellerratings.com. I can't wait for them to get here because that darn stutter is the only thing keeping me from actually using DVD-RB as a primary backup method. So I would like to make some tests to confirm that bug is dead. Plus I really want to be able to test out BOV and Multi-angle once jdobbs starts working on them. Check out version 0.42. All stutters are history. Start using it...

[RB]

Originally posted by jdobbs
There doesn't seem to be any rhyme or reason for the resets, and they don't count as layer breaks or discontinuities. As I mentioned earlier, I looked a recent NTSC movie and every single GOP had a timestamp of zero.
OK... so the whole NTSC drop-frame timecodes issue isn't relevant to DVD-RB either, right? You never enable the drop_frame ECL option for NTSC?

[wgw]

Originally posted by wmansir
After looking around I finally placed an order with Rima.com for a 10 pack of Ritek +RWs for $15 + $6 ground. I haven't ordered from them before but they have excellent marks at resellerratings.com.

Rima is the best. Cheap prices and cheap shipping. And great customer service. They even gave me a total refund once when my priorty shipment did not get delivered on time and let me keep the media.