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: