A bug in the segment editor

[Boulder]

I just noticed a rather annoying bug in the (new) segment editor in v1.23.3. When you adjust the bitrates in the segments manually and then use the sliders in either the "VIDEO TITLE SETS" or the whole VTS, all average bitrates are returned to the original values. This happens also after you have already saved the new values.

[Sharc]

I just noticed a rather annoying bug in the (new) segment editor in v1.23.3. When you adjust the bitrates in the segments manually and then use the sliders in either the "VIDEO TITLE SETS" or the whole VTS, all average bitrates are returned to the original values. This happens also after you have already saved the new values.

I'm not sure if this is really a bug, or if this is any different from previous version(s).
When you select a higher order level like the entire VTS, all segments that belong to that VTS are (re-)set to the global percentage value of the VTS as indicated by its reduction level (%), irrespective of your former tweaks of the individual segments.
But yes, it can be annoying when one reduces the bitrate of the the credits for example, and then wants to allocate the free space to the remaining segments. The workaround is to oversize the VTS first, and then reduce the segment with the credits until you are again within the target size, then save and exit. A little bit tricky, but it works.

[Voodoochild]

The workaround is to oversize the VTS first, and then reduce the segment with the credits until you are again within the target size, then save and exit. A little bit tricky, but it works.

Exactly It was also in previous versions, one need to blank the entire segment, fot example End Credits, then adjust the size of the VTS to be little less then 4.32, lets say 4.25 and then unblank the end credits and play with the slider till you go down back to 4.32, this is waht I do.

[Boulder]

Now that's pretty far from a practical approach. I think it would be much better if the higher order level sliders adjusted the bitrates according to what the current values are instead of what they originally were.

[Sharc]

Give RB-Opt a chance .... :D

[feedback]

Now that's pretty far from a practical approach. I think it would be much better if the higher order level sliders adjusted the bitrates according to what the current values are instead of what they originally were.
Your suggested method makes more sense to me. I am not sure how difficult it would be for jdobbs to implement, however.

In the meantime, I have been oversizing the entire VTS, then reducing the end credits bitrate to an acceptable size.
Otherwise, I reduce the end credits, then add the extra bits to high action segments or segments with a lot of fire and smoke,
to get an ISO of 4.36GB, overall.

[nashcity]

Just came across a bit of an issue here. I was using the segment editor and after making all adjustments and setting the final size to 4.35 g, it came out to 4.30 g. I tried this a few more times and I always ended up with a 500-700 mb difference between my chosen size and the actual size. (its always undersized)

My CCE target sectors is set to 2252000 in my REBUILDER.INI.

Cheers!

[sockeye]

Just came across a bit of an issue here. I was using the segment editor and after making all adjustments and setting the final size to 4.35 g, it came out to 4.30 g. I tried this a few more times and I always ended up with a 500-700 mb difference between my chosen size and the actual size. (its always undersized)

My CCE target sectors is set to 2252000 in my REBUILDER.INI.

Cheers!
You need to oversize first, then reduce back to your final size by adjusting the slider or blanking your segements you wish to adjust.
The tricky part is finding the right "balance" of oversizing then reducing.

[nashcity]

Just came across a bit of an issue here. I was using the segment editor and after making all adjustments and setting the final size to 4.35 g, it came out to 4.30 g. I tried this a few more times and I always ended up with a 500-700 mb difference between my chosen size and the actual size. (its always undersized)

My CCE target sectors is set to 2252000 in my REBUILDER.INI.

Cheers!

I just wanted to mention that this bug still occurs in the current version.

This is how it occurs for me. I typically use CCE OPV and when a dvd occasionally gets oversized I will run it through DVDRB again and use the segment editor to compress the credits only. I move all sliders to 100% and then adjust the credits segments accordingly. When I do this, moving the slider to hit a final size of 4.35 g results in a final size of 4.28-4.30 g. In order to achieve my preferred final size of 4.35 g, I have to move the slider to show a final size of 4.41 g or so.

As mentioned before, my CCE target sectors is set to 2252000 in my REBUILDER.INI.

Just wanted to mention this again in case it got lost with all the other posts.

THANKS!

[Sharc]

Could you save your settings?
I reported a similar issue a while ago. In my case the "Save and Exit" button was greyed after ticking the segments for "no reencode".
The workaround was to set all segments to 100% using the slider rather than ticking the "no reencode". This brought the "Save and Exit" button back to life.

[nashcity]

Could you save your settings?
I reported a similar issue a while ago. In my case the "Save and Exit" button was greyed after ticking the segments for "no reencode".
The workaround was to set all segments to 100% using the slider rather than ticking the "no reencode". This brought the "Save and Exit" button back to life.

Yes I could save my settings fine.

I do recall having the issue you described once a while back though. I marked a bunch of segments "no reencode" and tried to compress the credits segment only, but the "save and exit" box was greyed out and I couldn't do it. I think I ended up using the work around you described.

[Sharc]

Maybe you did it already so, but I think that one has to run a prepare phase on the oversized OPV from scratch in VBR mode, and only then shrink the credits.
You may also want to give RB-Opt a try and see if it solves your problem, or even try redistribution using RB-Opt, which should definitely eliminate the sizing problem of OPV.

[nashcity]

Maybe you did it already so, but I think that one has to run a prepare phase on the oversized OPV from scratch in VBR mode, and only then shrink the credits.

Yes this is what I typically do.

You may also want to give RB-Opt a try and see if it solves your problem, or even try redistribution using RB-Opt, which should definitely eliminate the sizing problem of OPV.

I am very interested in this redistribution method and have been following its progress on the other thread. I guess I'm still in a "wait and see" mode with it at the moment, in terms of figuring out what kind of sources this method would be best used on. Is it your opinion that the redistribution method actually results in significant improvement with most CBR and VBR sources?

[Sharc]

I am very interested in this redistribution method and have been following its progress on the other thread. I guess I'm still in a "wait and see" mode with it at the moment, in terms of figuring out what kind of sources this method would be best used on. Is it your opinion that the redistribution method actually results in significant improvement with most CBR and VBR sources?
Nice to learn that you follow this discussion.
Well, my opinion: I am trying to find conclusions myself as to when one should go for redistribution, i.e. when "significant" improvements can be expected. The question is if those cells that get bits stolen from will noticeably deteriorate. So far I have not seen this happening, because the bits are mainly stolen from dark and flat scenes where any loss of details or artefacts are barely visible. I have on the other hand seen improvements in clear and detailed scenes which get less compressed. I had so far no evidence that residual artefacts in the original would unduly boost the bitrate of some scenes, it rather seems that the native details, complexity and motion dictate the redistribution. No mathematical proof however. The original bitrate is seldom exceeded - it could happen with CBR originals with low bitrates.
Perhaps my opinion is biased.
However, there are other opinions around saying that OPV produced better results than multipass VBR. What other reasons but redistribution -- inherent to OPV -- could there be for such conclusions?
Last but not least the redistribution eliminates the OPV oversizing risk -- at the expense of encoding time which comes close to a 3-pass VBR.
Ok, that was a little outside of the topic of this thread.

Added:
An obvious benfit of redistribution (and OPV) is that end credits get typically - and automatically - a significant reduction from which the rest can benefit.

[nashcity]

I appreciate your input, you make a very good case for the redistribution method. I guess if I really want to find out how this method performs, I'll have to try it out myself and see if it looks significantly better to my eyes, which is all that really matters isn't it?

My current method adds only a little extra time to the swift OPV process and has given me great results.

1) I use DVDremake to strip and modify the original DVD9 keeping only what I want.
2) Start up DVD-RB and run a CCE OPV prepare stage, usually stealing some space from the extras while doing so.
3) Once I have a Q-Factor for the main feature, I then make a few adjustments. If the Q-Factor is 30 or less, I then start up RB-OPT and add -1 to the main feature Q-Factor. I do this because a) 90% of OPV encodes have resulted in a slight undersizing for me (4.20-4.30 g) and b) if and when I do go oversized, I use this opportunity the tweak the final result even further (i.e. compressing the credits and other cells to achieve desired final size).
4) If the Q-Factor is > 30, I run a standard 2 or 3 pass CCE encode, using RB-OPT or the segment editor to tweak cells as I see fit.

Running the end result through DVD-RB again (to compress credits, etc...) only takes about 25% extra time, so the final time for this entire process is still fairly quick, which is reasonably important to me I guess these days. And to be honest, I usually get better results using this OPV method as opposed to using standard multipass VBR, but I guess that's a topic that has been discussed to death already. My eyes say it looks better, so that's all that matters to me.

Anyway, back to the topic at hand, as you can see this little bug in the segment editor can get a slight bit annoying for me since I use the segment editor quite often.

[Sharc]

I guess if I really want to find out how this method performs, I'll have to try it out myself and see if it looks significantly better to my eyes, which is all that really matters isn't it?.

Exactly!

My current method adds only a little extra time to the swift OPV process and has given me great results.....

3) Once I have a Q-Factor for the main feature, I then make a few adjustments. If the Q-Factor is 30 or less, I then start up RB-OPT and ......
4) If the Q-Factor is > 30, I run a standard 2 or 3 pass CCE encode ....

I understand that your criterion for OPV or Multipass VBR is the Q factor.
Just a sidenote: You may also want to change the matrix from CCE default to Avamat6 aka AUTO-Q1. It will reduce the Q significantly, say from 30 to 15 for example. You would be back to OPV.....
The loss of detail is very little - to my eyes - and not visible when watching the movie.

[nashcity]

Just a sidenote: You may also want to change the matrix from CCE default to Avamat6 aka AUTO-Q1. It will reduce the Q significantly, say from 30 to 15 for example. You would be back to OPV.....
The loss of detail is very little - to my eyes - and not visible when watching the movie.

Thanks for the advice, I haven't really experimented too much with different matrices, always something I was eventually going to get into, but just haven't yet. I assume this Avamat6 matrix is for low bitrate encodes primarily?

Is the Avamat6 (or AUTO-Q1) matrix included with RB-OPT? I can't seem to find it unless its listed as something else.

[Sharc]

Is the Avamat6 (or AUTO-Q1) matrix included with RB-OPT? I can't seem to find it unless its listed as something else.

Here it is.
Copy it as text file with extension *.mtx - eg AUTO-Q1.mtx - into the "Matrix" subdirectory of DVDRB and restart DVDRB.
It is an all purpose matrix which is good over a wide range of bitrates, and it improves compressability, as can be seen from the Q-factor.

8 16 19 22 26 27 29 34
16 16 22 24 27 29 34 35
19 22 26 27 29 34 35 38
22 22 26 27 29 34 35 40
22 26 27 29 32 35 40 48
26 27 29 32 35 40 48 50
26 27 29 35 40 48 50 60
27 29 35 40 48 50 60 62
16 20 24 28 32 36 40 44
20 24 28 32 36 40 44 48
24 28 32 36 40 44 48 52
28 32 36 40 44 48 52 56
32 36 40 44 48 52 56 58
36 40 44 48 52 56 58 60
40 44 48 52 56 58 60 62
44 48 52 56 58 60 62 62

[nashcity]

Thanks Sharc.

[six13]

@Sharc and everyone out there.

The matrix you have made can I assume it will give good results with HCenc21 also and RB.

I am encoding TV captures from my sat. rec H B O Tv shows. Can you sugest a matrix which may work well with interlaced TV standard deff. I end up with the .mpeg file that I demux then author the DVD files. I have always used the matrix that HCenc selected. I believe it was the built in matrix MPEG. I have never used a different one.

Thanks in advance

[Sharc]

I really can't answer your question, as I do not have experience in this area. I think you just have to try and see if it makes a difference in your case.