No. Same error appears and it also messes up the aspect ratio (or don't know if that new version requires some extra parameters in the script to make it right).


Dialhot:

Not really a bug but a little improvement to HCmatic. When sample .avs is created, there should be one extra line break added before "multi = ((Framecount....."-line. One of my scripts ended like this:

and sample script like this:

and naturally that won't work because avisynth won't read lines starting with a #

took a while for me to find out where the problem was :wink:

I see :)
I think that you found by yourself that simply adding a line break at the end of your own script can be used as workarround ;-).

Is it possible to add a Q-value field in which you could manually enter exact value where to start predicting?

This won't be difficult to implement.

Meanwhile, let me tell you that the first Q tested is the middle between MinQ and MaxQ. And if you need a MaxQ smaller than 6, you can just close HCMatic, edit the Hcmatic.conf file, then reopen HCMatic. MaxQ will have the value you set into the conf ;-).

I saw also a bug : MinQ and MaxQ are never tested, and this is not normal. I will fix that too.

Download link temporary removed

I just discovered that audio size is completly wrong and thus video size, and of course bitrate to reach :(

I'll try to fix that ASAP.

Now that I was going to give HCMatic a run for its money?? :lol:
Great to know that you found the "sucker".
Hope you fix it in time for my next project that I was going to work on this WE :).
Cheers Phil

PS: I still just don't know how you've managed to get the audio wrong since it's the easiest part...
Care to share with us what went wrong?

I took the code from Calcumatic and... the error is there ;-).

I don't know wy but in calcumatic 1.1.14, thre one I had all is okay, but in 1.1.16, the version corresponding to the sources from Karl, there is a strange conversion between Kbits and KBytes :

8 Kbits = 1/1.024 KBytes insteed of 8 Kbits = 1 KBytes.

I dont know what decided Karl to introduce this 1.024 there.

Nevertheless, I don't understand anymore :(

I encode a stream that is 31min01s long = 1861 seconds. I encode at 128 Kbit/s

For me 128 Kb = 16 KB ( = 128/8 )
So the total encode should be 16*1861 = 29776 KB.

That is what I found too with Calcumatic 1.1.14 and HCMatic 1.3 (not delivered yet). But, I did the encode, and it is 29093 KB long. This is what Calcumatic 1.1.16 finds too (and what I put in HCMatic 1.2).

29093 is more or less 29776 / 1.024.

That means that my 1024 Kbit/s ADSL bandwith that I always considered as 128 KB/s is really 125 KB/s ? 8O :evil: :cry:

Edit: confirmed with a 10hours long project. The formula with the 1.024 is the correct one. So HCMatic 1.2 was correct.

HCmatic is sometimes trying to be a little too accurate.

http://www.digitalfaq.com/archives/i.../2007/04/1.jpg

Lol. Before to test a value, noone can tell that the result will be exactly the same than a value already tested :-).
Actually HCMatic 1.0 would have tested 3.64 too but I optimized that in 1.2 :-).

Actually Karl's 1.024 theory is right.
We all discussed this in depth back in the days when CQM and CalcuM where being developed.
Yes HCMatic 1.2 is correct and yes, your 1Mb internet connection is thr same as 128KB connection.
Don't ask me why but it is :).
Cheers

Great Phil!.

Thanx for this nice tool. I.m sorry I didn't have time earlier to test your predictor. I was still making use of the old-fine-working way with Andrej's ping-pong.

I was going to "ask" for the exact prediction tool, but already saw that was in your never todo list :lol: Just kidding!.

As there's no (at least, I didn't see any) "wish list", I'll post here a couple of suggestions (:?:)
1. My first encodes are a bit above destination size. I miss some way to tweak your tool to, for instance, ask for better accuracy. Some way I thought of:
- we could adjust sample size (1%, 2%, 5%...)
- when prediction is close to goal (i.e.<0.02), it could then use a bigger sample size. That is: uses a 1% sample, and when prediction is close to goal, changes to 5% sample (this is what I used to do with ping-pong) for better accuracy.

2. It could be added some blanks else, in order to put more than 8 .avs files in a KDVD.

I would like to be more helpful than just making suggestions. I guess it's not nice to develop a tool and read posts stating "I would like it also did...". This is not my intention.

Congratulations.

Actually, a lot of mine are too. This is mainly due to end credits that use a lot of bitrate, and unfortunaely are not enought represented in the sample during the prediction. The best solution would be to cut them off the movie to encode (what I do ).

I already thought about that. Did not do yet because I find the prediction time quite long and did not wanted to increase it more.

Not really usable in my method. I must be sure that the next Q found is in the range [minQ, maxQ], with minQ and maxQ the smaller and biggest values found in previous steps. If I change the sample, I take the risk the obtained Q to be out of that range, and the prediction will end there.
But I will give a try to see.

This is not possible because of Purebasic. There is no dynamic structure so I had to use a static array, that I dimensionned to 8.

No problem. Actually, in the end, I will always developp things that I need too :D

How about "Stop prediction and use current Q" button?

Didn't planed about that, but it should be possible to introduce it. Probably next release so.

Any update to this? been quite awhile since 1.3

Good remark :-). I'm using a "1.4" since a while but your message make me thinks tha I never released it :lol:. Now I have to remember what are the diff with 1.3 :lol:

Let me a couple of days.

no problem, cant wait to test it out :D

Thanks Phil testing it out right now :D

hi phil,

a minor issue, when in a script you're using assumefps, the new running time of the movie isn't correctly displayed, and thus messes up the bitrates.

If that is true, unfortunately there is nothing I can do : I'm using a purebasic internal call that returns the frame number and the time length. I guess one of the two are incorrect, because of the assume fps. But I will check.

Can you give me the fps of the source and the assumed fps ? Did you correctly set the fps value in HCMatic ?