trouble with dvdauthorgui and stuttering DVDs

[spase]

ok so i encoded a bunch of videos at compliant resolution, bitrate, etc using NuEnc

i made audio (MP2) tracks with TMPEGEnc

then i made a menu with gimp 2.0/dvdauthorgui

upon authoring the dvd i got an error:

STAT: Processing E:\dvd\title3.mpg...
WARN: Discontinuity in audio channel 8; please remultiplex input.
WARN: Previous sector: 0.184 - 0.184
WARN: Current sector: 0.263 - 0.263
and so on

now the dvd authored ok and plays back fine on my computer, but it stutters a lot on my standalone (as if the bitrate had been exceeded, but i am pretty sure it hasn't).

i am guessing this could be an issue with mplex?

if not is there anything else that could be causing this problem (other than a bitrate that exceeds the standard maximum?)

in any case i am re encoding all the clips now at a slightly lower bitrate (not really lower, just with a lower max bitrate so it doesn't peak as high) so i can test and see if this was the problem.

additionally...

i get this message as well:

++ WARN: [???] Target data rate lower than computed requirement!
++ WARN: [???] N.b. a 20% or so discrepancy in variable bit-rate
++ WARN: [???] streams is common and harmless provided no time-outs will occur
should i be concerned about this? and also, what exactly does it mean?

could it be causing the stuttering performance as well?

EDIT: i forgot to add that i am using dvdauthorgui 0.995 for windows, and in turn whichever tools it uses (mplex i believe)

[liquid217]

Im not familiar with tmpgenc's audio encoding abilities, but maybe you could try toolame, or some thing similar. Also, bear in mind that dvdauthorgui only uses a single titleset, so if your 3 titles are not the same resolution, format, etc, that may be the reason for the discontinuity.


++ WARN: [???] Target data rate lower than computed requirement!
++ WARN: [???] N.b. a 20% or so discrepancy in variable bit-rate
++ WARN: [???] streams is common and harmless provided no time-outs will occur

I have always recieved this when testing nuenc, and I believe it has something to do with the libavcodec. It seems like this was discussed in one of the quenc/nuenc threads in the encoding forum.