4.44 GB DVD output with HC ??

[Mugeb]

Hi !

I've selectionned a 4.34 GB size with the Preview/Edit option and I've 4,44 GB size as result why ?

Which target size I should choose to avoid that size error ?

Thanks in advance for your help.

Here the Program Statuts :

[03:20:44] Phase I, PREPARATION started.
- DVD-RB v1.24.0
- AVISYNTH 2.5.6.0
- HC encoder selected
- "One Pass VBR (w/analysis)" mode is enabled.
- "Movie Only" mode is enabled.
- Source: TC
- VTS_10: 3 495 249 sectors.
-- Scanning and writing .D2V & .AVS files
-- Processed 229 148 frames.
-- Building .AVS and .ECL files
- Reduction Level for DVD-5: 76,5%
- Overall Bitrate : 4 370/3 496Kbs
- Space for Video : 4 078 482KB
- Analyzing VTS_10 for optimal CQ factor.
-- TargetSize (sectors):2 069 830
-- Sampling 4590 of 229148 frames.
-- Predicted size (sectors) at CQ=2,8: 3 127 963
-- Predicted size (sectors) at CQ=4,2: 2 732 581
-- Predicted size (sectors) at CQ=5,5: 2 310 703
-- Predicted size (sectors) at CQ=6,1: 2 146 558
-- Predicted size (sectors) at CQ=6,3: 2 098 676
- CQ Value selected: 6,4
- HIGH/LOW/TYPICAL Bitrates: 3 818/3 135/3 496 Kbs
[03:56:04] Phase I, PREPARATION completed in 36 minutes.
[03:57:17] Phase II ENCODING started
- Creating M2V for VTS_10 segment 0
- Creating M2V for VTS_10 segment 1
- Creating M2V for VTS_10 segment 2
- Creating M2V for VTS_10 segment 3
- Creating M2V for VTS_10 segment 4
- Creating M2V for VTS_10 segment 5
- Creating M2V for VTS_10 segment 6
- Creating M2V for VTS_10 segment 7
- Creating M2V for VTS_10 segment 8
- Creating M2V for VTS_10 segment 9
- Creating M2V for VTS_10 segment 10
- Creating M2V for VTS_10 segment 11
[06:55:06] Phase II ENCODING completed in 178 minutes.
[10:21:15] Phase III, REBUILD started.
- Processing VTS_10
- Reading/processing TMAP table...
- Rebuilding seg 0 VOBID 1 CELLID 1
- Rebuilding seg 1 VOBID 1 CELLID 2
- Rebuilding seg 2 VOBID 1 CELLID 3
- Rebuilding seg 3 VOBID 1 CELLID 4
- Rebuilding seg 4 VOBID 1 CELLID 5
- Rebuilding seg 5 VOBID 1 CELLID 6
- Rebuilding seg 6 VOBID 1 CELLID 7
- Rebuilding seg 7 VOBID 1 CELLID 8
- Rebuilding seg 8 VOBID 1 CELLID 9
- Rebuilding seg 9 VOBID 1 CELLID 10
- Rebuilding seg 10 VOBID 1 CELLID 11
- Rebuilding seg 11 VOBID 1 CELLID 12
- Updating NAVPACKS for VOBID_01
- Updated VTS_C_ADT.
- Updated VTS_VOBU_ADMAP.
- Updated IFO: VTS_01_0.IFO
- Correcting VTS Sectors...
[10:43:02] Phase III, REBUILD completed in 22 minutes.

Done.

[~bT~]

pls use search. there are many many threads regarding over/under sizing.

[Mugeb]

I've already done that.

I just want to know which size a I should choose in the Preview/Edit option to have the 4.34 GB output I want.

Thanks.

[jdobbs]

I'm not aware of a "size" that you can choose in the Preview/Edit window.

[blutach]

Try 2 pass, VBR encoding.

Regards

[Mugeb]

I'm not aware of a "size" that you can choose in the Preview/Edit window.
So what is it then ? :confused:

Sorry, I'm newbie.

[Mugeb]

Try 2 pass, VBR encoding.

Regards
How I do that with HC ?

It seem that you can only do that with CCE. No ?

Thanks.

[Rippraff]

How I do that with HC ?
Under Settings => HC Settings => untick "One Pass CQ VBR"

Cu Rippraff

[Mugeb]

Ok I'll try that. Thanks.

[Mugeb]

Worked fine this time.

So why it's oversized when I use OPV in HC settings ?

Thanks.

[jdobbs]

One of the problems with OPV is that it is not completely accurate. In your case it was a little worse than normal.

[sockeye]

Worked fine this time.

So why it's oversized when I use OPV in HC settings ?

Thanks.
Read this:
http://forum.doom9.org/showthread.php?t=122724
Note post 14 (credit to writersblock29....great post)

[techreactor]

The output size in bytes that will result from HC encodes can be calculated as: TargetSectors * 2048 * 1.013. The default for DVD-RB is 2236400 sectors. You can also set it in the INI file.

In my encodes they tend to be +/- 4 MB off the target size using this calculation

[blutach]

I have HCTargetSectors=2260000 and it has never gone above 4482 Mb and is usually within 5Mb.

Regards

[Mugeb]

Ok thanks for the infos guys.

[Geekman]

Just wondering, but how was the 1.013 factor determined?

Basically, I'm looking for a TargetSectors formula to help with fitting the content to a DVD-5. I understand that encoding using OPV can drastically affect the result. Seems like the encoder used also affects the resultant size. Maybe a magic formula is difficult to define? (Too ambiguous of a question?)

So the 1.013 factor only applies to HC using 2 pass VBR encoding?

Thanks in advance folks!

[Rippraff]

Just wondering, but how was the 1.013 factor determined?
Empirical, I guess.
jdobbs is using 1.015 by the way.

Basically, I'm looking for a TargetSectors formula to help with fitting the content to a DVD-5.
It's above. ;)

Cu Rippraff

[jdobbs]

The extra 1.5% represents the overhead associated with VOB packeting. So the output size of all the M2Vs are going to grow to 101.5% of their original size when they get REBUILT. That's were that number comes from.

[sockeye]

I have HCTargetSectors=2260000 and it has never gone above 4482 Mb and is usually within 5Mb.

Regards
Does this target size work ok for you with opv?
I have problems with oversize when the CQ value is high, using opv and the default target sector.
2 pass VBR is consistant in final size.
Is it possible to set target sectors for both methods?
TIA

[Rippraff]

Is it possible to set target sectors for both methods?
No, it is not.
You can choose different target sectors depended on the encoder you use or set a global one.

In your case, if you want to fill up your dvd up to the edge I have only one recommendation: Don't use OPV. ;)

Cu Rippraff

[sockeye]

No, it is not.
You can choose different target sectors depended on the encoder you use or set a global one.

In your case, if you want to fill up your dvd up to the edge I have only one recommendation: Don't use OPV. ;)

Cu Rippraff
Thank you for the reply. :) I didn't think this was possible but thought I would ask.
My output size with opv is generally OK if the backup does not require a large CQ value, usually coming in smaller than the output I get with 2 pass variable. (at default target sectors) As many others have posted, the quality is generally very good.
So I will try setting the larger target sector, and only using opv for the titles that require a lower CQ value.

[Rippraff]

I'm not sure if this is related to the size of CQ value.
Keep in mind that during prediction of CQ values only a small part (2%) of the movie will be analyzed. If these parts don't represent the average of your movie output will be over- or undersized.
Staying with default values should give you a good reserve for this swinging.

Cu Rippraff

[blutach]

Sorry sockeye, but I really can't help too much with OPV. I always run 2 pass.

Anyway Rippraff has answered you :)

Regards

[sockeye]

I'm not sure if this is related to the size of CQ value.
Keep in mind that during prediction of CQ values only a small part (2%) of the movie will be analyzed. If these parts don't represent the average of your movie output will be over- or undersized.
Staying with default values should give you a good reserve for this swinging.

Cu Rippraff
Is the sampling always a fixed percentage of the file, or a fixed amount of data that is sampled, no matter how big the file? If the latter is so, that would explain why I only have problems with oversizing with opv, on longer titles. (the percentage of material sampled would be smaller, allowing more room for error)
I thought perhaps in my case a larger target sectors command would be in order, since my 2 pass vbr encodes consistantly come in at 4.31gb or 4.32gb, where as the opv, if not oversized, generally end up between 4.01-4.24gb.

[Rippraff]

Is the sampling always a fixed percentage of the file
Yes.
So for longer movies more frames will be analyzed but still 2%.

You can change the behaviour by pasting this line under [Options] in Rebuilder.ini
Q_sample_percentage=n
where n is the percentage number.
Try it with 1 or 3 and see if it fits better.

Cu Rippraff

[sockeye]

Thankyou Rippraff, I appreciate your help.
I will give that a try and see if it gives me better results.
Although it will increase the preperation time, I'm hoping a larger sampling may give me better results, and still be faster than 2 pass vbr.

[Mugeb]

BTW does this OPV oversizing problem will be fixed soon ?

Thanks.

[jdobbs]

As I said before, it isn't a problem -- it is something that is symptomatic of the OPV process. When you try to predict the size of your output based upon a 2% sample, you are taking the chance of being off. More often than not you will be within the boundary -- but sometimes it's just a fact that you will oversize. Other methods sometimes use transcoding as a last step when the output oversizes -- but in my opinion that defeats the point of using a high-quality encoder. If you choose to use OPV in order to save time, you also are choosing to accept the risk of sizing errors.

I may be able to make changes that make it more likely to undersize than to oversize -- but I really can't do much about the inaccuracy of OPV. The laws of physics are very difficult to overcome. For most people doing 2 pass encoding is a better choice.

[blutach]

For people who are more familiar with something like DVD Shrink: it is the difference between doing a "Deep Analysis", where every VOBU is analysed before transcoding and doing only the fast "initial analysis". On many occasions, without the DA, you would get unpredicatable sizing issues.

Regards

[sockeye]

As I said before, it isn't a problem -- it is something that is symptomatic of the OPV process. When you try to predict the size of your output based upon a 2% sample, you are taking the chance of being off. More often than not you will be within the boundary -- but sometimes it's just a fact that you will oversize. Other methods sometimes use transcoding as a last step when the output oversizes -- but in my opinion that defeats the point of using a high-quality encoder. If you choose to use OPV in order to save time, you also are choosing to accept the risk of sizing errors.

I may be able to make changes that make it more likely to undersize than to oversize -- but I really can't do much about the inaccuracy of OPV. The laws of physics are very difficult to overcome. For most people doing 2 pass encoding is a better choice.

I think it works well as is jdobbs.....it just takes a bit of experimenting to decide when to use OPV.
I find it comes in at an expected size, and saves time if the average bitrate is fairly high. (and I do not see any difference in quality, when comparing to 2 pass)
I can make it work with low average bitrate, if I set the sampling percentage much higher, however it takes so much longer to complete the "prepare" phase, I don't gain anything over regular 2 pass set at best quality which gives a consistant output size, and wonderful results.
Additonally, I have found that when OPV will come in within the desired output file size, a 1% sampling, will work as well as 2%, and saves several minutes during the prepare stage.
(all of my observations are based on using HC encoder)

[six13]

I have HCTargetSectors=2260000 and it has never gone above 4482 Mb and is usually within 5Mb.

Regards

blu, do you add that to the HC.ini configeratin settings file with notepad?

[Rippraff]

No, all target sectors entries must be placed under [Options] in Rebuilder.ini.

Cu Rippraff

[sockeye]

@Rippraff
Thanks for the tip earlier in the thread on setting the sampling percentage. I have found it very usefull. :)

[Rippraff]

You're welcome. :)

Cu Rippraff