Undersizing using 2.70.2.0 [Archive]

apfraats

31st December 2005, 02:26

@JDOBBS (sorry , missed youre message at first sight):

The only difference here is the use of 2.70.2.0 and the use 2.66.x.x.

Using 2.66/2.67 I have had NEVER a problem.

Using 2.70.2.0 gives me 2 undersized compressions out of 3 tried.

CROSPY dit about 900 and had 5 not explainavle undersized results.

Of course, me knowing me, i probably have 1 of those 5 in my first attemts :)

But seriously I do the normal job, no OPV, nothing about that with RB-OPT.

I have both CCE 2.66 and CCE 2.70.2.0 existing in the DVD-RB dir, of coursae renamed to the correct version so CCTSPT266 and CCTSPT2700200.

CCTSPT266 I use with ECLCCE and CCTSPT2700200 not, but with TRIAL CCE setup.

result:

CCE 2.66 = 4.34 GB
CCE 2.70.2.0 = 4.11 GB

That was the only variable factor in comparing.

a difference of .23 GB is really too m7uch, and probably:

1) An execptional case (always me)
2) Version dependent CCE behaviour.

All calculations done by DVD-RB-PRO including MAX/MIN/AVG bitrate and reduce % were exactly the same.

But after several hundereds of 2.66/2.67 compressed DVD's, that were always 4.34/4.35 GB, now suddenly with a trial of three with 2.70.2.0 I have more different restults up to wasting 230 MB of space.

I'm sure it is version specific and try other 2.70 subversions.

I sure can be the case that 2.70.2.4 is doing just fine.

I'm trying that now, with my laptop at my mothers place (lasting hours and hours.....) and will see the difference.

As far as I see know, 2.70.2.0 has more variation in target size than what I've ever seen from 2.66/2.67.

2.70.2.4 is on trial now....

apfraats

31st December 2005, 02:53

well well,

Same source, same setting, CCE version variable:

2.66 4.34 GB (1......X) repeatable.
2.70.2.0 4.11 GB (1.......X) repeatbale.
2.70.2.0 4.20 GB (1....X) repeatable. at MAX 100% compression !!!!!
2.70.2.1 4.13 GB (1....x) repeatable.

Well, even going for 100% at CCETARGETSECTORS>SOURCE SECTORS, only gives 4.20 GB !!! (source about 4.75 GB)

and now running 2.70.2.4, let's hope for better results....

Otherwise I'll try some other sources before returning to 2.67.......

Cropsy

31st December 2005, 14:12

If it matters.
I forgot to tell you that I always do 3 passes and always use the default CCE settings in DVD-RB. Except for the targetsectors settings that is.
But I always preprosess with Vobblanker first to delete everything I dont like, like trailers, FBI warnings, commercials and shit that starts before the movie itself starts. So my disc always starts in the main meny. Then I prosess it with menushrink and always keep the main menu in it's original size and the rest as stills.

Anyway HAPPY NEW YEAR TO EVERYBODY

And Jdobbs keep up the good work and lets hope that this DVDformat sticks with us for many many years :p

jdobbs

31st December 2005, 14:51

Happy New Year to all!!

apfraats

31st December 2005, 16:56

Of course to everubody : Happy Newyear !!

(and let the Blue Ray don't waste our pleasure, sure JDOBBS is already doing research on this :) :) :) )

@CROPSY:

I do much te same, even less complex.

I use DVDSHRINK to do a movie only backup, and the feed to DVD-RB-PRO is just 1 main movie, nothing else. Also always 3 passes set in DVD-RB-PRO.

And now the result with this annoying DVD of mine with 2.7.2.4:

4.13 GB.......

I give it up, 2.66 does ok, all 2.70 version I have tried not....

So I leave it here, and try other DVD's first.

Maybe it's a special case here......

Strange although that 2.66 does the job ok.....

As I do more DVD's first I'll see what happens....

raquete

31st December 2005, 17:28

i have the old cce2.50,266 trail,2700200 trial (with crazy speed indication) and 2700204 trial(seems that the speed indication was corrected).
i have the dvd-rb v0.96 free version and sometimes i use 2 passes and when the movie is cool,3 passes.all cce versions give me the same final size(few differences,when have)...i reencode one movie 5 times(crazy right?) to choose filters and his results.

now i'm curious apfraats:
can you post the rebuilder.ini from default instalation folder?
will be cool ! thanks.

:)

apfraats

31st December 2005, 17:54

Yep, I have to cut and paste.

You will notice a absurd CCETARGETSECTORS, because I had to 'force' DVD-RB-PRO ton 100% compression, and even then it's undersized, probably to about 4.23 GB.

So here it is:

[Options]
CCEtargetsectors=2400000 #2256400 #2277550 (4.30->4.34) #2255000
MIN_BITRATE=0
vts_min_size=0
Mode=1
OneClick=0
ReduceOpt=0
NoWarn=1
AdditionalOutput=1
LogFile=1
QuEncHQ=1
EncoderMinimized=1
RemoveDTS=0
HC_Quality=1
HC_Matrix=1
CCE=3
SkinVersion=10
Skin=Rebuilder Default
QuEncodeType=0
DVD_Label=THE SKELETON KEY_MO0140_[5.1]{2
DVD_Name=THE SKELETON KEY_MO0140_[5.1]{2.ISO
HalfD1=00
Convert_16_9=00
DisableInterlace=00
DCPrec=3
Completed=21
HalfExtras=0
MainMatrix=Encoder Default
AudioDub=1
iDCT=3
GOP=2
LowMatrix=Same as Main Feature
VLowMatrix=Same as Main Feature
ExtraMatrix=Same as Main Feature
ProCoder_Quality=4
MovieOnly=0
ConvertToYUY2=1
AVSFilter01=undot()
[Paths]
QuEnc=d:\DVD-RB PRO\Encoders\QuEnc\QuEnc.exe
ReJig=d:\DVD-RB PRO\Encoders\ReJig\ReJig.exe
HC=d:\DVD-RB PRO\Encoders\HC Encoder\HCbatch.EXE
ProCoder=d:\DVD-RB PRO\Encoders\EclPro\EclPro.exe
DECOMB=C:\Program Files\AviSynth 2.5\plugins\Decomb521.dll
MPEG2DEC=d:\DVD-RB PRO\DGDecode.dll
Working=E:\DVDRB\
Output=E:\DVDRB\
CCENew=D:\DVD-RB PRO\cctspt2700204.exe
Source=M:\20051228\THE SKELETON KEY_MO0140_[5.1]{2}_WLB\
[CCEOptions]
VBR_bias=0
Quality_prec=32
eclPasses=3
[Audio]
Selected=11
Remapping=
[Subpictures]
Selected=1111

Now the CCETARGETSECTORS are set to a value higher than original, and sure despite that the DV'D comes out undersized.

The original size is 4.43 GB and at 100% it will be about 4.23 GB, 200 MB are gone forever...... at 100%.

The 'normal' setting I use is 2256400 having about 4.34-4.36 GB.

If I use 2.66 it will be ok, with all 2.70 versions I tried it's undersized.

I hope it's for this particulair DVD only, I'll see.

A job lasts about 7 hours on my laptop, so I need more time.

If more DVD's are getting uncersized I simply go back using 2.67 or so.

But seeing other user comments, I probably have a 'weird' DVD or so.

archaeo

31st December 2005, 18:01

The original size is 4.43 GB...

A job lasts about 7 hours on my laptop, so I need more time.

why don't you just make life easier on yourself and use dvdshrink? you're only looking at a very minor compression here.

raquete

31st December 2005, 20:33

apfraats,
can you test only one time changing the line CCEtargetsectors=2???? to TargetSectors=2264000 and encode with any cce version? this is what i use and give me the right final sizes as i posted.
my cce options are differents from yours:
[CCEOptions]
VBR_bias=25
Quality_prec=16
eclPasses=3

ot but is in topic:(how can i explain?) :p
i read your post about min_bitrate=0 and really works and it don't input any error in the size target.no matter what value choosed(from 0 to 500) ...was a cool hint.

HNY :)

Cropsy

31st December 2005, 23:17

@CROPSY:

I do much te same, even less complex.

I use DVDSHRINK to do a movie only backup, and the feed to DVD-RB-PRO is just 1 main movie, nothing else. Also always 3 passes set in DVD-RB-PRO.

.

I like to keep the menu. I also like to keep the blooper reel if it is available. I never use DVDSHRINK anymore, even if the original is very close to 4,35G. Don't ask me why, I just like it like that. :p
DVD-RB is the only way for me to make backups

apfraats

1st January 2006, 03:37

@CROSPY

Sorry that I forgot to mention that doing a movie only backup is always UNCOMPRESSED !!

So I use DVDSHRINK as a quick way to FILTER the main movie out of the other things I don´t need, even the menu.

I know REAUTRHORING to MOVIE ONLY in DVDSHRINK has a bug in VOB/COUNT, but I also know JDOBBS wisely checks for this in REBUILD stage, and let DVD-RB corrrect it.

@raquete
I tested everything possible, with all 2.70 version this particular DVD get's undersized.

Even using 100% compression by setting targetsector much too high, yields a result of 4.20 GB !!

Simple use of 2.66 was solving this problem.

Now I'm trying a next DVD to compress with 2.70.2.4 and see what comes out.

Probably this one is ok.

Don't ask me why that .... DVD I have gives these stranges results.....

I really won't know, but it looks that CCE 2.70 is being at fault here, in some way.

Well, I have to go on, and try 2.70.2.4 some more times. If it's undersizing becomes a structural problem, I'll try running on another CPU and see.

Seeing others commenting, chances are BIG that only a few DVD's are getting undersized and most go ok.

Let's wait some time and see....

apfraats

1st January 2006, 08:33

Ok, let's say this:

I had one difficult DVD, that's all.

Two others came out fine at 4.36 GB pretty towards max DVD5 space.

And some other observations:

2.70.2.4 is much more dynamic in bitrate distribution. Even in 1 second it can raise or lower bitrate by more then 5000 Kbps !!!

The graphs with bitrate veiwer are totally different regarding to those of 2.66/2.67. There is much much more dynamic.

I have to test before drawing futher conclusions, but that comes with time.

The new encoding engine seems hyper-sensitive and I hope this will show up in results with the always problematic lower average bitrate compressions.

As far as concerning undersizing: It's DVD specific, I think in most cases it's OK. In some other cases it's not.....

winny

1st January 2006, 14:38

Preprocessing with shrink seems unnecessary, especially with the added risk of compatibility issues you've already mentioned.

Why not use rebuilder's movie only mode if that's all you want?

raquete

1st January 2006, 14:41

Simple use of 2.66 was solving this problem. good to know.

i told you that i have 250(full),266 and the last 2 CCE 2.70.2.0xx(the last 3 are trials and this 4 versions give me seamless final sizes.

let me ask and understand my question from who really don't know the advanced adjusts in cce:
using RB free version,i have and use all default cce adjusts:
[CCEOptions]
VBR_bias=25
Quality_prec=16
eclPasses=3i only change the number of eclpasses(2 or 3 and will try 4).

now comparing with your :
[CCEOptions]
VBR_bias=0
Quality_prec=32
eclPasses=3why you adjust this values and what advantages you get? :confused:
this adjusts of VBR_bias=0 and Quality_prec=32 can't give issues in the final size?

thanks for any clarification.

winny

1st January 2006, 14:46

Have you reported it to Cinemacraft support as an encoder specific bug?

magic144

2nd January 2006, 18:49

hi guys

I've just noticed the movie you're talking about is THE SKELETON KEY

I had what I thought was an undersized RB backup of this a while back
(the backup was a coupla hundred MB shorter than usual)

in THIS PARTICULAR case, if I remember rightly, the quality was basically already at the maximum, hence the CCE output was smaller than the original!

please checkout my original posted thread here:-
http://forum.doom9.org/showthread.php?t=102862

and aaron10's explanation here on CCE and Q values:-
http://forum.doom9.org/showthread.php?t=102862

hope this helps

apfraats

2nd January 2006, 19:23

@raquete:

Simple explanation:

VBR=0 gives MAXIMUM VBR.

As I never notice problems in low-demanding scenes, I want to create MAXIMUM HEADROOM for HIGH DEMANDING SCENS.

As you raise youre VBR_BIAS, bits are lost because CCE is tempered in dynamically assigment of BITRATE, so theoraticaaly bitrate is wasted.

The higher VBR_BIAS the more bitrate is wasted on places were it isn't needed and finally you even get FULL CBR, and then youre demanding scenes are lost for ever in blocking pictures.

To get the most OPTIMAL distrubution, I use FULL VBR, spending EVERY BIT on parts where they needed, and NOT wasting one on parts where they are NOT needed. That's to be short.

Towards QUALITY I have to say I have NOT NOTICED much difference between 0 or 64. Maybe it's visible at very LOW BITRATES, but I don't use very low bitrates, then I split the movie up.

So having not noticed differences, I simply set it between maximum and minimum setting in the middle, assuming it will be ok. Most of the time you see people use lower values, but as I even not see differences at my usual bitrates (depending on source, but usually split when movie is about 3 hours, keeping only 5.1 DD soundtrack), I set it at the middle value.

The only very important settings are VBR_BIAS=0 and MIN_BITRATE=0, as this will greatly improve movie quality as more difficult bitrates (lower onces) are to be used.

@MAGIC144

Thanks a lot, although this doens't explain why 2.66 does CORRECTLY finish the job. As long as there is no CBR at maximum bitrate, there is always room for extra bitrate.......

But I think it indeed has to do something with the encoder charisteristics as 2.70 has a new engine.

2.66 works fine, PROVING THERE IS ROOM FOR EXTRA BITRATE !!!!

(otherwise it won't result in the 4.35 GB).

There must be some strange fenomenia here, as all others DVD's (5 pieces) came out just fine using 2.70.2.4 .

So if youre not at FULL CBR MAXIMUM BITRATE, the encoder can always use the extra room for extra bits, but maybe I'm wrong. 2.66 is able to fill the CCETARGETSECTORS however.....
2.70.2.4 is not in this case, but glad to hear THE SKELETON KEY resulted in undersizing in youre case too.
Probably some weird circumstances together here.....

One thing to try is using a higher VBR_BIAS and see what happens......

Sure worth a try...

Thanks for the info, I feel a lot more assured now !

Mr. Monte

2nd January 2006, 20:12

Every thing has it's plus and minus's...so my qurstion is this:

Whats the Pro and Cons of adjusting the VBR BIAS from the default (25) and the Qual Pre (16)?

You state above setting the VBR BIAS to ) is all VBR, less CBR and will allow more bits to demanding scenes..o.k..as a novice..I might believe that..but whats the drawback?

What about Qual Prec?

TIA

jdobbs

3rd January 2006, 00:05

Adjusting the VBR bias down will create a higher likelihood of blockiness in black and fading scenes (disadvantage) while allocating more bandwidth to the high demand scenes (advantage). It also makes the stream more volatile (greater bitrate swings), which has been reported to cause problems on some players (although I can't name one).

Adjusting Qual_Prec decides whether to apply more of the available bandwidth toward complicated images (like say, the leaves on a tree) or flat areas (like the gradual color changes of a sunset). Reducing it also reduces mosquito noise on sharp edges -- but increases the "rainbow effect" in gradual color changes.

The default settings are set as they are because they have been tested and determined to have the best picture across the largest spectrum of picture types. They are a good balance.

As for minimum bitrate... the lower the setting, the better the use of available bits (advantage), but the higher the liklihood of creating a picture that may have problems on some players. The new default (300Kbs) is set at that amount because it is not know to cause problems on any players -- but keeps the bitrate for low demand scenes (like black or low motion pictures) at a reasonably low level.

apfraats

3rd January 2006, 01:02

I don't get the low bitrate problem at all.....

Why not ???

Simple.

A lot of commercial DVD's have black parts in thier beginning or between fading scenes. And then I can PROVE the min_bitrate goes even down to below 200 bits/sec !!!!

Seen the fact these are commercial available DVD's, there should be NO reason not to lower MIN_BITRATE.

I have had NO trouble with these DVD's on whatever DVD-player I use, even not on Sony players :D

I will search for the lowest bitrate I can find on a commercial rip and report it.

Bitrate-viewer can be used for this, as far as I understood it, it can only give higher readings then the TRUE FACTS, and not lower readings.

Even POWERDVD goes down to below 200 Kbps at longer totally black images, but this is a very unpredictable way to measure.

Then I have a DVD-PLAYER that reports VIDEO-bitrate as POWER-DVD , but much more accurate (frequenter updates).

I'll see what I can find.

And for the demultiplexer there is ALWAYS an audio track, that's has a nominal bitrate depending on format. This will almost per definition solve a 0 bitrate problem.

ADDITION: I have a DVD KINSEY that has a black part 25-29 seconds and the bitrate here is 'just' 204. So this is already pretty low, from a commercial R2 PAL DVD.

THE GODFATHER I have done at 58% compression, the result has levels of 172 bits/sec. No problem on players I tried. One old Sony, one new Sony, one Philips, 1 Targa.

It really looks that there is no problem here otherwise than the use maybe of specific versions of encoders that produce 'dirt' at very low bitrate. As HC doesn't honor minimum bitrate it would be nice to hear from hank what the minimum produced bitrate theoratically could be........

raquete

3rd January 2006, 01:43

i tend to agree with you in your last post and here (http://forum.doom9.org/showthread.php?p=761180#post761180) where you posted Never had this issue.
some old members here can remeber the problems with low "min-bitrate" because it happens when you're doing....mix this low resolutions :
vcds,cvds,svcds and some X(tranges)??cds (with low/limited max bitrate)...mix this together with old and bad matrices,old encoders versions and too much filters to get compression.don't forget mix with the (some bad)quality of the old standalones that don't like low bitrates....old avisynth versions and some more.(bad english,can't find words to explain better)
compression and perfect final size was the target in the past and not cool quality(we still read posts where some members want to put 3, 4 or more movies in one single media :scared: they will always get one economic trash imo)

i'm doing slow tests using min_bitate from 500 to zero (now with 200) for more than a week(or 2) and i don't have problems.(in my old standalone that don't like svcds with less than 300 in min_bitrate,run perfectly dvds with 200...still testing ;) )

i can't trust that dvd-rb can give this issues because the whole programs running new versions of all(filters,avisynth,encoders,etc) and rb use everything new as possible for dvds targets!

the issues with low min_bitrate is now history,are in our old encodes and "still alive" for who expect crazy miracles like 3 or 4 big movies in one single dvd media.

:thanks: (excuse poor english)

HNY for all!

dragongodz

3rd January 2006, 02:09

Never had this issue
tend to agree with you
how nice. so now its "i dont have the problem so its no longer real or true". so you guys can guarentee that will be so for everyone and on all dvd players current and future can you ?

Bitrate-viewer can be used for this, as far as I understood it, it can only give higher readings then the TRUE FACTS, and not lower readings.
actually bitrateviewer constantly gives me lower than real values so i nolonger use it.

apfraats - may i suggest to completely read threads you start before saying the same things.

And for the demultiplexer there is ALWAYS an audio track, that's has a nominal bitrate depending on format. This will almost per definition solve a 0 bitrate problem.
http://forum.doom9.org/showthread.php?p=755541#post755541

As HC doesn't honor minimum bitrate it would be nice to hear from hank what the minimum produced bitrate theoratically could be
http://forum.doom9.org/showthread.php?p=755603#post755603

both answers taken from http://forum.doom9.org/showthread.php?t=104178&page=1&pp=20
which you started.

jdobbs

3rd January 2006, 02:16

I'd just comment that if anyone is having good luck with any setting -- feel free to stick to it. The reason the settings are there is so you can use them.

You have to realize, though, that the product defaults have to be conservative so they work for the widest audience and with the widest range of sources. If you individually set it low and it has no problem -- that's the end of it -- you're happy, and if you have a problem or run into a source that looks bad -- you'll just change it back.

If the default is set too low, though -- and a few thousand people try it... I guarantee someone will have problems with it -- and I'm the one who will get the e-mails with the complaints.

The defaults are the best settings for most people, on most discs, under most circumstances.

dragongodz

3rd January 2006, 02:31

If you individually set it low and it has no problem -- that's the end of it -- you're happy, and if you have a problem or run into a source that looks bad -- you'll just change it back.
and may i add - you wont complain about DVD-RB if you do have a problem by changing it to a non default value. :sly:

If the default is set too low, though -- and a few thousand people try it... I guarantee someone will have problems with it -- and I'm the one who will get the e-mails with the complaints.
very true and what people tend to forget. i am sure you get frustrated enough reading emails and posts where people are using everything default without adding ones where people have been playing with things aswell. ;)

Mr. Monte

3rd January 2006, 02:55

Dragon,

While I respect you and jdobbs and MANY others here..for me anyway...I am just not content with if it works and looks good..leave it. I aspire to learn and make things the best I can..even if I can;t "see" the result difference...but it can be proved with tools.

Isn't that why some of the defaults have changed since DVD-RB 0.01 (joke..first ever release)?

Isn't that why Rockas and Feedback, Shark and many others have like 50 or more Matrices for different bitrates and different material?

Our backup's might look fine now on this TV..but what if we get a 500 inch SED super-duper-out-of-this-world Monitor..(another joke)..IOW is there anything wrong with asking what these different settings would do if you di this?..or that..and what would be the downfall?

No I know...some would say..well move that slider and try it yourself...O.k..and it might look fine to me..but a more authoritve figure with a better grasp on the subject coudl look at my "clips" with whatever tools they use and say..but your I_Frames are low and the B-Frames are unstable and the bitrates are this..etc..etc..

I hope you understand some of what I am trying to get across to everyone in this thread..I love DVD-RB...matter of fact I has donated more than once..it awesome and I feel I have progressed from the "one-click" world of only using DVDShrink..alot because of this forum...but I want to continue to progress...without having a masters in A/V.

Thanks to jdobbs for his great explaination of the two sliders.

Thanks to all

raquete

3rd January 2006, 04:02

how nice and still.newbys can't joke with advanced users but....i read your signature. :p
why that big resistence for new ideas and tests?!?!? if and when someone get problems with this "adjusts" will post it faster i can trust!
quoting your own words (http://forum.doom9.org/showthread.php?p=755541#post755541) as i remember it was mentioned long ago that when the minimum video bitrate was below about 300....
now myself: the issues with low min_bitrate is now history,are in our old encodes... if you search i'm right that you always will get issues with low min_bitrates in old threads doing svcds,vcds,etc(i posted the reasons)
:thanks:

I'd just comment that if anyone is having good luck with any setting -- feel free to stick to it. The reason the settings are there is so you can use them. great developer create great program and is open to news. :thanks:

...your last post... :thanks:
great post!

dragongodz

3rd January 2006, 04:26

I am just not content with if it works and looks good..leave it. I aspire to learn and make things the best I can.
and you have the ability to do that already. however suggestions that it(min bitrate) should be changed to 0 since most people dont have a problem is a different thing. especially where there have been cases of both players and certain versions of CCE(for example) that have had a problem with it.

if you search i'm right that you always will get issues with low min_bitrates in old threads doing svcds,vcds,etc(i posted the reasons)
and it has been a problem with dvds aswell not just vcd/svcd. ever think that maybe its older threads may be because we know about the problem so try to avoid it ? for example hank315's min bitrate hard coded etc.

so to end from me, as said several times now - you can already change settings such as min bitrate so go ahead if you wish. however please do not say just because you dont have a problem others wont either and dont complain there is a problem with DVD-RB from any problems caused by changing such settings that cant be reproduced with the default settings aswell.

HKT3020_1

4th January 2006, 21:30

@Jdobbs

I just recently encoded Toy Story R1 10th Anniversary Edition DVD and the output was smaller than usual. At times I would get 4.31-4.33GB but today for some odd reason it came at 3.73GB. I had backed up a season disc prior to backing up Toy Story and that came out fine at 4.33GB. Any suggestions, I have DVD-RB at thier default settings. The only setting that was altered was the VBR Bias set to 20. :rolleyes:

Here is the log, if it'll help. :D

[10:05:37] Phase I, PREPARATION started.
- CCE SP 2.70.2.4 encoder selected.
- VTS_01: 2,285,486 sectors.
-- Scanning and writing .D2V & .AVS files
-- Processed 116,027 frames.
-- Building .AVS and .ECL files
- Reduction Level for DVD-5: 92.4%
- Overall Bitrate : 8,304/6,643Kbs
- Space for Video : 3,924,190KB
- HIGH/LOW/TYPICAL Bitrates: 6,926/1,864/6,643 Kbs
[10:09:00] Phase I, PREPARATION completed in 4 minutes.
[10:09:00] Phase II ENCODING started
- Creating M2V for VTS_01 segment 0
- Creating M2V for VTS_01 segment 1
- Creating M2V for VTS_01 segment 2
- Creating M2V for VTS_01 segment 3
- Creating M2V for VTS_01 segment 4
- Creating M2V for VTS_01 segment 5
- Creating M2V for VTS_01 segment 6
- Creating M2V for VTS_01 segment 7
- Creating M2V for VTS_01 segment 8
- Creating M2V for VTS_01 segment 9
- Creating M2V for VTS_01 segment 10
- Creating M2V for VTS_01 segment 11
- Creating M2V for VTS_01 segment 12
- Creating M2V for VTS_01 segment 13
- Creating M2V for VTS_01 segment 14
- Creating M2V for VTS_01 segment 15
- Creating M2V for VTS_01 segment 16
- Creating M2V for VTS_01 segment 17
- Creating M2V for VTS_01 segment 18
- Creating M2V for VTS_01 segment 19
- Creating M2V for VTS_01 segment 20
- Creating M2V for VTS_01 segment 21
- Creating M2V for VTS_01 segment 22
- Creating M2V for VTS_01 segment 23
- Creating M2V for VTS_01 segment 24
- Creating M2V for VTS_01 segment 25
- Creating M2V for VTS_01 segment 26
- Creating M2V for VTS_01 segment 27
- Creating M2V for VTS_01 segment 28
- Creating M2V for VTS_01 segment 29
- Creating M2V for VTS_01 segment 30
- Creating M2V for VTS_01 segment 31
- Creating M2V for VTS_01 segment 32
- Creating M2V for VTS_01 segment 33
- Creating M2V for VTS_01 segment 34
- Creating M2V for VTS_01 segment 35
- Creating M2V for VTS_01 segment 36
- Creating M2V for VTS_01 segment 37
- Creating M2V for VTS_01 segment 38
- Creating M2V for VTS_01 segment 39
- Creating M2V for VTS_01 segment 40
- Creating M2V for VTS_01 segment 41
- Creating M2V for VTS_01 segment 42
[11:02:12] Phase II ENCODING completed in 53 minutes.
[11:02:12] Phase III, REBUILD started.
- Copying IFO, BUP, and unaltered files...
- Processing VTS_01
- Reading/processing TMAP table...
- Rebuilding seg 0 VOBID 1 CELLID 1
- Updating NAVPACKS for VOBID_01
- Rebuilding seg 1 VOBID 2 CELLID 1
- Updating NAVPACKS for VOBID_02
- Rebuilding seg 2 VOBID 3 CELLID 1
- Updating NAVPACKS for VOBID_03
- Rebuilding seg 3 VOBID 4 CELLID 1
- Rebuilding seg 4 VOBID 4 CELLID 2
- Rebuilding seg 5 VOBID 4 CELLID 3
- Rebuilding seg 6 VOBID 4 CELLID 4
- Rebuilding seg 7 VOBID 4 CELLID 5
- Updating NAVPACKS for VOBID_04
- Rebuilding seg 8 VOBID 5 CELLID 1
- Updating NAVPACKS for VOBID_05
- Rebuilding seg 9 VOBID 6 CELLID 1
- Updating NAVPACKS for VOBID_06
- Rebuilding seg 10 VOBID 7 CELLID 1
- Rebuilding seg 11 VOBID 7 CELLID 2
- Rebuilding seg 12 VOBID 7 CELLID 3
- Rebuilding seg 13 VOBID 7 CELLID 4
- Rebuilding seg 14 VOBID 7 CELLID 5
- Updating NAVPACKS for VOBID_07
- Rebuilding seg 15 VOBID 8 CELLID 1
- Updating NAVPACKS for VOBID_08
- Rebuilding seg 16 VOBID 9 CELLID 1
- Rebuilding seg 17 VOBID 9 CELLID 2
- Rebuilding seg 18 VOBID 9 CELLID 3
- Rebuilding seg 19 VOBID 9 CELLID 4
- Updating NAVPACKS for VOBID_09
- Rebuilding seg 20 VOBID 10 CELLID 1
- Rebuilding seg 21 VOBID 10 CELLID 2
- Rebuilding seg 22 VOBID 10 CELLID 3
- Rebuilding seg 23 VOBID 10 CELLID 4
- Rebuilding seg 24 VOBID 10 CELLID 5
- Updating NAVPACKS for VOBID_10
- Rebuilding seg 25 VOBID 11 CELLID 1
- Updating NAVPACKS for VOBID_11
- Rebuilding seg 26 VOBID 12 CELLID 1
- Rebuilding seg 27 VOBID 12 CELLID 2
- Rebuilding seg 28 VOBID 12 CELLID 3
- Updating NAVPACKS for VOBID_12
- Rebuilding seg 29 VOBID 13 CELLID 1
- Rebuilding seg 30 VOBID 13 CELLID 2
- Rebuilding seg 31 VOBID 13 CELLID 3
- Rebuilding seg 32 VOBID 13 CELLID 4
- Rebuilding seg 33 VOBID 13 CELLID 5
- Rebuilding seg 34 VOBID 13 CELLID 6
- Rebuilding seg 35 VOBID 13 CELLID 7
- Updating NAVPACKS for VOBID_13
- Rebuilding seg 36 VOBID 14 CELLID 1
- Rebuilding seg 37 VOBID 14 CELLID 2
- Rebuilding seg 38 VOBID 14 CELLID 3
- Rebuilding seg 39 VOBID 14 CELLID 4
- Updating NAVPACKS for VOBID_14
- Rebuilding seg 40 VOBID 15 CELLID 1
- Updating NAVPACKS for VOBID_15
- Rebuilding seg 41 VOBID 16 CELLID 1
- Updating NAVPACKS for VOBID_16
- Rebuilding seg 42 VOBID 17 CELLID 1
- Updating NAVPACKS for VOBID_17
- Updated VTS_C_ADT.
- Updated VTS_VOBU_ADMAP.
- Updated IFO: VTS_01_0.IFO
- Updating TMAP table...
- Correcting VTS Sectors...
[11:11:52] Phase III, REBUILD completed in 9 minutes.

Done.
[11:11:52] PREPARE/ENCODE/REBUILD completed in 66 min.

jptheripper

4th January 2006, 21:35

since it only took 66 minutes, would you mind doing the exact same thing without changing the bias? that way we could rule it out.

also, was this a 1pass or 2

apfraats

4th January 2006, 21:51

I started this thread because I had the same problem ESPECIALLY USING 2.7.2.X encoder version. Of course, as usual (I'm used to that now :) ), some said it was me and just me again.....and did 80000+ DVD's without problems...

Sure if you try a 2.66/2.67.0.10 release, it is fixed again.

Hower since I started the post, more reports of undersizing using 2.7x.xx.xx were comming in in special cases.

I already said that in the same environment, the use of the 'older' version solves the undersizing problem seen and lukely noticed by others using 2.70.X.X versions.

That's weird isn't it ???

Sure DVD-RB does do the right calculations, because I suspect them NOT TO BE VERSION DEPENDENT as far as it concerns encoder versions.

It's just a sign CCE 2.70.x.x probably has a glitch somewhere somehow.

What I call now 'the CCE 2.70 undersizing bug' seems to happen in cicumstances were following two basic facts are true:

1) Compression level is pretty low, so percentage is high => 90%.
2) Average bitrate is high >= 5000 kbps.

Just try 2.66/2.67 and the problem will be gone (pleasse don't kill me if it doesn't :) !)

I set up different encoder versions in one directory such as:

CCTSPT2670010.EXE (for CCE 2.67.0.10)
CCTSPT2700204.EXE (for CCE 2.70.2.4)

and you can easily compare the version specific behaviour.

I have already tried a full 100% cpmpression and a problem discs, and it even came out significantly smaller in size...... (adjusting CCETARGETSECTOR to very high oversized value, forcing DVD-RB to run at 100% compression).

Even setting MAX_BITRATE to 9000 didn't solve the problem.

So, I think it's CCE 2.70x specific and NOT DVD-RB's fault.

But maybe, just maybe, JDOBBS can find an answer for this problem, studying it at low level with the same source input.

I did a already MOVIE ONLY prepared disk (prepared with DVDSHRINK) from THE SKELETON KEY R2 PAL , and have experienced the precise same problem.

If you have signifivcant udersizing, you can raise youre CCETARGETSECTORS, but you risk at comming to a 100% compression level and DVD-RB is going to adjust it's TARGETSECTORS downwards to get same size as input size, but this will result in undersizing again.....

So there are two alternatives as far as I've seen:

1) Use 2.67.0.10 or so to do the backup, it will prob. come out ok in size.
2) Live with the undersizing you get at 100% compression level by raising CCETARGETSECTORS temporarely for that DVD.

Nothing else seems to work untill now....

jptheripper

4th January 2006, 22:46

"prepared with DVDSHRINK"

why are people doing this? is dvd-rb's movie only mode not working?

HKT3020_1

5th January 2006, 01:39

Well jptheripper, I went ahead and took your suggestion and ran it again (2-Passes) with DVD-RB's default values and once again it came out exactly as before 3.73GB. :confused: The picture quality looks good and I'll burn it regardless but was just wondering why this was happening.

[17:01:35] Phase I, PREPARATION started.
- CCE SP 2.70.2.4 encoder selected.
- VTS_01: 2,285,486 sectors.
-- Scanning and writing .D2V & .AVS files
-- Processed 116,027 frames.
-- Building .AVS and .ECL files
- Reduction Level for DVD-5: 92.4%
- Overall Bitrate : 8,304/6,643Kbs
- Space for Video : 3,924,190KB
- HIGH/LOW/TYPICAL Bitrates: 6,926/1,864/6,643 Kbs
[17:05:11] Phase I, PREPARATION completed in 4 minutes.
[17:05:11] Phase II ENCODING started
- Creating M2V for VTS_01 segment 0
- Creating M2V for VTS_01 segment 1
- Creating M2V for VTS_01 segment 2
- Creating M2V for VTS_01 segment 3
- Creating M2V for VTS_01 segment 4
- Creating M2V for VTS_01 segment 5
- Creating M2V for VTS_01 segment 6
- Creating M2V for VTS_01 segment 7
- Creating M2V for VTS_01 segment 8
- Creating M2V for VTS_01 segment 9
- Creating M2V for VTS_01 segment 10
- Creating M2V for VTS_01 segment 11
- Creating M2V for VTS_01 segment 12
- Creating M2V for VTS_01 segment 13
- Creating M2V for VTS_01 segment 14
- Creating M2V for VTS_01 segment 15
- Creating M2V for VTS_01 segment 16
- Creating M2V for VTS_01 segment 17
- Creating M2V for VTS_01 segment 18
- Creating M2V for VTS_01 segment 19
- Creating M2V for VTS_01 segment 20
- Creating M2V for VTS_01 segment 21
- Creating M2V for VTS_01 segment 22
- Creating M2V for VTS_01 segment 23
- Creating M2V for VTS_01 segment 24
- Creating M2V for VTS_01 segment 25
- Creating M2V for VTS_01 segment 26
- Creating M2V for VTS_01 segment 27
- Creating M2V for VTS_01 segment 28
- Creating M2V for VTS_01 segment 29
- Creating M2V for VTS_01 segment 30
- Creating M2V for VTS_01 segment 31
- Creating M2V for VTS_01 segment 32
- Creating M2V for VTS_01 segment 33
- Creating M2V for VTS_01 segment 34
- Creating M2V for VTS_01 segment 35
- Creating M2V for VTS_01 segment 36
- Creating M2V for VTS_01 segment 37
- Creating M2V for VTS_01 segment 38
- Creating M2V for VTS_01 segment 39
- Creating M2V for VTS_01 segment 40
- Creating M2V for VTS_01 segment 41
- Creating M2V for VTS_01 segment 42
[18:00:29] Phase II ENCODING completed in 55 minutes.
[18:00:29] Phase III, REBUILD started.
- Copying IFO, BUP, and unaltered files...
- Processing VTS_01
- Reading/processing TMAP table...
- Rebuilding seg 0 VOBID 1 CELLID 1
- Updating NAVPACKS for VOBID_01
- Rebuilding seg 1 VOBID 2 CELLID 1
- Updating NAVPACKS for VOBID_02
- Rebuilding seg 2 VOBID 3 CELLID 1
- Updating NAVPACKS for VOBID_03
- Rebuilding seg 3 VOBID 4 CELLID 1
- Rebuilding seg 4 VOBID 4 CELLID 2
- Rebuilding seg 5 VOBID 4 CELLID 3
- Rebuilding seg 6 VOBID 4 CELLID 4
- Rebuilding seg 7 VOBID 4 CELLID 5
- Updating NAVPACKS for VOBID_04
- Rebuilding seg 8 VOBID 5 CELLID 1
- Updating NAVPACKS for VOBID_05
- Rebuilding seg 9 VOBID 6 CELLID 1
- Updating NAVPACKS for VOBID_06
- Rebuilding seg 10 VOBID 7 CELLID 1
- Rebuilding seg 11 VOBID 7 CELLID 2
- Rebuilding seg 12 VOBID 7 CELLID 3
- Rebuilding seg 13 VOBID 7 CELLID 4
- Rebuilding seg 14 VOBID 7 CELLID 5
- Updating NAVPACKS for VOBID_07
- Rebuilding seg 15 VOBID 8 CELLID 1
- Updating NAVPACKS for VOBID_08
- Rebuilding seg 16 VOBID 9 CELLID 1
- Rebuilding seg 17 VOBID 9 CELLID 2
- Rebuilding seg 18 VOBID 9 CELLID 3
- Rebuilding seg 19 VOBID 9 CELLID 4
- Updating NAVPACKS for VOBID_09
- Rebuilding seg 20 VOBID 10 CELLID 1
- Rebuilding seg 21 VOBID 10 CELLID 2
- Rebuilding seg 22 VOBID 10 CELLID 3
- Rebuilding seg 23 VOBID 10 CELLID 4
- Rebuilding seg 24 VOBID 10 CELLID 5
- Updating NAVPACKS for VOBID_10
- Rebuilding seg 25 VOBID 11 CELLID 1
- Updating NAVPACKS for VOBID_11
- Rebuilding seg 26 VOBID 12 CELLID 1
- Rebuilding seg 27 VOBID 12 CELLID 2
- Rebuilding seg 28 VOBID 12 CELLID 3
- Updating NAVPACKS for VOBID_12
- Rebuilding seg 29 VOBID 13 CELLID 1
- Rebuilding seg 30 VOBID 13 CELLID 2
- Rebuilding seg 31 VOBID 13 CELLID 3
- Rebuilding seg 32 VOBID 13 CELLID 4
- Rebuilding seg 33 VOBID 13 CELLID 5
- Rebuilding seg 34 VOBID 13 CELLID 6
- Rebuilding seg 35 VOBID 13 CELLID 7
- Updating NAVPACKS for VOBID_13
- Rebuilding seg 36 VOBID 14 CELLID 1
- Rebuilding seg 37 VOBID 14 CELLID 2
- Rebuilding seg 38 VOBID 14 CELLID 3
- Rebuilding seg 39 VOBID 14 CELLID 4
- Updating NAVPACKS for VOBID_14
- Rebuilding seg 40 VOBID 15 CELLID 1
- Updating NAVPACKS for VOBID_15
- Rebuilding seg 41 VOBID 16 CELLID 1
- Updating NAVPACKS for VOBID_16
- Rebuilding seg 42 VOBID 17 CELLID 1
- Updating NAVPACKS for VOBID_17
- Updated VTS_C_ADT.
- Updated VTS_VOBU_ADMAP.
- Updated IFO: VTS_01_0.IFO
- Updating TMAP table...
- Correcting VTS Sectors...
[18:10:21] Phase III, REBUILD completed in 10 minutes.

Done.
[18:10:21] PREPARE/ENCODE/REBUILD completed in 69 min.

jptheripper

5th January 2006, 02:00

for two passes it just seems so fast.. but since you video looks good (so it isnt an avisynth error) something else is going on.

the only other thing i noticed is the bitrates are very very high, the video must be very short. You may have maxed out your q value

therat

5th January 2006, 03:32

Maybe the undersizing has to do with the particular DVD. I am using DVDRB 1.05.2 with CCE 2.70.2.0 and i just finished backing up a dvd I created of a TV concert.

The original DVD was created by DVDAuthor and was 5.5gigs in sze. DVD-RB created a nice backup 4.31 gigs in size.

I have all settings set to default

jdobbs

5th January 2006, 05:15

Unfortunately if it undersizes the problem would have to be within CCE, which is out of my control.

raquete

5th January 2006, 15:08

"prepared with DVDSHRINK"

why are people doing this? is dvd-rb's movie only mode not working?

for RB free version users.

Cropsy

5th January 2006, 19:09

I started this thread because I had the same problem ESPECIALLY USING 2.7.2.X encoder version. Of course, as usual (I'm used to that now :) ), some said it was me and just me again.....and did 80000+ DVD's without problems...

If this is ment for me I just have to say that I was not hostile nor did I brag about my 800-900 encodes. I just said that I believe that some discs may come out undersized for some reason I don't understand. Maybe that's just the way it is. I have never said anything about "it is only you".

Just wanted to clear the air:D

Boulder

5th January 2006, 19:49

Would it be possible that the encoder actually saturated and couldn't use more bits?

winny

5th January 2006, 20:10

jdobbs

5th January 2006, 20:39

Would it be possible that the encoder actually saturated and couldn't use more bits?Not only possible -- but highly probable. 6,600Kbs is a LOT of bandwidth. CCE will not add bitrate for the sake of bitrate. When it maxes out you have to assume that the Q is so low that adding more won't help.

Boulder

5th January 2006, 21:36

If that is the case here, I'd use LimitedSharpen ;)

Mr. Monte

5th January 2006, 22:35

Unfortunately if it undersizes the problem would have to be within CCE, which is out of my control.

Except maybe the OPV feature ... correct?

You may need to tweak the setting for this correct?

jdobbs

6th January 2006, 00:56

You can always tweak OPV -- but it is inherently inaccurate, so if you tweak it in the positive direction a little there is always a chance that on another disc is will be slightly over. I'm thinking of adding a "correction" mechanism that will use ReJig to bring it into line if it goes a little over.

HKT3020_1

6th January 2006, 01:28

For the Toy Story example above which audio tracks are being kept? I'm intrigued why the available size for video is so high.

- Reduction Level for DVD-5: 92.4%
- Overall Bitrate : 8,304/6,643Kbs
- Space for Video : 3,924,190KB
- HIGH/LOW/TYPICAL Bitrates: 6,926/1,864/6,643 Kbs

Reducing 3,924,190 by 92.4% is not far off your final output size if there were no audio tracks.

The DDEX 5.1 track was what I kept, leaving out the English 5.1 DTS, English, French and Spanish 2.0. I suppose another alternative is to edit the DVD and keep the DD English 2.0 track and have the video untouched. I doubt my younger sibling will notice the difference between DDEX & DD 2.0. :D

TECK

6th January 2006, 05:04

With CCE SP 2.70.02.04 Trial, there is no undersize. I just did the movie Batman Begins (NTSC) today... it came perfect.
I used:
CCE=3
CCETargetSectors=2260000

in Rebuilder.ini file. The movie came out at 4696MB, just 10MB under the limit.
All the movies I do with the CCETargetSectors value listed above come close to this, never over 4706MB.

Here it is the .ini file for the Batman Begins movie:
[Options]
CCE=3
CCETargetSectors=2260000
SkinVersion=10
Skin=Teck Original
AudioDub=0
LogFile=0
QuEncHQ=0
QuEncodeType=0
iDCT=3
GOP=0
DCPrec=0
MainMatrix=Encoder Default
LowMatrix=Same as Main Feature
VLowMatrix=Same as Main Feature
ExtraMatrix=Same as Main Feature
HC_Quality=1
ProCoder_Quality=4
ReduceOpt=0
DVD_Label=BATMAN_BEGINS
DVD_Name=BATMAN_BEGINS.ISO
MovieOnly=1
HalfD1=00
Convert_16_9=00
DisableInterlace=00
ConvertToYUY2=1
ITU_Aspect=1
EncoderMinimized=1
RemoveDC=1
OneClick=1
NoWarn=1
AdditionalOutput=1
ISO_Output=1
ISO_Delete_Option=0
Decrypter_Write=0
Delete_Image_Option=0
Completed=1
[CCEOptions]
VBR_bias=25
Quality_prec=16
eclPasses=2
[Audio]
Selected=1
Remapping=
[Subpictures]
Selected=1
EDIT: One detail I forgot to mention, I never got an undersize issue with any CCE version.

TECK

6th January 2006, 05:20

HKT3020_1

7th January 2006, 05:29

HKT3020_1, something is definitely wrong in your configuration. A movie like that done in 69min??? My Batman took 120min on a 3.2 HT processor.
Are you running a farm? Curious... If yes, lucky you. :)

Like you I'm also no a 3.2 P4 machine and not running anything else with DVD-RB, I try to avoid all possibilities of potential headaches. :D Toy Story is only a 81 minute movie so that would answer the short encode time. I'm usually not around when DVD-RB is creating a backup but according to my recent logs, it usually takes no longer than 100 minutes for a full backup. :)

apfraats

7th January 2006, 21:11

Just to point out:

1) This undersizing problem is REAL
2) It doesn't happen with all DVD's
3) In cases were it happens there are high bitrates and low compression reported.
4) It's an typicall 2.70.X.X 'feature'
5) It has nothing to do with DVD-RB
6) The problem is gone with CCE 2.66/2.67.
7) JDOBBS is wrong about 'saturation', because 2.66/2.67 don't have this problem.
8) We have to live with it, it's an CCE 2.70 feature.
9) You can do a 100% compression job, it will give larger output, but even then it can be undersized.
10) Quality of result, despite underzizing, is good.
11) We just have to live with it.

So clearly a typical 2.70.x.x issue, for sure.

Don't ask JDOBBS about it, because CCE is the target here....

But an 'saturated' bitrate doens't exists in DVD-land.

If you set average bitrate for cells a bit higher (with RB-OPT) , output comes out larger. I already tried that. So there is nothing like a 'saturated bitrate'.

A bitrate can be forced to be 9500 Kbps if you wish. Just use CBR (VBR_BIAS=100 IIRC) and set cell average to 9500.

You sure get oversized output in that way (if movie lasts long enough and that will be in the most cases).

The only restriction is:

totalbitrate (including all audio/subtitl./video)=<10.08 Mbps * time in seconds.

So you cannot fill a DVD with just 1 minute video at highest bitrate.

That's because of the DVD-SECS and not of any 'saturation'.

A 'saturation' doesn't exists.

I can encode a black picture stream at 9500 kbps if I want using CBR.

So there is no 'saturation'.

We have to live with it, as it seems to be erronous encoder behaviour in certain cicumstances. Lukey it's underzizing, NOT OVERSIZING, as that would be more problematic.

If you don't wanna have this undersizing just use 2.5 or 2.6X versions of CCE.

But it only seems to occur verry rarely so I gonna keep using 2.70.2.4 as it's faster, has a better encoder engine and hasn't problem 99,X % of the cases.

In the case I get this undersizing issue, I set DVD-RB targetsectors higher and try to get the most out of it.

'Saturated bitrate' also doens't exists, or the original could not be the original in these rare cases.

As long as you do not reach (MAX_TOTALBIRATE*TIME) there is always room for more bitrate......... definitely..

jdobbs

7th January 2006, 21:19

Please don't start making statements until you understand the facts. Saturation DOES exist. It has been proven repeatedly. You speak as if everything that leaves your mouth is coming from the burning bush....

To quote Shakespeare "There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy".

The saturation has NOTHING TO DO WITH BITRATE. It has EVERYTHING TO DO WITH Q.... and it is related to CCE, not to DVD standards. It is related to VBR not CBR. CBR is very definitely NOT VBR!!! If you knew the difference, you wouldn't argue this point.

And one more point. Could you please try writing, just once, a post that will fit on one page?

Boulder

7th January 2006, 22:51

Yep, there is saturation. No matter what matrix you use, some sources do not use the bits you wish to allocate. Even at q1, the avg bitrate will be less than is desired. This is a well-known issue with MPEG4 codecs and MPEG2 isn't that different from them. The solution is to either live with it, make the source less compressible or use a matrix that quantizes less. I would choose option 3 first, then the rest.

Just try encoding something at q1 with HC and you'll see that the bitrate doesn't hit the max all the time.

Trahald

8th January 2006, 15:51

testing it with cbr doesnt work. mpeg-1/2 with cbr will pad out the difference to obtain the desired bitrate. this is done since generally when cbr is used falling below bitrate would cause flow problems (either from dvd/cd drive as with VCD or perhaps a streaming source.)

the only way to find out that a stream will undersize (saturate) is to run a vbr encode and then if its under-sized taking addition time to encode it in cbr. that is totally useless since the quality will only be at best AS good and even possibly worse in high demand sections than the smaller vbr encode.

apfraats

8th January 2006, 16:13

Keep youre horses, ok, maybe saturation exists, but I mean it is not an explanation for undersizing as 2.70.X should be saturated and 2.66 not with the same source ??? Nope... I don't think so.

So if it exists indeed it would have nothing to do with bitrate, so nothing with indersizing also, and you JDOBBS used it as argument for undersizing...

Q=1 ???

Not with the sources I've seen, nore with the results when using FULL VBR.

This thread was about undersizing, so if you mention SATURATION is probably the course, you have to put somoe more evidence to the scene.

I interpreted staturation as 'No more bit's are needed to improve quality'.

If it's an official term, sorry it's the first time I hear of it in this context.

So forgive me my ignorence, but still it isn't a reason for the undersizing, and that was were it all was about....

And this is NOT a page long.

Maybe a larger monitor would do the job :D

By the way, setting higher averages leaves larger result.

So it is not saturation here, or it would make no difference.

jptheripper

8th January 2006, 16:24

full vbr has nothing, and is probably inversely related to, q

full vbr is very bad for the encoder, it may alot many more bits where needed but it fails to alot bits properly (as you are seeing)

please do the same test with 2.7 but at defaults (vbr, q, etc..) i am resonably sure it wont undersize

apfraats

8th January 2006, 16:50

Some already reported undersizing with default settings....., I have tried also 'normal' settings, but NO it doesn't help.

The only thing that helps is using 2.66 instead of 2.70.x.x, and then the 'exact' targetsectors are reached.

I disagree about FULL VBR, a setting I always use.

Have the best results with it, so I won't stop using it. At least not in combination with CCE that behaves perfectly in FULL VBR.

Theoretically is the best way to dirstrubute bits in lesser room.

What's needed is used, what's not needed is not used.

As we deal with compression 100% of the times here (Why bother using DVD-RB else ?) it's the far most optimal setting if the encoder can handle it perfectly. CCE can, so why not use it ???

Since I used MIN_BITRATE=0 and VBR_BIAS=0 , results are much much better in compressions with lower averages.

No macroblocking anymore, although a 3 hour constant action movie with DTS and 5.1 DD is simply almost impossible to squeeze to a 4.35 GB DVD-5.

But everybody has the right to use their own 'optimízed' or prefered settings. That's the beauty of parameters, matrices, filters.

jdobbs

8th January 2006, 16:59

No one is arguing that CCE 2.70 doesn't have a sizing accuracy problem. I'm pretty confident it does. It just seems to be rare and on certain types of sources -- and I haven't seen the correlation between type and result yet. I only responded to your claim a few posts ago that "saturated bitrate does not exist" -- which is absolutely incorrect.

Your problem is that you're trying to come up with a "one size fits all" reason from undersizing. I'm telling you that one reason is saturation. Another is the fact that DVD-RB will not allow bitrates higher than the original. The CCE 2.70 output accuracy problem is just one more.

apfraats

8th January 2006, 22:22

Ok, I have mistakenly interpreted it, but It looked youre were pretty sure about it being the problem. No offense at all.

If it were due to saturation do you agree that:

1) Sizing UP targetsectors won't help in any way because of saturation (using FULL VBR, MINIMUM_BITRATE=0, MAX_BITARE=9000) ??

This is asked because setting a larger CCETARGETSECTORS yields a LARGER result with my problem DVD but I couldn't go towards reaching 4.35 GB, because DVD-RB decides to stop at 100% and probably adjusted CCETARGETSECTORS down towards SOURCESECTORS.

Correct me if I''m mistaken.

2) The limitation of MAX_SEGMENT_BITRATE by source I didn't like from start. So I always set it to 9000 , if not lower as the critical 10.08 mbps is gonna be reached, taking room for error in account.

I still don't see the use of this limitation as filters, matrices, different encoders can be expected to have total different charasteristics and why should a compression not have temporary spikes above source ?

Limiting it is usefull if encoding artificacts, I agree, but the limitation should be something to switch off in advanced settings for using correct sources and different encoders, which easily can behave differently and need this higher than source bitrate, due to matrices, filters, whatever reason.

For example sharpening or playing with contrast/brightness levels could simply demands a higher bitrate at a place.

Of course never TOTAL_MAXBITRATE must be exceeded....

Now I use RB-OPT to prevent DVD-RB from limiting bitrate.

However I notice that DVD-RB does NOT completely follows source, it still does use a max of 9000, even if source is going above (not it will hurt that much).

(I noticed this in different encodes having a 5.1 track only)

Well, the DIG.TV here 'just' uses CBR 6750 kbps.........

jdobbs

8th January 2006, 22:52

1. Incorrect. Bitrate is applied by segment. So changing TARGET_SECTORS will change the target size of all segments, not just the ones that are saturated.

2. You can do whatever you want with your source... but I wouldn't recommend it as a practice to the general population. There are other good reasons why I added it as well.

3. Setting the maximum bitrate to 9000 when DVD-RB recommends otherwise is a bad practice in all but CBR sources. But like I said -- it's your backup and you can do whatever you want with it... but, again, DVD-RB does things for a reason. When you bypass it's settings or override them with another package -- you also surrender your right to complain!

I suspect all these "customizations" you are performing after the fact may contribute to why you seem to see more undersizing than most do. But that's just speculation.

apfraats

9th January 2006, 11:25

Thanks JDOOBS,

1) I get it, yep, NOT ALL SEGMENTS ARE SATURATED.
You should be able to find the SATURATED SEGMNETS because they should have a lesser average then DVD-RB assigned to them ?

2) That MAX_BITRATE is the problem, I am talking about longer, because here in R2 a lot of movies have CBR.
To prevent a user from making mistakes, is precisely the REASON why it should be a user-defined setting. That's all I ever asked for.

So you could set: Limit to source bitrate: Y/N ?

Default: Y
In template: Y

If you set it to NO, then DVD-RB comes in and is going to calculate for you (on a per segment base):

10.08-(room for error)-(bitrate needed for suntitling/audio)= LIMIT FOR SEGMENT.

So then I'm satisfied with my CBR sources and I CANNOT make mistakes.

I don't see why this is so hard to do , because it was this way in older versions of DVD-RB IIRC.

So ALWAYS DVD-RB makes the decision for you.

When it goes wrong using it this way, I CAN BLAME YOU :D :D

But seriously, now I have to do manual calculations, I can make mistakes and all this calculation is already present in DVD-RB (or was at least).

So just choosing between: LIMIT BY SOURCE or LIMIT BY CALCULATION or whatever you call it, is simply more user-freindly for me as it saves me from making mistakes and doing manual calculations.

There is quit a lot of CBR stuff here. The latest was having 5500 CBR !!.

And my DVD and HDD-recorders use CBR as far as I know.

So that option would be really nice and helpfull. If it's implemented it has the major advantages:

1) Not having to adjust things manually.
2) Not making ERRORS
3) Not using not JDOBBS approved software tools :D

(remeber CCE 2.70.2.4 support ? oh boy.....:) )

And the undersizing: Like I always have:

1 DVD uptill now, and of course the very FIRST one using 2.7.x.x.
That was THE SKELETON KEY, and that problem was acknodledged by someone else.

I have tried about 25 now, and have no problem at all despite my settings. Because if there is someting wrong I always try the first and only thing before starting to make a statement:

Doing the thing with DEFAULT SETTINGS AND NO USER INTERVENTION IN ANY WAY (i'm not THAT stupid anymore :o ).

jdobbs

9th January 2006, 13:05

I think most realtime recorders use VBR. CBR use should be very limited. VBR always provides a better picture -- even if it only distributes across a small section of buffer.

Hmmm.... I think I'll test my recorder later...

[Edit] Just looked at the bitrate on a home video recorded by my realtime DVD recorder. As expected it is VBR -- and also as expected the range between high and low is much less than you'd get on a full analysis VBR encode. The recording peaks at about 4900Kbs and bottoms out at about 3100Kbs in 2 hour mode.

winny

9th January 2006, 14:55

@apfraats. What was the response from Cinemacraft support about the problem, as you stated early on the problem has nothing at all to do with Rebuilder.

Changing the default Rebuilder settings seems to be treating the symptom rather than finding a proper cure (to misquote the infamous 'aspirin management' technique spouted by executives).

I applaud anyone as committed as you are to finding a solution, but try not to overuse your CAPS LOCK key to hammer home your point to people with experience on their side, it just looks rude.

Cropsy

12th January 2006, 12:29

I made an encode that gave me 4.12G. It is the scandinavian release of Amityville horror 2005 released by Scanbox. It is protected by Macrovisions Ripguard system. I used fixvts to clean the vobs first.
I tried to change to cce 2.67.0.23, and it gave me an output of 4.20G with the same settings. I will try 2.67.0.10 later.
I use 3 passes and ccetarget set to 2255000.
The 2.70.2.0 used a total of 131 min, and 2.67.0.23 used 124 min. including creating an ISO.

HKT3020_1

13th January 2006, 12:53

With CCE SP 2.70.02.04 Trial, there is no undersize. I just did the movie Batman Begins (NTSC) today... it came perfect.
I used:
CCE=3
CCETargetSectors=2260000

in Rebuilder.ini file. The movie came out at 4696MB, just 10MB under the limit.
All the movies I do with the CCETargetSectors value listed above come close to this, never over 4706MB.

Just a note to those who alter the CCETargetSectors to 2260000, for the most part it works well with movies that average in at about 120 minutes but recently I ran Braveheart R1 DVD (177m) and it came in at 100.2% full for a DVD5 disc.:sly: I had to edit the credits to get it down to size to fit properly. I ran Movie & Menu mode keeping audio track #1.

I made an encode that gave me 4.12G. It is the scandinavian release of Amityville horror 2005 released by Scanbox. It is protected by Macrovisions Ripguard system. I used fixvts to clean the vobs first.
I tried to change to cce 2.67.0.23, and it gave me an output of 4.20G with the same settings. I will try 2.67.0.10 later.
I use 3 passes and ccetarget set to 2255000.
The 2.70.2.0 used a total of 131 min, and 2.67.0.23 used 124 min. including creating an ISO.

Take note that from the previous 2 ripguard DVDs I've purchased in the past, there was a 600-700MB blank PGC found in the Video Manager when browsing with DvdReMake and found in the VIDEO_TS.VOB file when using VobBlanker.

kmac61

13th January 2006, 15:34

i just wonder why apfraats is still using trial versions of ccesp while seeming to have every version since the dawn of time
CCTSPT2670010.EXE (for CCE 2.67.0.10)
CCTSPT2700204.EXE (for CCE 2.70.2.4)
If the logo doesn't bother you why complain about a slight undersize or
if you're using a patched version then this thread is violating the spirit of rule6

raquete

13th January 2006, 18:50

@ kmac61
everyday i search this thread to read.
i'm using the trial CCTSPT2700204.EXE too.the logo bore me but more the undersize like apfraats and sometimes oversize(sometimes) with this version.without logo the problem exist too.i think that apfraats bore more with undersize than with logo because when don't have under or oversizes problems,we can buy the full version.(i will).
i can't comment about "if you're using a patched version then this thread is violating the spirit of rule6",for my taste is strange to read words that don't was wroten(i read the whole thread and don't saw anything about it)...."if" is only conditional/imagination against who is posting about this cce version and not against RB! let the ball roll kmac61,all issues found about cce are true,we can't argue against legality,let the mods do that,they are "sensitives" and will close the thread if we start to post what is off topic.

jptheripper

13th January 2006, 19:23

my main issue is if you send the same script to 3 different cce's you get 3 different sizes. The most jdobbs can do is try and make sure things are right on his end. They are for 90% of users (made up but likely close statistic). the rest are likely cce issues, and therefore dont belong in this forum. the belong in the encoder forum, thats what it is there for.

I have a suspicion that incorrect avisynth and dgdecode versions may also be a source, in which case it is an installation error (user error) not a bug.

jdobbs

13th January 2006, 19:33

All I can comment upon is my own experience. Which is that I use CCE Basic v2.70.01.07 and CCE SP v2.20.01.05 (Trial) and I get the exact same size within 1% every time I run it.

jptheripper

13th January 2006, 19:42

i am the same

cce 2.5 and cce 2.67 and 4.30-4.32 everytime

Cropsy

13th January 2006, 21:11

OK. Here I go again.
Still working with the Amityville horror 2005 scandinavian release

I tried it with 2.50.1.0 and the result is 4.17G.
Then with 2.67.0.10 and it came out 4.20G.
And last I tried it with the latest HC that came with the installer, and it came out 4.21G in the best quality mode. HC used 162 min.

Maybe it is like HKT3020_1 said, that Ripguard is the bad guy here. Even though I cleaned the vobs with vtsfix first?

jdobbs

13th January 2006, 23:08

I don't think so. How could it randomly choose who it decides to affect?

Tell me this:

1. What version of AVISYNTH are you using?
2. What version of DGDECODE?
3. What happens if you don't do "FixVTS" first? (I've never used it and have never had a failed backup).
4. Are you doing any other preprocessing?
5. Are you using any other tools, like Matrix editors etc?
6. Are you using OPV?
7. Movie Only modes?
8. What is the overall bitrate shown by DVD-RB in the prepare phase? How about HIGH/LOW/TYPICAL?

Cropsy

14th January 2006, 16:07

Hi jdobbs

1. AVISYNTH 255
2. The one that comes with the installer, dated 21.1.2005
3. Haven't tried that yet. I will do so later today.
4. Yes and no. (tried both)
5. No
6. No
7. Whole disc and movie and menues
8. HIGH/LOW/TYPICAL Bitrates: 7*104/400/6*235 Kbs

Last night I increased the targetsectors to 2295000 and tried it with 2.70.2.0 again and it came out 4.12G

And just finished movie and menues only and it came out 4.20G with 2.70.2.0 wich is the biggest I got with 2.70.

It is now running without using fixvts, so I will be back with the result later.

jdobbs

14th January 2006, 18:09

Based upon your bitrates, I think what you are experiencing is CCE bitrate saturation. CCE seems to only allow the bitrate to rise to the point at which it has determined it has done a "perfect" representation. So some of the segments will not increase in size beyond a set point.

So the bad news is you aren't going to easily make it any larger. The good news is that it wouldn't increase the quality of the picture, even if you did.

Remember that output size is not representative of quality. It often correlates -- but occasionally it doesn't.

Mr. Monte

14th January 2006, 19:42

So the bad news is you aren't going to easily make it any larger. The good news is that it wouldn't increase the quality of the picture, even if you did.

Remember that output size is not representative of quality. It often correlates -- but occasionally it doesn't.

Not to mention..the less you write to the outside of a DVD..the less possible playback errors. Most blank DVD's have higher errors near the end of the disk.

Cropsy

15th January 2006, 11:32

OK thank you jdobbs.

I'm not into the technical details at all. I'm just a regular user.
I'm glad that there was a natural explanation for this.:D
The version I did without preprosseing with fixvts also came out 4.12G with 2.70.

apfraats

15th January 2006, 17:58

But if the saturation question is in effect here, one might assume that using a VBR_BIAS of 100 (= constant bitrate) MUST give correct output resutls.

But as I tried this, even this is not the case, and the result quality you even don't wanna see.....

But assuming this is the case with 2.70.x.x is is a reason for DVD-RB to take this into account.

I know JDOBBS (don't take this seriously !!)

If there are suaturated segments, and this is noticed by DVD-RB is some way, THEORATICALLY it should be possible to spent more bitrate to segments NOT SATURATED, thus yielding a better result.

You then get something like a TWO PASS DVD-RB job.

In the first pass it can detect segments that are smaller then predicted, these are marked saturated. The whole process can be done again with newer parameters for the really compressed segments, so these get improved.

And the the OLD question comes up:

Doing the whole PGC in one-pass, oh boy, there we go again.

Then we have NO SATURED SEGMENTS anymore....

CCE will automatically spread the bitrate on a needed base concerning the WHOLE chain, and not just the segments.

As no other encoders seem to have this problem we also could make the statements that CCE 2.70.x.x is one of the best, if not THE BEST encoder.

It's simply won't spend bitrate where it isn't needed.

But still segments that are not saturated are NOT COMPRESSED IN THE BEST POSIBBLE QUALITY because we waste space....

That's because of the SEGMENT LEVEL in which DVD-RB operates.

But let's be honest all together, how many % of the compressions are really iundersized ???

Uptill now I have had two... out of 50 done do far..

jdobbs

15th January 2006, 18:17

This is going way overboard. Why do we want to spend all this time discussing something that doesn't improve the quality -- but only adds more bits to satisfy someone's "fill 'er up" obsession. Frankly I have better things to do with my time.

Setting a bias to 100 makes it more like CBR -- but doesn't make it CBR... so it would have little effect on saturated areas.

As for doing the entire PGC in one pass... you're ignoring lots of factors... it's been discussed -- it's a dead subject. No more, please.

Let's get on to something more important, ok?

raquete

15th January 2006, 20:32

Why do we want to spend all this time discussing something that doesn't improve the quality ........it's been discussed -- it's a dead subject. ...
Let's get on to something more important, ok? ok! :goodpost: :thanks:

Mr. Monte

15th January 2006, 20:40

Yea..like 1.06 <g>

apfraats

15th January 2006, 21:10

This is going way overboard. Why do we want to spend all this time discussing something that doesn't improve the quality -- but only adds more bits to satisfy someone's "fill 'er up" obsession. Frankly I have better things to do with my time.

I also told 'not to take it seriously'.

and said I didn't condsider it a real problem seen the percentage affected.

Although I still wonder what encoder 'the pro's' use to produce oversaturated segments in a stream.....

I also still wonder if CCE's decession to cut on bitrate is really based upon saturation or is faulty at this point.

As all other encoders seem not to have any problem with this, that would mean:

a) CCE 2.70 is at fault here....
b) Other encoders waste bitrate...

Seen the results of CCE 2.70.2.4 on difficult material using VBR_BIAS=0 and MIN_BITRATE=0, which are perfect even at 8* zoom (:D ), I suppose the quality of CCE is just still at TOP-LEVEL........

However concerning the MIN_BITRATE that still under heavy fire (I really don't know why, as other encoders even doens't have such a setting), I'll test soon with a complete BLACK movie. Just replace a 3+ hour movie in DVD_SHRINK with a complete black image. Also saturation will show up, because there is no need for bitrate in P,B frames.

jptheripper

16th January 2006, 00:57

wow, what a complete and utter waste of time (my opinion only). can we kill this thread? as it is going nowhere and producing nothing

apfraats

16th January 2006, 01:19

In youre opinion maybe.........

And of course youre the master of the universe....

Ignorance is not the same as knowledge.

winny

17th January 2006, 22:34

Ignorance is not the same as knowledge.

... and people in glass houses shouldn't throw stones.

Anyone who feels the merit in testing 3 hours of black movie go for it, I agree the point is lost on me too.

apfraats

18th January 2006, 01:02

Considering the intellectual level of youre post, I even don't gonna explain.

apfraats

18th January 2006, 01:10

And the good news so far:

Using blankclip(framecount) gives CCE complete saturation at bitrate of contantly 0.21 (210 bits/sec) and a Q of 1.

Because there is full saturation the result is ridiculously undersized.

And it plays great, seeing nothing but black and of course the audio track plays.

So no need for anybody not to use MIN_BIRATE=0, as CCE's lowest value is a bitrate of 0.21 kbps constantly on a black source.

VBR_BIAS=0. MIN_BITRATE=0.

And it even generates GOP strcuture that's perfectly having q=1 for all I,P,B frames.

Now running HC test. That indicates an even lower bitrate.

So anyone complaining about player compatebility problems with a MIN_BITRATE=0 settings and using CCE 2.70.2.4 has to try HC that doens't honor MIN_BITRATE and procduces even lower bitrates on black straems.

HC reports 184 bits/sec...... Checked M2V's so far and also have Q=1.

When this output of CCE is input for DVD-RB again, it reports a 'source compliant' bitrate of 11xx bits/sec.

Well that's not source-compliant (500% too much !) but I suppose JDOBBS can explain this.

BITRATEVIEWER also reports averages according to the encoder information of CCE. So why DVD-RB decides reporting an 11xx bits/sec is a complete riddle for me.

dragongodz

18th January 2006, 02:49

So no need for anybody not to use MIN_BIRATE=0, as CCE's lowest value is a bitrate of 0.21 kbps constantly on a black source.
So anyone complaining about player compatebility problems with a MIN_BITRATE=0 settings and using CCE 2.70.2.4 has to try HC that doens't honor MIN_BITRATE and procduces even lower bitrates on black straems.
no what you need to do is give this constant pushing of "min bitrate = 0 is fine for all players" a rest. you have been told multiple times using a min bitrate of 300 fixed playback problems with a few dvd players irrelivant of if its not needed on yours. since anyone can change it to 0 if they wish please leave it at that and stop posting the same thing repeatedly.

oh and the fact that the encoders dont pad out that black stream doesnt mean the results will be fine on all players etc. you are trying to prove a point with an unnatural stream and how an encoder handles it, not how all dvd players will handle the produced streams, there is no relation. so PLEASE dont keep trying to find proof of what you think when you dont understand it.

hank315

18th January 2006, 13:18

I still don't see what you want to prove with this black frame movie.
HC that doens't honor MIN_BITRATE and procduces even lower bitrates on black straems.
HC calculates a minimum bitrate internally which is used to create a compression curve, that min. bitrate value has nothing to do with the actual minimum bitrate as it can appear in a stream.
If there's nothing to encode it will saturate even at Q=1.
In previous versions of HC padding was used to keep the bitrate above 400, that was dumped because it didn't work well with the last bitrate control algorithm and until now I didn't get any complaints about it.

The bitrate for black streams of HC will be a bit lower than CCE's bitrate, CCE always uses some padding (not only on black streams).

jdobbs

18th January 2006, 15:36

When this output of CCE is input for DVD-RB again, it reports a 'source compliant' bitrate of 11xx bits/sec. I have no clue what this means. DVD-RB doesn't check the MPEG input stream for source bitrate compliancy. The bitrates reported by DVD-RB are those it is passing to the encoder.

winny

18th January 2006, 18:42

... I even don't gonna explain.

No worries. If the above quote is anything to go by I wouldn't have been able to understand it anyways.

Have Cinemacraft responded to your support request yet? I would have expected them to have done by now, especially with the money they charge for the product.

jptheripper

18th January 2006, 18:57

In youre opinion maybe.........

And of course youre the master of the universe....

Ignorance is not the same as knowledge.

this was aimed at me I see.

And i can only assume you are the one chosing ignorance over knowledge, as the knowledgeable on this forum (jdobbs, etc..) have told you this is a saturation issue, and you have chosen to _ignore_ their knowledge. But hey, if you want a perfect 4.37gb blank video.. more power to ya. Just please stop wasting my time, and I assume the time of many others

apfraats

18th January 2006, 19:17

I have no clue what this means. DVD-RB doesn't check the MPEG input stream for source bitrate compliancy. The bitrates reported by DVD-RB are those it is passing to the encoder.

What I supposed to say , sorry not to be clear on this, is that you stated the max_bitrate DVD-RB is determing is depending on the max_birate found in the source segment (aka CELL).

In my back movie there is a constant bitrate of 210 at GOP-LEVEL, as usual BITRATEVIEWER makes a mess of this because it's trying to caclulate on a per second base. but the average is displayed ok.

So if I give the output that consists of constant 210 kbits/sec GOP's to DVD-RB again, and I do PREPARE, and look with RB-OPT it's reporting a MAX_BITRATE for the segments that all are equal and all are 210 kbits/sec GOPS of 1219 kbit/sec and for some segments 1220 Kbit/sec.

So what I want to say here is:

Input for DVD-RB consists of 210 Kbits GOPS constantly for over 2 hours.

DVD-RB assigns MAX_BIRATES of 1219 Kbits/sec after prepare !!!!!!

This is far too high and now I wonder what CAN happen in other cases....

JDOBBS , you told me the source was inspected as GOP-level and that bitrate determines the MAX_BITRATE for that segment.

But 120 Kbits source results DVD-RB in believing the max is 1219 Kbits/sec for a segment !!

That is simply impossible, or you have another explanation for this.

Simply I don't understand what's happeninmg here and expected a caculated max_bitrate of about 210 Kbits/sec or a little higher maybe but not a 500% difference !

That's my problem, and maybe you can explain.

For example it's possible you have a minimum implemented, I don't know.

Just experimenting and seeing what's happening.

It's 1219/1220 for ALL segments, and there are absolutely NO spikes whatsoever. I even tried DVD-LAB and it reported no peak bitrate over what was expected.

apfraats

18th January 2006, 19:24

I still don't see what you want to prove with this black frame movie.

HC calculates a minimum bitrate internally which is used to create a compression curve, that min. bitrate value has nothing to do with the actual minimum bitrate as it can appear in a stream.
If there's nothing to encode it will saturate even at Q=1.
In previous versions of HC padding was used to keep the bitrate above 400, that was dumped because it didn't work well with the last bitrate control algorithm and until now I didn't get any complaints about it.

The bitrate for black streams of HC will be a bit lower than CCE's bitrate, CCE always uses some padding (not only on black streams).

Thanks HANK, now I know that the statement of others that HC uses a minimum bitrate inernally is no longer true.....

So if youre encoder procudes lower bitrate and the Q was indeed perfectly 1 over the whole output, can you explain to me why CCE 2.70.2.4 produces undersized output probably due to q=1 sections and HC doen not ??

I would expect that knowing now what you stated about CCE that the underzizing of HC would even be more.

Biut with the sources I tried it wasn't so, there only CCE 2.70.2.4 was undersizing.

Thanx for explanation so far...

jdobbs

18th January 2006, 19:33

apfraats

18th January 2006, 19:35

No worries. If the above quote is anything to go by I wouldn't have been able to understand it anyways.

Have Cinemacraft responded to your support request yet? I would have expected them to have done by now, especially with the money they charge for the product.

Yes they answered, but only are concerned in bugs and they don't consider this a bug.

They also mention saturation and said the encoding engine was improved and totally different of that used in 2.66/2.67 versions of CCE.

They claimed that CCE 2.70.2.4 has an inmpoved engine and thus results can't be comapred on bit level to previous versions.

As far as I subjectively see the quality of 2.70.2.4 I have no complaints at all.

It's still a superior encoder in my opninion but I also have to do more testing on HC 0.16 encoder.

But as long as HC is beta I just do not wanna make my backup's with it, because it is not impossible that HC has bugs and my backups will also have them.

I try it as I really deeply respect someone to be capable of building such a complex piece of software.

apfraats

18th January 2006, 19:39

You have to be careful in comparing values.... Q in CCE is not just "Quantization" -- it is one of those mysterious CCE values that means "Quality" and includes quant but not just quant. For example, if you do one pass encoding in CCE and set the Q equal to 10 you might get quants that are 3.

No I mean Q in bitrate viewer.

And I don't ever use OPV or something like that.

Still I wonder the max bitrate of 1219 Kbit/sec over a 120 kbits source.

That is really of interest to me.

jdobbs

18th January 2006, 19:42

DVD-RB assigns MAX_BIRATES of 1219 Kbits/sec after prepare !!!!!!

This is far too high and now I wonder what CAN happen in other cases....

JDOBBS , you told me the source was inspected as GOP-level and that bitrate determines the MAX_BITRATE for that segment.

But 120 Kbits source results DVD-RB in believing the max is 1219 Kbits/sec for a segment !! Apfraats, please stop talking all this nonsense! The maximum bitrate setting also has other considerations that will be allowed within DVD-RB in order to give VBR some room to work.

You are way over your head here... but unfortunately those who don't understand these things are reading your posts and don't know the difference.

I ask again. Please stop this obsessive nonsense. I am familiar with the knowledge levels of people like Hank315 and DragonGodz... and to argue with them about MPEG is really, really a futile effort.

I remember only a few days ago that you said "JDOBBS is wrong, there is no such thing as saturation". Now here you are talking as if you are the "Lord of Knowledge" on the saturation issue.

I understand that you are trying to learn from these posts and test the outcomes... and that's fine, but arguing with people isn't helping you learn.