2 tests and results using CQMatic 1.0RC1 searching prediction:

first:
wanted size 290mb,31 minutes.
after 3 times searching prediction give CQ63,62.

second:
wanted size 800mb,88 minutes.
after 3 times searching prediction give CQ64,14.

i did 2 differents projects with dvd2avi.
the first with 56409 frames, 31 minutes,
the second with 159613 frames, 88 minutes.

i think it's perfect cos the final final CQ for each have seamless
and they are from the same source (dvd)!
i did the same tests twice...same results :!:

:wink:

Just adding my results (first time with CQmatic)

1 test and using CQMatic 1.0RC1 searching prediction:

Kangaroo Jack
MA script 352x480 encode
average bitrate=1106
film length=89 mins
Min=300 Max=2500
Cq=64.75

Won't bore you with the rest - 799M result with audio(128K)

:ole:

Just a couple of questions:

I was using Min=300 Max=2500 - should I have used Min=average bitrate*0.75 and Max=2500 .... it did seem on target using the default KVCD template

Do I have to always find the target for TMPGenc before each try using CQmatic - or will it remember?

I may try the movie using 480x480 resolution (DVD player won't plaly the 528x480 :? ) - though still not sure if a lower CQ (~54) value is worth the increase in resolution

Anyway so far great work!!!!!!!! :angel:

I think there is some confusion here. .75*min or .57*min??

Hello audi2honda:

Several posts have stated that the minimum should be (avg X .57)

Totonho03

Edit.- Audi2honda: I went back and saw what you are talking about............ I will go back to some other posts and try to clarify, at least in my mind what the proper number is....

Yep, we need a clarification on this number.Different quotes regarding this issue:

Quote:

You can probably use any bitrates you want now, but I'm still using the (0.57 * average) for MIN.

.........These are but some of the quotes regarding this issue. I still believe that it is (average X .57). But I suppose that kwag will clarify it.

Totonho

Edit: This has been answered. It is (average * .57) Thanks kwag

TESTING CQMATIC WITH MODIFIED MVCD2.5EX TEMPLATE
 

Yesterday I encoded "The Bonecollector" with an modified KVCD Template.

FACTS: The final file was to small. 783 MB inkl. 2 128 Stereo MP2 Tracks.

Today now I test it with an modified MVCD 2.5ex Template. I did before a short sampler with both templates. Because I encode in 704x576 I was wondering why I get a better Quality with MVCD2.5ex!!!

So I encode now the movie again. I will post the FACTS then.

BTW: I had with KVCD a CQ of 53 and with MVCD i have now CQ 57.75!!!!

What I changed in both Templates: Motion estimate Search, 704x576. CQ 50 for start.

MVCD2.5ex encode 10% faster than KVCD... Why ????

Here the CQMatic Log:

Re: TESTING CQMATIC WITH MODIFIED MVCD2.5EX TEMPLATE
 

Which is just fine, because it's ~17 MB under, and that's about 2% which is in my design target range.Because you can't compare pears and apples :lol:
704x576 is higher than 528x4576 :!:
But the longer the movie or more action (after bitrate starts to exhaust), you'll get more bits per pixel at 528x576, and it will look better than 704x576. Of course :!: They now have another matrix, which throws off the CQ curve completely, and a higher CQ doesn't mean it's better quality.
The only way you can compare, is if you make a target file size "identical" with their's and our's, and then compare ( I did, and I know the results :mrgreen: )
BTW ( and FACT: ): MVCD and mole are " PERSONA NON GRATA" here, for their thieve practices. Maybe you should look at some facts here:
http://www.kvcd.net/forum/viewtopic.php?t=4364
and here:
http://www.kvcd.net/forum/viewtopic.php?t=4351
which of course, now they have their own matrix, but their foundation was based on our work, which permanently marks them as "Pirates" of technology. It's telling you the results right there :lol:
Of course :!: The encoder is seeing less data (because of their matrix), so you're loosing frequencies that are being discarded, and are not being processed by the encoder :D

Thanks for bringing this up ;)

-kwag

@Avalon,

Saying "mvcd" around here is similar to swearing! :lol: As Kwag directed you, mvcd blatently and disrespectfully ripped-off their ideas from KVCD and didn't admit it. They may have made a few extra changes here and there lately so that they seem different or unique, but most people here at kvcd.net know the real truth about mvcd's origins.

-d&c

After many tests i thought i would try an just do an encode and here are the results

Wasn't sure which number to use Last CQ = 81.082985
Current CQ = 80.874969(feeling pretty stupid now) but i decided to use 81.082985 and the final size of just the video is 792 m,now i figured i used the wrong one but there is such a small difference it wouldn't make it that much bigger.

Hi bigggt,

Well, I think I'm going to have to specify that CQMatic is accurate only on DVD (MPEG-1 or MPEG-2) sources (for the time being), and not on avi sources :!:
I'm getting very accurate results, but only processing .d2v (DVD) material.
Maybe it's a CODEC related issue when reading the avi :idea:
That's the ONLY thing I can think of, because it's the same process to calculate prediction, no matter what the source is.

@All,

Here are the tests I have encoded since yesterday, all with CQMatic RC2:

Red Planet (352x480): CQ: 80.120 Encoded size: 742,198KB Wanted: 726,338KB :arrow: ( Diff. 2.13% )
The Bourne Identity (528x480): CQ 56.25 Encoded size: 715,574KB Wanted: 715,701KB :arrow: ( Diff. 0.017% )
K19 ( 528x480 - Raw, no filters. Only Bilinear resize): CQ: 61.06 Encoded size: 678,294KB Wanted: 699,875.78 ( Diff. -3.181 )

So for CQMatic RC-3, I'm adjusting the final precision by 1% (tighter) to shrink the final bracket calculation. This should bring the average final encoded material to about (-2% to +1%).

-kwag

Hey Kwag,the thing is Tok gave me almost the identical CQ and now when i went to mux the audio and video with bbmpeg(never had a problem before)it won't even scan the video so i'm thinking i must have a problem in tmpeg. here is what it says in bbmpeg

and the audio underflow keep going

You bet you have a problem 8O. Look at this:

Your mpeg file is encoded as I pictures only :!:

Edit: Try this: Open your .avs file, and then load your template.
Then save your text project :!:

-kwag

How would this have happened and how do i adjust it

Somehow, the values in your template got all screwed up :!:
So just reload your template, but after you load your .avs source. Remember to clear the source range before saving.
Try that :)

-kwag

Thanx Kwag,tried it with a short clip and everything worked ,everytim i open souce range i get errors so maybe i hit the wrong button :(

Here's another result, with RC-3:


Wanted file size (Moviestacker) 722,779.89KB
Encoded file size 718,351.00KB

-kwag

Hi Kwag,

finally i have good results (1.0 Release) with my "problematic" source:
Final video size is 181 MB, wanted is 188 :!: http://www.digitalfaq.com/archives/error.gif

Great to hear that Krassi :D
Well, I guess CQMatic is getting better :mrgreen:
Btw, what type of source was that :?:

-kwag

Sorry for my late response. It is a mpeg2 video stream from a digital satellite receiver card (near DVD quality).

So that means it is an interlaced stream, right :?:

-kwag

Here are some movie details (can't figure out if its interlaced because i don't have access to the source right now) but here are some movie details:
AFAIK its not interlaced, only some tv-stations are having interlaced material in germany :D

Thanks Krassi,

I asked, because I'm having problems prediction interlaced material. That's what I'll be tackling tomorrow (actually today :) )

-kwag

only removing doubts:
my source is 29,97!
the first fast search in CQMatic 1.03 using CQ50 encode as 0,0023976!
is ok?
:?

Yes ;)

-kwag

:D
thanks!

Result of CQMatic 1.1.02
 

Here's the result of my first full encode with CQMatic version 1.1.02 :D

Movie: K19 (138 minutes)
CQ found: 56.64
Wanted file size (Moviestacker) : 699,875.78KB
Final encoded file size: 697,860KB

Using this raw script:
-kwag

The 1.1.0.2 Version is giving me serious problems. On my the first prediction for the 90 Minute Movie "May" the CQ went up to 90. But I encoded the Movie one day before with a CQ of 63,75, which gave a final size, that was 16 MB off target, so 90 just cannot be serious. And another Movie called "2009 - Lost Memories" was a total flop. On that Movie, CQmatic 1.1.0.1 gave me CQ of 44,94, but CQM 1.1.0.2 was going below 30, when I cancelled the whole process. The strange thing is, that the Low Fence value always remains 2.000000, even after several prediction cycles the low fence remains at 2. On both Predictions I did not override the CQ.

Here's my Log for that Movie. In the End I cancelled it, because I saw that it wasn't going to be successful.

Hi Bchteam,

What resolution are you encoding :?:
I ask, because ALL the tests I've done, have been KVCDx3 (528x480).
Now that you mention that, I haven't tested any other resolution 8O
Maybe this is a cause of prediction problems :idea:
I'm going to try a 352x480 now, and see what results I get.
As far as 528x480 (NTSC), I'm right on target :!:

-kwag

Hello Kwag:

I am presently testing the new version of CQmatic. These were my steps:
1.- Loaded the new 1.1.02 version
2.- Used 120 minutes with the new average bitrate (779 from Moviestacker)
3.- Using yesterday's .tpr file (From Tmpgenc) Did not change the max or min here. (max 2,000, min 537)
4.- I did not reset TMPGenc at all, therefore it used yesterday's settings.

So far it is in its 5th prediction cycle (Each cycle is around 27 minutes). The CQs that have/are being run are:
60 > 69.73 > 75.83 > 78.07 > 80.26...and counting.
Max bit rate= 2000; min bit rate= 537
non-interlace
Motion estimate search
Average bit rate at CQmatic=779, which corresponds to the new 120 minutes setting.

I was expecting to see a CQ lower than the one obtained yesterday, which was +/- 63, but as you can see, it presently is in its CQ 80.26 run, which means that the file size is going to be way over the 700 Meg target.

Thanks
Totonho03

"May" is 704x480@25fps and "2009 - Lost Memories" is 528x480@25fps. It doesn't seem, that it's resolution related problem.

P.S.- Maybe I should try, for testing purposes, your raw script.

Totonho03

@totonho03,

Are you encoding 528x480 :?: or some other resolution :?:
This doesn't make sense AT ALL 8O
How can I get a movie to within ~2MB difference (K19), and everyone else CQs are so way off :!:
Something in the encoding chain is WAY different from what I have to what everyone else having problems has. I can run 10 times CQMatic against that same movie, and get the same CQ every time. So I need more information, as to what resolutions are being used, if different that 528x480. I just started a prediction test on a 352x480, to see if there's a difference. I just can't think of anything else right now that can possibly create such drastic differences in CQ :!:
:banghead: :banghead: :banghead: :banghead: :banghead: :banghead:

Thanks,
-kwag

I think that to test CQMatic, everyone is going to have to insure that the other involved programs and factors are consistant across users. For example, everyone should use the same bitrate calculator, or better still, the manual average bitrate formula. Everyone should configure TMPGEnc the same way, i.e., minimum bitrate padding, etc. This way, we can make many tests against many films with CQMatic the only real variable. It would probably be best if we all used the same resolution, fps, etc, for each set of tests.

We could all test 528x480 at 24fps and list results. Then move on to another resolution, fps, etc. It really doesn't matter if the output is usable at this stage, just that the CQMatic generated file is near the desired file size.

If any problems occur, we could isolate them to a particular film or conditions. We need to be giving Kwag consistant test results based upon known factors.

Hi kwag with the latest version my reference DVD jumps straight to a CQ of 90. Using resolution of 704x480, 1686 avg bit rate, movie length 120 minutes.

Hello Kwag:
These are my TMPGenc settings:
CQmatic is still running, and presently is doing CQ 80.87
I feel like :imstupid: for my lack of experience here, but please do not :gun: , but if my failures keep on happening, then they are going to drive me to :drink: :drink: cachazas (capirinhas) :D. Perhaps I should already hit for the refrigerator and star fermented cebada juice.

Totonho03

Hi nicksteel,

Yes, you're right :!:
But now I have a new piece of information for everyone, which is really weird 8O
I just did a 352x480 prediction on the movie "Red Planet".
I used a MAX of 2,000 and MIN of (.57 * 919(avg.)) = 523.83Kbps
I got a CQ of 80.25
Now I changed the MIN to 300 and the MAX to 2,500 and ran prediction again.
Surprise :!: found CQ of 74 8O
Now, which is the correct CQ :?:
Is it the resolution :?:
Is it the MIN :?:
Is it the MAX :?:
Too many factors, and this is getting wild :!:

The only thing I can think of, is that at higher resolutions, the MIN and MAX are being used to the full extent by the encoder, but on lower resolutions, the bitrate MIN/MAX ratio is not being reached during prediction. And that's why there's such a difference from 528x480 to 352x480 :!:
This brings me to another question: Which is the correct MIN/MAX to use, if there's such a large difference of CQ with a change of resolution :!:

Too many factors, too many variables, and this is the root of the problem :!:

-kwag

Perhaps I should go out running as fast as I can into a bar, and get really drunk 8O
Maybe after drinking a six pack of beers I can think of something, other than hanging the creator of TMPEG for not making the CQ curve linear :twisted:

-kwag

Sr Kwag:

If you do not mind my 2c., I also believe that nicksteel is correct in his assertion and recommendation. Perhaps what we all need to do is to use the same parameters, then compare notes and see if the different OS and machines, are given us the same results. Once this is established then groups of 2 or 3 can test different parameters. Needless to say that you will provide us with the first parameters/settings and guidance, as well as with the following testing settings.

Regards

Totonho03

PS.- Not that it makes any difference now, but CQmatic just finished its prediction and is given me a CQ of 80.87. It took about 180 minutes to do so.......

Ok, let me finish some tests at different resolutions to see the results. I want to test the relationship between bitrate/resolutions before moving on.

-kwag

:wink:
great observation my friend nicksteel,very logical.
i was thinking the same but i can't be so clever.
:!:

Kwag wrote:
"Too many factors, too many variables, and this is the root of the problem :!: "
" :?:
"Too many factors, and this is getting wild :!: "
i post it somewhere here: if i encrease the "MIN",and decrease the "MAX",
the CQ encrease and the final size encrease too :!:

Otto
give me 2 "caipirinhas",i need it too!
:lol: