RB v1.26 bitrate redistribution

[Carpo]

is this feature classed as stable now? have a few encodes to do and am thinking about trying it out

[Sharc]

Stability and performance is much ensured by many users trying it and giving feedback. I feel it's safe to use at the stage it is, with perhaps in exceptional cases a tendency to slightly undersizing, depending on the source and redistribution profile.

[Carpo]

i'll think i'll pass for now then, have done enough alpha/beta testing on other tools ;)

[laserfan]

i'll think i'll pass for now then, have done enough alpha/beta testing on other tools ;)No reason to do that--it's perfectly stable AFAICT.

There is one difference in workflow that I noticed last night. I tried a backup of Full w/Menus and Steal 25%. As I usually do, after the Prepare phase I went into the Editor looking for garbage to blank. I was easily able to find & blank a Warner logofilm, a Rating display, and a Warning, but because these were in the "Main Feature" titleset I was not able to increase the main feature bitrate as I usually do, to take advantage of the blanks. I could see that the cells in the feature all had differing bitrate allocations, but I was not able to adjust them--at least, when I tried, the indicator that would show me approaching 4.34Gb didn't change--I wasn't able to allocate the extra bits to any of the movie cells. I instead went to the one Extra (a featurette) which, owing to the "Steal 25%" was really crunched, and gave the extra space to IT. The encode/rebuild went as expected and the disc hit the target perfectly.

I guess for discs where "things you wanna blank" are in the Feature titleset it would be best to use maybe Vobblanker on it first, unless someone knows of another way to do this, or maybe something I did wrong...

p.s. this movie was (perhaps a typical?) action/adventure but with a lot of drama and a love story so it's slower than most A/A movies in parts, and you could easily see where RB was allocating less bitrate to the stationary scenes, and more to the outdoor action scenes. At least that's the way I interpreted the variation in compression from 45% on some cells to 80% on others!!!?!

[Boulder]

Here's the graph for my tests, doing the redistribution with HC's three different profiles:
http://img154.imageshack.us/img154/9923/comptestcg2.th.png (http://img154.imageshack.us/my.php?image=comptestcg2.png)

As you can see, one can definitely use "Fast" for doing the redistribution pass, it doesn't affect the result in a noticable way.

[blutach]

@Boulder - have you experienced the same issues I reported earlier (see post 95) with HC in BR Redist (ie very slow to complete the prepare)? If not, I'd be real interested in your settings.

Regards

[Boulder]

The slowdowns are due to HC re-encoding the GOPs where buffer underflows occur. You can verify that by checking the "Show buffer" checkbox and seeing how the buffer level is gradually lowered when you experience a slowdown, you can also see that the quants are raised in those GOPs.

For me it happens only when the avg bitrate is rather high, say over 5000kbps. On lower bitrates it is quite rare but does occur when there are GOPs that require lots of bits, hitting the maximum bitrate that you have set (in this case HC needs to re-encode the GOP as well).

[jdobbs]

On the next release of DVD-RB I've set it up so HC redistribution disables VBV and SCD and also runs in "Fast" mode. In addition I've set it up so that HC will be used for redistribution with ProCoder and CCE Basic.

[blutach]

Excellent. Thanks for that jdobbs and for the info Boulder.

Also thanks to you, Sharc and jdobbs (and others) for exploring this idea. Kudos.

Regards

[Carpo]

ok my next question regaurding this feature would be the threshold on which to use it - by that i mean at what percentage would it be a waste of time using it on i have a few dvd9s i want to back up but the percentange is at 53.4% - br is about 2653 roughly, is it worth using this feature on discs like that ?

[jdobbs]

So far my recommendation would be that if you've decided to use it, just turn it on and leave it on. But, keep in mind that on most discs you won't be able to tell any difference from a standard "no redistribution" encode. It's the exceptions that give you the "bang".

[Carpo]

cant say fairer than that :) guess i'll leave it on :), have had to do a backup due to hdd error - all i need to do is add redist_all=1 to rebuilder ini correct ?

[jdobbs]

"redist_all=1" should only be turned on when you are doing a series disc. All others should only have "redistribute=1" set (which is done by checking "Enable Bitrate Redistribution" from the MODE menu. In the next release I've made it so both can be turned on/off from the menu.

[Boulder]

On the next release of DVD-RB I've set it up so HC redistribution disables VBV and SCD and also runs in "Fast" mode. In addition I've set it up so the HC will be used redistribution with ProCoder and CCE Basic.Could you please leave SCD on if the redistribution percentage is 100%?

[jdobbs]

Makes sense... done.

[kumi]

In addition I've set it up so that HC will be used for redistribution with ProCoder and CCE Basic.Awesome feature, thanks jdobbs.

[Carpo]

"redist_all=1" should only be turned on when you are doing a series disc. All others should only have "redistribute=1" set (which is done by checking "Enable Bitrate Redistribution" from the MODE menu. In the next release I've made it so both can be turned on/off from the menu.

just seen the option you are on about in the new release, giving it a test now

[jdobbs]

Awesome feature, thanks jdobbs.That's why I'm here. :)

[blutach]

Just reporting that the BR dist on HC goes a lot quicker. Still somewhat slow (21 fps - a 14 minute prepare compared to 2 minutes without - I might have expected say 7 minutes on this source at 45 fps, so there is still something holding it back).

-----------------
[11:15:22] Phase I, PREPARATION started.
- DVD-RB v1.26.2
- AVISYNTH 2.5.6.0
- HC v0.21.0.0 encoder selected
- VTSM_01: 38,163 sectors.
-- Scanning and writing .D2V & .AVS files
-- Processed 1,887 frames.
-- Building .AVS and .ECL files
- VTS_01: 1,847,486 sectors.
-- Scanning and writing .D2V & .AVS files
-- Processed 133,200 frames.
-- Building .AVS and .ECL files
- VTS_04: 43,572 sectors.
-- Scanning and writing .D2V & .AVS files
-- Processed 2,260 frames.
-- Building .AVS and .ECL files
- VTS_05: 50,310 sectors.
-- Scanning and writing .D2V & .AVS files
-- Processed 2,748 frames.
-- Building .AVS and .ECL files
- Reduction Level for DVD-5: 100.0%
- Overall Bitrate : 5,525Kbs
- Space for Video : 4,344,918KB
- Redistributing using Base_Q: 19
- HIGH/LOW/TYPICAL Bitrates: 8,808/3,550/5,525 Kbs
[11:29:51] Phase I, PREPARATION completed in 14 minutes.

This source could fit on a DVD5 so it was only for testing and, given its high BR already, there was no meaningful change.

BITRATE APPLIED TO FEATURE SEGMENTS (SEGMENT ORIGINAL REDISTRIBUTED)
(Created using a 10% sample)

V01000000001001 5,538 Kbs 5,534 Kbs
V01000100001002 5,235 Kbs 5,340 Kbs
V01000200001003 5,453 Kbs 5,313 Kbs
V01000300001004 5,389 Kbs 5,389 Kbs
V01000400001005 5,272 Kbs 5,272 Kbs
V01000500001006 5,349 Kbs 5,349 Kbs
V01000600001007 5,504 Kbs 5,524 Kbs
V01000700001008 5,377 Kbs 5,377 Kbs
V01000800001009 5,460 Kbs 5,460 Kbs
V01000900001010 5,573 Kbs 5,573 Kbs
V01001000001011 3,550 Kbs 164 Kbs

The only thing I noticed that is a bit strange is the last segment - obviously a blank cell. Now, given it goes for 15 frames, the redist up to 3550 is irrelevant, but for such short cells, does it make sense to redistribute?

Regards

[jdobbs]

If a segment is less than 60 frames the it will be encoded at a minimum bitrate of 4500Kbs anyway. That's because of a bug in CCE than can cause it to randomly crash if you try.

I do think it's a good idea to redistribute, though, regardless of segment size. Only 15 frames wouldn't make a lot of difference -- but why use any bitrate that you don't really need? Apply it (however small) to another segment.

[blutach]

Thanks for that. Any idea why an encode with HC alone is at 45fps but under DVDRB is 20?

Regards

[jdobbs]

Are you saying it is always slower, or only when doing redistribution pass?

During a redistribution pass (or an OPV prediction pass) you are not reading contiguous frames. DVD-RB is using the AVISYNTH function SelectRangeEvery() to get a sampled subset of the entire stream. To do that it has to jump through the source -- for example it might encode 12 frames, skip a couple of hundred, and then encode another 12 (depending upon the sample percentage). When it does that it has to seek the frame, then step back and find any dependent preceding frames because of the way MPEG works (suppose the start point is a B or P frame, for example) -- and in some cases (like a GOP that isn't closed) you may have to even read another GOP. All that extra work makes it a lot harder -- and slower -- during the encode.

[blutach]

Only during redist. I will try an experiment tomorrow with the same AVS fed into HC alone and see how it goes.

EDIT: Same times both within and outside DVDRB.

Regards

[Carpo]

im giving the redist option a try and am finding that a cce prepare is 11mins and hc is 21 mis - this is the same disc, so any idears why hc is 50% slower than cce.

Please note im not bashing HC i have used it many times in the past and found it to kick cce's arse on one or two discs :)

Ok this may be a stupid thing to ak but i will ask anyway, i have a disc i want to bck up but i do not wish to keep all the extras just a few - so im guessing i will need to select redist_all, question is if i do the prepare phase and let it do the redist then use segmant viewer and blank out the extras i dont want, how will this affect the redist ? I know it will, and prob am going to be told not to use redist option for these circumstances, but thought it best to ask anyway :)

edit: one other question does anyone here do all their backing up with real time anti virus on or off ? does it affect making isos and burning them with av on ? i use avg and eset nod32, normaly i have it off and do a full pc scan everynight while i am in bed, when i do use dvdrb to back up i norm leave it off

[kumi]

Hi, can bitrate redistribution be safely used with these options?

1/ Steal Space
2/ Movie and Menus Only Mode
3/ Half-D1 and Half Space for Extras

(If it makes a difference, I'm always using redist_all=0)

[Fishman0919]

1) Yes
2) Yes
3) Yes

jdobbs had stated before that it was fine.

bitrate redistribution is done 1st, then the space adjustment for extra is done

[kumi]

Thank you.

[jdobbs]

The redistribution is done before those actions... so the actions will be applied against the redistributed allocation.

[archaeo]

I wanted to report a particular instance where redistribution definitely gave me an inferior result compared to a regular VBR encode. Source for this backup is non CBR, commercial disc.

I report this primarily in response to another thread (couldn't find the exact one) where a forum member asked if redistribution should be enabled 'all the time' even for non CBR sources. Since v1.26, I have been doing almost all my encodes with 'enable bitrate redistribution' ticked until I saw this come up.

The source is 'Apocalypto', and I ran the project first with 'Enable Bitrate Redistribution' checked, CCE 3 pass, movie only, 87.2% reduction, avg bitrate @ 3943. DVDRB base_Q came in at 26. The output sizing was good at 4.32 Gb. The problem was with many of the jungle scenes, where the source had a fair amount of motion and 'noise' in the background, ie layers of leaves, vegetation, etc... As you will see the output had a great deal of blocking and pixellation. I submit my results for one typical scene during a chase in the jungle: apoc_redis_2.jpg (1st image)

After I saw this, I wondered if this blocking/pixellation problem was due to the redistribution process, so I simply unchecked redistribution, and ran the same project through the same parameters. The results are here: apoc_vbr2.jpg (2nd image)

As you can see, the regular VBR encode did not macro-block or pixellate as did redistribution encode. There seemed to be some issue in the redistribution process that had trouble with the complexity of the scene, motion, etc.. where the regular VBR encode did not. The macro blocking was apparent in many of the chase scenes in the jungle.

I have to say that up to this point I had not noticed a problem with any of my encodes when using redistribution on non-CBR sources. However, catching this, I wanted to post this comparision so that one is aware that there may be a risk attached to keeping 'enable bitrate distribution' checked by default, primarily for a non CBR source.

[Boulder]

Did you use the default amount of 10% in redistribution? If so, please try 100% and redo the whole project. If you don't use 100%, there is always a chance of inaccuracy in the redistribution.

It would also be interesting to see the redistribution log in both cases to compare them.

[archaeo]

Did you use the default amount of 10% in redistribution? If so, please try 100% and redo the whole project. If you don't use 100%, there is always a chance of inaccuracy in the redistribution.

It would also be interesting to see the redistribution log in both cases to compare them.


Yes, I did use the default amount of 10%. I'm currently running the project again through RB-Opt, to see if anything differs, (edit:which it does, in the calculated Q: RB-OPt uses 55, and RB used 26). I'll check the results visually as soon as it is finished.

[archaeo]

Ok, it appears that the redistribution process in DVD RB is causing the problem - RB Opt's redistribution results for the same project and same parameters are good - I've posted another screenshot (above, bottom image), showing the results using RB Opt's (v30) redistribution process, using 'calculate optimal Q'.

As you can see (when they're approved) the image quality is good and is comparable to that when using DVDRB's normal 3 pass VBR.

Here's the redistribution profile from DVD RB (apoc_redis_2.jpg):

BITRATE APPLIED TO FEATURE SEGMENTS (SEGMENT ORIGINAL- REDISTRIBUTED)
(Created using a 10% sample)

V01000000001001 4,095 Kbs 4,523 Kbs
V01000100001002 4,149 Kbs 4,469 Kbs
V01000200001003 3,738 Kbs 4,090 Kbs
V01000300001004 4,204 Kbs 3,521 Kbs
V01000400001005 3,917 Kbs 4,165 Kbs
V01000500001006 3,642 Kbs 3,762 Kbs
V01000600001007 3,975 Kbs 4,298 Kbs
V01000700001008 3,767 Kbs 3,766 Kbs
V01000800001009 3,539 Kbs 4,057 Kbs
V01000900001010 4,001 Kbs 4,655 Kbs
V01001000001011 3,890 Kbs 4,459 Kbs
V01001100002001 3,805 Kbs 4,362 Kbs
V01001200002002 3,622 Kbs 3,765 Kbs
V01001300002003 3,319 Kbs 3,805 Kbs
V01001400002004 4,002 Kbs 4,547 Kbs
V01001500002005 4,346 Kbs 1,605 Kbs
V01001600002006 4,360 Kbs 4,717 Kbs
V01001700002007 4,588 Kbs 4,698 Kbs
V01001800002008 4,925 Kbs 4,529 Kbs
V01001900002009 4,346 Kbs 3,907 Kbs
V01002000002010 2,207 Kbs 2,503 Kbs
V01002100003001 4,226 Kbs 114 Kbs

______________________________________________
Here's the redistribution profile results from RB-Opt:
(created using 10% sample)

--- Calculating Bitrate distribution
Bitrate for VTS 1 VobID 1 segment 1: original 4086 - redist. 4284
Bitrate for VTS 1 VobID 1 segment 2: original 4141 - redist. 3988
Bitrate for VTS 1 VobID 1 segment 3: original 3731 - redist. 3540
Bitrate for VTS 1 VobID 1 segment 4: original 4195 - redist. 2680
Bitrate for VTS 1 VobID 1 segment 5: original 3909 - redist. 3860
Bitrate for VTS 1 VobID 1 segment 6: original 3635 - redist. 2909
Bitrate for VTS 1 VobID 1 segment 7: original 3967 - redist. 4064
Bitrate for VTS 1 VobID 1 segment 8: original 3760 - redist. 3401
Bitrate for VTS 1 VobID 1 segment 9: original 3532 - redist. 4279
Bitrate for VTS 1 VobID 1 segment 10: original 3993 - redist. 4986
Bitrate for VTS 1 VobID 1 segment 11: original 3882 - redist. 4805
Bitrate for VTS 1 VobID 2 segment 12: original 3797 - redist. 4761
Bitrate for VTS 1 VobID 2 segment 13: original 3614 - redist. 3018
Bitrate for VTS 1 VobID 2 segment 14: original 3312 - redist. 3949
Bitrate for VTS 1 VobID 2 segment 15: original 3994 - redist. 4578
Bitrate for VTS 1 VobID 2 segment 16: original 4337 - redist. 4094
Bitrate for VTS 1 VobID 2 segment 17: original 4351 - redist. 4703
Bitrate for VTS 1 VobID 2 segment 18: original 4579 - redist. 4650
Bitrate for VTS 1 VobID 2 segment 19: original 4915 - redist. 4080
Bitrate for VTS 1 VobID 2 segment 20: original 4338 - redist. 3213
Bitrate for VTS 1 VobID 2 segment 21: original 2202 - redist. 2215


Edit: After visually checking through the final results, the segment that had the problem is V01001500002005 (seg 16) which happens to be the one that stands out: DVDRB original = 4,346 Kbs and redistributed = 1,605 Kbs. No surprise that a 1605 bitrate would yield these results! Question is why DVDRB redistribution gave it only 1605 kbps when RB-Opt allocated over 4000?

[jdobbs]

The original bitrates don't seem to match between the two?

Any idea why these two might be so different? Best guess is that's where your jungle scene is... it sure looks out of place -- and none of the other output bitrates seem to be far enough off to make a lot of difference.

V01001500002005 4,346 Kbs 1,605 Kbs
Bitrate for VTS 1 VobID 2 segment 16: original 4337 - redist. 4094

Is this the R1 version of Apocalypto?

[archaeo]

The original bitrates don't seem to match between the two?

Not exactly. See edit... The problem segment somehow was only allocated around 1600 kbps.


Edit: yes every other segment appears to be OK thru visual inspection and bitrate allocation - seg 16 is kind of the oddball segment thats thrown a wrench into DVDRB's redistrib process.
**Yes, It's the R1 version

[jdobbs]

Sorry -- it appears I was editing my response the same time you were typing.

Was this a particularly short segment?

[archaeo]

Sorry -- it appears I was editing my response the same time you were typing.

Was this a particularly short segment?

Not too short - when looking in the D2VAVS folder the m2V segment is 127,445 KB.

[mc2man]

since I've been fooling around with this new feature i've saved most of the .tx's Same title,similar setting's produced this
V04000000003001 4,103 Kbs 4,388 Kbs
V04000100003002 4,158 Kbs 4,197 Kbs
V04000200003003 3,746 Kbs 3,528 Kbs
V04000300003004 4,213 Kbs 2,883 Kbs
V04000400003005 3,926 Kbs 3,848 Kbs
V04000500003006 3,650 Kbs 3,036 Kbs
V04000600003007 3,984 Kbs 4,121 Kbs
V04000700003008 3,775 Kbs 3,442 Kbs
V04000800003009 3,546 Kbs 4,057 Kbs
V04000900003010 4,010 Kbs 4,587 Kbs
V04001000003011 3,898 Kbs 4,459 Kbs
V04001100004001 3,813 Kbs 4,362 Kbs
V04001200004002 3,630 Kbs 3,204 Kbs
V04001300004003 3,326 Kbs 3,805 Kbs
V04001400004004 4,011 Kbs 4,588 Kbs
V04001500004005 4,356 Kbs 4,131 Kbs
V04001600004006 4,369 Kbs 4,738 Kbs
V04001700004007 4,598 Kbs 4,757 Kbs
V04001800004008 4,936 Kbs 4,176 Kbs
V04001900004009 4,356 Kbs 3,513 Kbs
V04002000004010 2,211 Kbs 2,539 Kbs
V04002100005001 4,235 Kbs 137 Kbs
Ive found for med.-high bitrate movie only the redis. is useful as a "preset" for the segment editor. After prep i go in and do some fine tuning, in the case of this title knocked down seg. 20, bumped up seg 3 and pushed a couple of others to 100%, i think I had 7 or 8 extracted which was a decent timesaver in encoding

[kumi]

Are you using non-default matrices, by any chance? See what kind of bitrate redistribution you get using with "Encoder Default" selected for all the matrices.

[archaeo]

Yes, I used 'high_medium 4000' mtx on all samples, since the source was close to that avg bitrate. I will run it again using the encoder default matrix to see if that solves the one problem segment.

Still, the problemmatic segment did not cause an issue with RB Opt's Redistribution pass. It came in at an acceptable bitrate. :confused:

[jdobbs]

I'll run it through tomorrow and see what I get for that segment. My suggestion has always been to use standard matrices in most instances, and only change the matrix when you have a specific reason to do so.

Theres something odd going on here... because I can't figure why, out of that entire feature, only one segment came in at that very low bitrate -- especially a segment with lots of detail (jungle action). :confused: Any chance the encoder is bombing out during the redistribution phase and the small output file was used to make the size determination?

Just as a test, could you do a PREPARE phase with HC and see what it's distribution table looks like?

[archaeo]

Ok... using the standard matrix in DVDRB's redistribution solved the 'odd segment' issue, getting the bitrate up to 4186. Here's the result using the CCE default mtx:


V01000000001001 4,086 Kbs 4,380 Kbs
V01000100001002 4,141 Kbs 4,112 Kbs
V01000200001003 3,731 Kbs 3,497 Kbs
V01000300001004 4,196 Kbs 2,726 Kbs
V01000400001005 3,910 Kbs 3,820 Kbs
V01000500001006 3,635 Kbs 2,895 Kbs
V01000600001007 3,967 Kbs 4,184 Kbs
V01000700001008 3,760 Kbs 3,396 Kbs
V01000800001009 3,532 Kbs 4,057 Kbs
V01000900001010 3,993 Kbs 4,587 Kbs
V01001000001011 3,882 Kbs 4,459 Kbs
V01001100002001 3,797 Kbs 4,362 Kbs
V01001200002002 3,615 Kbs 3,182 Kbs
V01001300002003 3,312 Kbs 3,805 Kbs
V01001400002004 3,994 Kbs 4,588 Kbs
V01001500002005 4,338 Kbs 4,186 Kbs
V01001600002006 4,351 Kbs 4,804 Kbs
V01001700002007 4,579 Kbs 4,824 Kbs
V01001800002008 4,915 Kbs 4,015 Kbs
V01001900002009 4,338 Kbs 3,503 Kbs
V01002000002010 2,202 Kbs 2,530 Kbs
V01002100003001 4,218 Kbs 160 Kbs


Just to be clear, I confirmed that the matrix used in RB Opt's redistribution process was in fact the custom 'high_med 4000' mtx... For some reason, DVD RB's redistribution process required the use of the standard mtx to avoid this peculiar 'odd segment' issue in this particular sample. Perhaps just a rare occurance.

[Insomniak4700]

Is it just me, or are the menus not being reencoded when redistribution is activated (yes, the option for menu reencoding is active)??

[Sharc]

@archaeo & jdobbs:

Differences between RBOpt and DVD-RB:

- RBOpt always uses a minimum of 500 frames for redistribution for small segments, whereas DVD-RB increases the 10% to 25% which may perhaps still be too few frames for small segments.

- RBOpt uses the "final_Q" for the given matrix, whereas DVD-RB uses the "Base_Q" which may lead to significantly differetnt Q values and in some cases to significantly different bitrate profiles - depending on the selected matrix.

- Further, I have noticed that CCE may just silently abort without warning during the redistribution pass. It will then simply continue with the next segment. I have seen this happening for very low Q values only. The result was a ridiculous low bitrate for the aborted segment.

[Sharc]

Did you use the default amount of 10% in redistribution? If so, please try 100% and redo the whole project. If you don't use 100%, there is always a chance of inaccuracy in the redistribution.

In my experience it is important for an "accurate" redistribution profile to use the "Final_Q" rather than the "Base_Q", in particular when non-standard matrices are used. I consider this even more critical than a large sample size.

[jdobbs]

I disagree. Look at the historical values given for bitrates -- and it doesn't seem to make a whole lot of difference at least 95% of the time.

I think that segment was probably an anomaly caused by CCE aborting. I'd also guess that the choice of matrix in use is the most likely catalyst for the aborting.

@archeao

Did you try it with HC? Did you try it more than once with CCE (using the matrix)?

[Boulder]

I disagree. Look at the historical values given for bitrates -- and it doesn't seem to make a whole lot of difference at least 95% of the time.Which still leaves room for error ;) But in this case I also agree that it probably is an encoder issue.

[jdobbs]

Well... I used 95% -- but it's probably much higher. The point is that if you're looking for perfection in this world, you're always going to be disappointed. ;)

[archaeo]

@archeao

Did you try it with HC? Did you try it more than once with CCE (using the matrix)?

I'll run those two this morning...

[Sharc]

I disagree. Look at the historical values given for bitrates -- and it doesn't seem to make a whole lot of difference at least 95% of the time.

I think that segment was probably an anomaly caused by CCE aborting. I'd also guess that the choice of matrix in use is the most likely catalyst for the aborting.

Hmmm.... I think the low Q is the reason for CCE to abort. If the "Base_Q" is low compared to the "final Q" I suspect that the bitrate is driven to high values beyond the mpeg standard, causing the abortion. This happens in particular for high bitrate matrices where the Base_Q of DVD-RB is normally too low (say 25 instead of 60).

I verified the abortion by selecting a low Q with RB-Opt.

Again, no proof, just observations .....

[archaeo]

@jdobbs,
I ran the two additional redistribution samples. Once again I was able to repeat the same segment error when running the original parameters using DVDRB w/CCE, and custom mtx, Base_Q=26:
V01001500002005 4,338 Kbs 1,601 Kbs

However, using DVDRB w/ HC .21, and custom matrix, Base_Q=26:
V01001500002005 4,317 Kbs 4,076 Kbs

and as posted previously...

DVDRB, CCE, standard matrix, Base_Q=26:
V01001500002005 4,338 Kbs 4,186 Kbs

RB Opt, cutom matrix, Q=55:
segment 16: original 4337 - redist. 4094

The problem occurs only when using CCE w/ DVDRB using the High_med 4000 matrix, and only at that one particular segment.