Great :D

Let me know if the results are any good, so I can either celebrate, or hang myself :lol:

-kwag

Nooooooooo :mrgreen:

Here are the results:
I think thats really good for that small sample size :D Only 2.6 % off target.
I'll test this later with a bigger source.
Thanks Kwag :!:

Yesterday I encoded the Movie "May" with a CQ of 63,6. The target Size was 726 MB and the encoded file size was 669 MB. A huge difference of 57 MB. Now, I made a new prediction with CQMatic 1.1.0-Pre-Release-2. The new CQ was 70,13, but then I saw, that Kwag already released CQMatic-1.1.01. So I decided to predict the CQ again for that Movie, but the result with Version 1.1.01 was only 62,82, that's lower than the CQ, which gave a file, that was 57 MB too small.

I hope y'all understood me.

Hey Kwag,

i did another prediction and full encode with another resolution on the same source (544x576, before it was 704x576). The resulting vido file is bigger:
229 MB :!:
Here's the log:
Is prediction resolution-dependant :?:

Okay, so here are my results using VCALC as bitrate calculator vs. moviestacker

Wanted file size: 728,194,990 bytes (from moviestacker)
Encoded file size: 700,923,158 bytes (3.74% under)

So it looks like, at least in this particular case, I need to fiddle around with some settings in vcalc to get an avg. bitrate somewhere between the two programs. I'm currently setting MS precision to 0.74, giving me an avg bitrate now of 1044. It'd be my hope that finding the right avg. bitrate to use would solve all our prediction problems, but somehow I think that's asking for too much! BTW I am encoding in MPEG-2 for this movie.

There you have it, 0.38% precision!

Wanted file size: 728,194,990 bytes (from moviestacker)
Encoded file size: 725,391,333 bytes

Again, this was using vcalc as bitrate calculator, set at 1024k and an MS precision of 0.74. I'm going to try some other dvd sources and see if these settings are consistent!

Hello kwag:
I run the new CQmatic version 1.1.01, and it gve me the following results:

Two things worth noting:
1.- The process time was shorter than the previous version
2.- The final CQ here is 63.46, this compares to 64.31 obtained previously.
3.- Settings run on both tests were similar........

Is there something wrong w/Moviestacker?
 

Gentlemen:

I have been encoding with CQmatic several times, and not once did I hit the right number. While trying to resolve this problem, I noticed that the length of the video, was erroneously given by Moviestacker. How did I determined that moviestacker was erroneous?
Sr. Kwag advised that I should re-do dvd2avi, and I did. Except that this time, I recorded the time stamp given by the audio window within dvd2av1, and these were the results:
1.- Audio dvd2avi time stamp: 2:00:55
2.- Moviestacker time in minutes: 95 minutes 46 seconds.
3.- Tmpgenc time stamp: 2:00:55 (checking it via avi :D )
4.- Power Play time stamp: 2:00

Any ideas why this is happening? Has anyone noticed this difference in time between Moviestacker and dvd2av1?
On my next encode I will use the dvd2avi time stamp, that appears to be more accurate than Moviestacker.

Thanks

Totonho03

Hi Totonho03,

This happened to me once, and it cleared after I did the .d2v again.
If moviestacker reads an incorrect number of minutes, it will then give you an incorrect average bitrate, which will throw off CQMatic completely :!:

-kwag

Hi kwag:
Thank you for your response. I uninstalled moviestacker, re-installed again, and it keeps on given me 97 minutes, while dvd2avi, which was also re-run, gave me 120 minutes.
WHY ME????? :cry:

I will run CQmatic using the new time and will post the results.

Regards

Totonho03

Hi Totonho03,

Try DVD2AVI 1.77.3 :idea:

-kwag

Hello Kwag:

I have run CQmatic with a different time length, and it gave me a lower CQ, which was what I expected to see. The new run now looks like this:

I will run the encoder later on tonight, and will have an answer tomorrow.

As suggested, I did try dvd2avi 1.77.3 , and it gave me the same time as before, that is 2:00:55, then I loaded the outpu of dvd2avi into Moviestacker, and it gave me the same 97 minutes as before.
Now, I manually changed moviestacker's minutes and seconds to match what I was seeing with dvd2avi, and in doing so, the average rate changed, instead of the 1005 number that I was getting with the 97 minutes movie, I am now getting 779, when manually changing the 97 minutes to 120.
So now I have another variable to worry about. I suppose that the average rate that I should be using is going to be 779, and not 1005. Does this make sense?
Should I run my next encoding test with the higher movie length and lower average number? I guess that the answer to this question is yes.

But the 64,000 pesos question is Why is Moviestacker behaving like this? Meaning given me the wrong time?......Only the shadow knows..................

Regards

Totonho

@totonho03,

Is this a avi problem only or is DVD effected also???

-bp

Hello bp:

If I understood your question, the files that I am using are coming from a DVD via decrypter. Then I feed the output of dvd2avi, to Moviestacker. I have tried dvd2avi v 1.76, and v.1.773, and both versions are given me the same video lenght, that is 120 minutes, while moviestacker is telling me that the film is only 97 minutes.

Thanks

Totonho03

Kwag:

Any particular reason why 1.1.x always starts prediction at CQ 60? I can understand that you might want to do this for the sake of consistency between prediction runs, but sometimes when I'm trying to fool around with different script changes it helps to start at a CQ closer to what I expect it to be.

Hi all..

Actually, that's not a bad idea.. enabling an optional feature for a user to
input a CQ starting value, and go (calculate/predict) from their.

But, on the other hand, this idea may not flow right w/in the param of Kwag's
prediction algorithem and calculations of things :roll:

At best, what I do is save my .tpr projects w/ an initial CQ value of 50. I
have ben assuming that CQM's process included some form of starting point
"based" on MY value for CQ. Perhaps I'm wrong, in any event :roll:

-vhelp

It used to include a starting point but in the latest release kwag has overridden that value for whatever reason. **A good one I'm sure** but i agree it would be nice to set your own starting value because most times you have a general idea where CQ will end up so it cuts down on prediction time.

.
.
and, also to add here.. that the one key focus w/ CQM is the Automation
of the whole process. If memory serves me correctly, CQM's main intent
was to do it all w/ out the user's intervention (hence, tainting) of anything
that would impead, hamper, or invalidate an as accurate a prediction as
possible. Hope that made sense :roll:

Yes, a design for beginner, newbies, or even pro users.. it's for all.

Basically, a point and click process, w/ minimal user intervention 8) hence,
the Matic of things ( autoMatic, that is :wink: )

It'll all be interesting to see the final "un-vailing" of the process (start to finish)
though :!:

-vhelp

.
.
ok, I wasn't finished in thought :roll:

.
.
Personally, I like a little room-play for scenarios.
I'm also an automaic kind of guy too - I like to streamline anything and
everything that is doable, BUT sometimes, I just like to tinker a bit w/ some
what-ifs and things.. you know! That's partly why I designed vcalc in the
way it is today.. tweakable, and to be a little on the edge, so to speak.
maybe this is a form of suggestion for CQM, or not.

On the other hand, it would also be interesting to see how CQM stacks up to
a FAST system, that can encode a 90+ min in an hours time.. point, click
and burn (PCB) !!
We shall see :roll:

-vhelp

Well we'll wait for the reply from the almighty above (i.e. KWAG!) but I think it would be nice if there was an Advanced Options button that would let us chose the starting CQ or other such advanced things. :wink:

Yes. It has to do with the linearity range of CQ, and makes the following CQ values easier to calculate.

-kwag

I'll add a "CQ Override" check option for the next rev ;)
But remember: Use it at your own risk :!: :lol:

-kwag

CQMatic 1.1.02
 

Good morning people :D
Let's start the day with more new stuff ;)
http://www.kvcd.net/CQMatic-1.1.02.exe

Changes:
First of all, forget DivX predictions from this release, and on.
The new sampling is now One snapshot every 5 seconds, with a time slot of 0.0833 second each. This provides a very fine grained sample of the material to be encoded, at the cost of longer prediction. There's just no way around it :!:
The current sampling stresses SO MUCH the DivX (XviD) CODECS, that renders prediction useless on these types of materials. With MPEG-1 or MPEG-2, this behaviour is not seen. It's a problem related to "seeking" random frames in MPEG-4 CODECS. So, bye bye MPEG-4, as far as prediction goes, until future versions of those CODECS are revised for faster random access.
I've added an "Interlaced" hack, that takes into consideration if the source is 29.97fps interlaced. I've only tested it on one Video ("Styx - Back to Paradise") and the CQ was right on target. I don't have any other Video DVDs, so I can't test it any further. Your testing is greatly appreciated :!:

If the source is Interlaced, and you are using TMPEG to deinterlace, the "Interlace" checkbox will auto detect, and will be checked automatically. If you are using an external deinterlacer ( Bob(), FiledDeinterlace(), etc. ), then you must manually "check" this option. This applies ONLY to interlaced sources.

I've also added a "Override Default CQ" for prediction. If you "check" this option, CQMatic will use whatever CQ you set in your project (.tpr) file. If you leave it "unchecked" (default), CQMatic will use it's own (recommended) starting CQ/CQ_VBR value for prediction.

Have fun :!:
And please, report EVERYTHING (good or bad), so I can keep pushing this forward, and tune it in the right direction.

-kwag

Thx Kwag,

which bitrate calculator are you using :?:
What is your recommended resolution :?:
Prediction is currently running...

CQ seems to be a bit low, but i'll do a full encode to see if its hitting target.

Remember this: Finding CQ will ALWAYS take a long time when the values are below 50, because there is almost no file size change for a change in CQ value. Same applies above 80. The fastest results will be between CQ of ~50 to ~75. There's just no way around it :!:
Look at the File size difference = xxxxx. There's almost no change, for a change in CQ.

-kwag

What is your target size :?: :?:

Sure. I don't have any problem with long prediction cycles, for me its more important whats coming out :D

My target size is 188 MB.

Me too :D Ok, that's what I thought, based on you numbers. Let me know the final size, as I see that your source is interlaced. :)

-kwag

Will the CQ be affected by the Video Source Type ?

I mean, if I set the Video Source Type in TMPGEnc to interlaced instead of Non-interlaced (Progressive) will the CQ be smaller or bigger ? And if yes, will the difference be considerable ?

And will the video quality be affected, if I set the Video Source Type to interlaced, even if the source isn't interlaced ?

If you set the source in TMPEG to interlaced, but your real source is not interlaced, you'll throw off the prediction formula completely :!:
CQMatic will assume the source is interlaced, and use some internal correction factors. So your file size will be way off :)

-kwag

Good morning folks:

This is my daily report, but I can see that it is already obsolete. Well not quite, because I still have the 64,000 pesos question....... Why is Moviestacker given me the erroneous film length?...Am I the only one having this problem? Just for fun, next time you guys run dvd2av1 and moviestacker, please compare the time you see in dvd2avi (audio time stamp) to the time given by Moviestacker. Thanks

The encoding finished earlier today, and actually I am not going to post the log, but the file size is still large. The file size of the M1V is now 978,573 KB, which is a heck of a lot better than the 1.2+Giga, but far from my target, which is about 700 MB (Moviestacker number)
As mentioned before, when I changed moviestacker to the proper time (from 97 to 120 minutes), the average bitrange also changed, it went down, from ~ 1000 kbps to 780 kbps, so the next logical question is, if the average bitrate goes down, would the final M1V file go down as well? If the answer is yes, then perhaps I will reach target on my next test. I will run the new CQmatic and post the results of it, but the file size will be seeig manana........If TMPGenc would improve its encoding speed it would be great (Yes, I know, I can always purchase a 2 gig machine, but........)

Thanks

Totonho03

Thanks

Totonho03

@ Kwag

I think you didn't understand what i meant (presumeably because of my primitive english) :wink:

I'll try to explain it in really easy way:

I have a not interlaced source with 1000 Frames and I encode it with CQ 50 in TMPGEnc with the Video Source Type set to "interlaced". Will the Size of that clip be bigger or smaller than the same clip with the same CQ and the same framecount with Video Source type set to "Non-interlaced (Progressive) ?

Your file size will be identical ;)

-kwag

just wonderin is there a possibility u could add a function that gets the average bitrate like in moviestacker??

That's what the little "calculator" icon is there for :)
It will be integrated in version 2.0 :cool:

-kwag

XSVCD
 

When i'm using other max and min values, eg. min=300 and max=3300,
won't the prediction be so accurate or will the final size be out of range?
Where are the differents beetween max.=2000 and 3300??? :?

Re: XSVCD
 

Hi OBK,

The way CQMatic predicts, it might just solve the old prediction problems, where we had to tighten the MIN/MAX in order to achieve better accuracy.
Because of the way the new prediction in 1.1.02 works, it might not be necessary to restrict the bitrates :!:
I haven't tested that, but thinking about it, CQM takes so many samples per minute, that you might be able to use any bitrates you want, and still maintain accuracy. You're going to have to try it out yourself :)
As far as max of 2,000 and 3,300, the higher you go, the better the quality and but also the larger the file size.

-kwag

I am using Telecide()/Decimate() with DVD2AVI non-ForceFilm output with KDVDfull. Should I check or not check "Interlaced Source" on Version 1.1.02?

It sounds better and better!

But when predicting in two different max bitrates the final size should
be the same, only the CQ changes, or am I wrong? :roll:

Thanks, OBK!