How do I stop it???
 

Hi Kwag

I've been playing around with this prediction method. I changed the .avs file for 20 samples and found it didn't stop automatically and thus put in the last frame sample several times. This made my output file bigger than it should be by the time I aborted the encoding. Am I doing something wrong or is this a "feature" :roll:

Is there someway to automatically stop Tmpgenc? or do you just press abort when everything finishes?

Cheers

Clive

Just a quick note
 

Hello kwag,

Just a quick note:
The script on the vcdhelp forum is for standard svcd not kvcd.
I have not published a kvcd script that incorporates my latest findings.
My original kvcd script, like yours, is broken.
Your script introduces an error that can be easily eliminated. The one-second snapshot that you recommend will only be accurate using a couple of the kvcd templates.
I have asked you if you were interested in testing my findings and had no
reply, so I can only assume your not.
I hope that for the benefit of all forum users that you open your mind and stop rejecting new ideas before fully investigating them.

Thank you,
Ozzie.

Re: Just a quick note
 

Again Ozzie, NO 8O
I never rejected your formula. I just tried it over and over again, and the file size prediction was always more that 5% from the final size. It doesn'm matter if it's NTSC or PAL. The principles still apply the same.
The formula I applied has been tested not only on KVCD's, but on VCD, SVCD, CVD, SKVCD and KDVD. It's not a "template" oriented formula. It's an mpeg oriented formula. I does work with every TMPGEnc template. Standard or non standard, unless of course you create a huge 80+ frame GOP, then of course it will start to fail. I am aware that not all video material will fall in that 1%, because every material is different. But then again, what is so wrong with a +- 1% error formula :?:
As I said before. I am not rejecting any ideas. But the formula and method you presented, is off by more that 4% from the one I'm currently using.

Regards,
-kwag

audio calc confusion
 

Hey all,

I'm really green when it comes to much of this stuff as I am only about a week into learning this. This forum has been a great help in my quest. Just a newbie question.....I've been following this thread on VBR size prediction, downloaded HeadAC3he and followed your instructions...however I don't see anywhere to change the output bitrate for determining audio file size. Am I just a moron and not seeing it (or just don't know what I'm looking for) or was this option available in an older version and not in the new (I've got ver 0.23)

Thanks for the help,
Greg!

audio calc confusion DUHHH!
 

After further searching this forum about demuxing......I found the answer to my own question.....GEEEZZZEEE I love this place!!

Kwaq,
Excuse my ignorance but what does the above mean?

Re: How do I stop it???
 

The same hapenned with me.

I got around it this way:

1) In TMPGEnc open the "source Range" dialog
2) Reset it to default (start=0, end=-1)
3) Click on the go to the end button
4) Click the Set end button
5) Close the Dialog with OK

Now TMPGEnc knows the real length of your input clip.

While I'm typing it ocurred to me that perhaps includind a "Trim" instruction after the predict size script may work too (and it would be easier) - I'm gonna try this.

Go here: http://hellninjacommando.com/con3d/
It's all explained in the document there.

-kwag

Could somebody help me get my head around this formula? I could get it if you could show me an example. I'm trying out the film Austin Powers. Here's the film's information:

Length: 91min (5460secs)
Framerate: 25fps
Test Clip 1sec @ 161KB

Could someone insert the numbers into the formula for me to see how it works? Any help would be greatly appreciated.

P.S. - Great templates kwag! I've been using them for a while - I started using them way back when you posted one on VCDHelp over a year ago (the ones with clips from some airoplane movie where some guy spills his coffee over himself).

YesI recall in a thread that SansGrip pointed out that there was an error in FitCD's method of determining the total frames. Probably muaddib fixed this in MovieStacker :wink: Not sure if I follow you here, but you encode at the same frame rate as your source. In Windows explorer, the file sizes are reported in KiloBytes.But this is all very old stuff :D. You can forget about this prediction method, and simply use MovieStacker, which will create a .avs script with "Sampler" DLL which takes care of all of this for you :wink:

-kwag

Thank you sir!

I deleted my own post by accident! Sorry about that.

Sure but I was using it with "Sampler DLL" in my .avs script and file size
was way too big. When I recalculated it using prediction method the
difference is:

1) With sampler dll: about 650mb but for real it was over 1gb
2) With prediction method: 671.38mb for real 668mb

Did you always get the same consistent results using the manual method :?:
Maybe there are still a couple of hickups in sampler :idea:

-kwag

I found what I was doing wrong. The calculation. I was working with
29.97 fps which is the framerate for my movie from the dvd, but I should
use 23.976 fps which is the framerate after encoding with tmpgenc.

If you are converting from PAL it's pretty easy. Always 25 fps, but NTSC
grrrr I didn't think, that's why.

So the formula is:

PAL = total frames / 100 / 25 * MPEG Sample * .98
NTSC = total frames / 100 / 23.976 * MPEG Sample * .98

Note: For NTSC doesn't matter what is the input framerate NTSC or NTSC Film.

Still small difference between using sampler.dll (671.38mb) and prediction
method (645.27mb) but as you wrote in the manual ±50mb shouldn't
matter that much.

Btw I was so stressed out yesterday night when I reloaded the page and
I've got the new one. I've got almost a heart attack :-) I was thinking
that I'm spending too much time in front of the computer because I didn't
believe what I see. After that I found that this is the new look (too much
"I"s in those sentences above).

Very good job with the new design. Thank you a lot for the time you spent
to answer me.

Thanks JoZ :)

-kwag