RB-Opt v0.23 BETA a tool to change titles bitrate, CCE parameters and AVS scripts.

[FredThompson]

Could RB Keeper functionality be added to RB-Opt? That would let the user select streams to keep in the orignal form. RB-Opt must be recalculating target sizes for all the parts, anyhow, so this would fit in.

[jdobbs]

Another thing you might want to look into is proper loading fo custom matrices for HC. DVD-RB doesn't seem to be doing it properly. I chose custom matrices but the MPEG default is used by HC.Could you be more specific... exactly what is happening? If there is a problem it should be reported so it can be fixed.

[Carpo]

gonna guess at the issue here

if you go to options -> advanced options -> quant matricies

you can select what you want to use for certain bitrates - if you put the custom ones you make into the same dir as all the other matrices you should be able to select them from there (as long as they are in a format dvdrb understands)

[FredThompson]

I'm still trying to isolate consistent conditions to create the situation in which custom matrices for HC are ignored. It looks like running phase I with the encoder default matrix is locking that in. If the matrix is set to something else after phase I has been run, that new setting is ignored. Now, that may be a parsing bug because the filename of the matrix I chose starts with the "-" character, I just don't know. Restarting DVD-RB then running phase II doesn't remove the problem, re-running phase I does. This is something I just noticed so I'm still chasing it down. Yes, this should have gone in a different thread. Sorry, I was doing too many things at one time and was thinking RB-Opt, bitrates, select encoder, OPV, etc. all at one time.

[jdobbs]

???? DVD-RB sets the Matrices in Phase I... so changing them after PREPARE would have no effect (at least not until the next PREPARE).

[FredThompson]

That's what I said. However, the interface allows specifying a custom matrix after phase I has been run but there's no indication such a setting will be ignored.

[Boulder]

???? DVD-RB sets the Matrices in Phase I... so changing them after PREPARE would have no effect (at least not until the next PREPARE).
This is getting OT, but IMHO it would be good to be able to change the matrices just before the encode phase, because you'll get to see the min/avg/max bitrates for the cells after the prepare phase.

[robot1]

Could RB Keeper functionality be added to RB-Opt? That would let the user select streams to keep in the orignal form. RB-Opt must be recalculating target sizes for all the parts, anyhow, so this would fit in.I'm not sure to add this feature, for two reasons:
1 - I think jdobbs will add this feature in a next release of DVD-RB Pro.
2 - I don't want give for free PRO features to the free version of DVD-RB.

If jdobbs would be not interested in this feature, I could add it.

[jdobbs]

This is getting OT, but IMHO it would be good to be able to change the matrices just before the encode phase, because you'll get to see the min/avg/max bitrates for the cells after the prepare phase.The problem is... what happens if you've decided you wanted to change them and run PREPARE again?

You'd have to manually remove the results of the first PREPARE in order to be able to do a PREPARE again...

[FredThompson]

Ah, yeah, Pro stuff should stay in the Pro version. Good point.

[SpazzHH]

The problem is... what happens if you've decided you wanted to change them and run PREPARE again?

You'd have to manually remove the results of the first PREPARE in order to be able to do a PREPARE again...
But the general request is to be able to change the matrix without having to run the "Prepare" phase all over again. If that is all that you're changing, why else would you want to run it again?

[Carpo]

if you chnaged something say Matrices after prepare - the ecl or hc files will not have the updated changes in them - so running prepare again would have to be done (afaik)

what would be good was if dvdrb did a scan over the files and gave you the output (reduction/bitrate and so on) without making the files thereby allowing you to choose all your settins based on bitrate and such - although to me this would seem like a good idear some may see it as an extra and non needed step (mind u its no diff to runing prepare getting all the info and having to run prepare again should you make changes)

half a dozen of one and six of the other - as they say

[FredThompson]

It should be possible to parse and modify those files without completely rescanning the source material. They're just text files. Good point, though.

[thewonderer]

I have a question about this program..

I have been using dvd2svcd for sometime but have been trying out dvd-rb with cce 2.70 as this version of cce has better quality than 2.67

I've been using d2roba for OPV one pass encoding and have been led to believe that OPV is equivilant to about 5 pass CCE VBR. So i have tried this rb-opt with OPV using standard settings. As is the goal of nearly everyone here, they want to get the best quailty encode possible within reason (not spending an hour tweaking etc).

So I've used OPV with RB-OPT and wanted to know what settings it overrides from DVD-RB... I've read that the Pro version of DVD-RB can use Adaptaive Quantization Matrixes which to me, means better quality. I wondered if using RB-OPT would override this setting as I noticed there are some setting in OPT which refer to the different matrixes ....

Thanx!

[robot1]

So I've used OPV with RB-OPT and wanted to know what settings it overrides from DVD-RB... I've read that the Pro version of DVD-RB can use Adaptaive Quantization Matrixes which to me, means better quality. I wondered if using RB-OPT would override this setting as I noticed there are some setting in OPT which refer to the different matrixes ....

Thanx!
RB-Opt overrides the Adaptaive Quantization setting.
If you dinamically change the matrix, you can't be sure the prediction you've done using the original matrix is accurate. To respect the prediction, you have to use always the same matrix.
I don't know if the original OPV mode in DVD-RB uses the AQM

[thewonderer]

Thanx for the feedback. So just to be clear. When using OPV and checking the CCE settings there is the pull downlist of Matrix's to choose from and below that, a tickbox to enable adaptive Q matrices. Is this the same setting as Adaptive Quantitzation setting? ie, does it allow CCE to dynamically change the matrixes as CCE works through the job?

Thanx.

[J-Wo]

Can RB-Opt be used to change the matrices when I am using HC Encoder? I seem to be only able to if I am using CCE...

[robot1]

Thanx for the feedback. So just to be clear. When using OPV and checking the CCE settings there is the pull downlist of Matrix's to choose from and below that, a tickbox to enable adaptive Q matrices. Is this the same setting as Adaptive Quantitzation setting? ie, does it allow CCE to dynamically change the matrixes as CCE works through the job?

Thanx.
Yes, it's the same setting.
It works in normal VBR encoding.

[robot1]

Can RB-Opt be used to change the matrices when I am using HC Encoder? I seem to be only able to if I am using CCE...
I haven't tested much HC.
If DVD-RB reads the matrices to feed to HC from the Rebuilder.ecl file, it will be possible in a next version.
I need info.

[J-Wo]

I believe it does, because it creats a HC.INI file which only contains information for the current cell being encoded. This file is fed into hcbatch.exe and includes all the input/output/bitrates/matrices information. I can only assume that it gets this info from Rebuilder.ecl. After my entire movie is done encoding, HC.INI only includes info for the very last cell of the movie, so that's where I'm deducing my information from.

If you could add HC support that would be super! In teh meantime, anyone know of a program that can do this?

[jdobbs]

Yes, DVD-RB reads uses the matrix specified in the .ECL file when it passes them to HC -- but only in the Professional Edition. Calls to HC in the freeware version are made using the QuEnc style command line.

[rendez2k]

I'm, just running my first test with RB-Opt and so far, so good... but I have a few questions...
1. Whats the ideal minimum bitrate to use on extras without making them too crappy (I tend to use HD1), or is it just a matter of getting the main feature above 3000?
2. Is it correct, that after running the prepare stage, i then run RB-Opt, make my changes then hit encode? As DVD-RB has made an average bit rate prediction, and I've changed things, does it get over-ridden? Also, are the matrixes from RB-Opt used or do I need to run the prepare phase again (as if I’m right, any matrix changes in DVD-RB normally, require a re-run of the prepare phase)?
3. I take it that it works with all encoders, not just CCE?
4. Any new versions on the horizon as things have been quiet for a few months!

Manu thanks, I’m sure I’ll have more questions as I experiment!

[robot1]

1) HD1 could be very good at about 1.500 kbps
2) RB-Opt overrides the parameters set by DVD-RB. You don't have to run prepare again, else you loose your changes. After changing the matrices, you have just to encode (it's different from Rockas' Matrix Editor)
3) CCE and Procoder.
4) There are a couple of (small) bugs and I have to add support to HC. Anyway, next release will not be soon (I hope at the begin of 2006)

[knife]

Hi robot1,

I did out of curiosity a test were I used DVD-RB latest free and RB_OPT 0.21.
Did the prepare with 00% extra savings.
Opend the rebuilder.inf in RB-OPT 0.21
Saved settings and then examined the rebuilder.in and ecl for differances.

I found that:
RB Target sectors were changed from default 2236400 to 2236369, no big thing but still a change.
You added no_move=0, thats also OK because it's default DVD-RB
You increased max bitrate on several instances, why?
Example:

vbr_brate_avg=4575
vbr_brate_min=500
vbr_brate_max=8433
to
vbr_brate_avg=4575
vbr_brate_min=500
vbr_brate_max=8957


I'm happy with your program and use it all the time, I just begun checking if it complies with the late DVD-RB Pro with new way of setting the max bitrate etc.

Thanks for a great tweaker
//Knife

[spyhawk]

Glad you brought it up. I've been noticing this too. I just change the max bitrate back to the original.

RB-Opt puts the maximum vbr_brate_max (and opv_brate_max) value from one of the segments to every segment of the same vobid. Also when 2 or more vobids are linked in the same VTS.

The Video_Sectors value is changed for every segment in the INF as well. I just use the original INF instead. I don't know what is the difference in the changes.

I also notice the GOP parameters sometimes change for certain segments.

Try to do a CCE prepare. RB-Opt changes other parameters as well, something to do with filter, even if you don't go into CCE settings.

[robot1]

Sorry for the late reply, but I'm very busy at the moment.

I confirm it's a bug, and I hope to fix it as soon as I've some time to code.
Anyway, it shouldn't give any problem, so it should be safe to use RB-Opt.

[rendez2k]

I came across a new question last night - I have an episode disc with 7 27-29 min episodes on it (no extras), but the automatic bitrates are all quite different ranging from 3177 right down to 2300. Should I override these and make them all similar? Are the automatic values from DVDRB or RB-Opt?

[Boulder]

They are the values DVD-RB has set.

[jdobbs]

I came across a new question last night - I have an episode disc with 7 27-29 min episodes on it (no extras), but the automatic bitrates are all quite different ranging from 3177 right down to 2300. Should I override these and make them all similar? Are the automatic values from DVDRB or RB-Opt?I would definitely recommend that you not change them. Those values are calculated based upon the bitrate distribution of the original DVD. That just means some segments don't have as much demand as others. If you steal bandwidth from others, the others will suffer more than those segments will gain.

I have to emphasize... bitrate is not an indicator of quality. While it often correlates -- it also sometimes doesn't. The value of Variable Bitrate Encoding (VBR) is that the encoder allocates what is needed.

In almost all cases manually playing with the bitrate will decrease quality and pretty much always it will damage the consistency of the quality.

[rendez2k]

In almost all cases manually playing with the bitrate will decrease quality and pretty much always it will damage the consistency of the quality.


Jdobbs, are you saying you shouldn't mess with the bitrate ever, or just in this case?

[jdobbs]

I personally would never change it within a single feature. You are second-guessing the original encoder and in almost every case you would be doing more harm than good. Where the adjustments might come in handy are, for example, lowering the bitrate on a preview and allowing the savings to be allocated proportionately across all the segments in the main feature.

[erdoke]

They are the values DVD-RB has set.
...and were calculated from the original bitrate allocation between the episode cells.:)

EDIT
Ohh, forgot to check if other replies have been posted since...:rolleyes:
Sorry.

[erdoke]

Jdobbs, are you saying you shouldn't mess with the bitrate ever, or just in this case?

In special cases it would help some to join the movie into a single VOBID/CELLID and re-chapterize after the encoding so that the encoder can redistribute the bitrate throughout the movie. For example it can be an alternative when you drastically change (decrease) the original bitrate. I rather prefer to use a DL disc or two SL discs in that special cases. :D

[jdobbs]

I've done numerous comparison tests... you'll find that the bitrate is distributed almost identically whether it is done based upon the original by segment or if it is done in one "whole movie" encode. That whole argument is urban legend...

[FredThompson]

Well, let me throw my 2 pennies into this fray...

jdobbs' underlying assumption regarding bitrate is the delivery medium is a DVD. If the original source is streaming MPEG2 (satellite, land line, etc.) there is very often a variable amount of bitrate available. While the internals of the streams might be VBR, the maximum bitrate per transmission can be different as bandwidth is frequently allocated differently at different times. I've seen satellite transmissions of the exact same episode in which the filesize can vary widely. In fact, my common practice is to record as many episodes of a repetitive transmission as possible and keep the one with the highest bitrate under the basic assumption that a higher available bitrate means the result will be higher quality.

Suppose you have a 47 minute episode which is 600M and a different which is 999M but also 47 minutes. All things being equal, it would be far better to sacrifice size from the 999M "original" than the 600M original.

Granted, on homemade OTA DVDs you really should target the DVDR size. The only "good" reason for using DVD-RB on this type of source is to make the streams more compatible with DVD standards and to reduce the size of the larger episodes a little if you overshoot the blank size.

As an example, I made a complete set of a 5-episode series which came out to 4.5G. What to do? In this case, I used DVDShrink to reduce the larger streams and left the smaller ones untouched. Something similar could be done with DVD-RB. (Although, frame sizes aren't full or 1/2 D1 for the vast majority of streaming sources so some other trickery is needed.)

Having said that, thanks a TON for providing support for newer DGDecode builds.

[jptheripper]

the assumption is more of a professionally authored source, as this is a DVD backup tool, not a universal video encoder

[FredThompson]

Methink you didn't understand either my post or its point. I was talking about complete filesets in DVD format.

There are many commercial discs for which custom bitrate allocation would be appropriate. Sometimes DVD-RB defaults to re-encoding long segments which are collections of still images. That's not always a wise choice.

There are commercial discs with content for some some parts have very low bitrate.

Standalone DVD recorders may also be used as source for DVD-RB Pro.

[jdobbs]

Fred,

You're correct for sources that are from "other than commercial" sources... because of the limitations imposed by the transport media. But you'll also find that in those cases the damage is already done. The killer for prerecorded MPEG that is transmitted OTA is the maximum bitrate put on channels. For the ones that are encoded on-the-fly (e.g. "live" encoding) the span of consideration for VBR allocation is often the culprit.... In either case, throwing more bandwidth at an already damaged source isn't going to help it. In fact you'll find the sections with the most error will become bandwidth hogs in the MPEG encoder's attempt to faithfully replicate what was essentially transmission damage.

My comments are aimed at those who are doing backups of standard DVDs -- so I guess the thing to remember is that there are exceptions to every rule.

[FredThompson]

Boy, this seems to be taking a life of its own.

All I meant was the "general rules" of movie DVDs don't apply to all DVDs. I tried to give an example which makes sense. I've got a number of silver discs where the extras are lower bitrate than the main feature, for example. Other good examples are the stuffed releases with huge numbers of still images (usually Disney related - think Gold series, Pirates of the Caribbean but also Lord of the Rings extended discs.)

It sure would be nice if there was a reliable way to set overall quality, as judged by human eyes as a way to control encoders.

Sorry for the confusion. I wasn't trying to say making a segment larger would help. I was trying to say that with segments of the same play time, shrinking the larger one is generally better than shrinking both by the same percentage. Hope that makes sense. This seems to be going in circles. We all probably understand the same things and are in agreement.

[manono]

Hi-

Suppose you have a 47 minute episode which is 600M and a different which is 999M but also 47 minutes. All things being equal, it would be far better to sacrifice size from the 999M "original" than the 600M original.

I think I disagree. Did you happen to check the average quants of the 2 different episodes? Perhaps the larger one didn't compress as well as the smaller one, perhaps because of more action, perhaps because of more grain or noise. And maybe the original encoder, taking that into account, gave one of them a larger size in order to even out the quality among the different episodes. In such a case you want to compress them by an equal percentage so that the resulting encodes will have a similar quality. I'm not saying that's true in your case, but it's a distinct possibility.

In my opinion, pure file size or pure bitrate is an almost worthless indicator. Here's a different example. I have one of the Have Gun Will Travel TV boxsets. It's an old western TV series. Each 26 minute episode is given an almost identical file size, but the average quants of the originals vary from around 7 to upwards of 13. Do I want to compress them equally so that they wind up with the same filesizes? Not by a long shot. These old and grainy episodes often have about 3 hours of video on each disc. Compressing each of them to 52% of the original size could easily lead the poorer quality, higher ave Q episodes to have noticeable artifacts. When I compressed them, I chose resulting file sizes that would give each episode a similar ave quant.

Because they often stuff so much into these TV series DVDs, and often use hard telecined film sources, they can be quite difficult to back up successfully.

[FredThompson]

That's not how streaming source works. There is a finite amount of bandwidth available for all channels in the stream and it's reallocated based on audience. The Super Bowl will be broadcast with a higher than average amount of bandwidth which means other channels will have less available to them. Encoding by these sources isn't done in an attempt of matching visual quality between episodes. It's done by using the full available bandwidth for a channel but that bandwidth allocation isn't constant for a channel.

You're very correct about the packed DVDs. For that matter, a high bandwidth version of a VHS source isn't necessarily going to be better than a smaller bandwidth version of the same source. Imagine a disc with old TV shows and a "bonus" feature or two with modern footage (interviews, reunion, retrospective, etc.) Some form of weighted and averaged bandwidth allocation would make a lot of sense.

I was just trying to communicate the basic concept. Sure didn't think it would grow into this amount of discussion. Still, you've got me envisoning a global Q(uality) function which is applied after RB-Opt is used to set a target size for the whole file set. That would be nice. So would some kind of DVShrink-like checkboxes to specify what parts are to be re-encoded.

Sure am glad my nick's not jdobbs. Bet you'd get tons of mail with a moniker like that :P

[manono]

OK, forgive me then. Although I read the comments about the TV bandwidth varying, I thought you were extrapolating to connect it to DVDs, with your comments like this:

I was talking about complete filesets in DVD format.
and All I meant was the "general rules" of movie DVDs don't apply to all DVDs.

So I was taking your example of recording a show twice with 2 different file sizes, and trying to explain (not very well) how something like that on a DVD might be the right approach to take. But I screwed up, you're right. Rather than using that example, I should have disageed with this statement of yours:

I was trying to say that with segments of the same play time, shrinking the larger one is generally better than shrinking both by the same percentage.

Again, I don't see how that follows, since, if DVD-RB is doing its job right, the larger segment needs the higher bitrate for the same quality as the smaller segment, and both should be compressed by the same percentage.

Some form of weighted and averaged bandwidth allocation would make a lot of sense.

I couldn't agree more, but I don't know if it could or even should be done through DVD-RB. Plus, it would just leave the door wide open for all kinds of rookie screwups. Even something as seemingly simple as the "Steal Space" concept can give wildly varying results for the same percentage, since, as you mentioned, these extras, even within the same DVD, are often encoded at different quality. Or, you steal 33% for the extras on one DVD, and they look OK, but you do the same for another DVD, and they might wind up looking like garbage. Your global quality concept is an interesting one, for sure.

Sure didn't think it would grow into this amount of discussion.

Personally, I find this particular subject fascinating. That's what I try to do with my own encodes; ensure a good quality for the main movie, and a lessor but equal quality among the extras I decide to keep. And although I haven't worked much with TV series DVDs, they're becoming more and more popular, and when doing them, I try and ensure more-or-less equal quality among the reencoded episodes. And it can be real tricky to accomplish sometimes.

[Boulder]

Personally, I find this particular subject fascinating. That's what I try to do with my own encodes; ensure a good quality for the main movie, and a lessor but equal quality among the extras I decide to keep. And although I haven't worked much with TV series DVDs, they're becoming more and more popular, and when doing them, I try and ensure more-or-less equal quality among the reencoded episodes. And it can be real tricky to accomplish sometimes.
I've got an Excel spreadsheet to calculate the average bitrates for that purpose. I encode a sample of each episode/title with the same Q in CCE and use the average bitrate for the maths. It would be easy to use the same sheet for a movie plus extras as you would only need to add a factor to have the extras encoded at a slightly lower quality level than the main movie.

[manono]

Cool, someone else trying to accomplish the same thing. Yeah Boulder, for these TV episodes I got the the average quant of the originals, figured how much space I had available for the video, divided that by the number of episodes, and then adjusted the file sizes/bitrates up or down in order to bring the average quants into line for the reencode. It didn't always work on the first try, so the ones that were still off, I adjusted some more and ran another pass or 2. Not as precise as your method though.

When doing extras, I'm even less precise. I run the passes guessing at the bitrate for the ave quant I want to end up with. And adjust some more when done if it didn't turn out right the first time. Then I figure the remaining space available and the matrix to use for the main movie which I do last. I like your method better. :)

[FredThompson]

[QUOTE=manono]OK, forgive me then. Although I read the comments about the TV bandwidth varying, I thought you were extrapolating to connect it to DVDs, with your comments like this:[QUOTE]
I was thinking about what I do; direct access to the stream then author DVD file sets. Sometimes the stuff that is destined for one blank is just a little too large. I was also thinking about some of the packed discs like Disney Gold, LOTR, etc. It all kind of got mixed up.

[Boulder]

Cool, someone else trying to accomplish the same thing. Yeah Boulder, for these TV episodes I got the the average quant of the originals, figured how much space I had available for the video, divided that by the number of episodes, and then adjusted the file sizes/bitrates up or down in order to bring the average quants into line for the reencode. It didn't always work on the first try, so the ones that were still off, I adjusted some more and ran another pass or 2. Not as precise as your method though.

When doing extras, I'm even less precise. I run the passes guessing at the bitrate for the ave quant I want to end up with. And adjust some more when done if it didn't turn out right the first time. Then I figure the remaining space available and the matrix to use for the main movie which I do last. I like your method better. :)
I could give you the spreadsheet if you like, there's nothing fancy about it - it's just some simple maths. The bitrate distribution is as accurate as the sampling so it will vary but not much I think. At least when I've done an OPV encoding in CCE, the Q values have been quite close to each other.

EDIT: And to ensure this is not completely off-topic, it would be nice to see a feature like this in RB-Opt.. I've seen several series boxes in which the avg bitrates for the episodes have been almost exactly the same. I find it hard to believe that this would be the case if it was based on complexity of the video. The authors have probably just divided the available space evenly between the episodes as the avg bitrate was high enough to ensure a good enough quality for each episode.

[manono]

Thank you very much for the offer, Boulder. I don't have Office installed on my lean, mean, encoding machine, so I wouldn't have much use for an Excel spreadsheet. That kind of thing is reserved for my wife's computer. Perhaps others would be interested.

The authors have probably just divided the available space evenly between the episodes as the avg bitrate was high enough to ensure a good enough quality for each episode.

Yes, that's what I found with that Western TV series boxset I did. I'm sure that to keep the costs down on these TV boxsets, they're rushing them out as fast as they can, with no regard for equal quality among the different episodes. I also think that encoders that do the same thing for their DVD backups, or even AVI backups, of TV series DVDs, are making a serious mistake in doing so. While the quality may have been "good enough" for the original retail DVD, once you start recompressing for DVD5 or AVI, the artifacts might start showing up in the episodes done with lower quality.

[robot1]

If the various episodes are in the same VTS, why don't you use the OPV mode?
RBOpt can handle OPV for episode in the same VTS, linking all the VobID's. I'm not sure about native OPV mode in DVD-RB

If the episodes are in different VTS's, it's a problem :-(

[TuRiSOft]

@robot1 :
there's need of a new release , rb-opt doesn't handle the new Menu Encoding function and crashes !!!

[jptheripper]

nice of you to give him a couple hours after the release to fix it!

(sarcasm)

sorry.. i am sure he will fix it in time