Setting Targetsectors explanation incorrect?

[Harm]

At some DVD jobs I had to use the Targetsectors setting option because the first result came out slightly too large.
For that I used the explanation in the hidden settings (http://forum.doom9.org/showthread.php?s=&postid=482090#post482090)
In there the explanation is that 1 sector = 2Kb and the default used is 2236400 sectors.

On every occasion my calculation to correct the oversize turned out to be incorrect (i.e. still too large but slightly better).

Today I had an oversize of 70 Mb. So I calculated 70 Mb * 1024 = 71680 Kb / 2 = 35840 sectors.
So I lowered Targetsectors to 2200000.
I reran the rebuilder job entirely with an oversize result of 52 Mb.

Am I doing something wrong or is the 1 sector = 2Kb wrong? If it is the other way round 2 sectors = 1Kb then I would get a result like I got on the 2nd run.

Anyone has experience with this?

[NaN]

The Targetsector explanation is perfectly correct. It seems your encoder has problems hitting the desired size. dvd-rebuilders default target is already more than 100MB below dvd-size to prevent oversizing.

I suggest that you post what encoder in which mode you use.

Cheers, NaN

[wmansir]

If you check my post at the bottom of the first page on that thread you'll see I've experienced the same thing when determining the max TargetSectors for a DVD-5.

It could be due to the encoder not maintaining the right bitrate, or a k= 1000 vs 1024 error or perhaps just some unaccounted overhead.

Anyway, the forumula I use is

2267500
------- X (target)GB = targetSectors to use
4.38 GB

The enocoder will make a slight difference. For instance I find ProCoder's output is usually about 10MB larger than the same job done with CCE.

[Harm]

I am using CCE as the encoder. 9 out 10 times the result is below the mark (sometimes more than 100 Mb). I use one pass. Normally I don't use the targetsectors option.

I tried to calculate the other way round (i.e. multiplying by 2 instead of dividing) and used 2093000 as the targetsectors figure.
The result was an undersize of 183 Mb!

So lowering by 36400 sectors resulted in 18 Mb less and
lowering by 143400 sectors in 253 Mb!
Can somebody explain this?

Either something weird is happening here or maybe the default specified is incorrect?

Maybe there is also an enhancement in this. Could jdobbs make an option (maybe only as a hidden one) to be able to specify a relative correction (i.e. xx Mb less). As I understand the exact result is never to be predicted so everyone will encounter an oversize once in a while.

[pg55555]

I use one pass.
This is the core of our problem. OPV (One Pass VBR) is not very good at getting at a target size.
It is my understanding it is so due basically to two reasons:
- The calculated Q is based upon a sample, not by analysing all the cell to encode.
- The granularity of Q: As Q values can only been integers, at low Qs the difference between 2 inmediate values are relativelly big. Example: If with Q=10 you get an oversize of 200 MB (4.58 GB), you have to go with the next value wich is Q=11 (a 10% increase). If compression were linear with the Q value (which is not, but so you can get the picture), output size would be reduced by 10% to 4.12 GB, being 260 MB undersize. OF course, with bigger Qs the problem diminishes (the difference between Q=30 and Q=31 is just 3.3% which wuld be 140 MB size diference between both)

So, if you want precission size use CCE 2-pass VBR.

[jdobbs]

The problem is that encoders are inherently inaccurate. OPV is even more so. The amount of inaccuracy ranges depending upon the encoder (CCE is pretty accurate) and the material. You are measuring the end result. Target sectors is just that -- a target. It is always better to target slightly smaller than the true size of a DVD -- coming in slightly undersized is ok -- first it helps counteract the problems some blanks have with weak retention near the outer ring, and second, the increase of a few Kbs in bitrate resulting from the loss doesn't make any noticable difference in video quality.
Originally posted by Harm
I am using CCE as the encoder. 9 out 10 times the result is below the mark (sometimes more than 100 Mb). I use one pass. Normally I don't use the targetsectors option.

I tried to calculate the other way round (i.e. multiplying by 2 instead of dividing) and used 2093000 as the targetsectors figure.
The result was an undersize of 183 Mb!

So lowering by 36400 sectors resulted in 18 Mb less and
lowering by 143400 sectors in 253 Mb!
Can somebody explain this?

Either something weird is happening here or maybe the default specified is incorrect?

Maybe there is also an enhancement in this. Could jdobbs make an option (maybe only as a hidden one) to be able to specify a relative correction (i.e. xx Mb less). As I understand the exact result is never to be predicted so everyone will encounter an oversize once in a while.

[Harm]

So is there a rule of thumb on how many passes you need to get more precise results?
Is 2 passes enough or should there be more?

And is it possible after I have run an OPV to instruct Rebuilder to run another pass without having to go through all previous passes (so adding the result on top of it so to speak)?

[jdobbs]

You will get the same size with any number of passes of 2 or more.

I am working on an option that will have DVD-RB do a second pass automatically if an OPV pass is oversized (or if undersized by some percentage).

[wmansir]

2 passes is enough to get a consistent size.

There is no way to tell DVD-RB to re-use the first pass. When you switch out of OPV mode you have to re-run the Prepare step, which deletes the .vaf files created in the first pass.

You do it manually by moving the .vaf files to another folder and then putting them back after the prepare step is finished. CCE 2.5 would then use them automatically. Later versions have a create_new_vaf= setting which will have to be changed. You can search/replace the Rebuilder.ecl file for all instances of

create_new_vaf=1

with

create_new_vaf=0

to use the existing .vaf files.

EDIT: a little late, I had to search around for the .ecl parameter to change.

[Rockas]

I am working on an option that will have DVD-RB do a second pass automatically if an OPV pass is oversized (or if undersized by some percentage).

You could create an option like "Use transcoder if result is oversized?" if user chooses yes then if the oversize=true then run ReJig :)

[robot1]

Originally posted by wmansir
2 passes is enough to get a consistent size.

There is no way to tell DVD-RB to re-use the first pass. When you switch out of OPV mode you have to re-run the Prepare step, which deletes the .vaf files created in the first pass.

You do it manually by moving the .vaf files to another folder and then putting them back after the prepare step is finished. CCE 2.5 would then use them automatically. Later versions have a create_new_vaf= setting which will have to be changed. You can search/replace the Rebuilder.ecl file for all instances of

create_new_vaf=1

with

create_new_vaf=0

to use the existing .vaf files.

EDIT: a little late, I had to search around for the .ecl parameter to change. If you don't want to move files and run the preare step again, you can open the project in RB-Opt and change from OPV to VBR, than save.
Anyway, you have to edit the rebuilder.ecl as described above.

Anyway, you have to edit the rebuilder.ecl as described above fot

[Harm]

Originally posted by jdobbs
You will get the same size with any number of passes of 2 or more.

I am working on an option that will have DVD-RB do a second pass automatically if an OPV pass is oversized (or if undersized by some percentage).
Looking forward for that option jdobbs!

Anyway I'll set the number of passes to 2. Thanks for all the info!
:)

[ceedub]

Originally posted by Harm
I am using CCE as the encoder. 9 out 10 times the result is below the mark (sometimes more than 100 Mb). I use one pass. Normally I don't use the targetsectors option.

I tried to calculate the other way round (i.e. multiplying by 2 instead of dividing) and used 2093000 as the targetsectors figure.
The result was an undersize of 183 Mb!

So lowering by 36400 sectors resulted in 18 Mb less and
lowering by 143400 sectors in 253 Mb!
Can somebody explain this?

Either something weird is happening here or maybe the default specified is incorrect?

Maybe there is also an enhancement in this. Could jdobbs make an option (maybe only as a hidden one) to be able to specify a relative correction (i.e. xx Mb less). As I understand the exact result is never to be predicted so everyone will encounter an oversize once in a while.

I am getting this exact same error/problem using DVD-RB ver 0.77. I have been using 4 passes. The last two backups I produced (CCE 2.70 SP Trial) were 18kb oversized despite lowering TargetSectors=2264000, to Targetsectors=2262000. Got the same oversize result.

[jdobbs]

I am getting this exact same error/problem using DVD-RB ver 0.77.Error? Problem? I truly don't want to sound intolerant, but I have repeated many times... you should leave the target sectors at the default (2236400) -- if you increase it and run oversize, how can I be held responsible for a self inflicted injury?