Hi kwag when I try some pure film dvds tomorrow I'll report back in but so far on hybrid material it is way over. My last encode. Wanted file size was 764MB and the final was 789. This is only on one source though and it's a hybrid with telecide and decimate.

I"ll get some pure film results and let you know.

this was my post a couple up with 1.1.12 with a cq of 71.65
just ran the same tpr file through cqmatic 1.1.07(which gave me almost perfect result last time) and this time got a cq of 70.2108

Now the cq is almost 1.5 lower but what kind of size differnce would 1.5 cq points be.

@ all.

Well, here it is, at 5h:2m later..

* Movie: "Red Planet"
* Length: 107 minutes
* Audio: 112k
* Max: 2000
* Ave: 909
* Min: 518 ... (by vcalc)
* MPEG-2 / AR: 16x9 / Res: 704x480
* Scene Detect: unchecked
* Audio: 87mb
* FileSize: 755,426mb

Equals: 843mb

Too tired to MUX and see final results.. will let you guys guess, cause I can't
figure out how mstaker get it's wanted filesize 8O

-vhelp

Running a similar test vhelp. Result in ~4 hours.
But I got a CQ of 56.66 (CQM 1.1.12a) with a MIN of 523.83, MAX of 2,000 and average of 919 8O
Encoding as MPEG-2 with 3:2 pulldown, directly from .d2v (Force FILM) ( Not frameserving :!: ) using Film Pixel area of 718x388 for a correct resize of 704x272 and target of 704x480.

Edit: Here's the little sample. Not as good as MPEG-1, but what the hell ;)
This is just a "fitting" test :lol: )
http://www.kvcd.net/red-raw.704x480.mpg

-kwag

Yesterday i've encoded "Days of Thunder", 704x576 with filters. Thats a real uncompressable movie. I had a final CQ of 21 :lol: :roll:
The final VS was about 1,5% higher than wanted bitrate. For that low CQ, thats a very good result.

And here is my result of Red Planet, as described on my previous post :mrgreen:

Wanted file size (By Moviestacker) : 726.338.51KB
Final encoded file size: 720,333KB
For 0.82% accuracy :!:

So, what's going on here :!:
I will post my process step by step later today, just to make sure everyone is doing the same thing :roll:

Edit: No need to explain. See next post :!:

-kwag

@vhelp and all,

Please take a look at this thread, for the correct procedure for obtaining "Film Pixel" area, and feeding the correct area to TMPEG:
http://www.kvcd.net/forum/viewtopic.php?t=2190

-kwag

Hi Kwag and others..

I'm getting conflicting results here w/ MStacker's v2 readouts for wanted size (WS) :!:

Please note the difference below.

Using your "Red Planet" WS as a template, I opened my a few sources, and there are the results:

.d2v-VFAPI
------------------------
* Length: 107:15
* ave: 911
* seconds: 6435.48
* frames: 154298
* I frames: 10286
* Audio: 112k / 91870044 Bytes 89716.84KB = 87.61MB
* Video Stream: 724972.25KB = 707.98MB
* bbMPEG-VCD MPEG-1 / [ ] Seq. header... / [ ] SVCD scan...
* 80Min CD

.d2v
------------------------
* Length: 107:22
* ave: 910
* seconds: 6442.19
* frames: 154457
* I frames: 10297
* Audio: 112k / 91969976 Bytes 89814.43KB = 87.71MB
* Video Stream: 724965.45KB = 707.97MB
* bbMPEG-VCD MPEG-1 / [ ] Seq. header... / [ ] SVCD scan...
* 80Min CD

Not to mention your MStaker readout:
.d2v
------------------------
* Audio: 112k
* Video Stream: 726,338.51 kb

So, perhaps we should be factoring in these results into our "later" issues
when computing "what went wrong" scenarios :!:

So, maybe the above is something to think about, in CQM choice of CQ's
for a given users test, using the same movie ie, "Red Planet" This could
explain the difference in Wanted size vs. Sample Size vs. another users..

-vhelp

Hi vhelp,

I think the whole issue is that you are processing via a pseudo AVI file (VFAPI), or you're not masking out the black area completely in TMPEG (clip frame? Check link I posted above. )
Also, why are you processing via VFAPI :?:
You don't need that if you are going to process directly from a .d2v file, not to mention the slow processing speed by the VFAPI overhead :!:
Also, I am using DVD2AVI version 1.77.3. I stopped using version 1.76 a LONG time ago :!:

-kwag

Hi Kwag..

psuedo .avi files are my favorite when it comes to DVD sources. I can't
work things out w/ the color space issues that AVS scripts give me, unless
I use the much older version AVS .dll ..I think it was v1.0 BETA 3 or 5.
these gave me the best color space results, but since I'm trying to stear
towards "change" ie, AVS v2.52, I'm trying to leave the old BETA avs .dll's
alone. Anyways..
I can do lots, w/ .d2v-VFAPI source files, when I use vdub.. and there are
other benefits to using this route on my end here.. those benefits I can't
quite display in words here at this time. But, FWIW, and IMO, this route
that I use is the best in final quality. Ok, it may take slightely longer to
complete, but for me, the end result is quality, w/ this approach, for the
time being !! But, there will be times when I might practice your same
steps for comparison.

Ah, there's our first difference. I'm the reverse. I revereted back to v1.76 cause I
feel the quality differnce is there. So, it all boils down to taste. hmm..

Never the less, I don't thing that my route is what's causng the difference,
thought it may play a part to some degree. This is a method that works
for me quite fomfortably for the moment.. plus, I have my other reasons 8)

-vhelp

Hay Kwag..

getting back to the topic here.. and going to my post in prev. page, if I
used your "Red Planet" wanted video size: 726mb and calculated my
percentage difference, it would come out to:
--> 3.841 ( or 3.8 )

So, I guess that is not TOO bad after all.. even though I went past my 800mb
CDR ??

What do you think ??

I did play the movie in PowerDVD and it looked great. If only it would make
the 800mb CDR, I'd sure love to of known how it would look at a one cdr
movie in my dvd player !!

-vhelp

Ok, but keep this in mind: You are processing your VOBs via: VOB->.d2v->VFAPI->Vdub->.vdr->TMPEG
That's a LOOONG chain, compared to: VOB->.d2v->TMPEG :!:

-kwag

Yes, fair enough :)

But, at the moment, TMPG doesn't have a good method for working out
those AR issues, and resizing. That's one of my key reasons for the
.d2v-VFAPI route in my encoding projects :roll:

I did some playing around over the weekend w/ .d2v and AR diggiting, but
I did have some problems with maintaing the same level of quality that
I got than my regular .d2v-VFAPI route. :!:
Maybe I'll do some more playing around later :)

Kwag.. plus, you have to understand and accept other peoples prefered
mechanism for source feeding into TMPG.. if it works for them in their given
system.. that's what counts. In any case..

-vhelp

Sure it does 8O
That's why I posted the link I did above :!:
It's a piece of cake, and your aspect will always be correct :!:
Here's what you do.
Open your .d2v as "Video Source" in TMPEG. Got to "Crop" and clip out your black borders, leaving only your Film area.
You'll get this:

http://www.digitalfaq.com/archives/i.../2003/08/6.jpg

Now look at the top values on the top left. In my case, it's 718x358. So take those values to Moviestacker, and enter them in the "Film pixel" text boxes.
Now read the "Resize" values that MS gives you, and enter them in TMPEG's "Video Arrange Method" pixels text boxes.
You'll have this:

http://www.digitalfaq.com/archives/i.../2003/08/7.jpg

That's it :!:
Now your movie will have the aspect it's supposed to have, perfectly :!: Just follow the above, as it can't fail ;)
Also, take a look at the link I posted before, as it's a good discussion as to why it's done that way. Sure, I'll accept any mechanismm, as long as it's correct :D
And the mechanism I just explained, is the correct method, as suggested by the experts such as SansGrip and shh (designer of FitCD) specifically for that reason. Any other method is not correct, unless you arrive at the same resize as described above, which is "the" correct method for correct aspect ratio.

Edit: The same method is used for feeding TMPEG with an .avs script. After the "Film pixels" are found, the .avs is written, and then the .avs is opened with TMPEG instead of the .d2v

-kwag

Thanks Kwag, for your alternative mini, mini guide :) to AR your way :)

I'll look into it as well. Case you're not aware, I've ben researching AR
calculations and things, for an AR calc I'm working on. But, the difference
w/ my ARCalc, is that it's derived from formulas (tricky and nasty) The
pics and things are nice, but don't help w/ my ARCalc app project, but I
will definately look into trying out your method for the encoding projects
we've all ben working on, in hopes to be in close sync'ized steps so that we
all experience the same (or similar) results :)

but I'm really interested in getting my app complete.. another tool for the
users :)

Anyways.., I'll do some experiments w/ your methods outlined above, and
see how it compares to what I use currently :!:

Thanks again for your assistance, :)
-vhelp

Thanks. But it's not my method. I learned it from the pro's ;)
http://www.kvcd.net/forum/viewtopic.php?t=2190

-kwag

..well, I ment.., "the pros'" method hehe.. :wink:
-vhelp

I've been encoding episodes of Babylon 5 from DVD, fitting two episodes each. Ripping was done using DVD Decryptor and d2v files created with DVD2AVI v1.77.3. Each CD is always 83 minutes in length, giving an avg bitrate of 1094 according to MS. I'm using the same script for all my encodes, thing is sometimes the final size is either right on or way off. Here's an example:

Wanted size: 710,690,090
Ep 213/214: 736,931,022 (3.69% over)
Ep 215/216: 714,698,247 (0.56% over)
Ep 217/218: 785,231,809 (10.48% over)

This last one is way too big to overburn when muxed with audio! :cry: Here's the script I'm using:The only major differences from the optimal script is I changed the asharp line to (2,4) to increase sharpness a little. I'm also using TomsMoComp to deinterlace the video because all the CGI shots for Babylon 5 are 29.976fps. If I use telecide/decimate to convert the movie to 23.976fps there is visible choppiness during the CGI scenes (but otherwise live action material looks fine).

Any suggestions on what I should do next? I am using CqMatic 1.1.12a. Min bitrate is set to 623.58 and max to 2000.

From my early post in this thread

Wanted vs by moviestacker -738220
Cq Matic v 1.1.12a -799565
for a difference of 7.6% and this was with a cq of 71.65

Cq matic v 1.1.07 i got a cq of 70.21 but unfortunately had computer problems and couldn't fish the encode.

Last night loaded the same avs into TOK and got a cq of 70.345 and got a final video size of 712 782 which is a difference of 3.45%.

This is an avi ,but now my question is i got almost the same cq with TOK and CQmatic v1.1.07 but the size difference is 87 mb from v1.1.12 with only 1.5 cq points.Is it possible to get that much difference with 1.5 points or is it when using tok and cq matic i must have different settings in Tmpge.

Please give opinions because i'm getting :?
Thanx

Two more tests on the same movie "The Rock" ( NTSC 136 minutes, extreme high action movie! ) CQMatic 1.1.12a

1) 352x480 CQ=50.80 Wanted size: 701,053KB Encoded size: 677,781KB ( -3.3%)
2) 352x240 CQ_VBR=28.09 Wanted size: 701,053KB Encoded size: 693,193KB (-1.12%)

Both processed with full MA script, as posted.
DVD2AVI 1.77.3 (Force FILM), precise resizing (from Film pixels) in Moviestacker, TMPGEnc PLUS 2.520. AviSynth 2.52.

Edit: Both done at MIN=300, MAX=2,500.

-kwag

Setting the min bitrate to 0.57 * average-bitrate will likely increase it above the old standard 300kbps, right? So will that not reduce video quality since more bits are used to encode frames that dont need them and the overall CQ will have to be lower? Or did I miss something again?

/girv

Yes, but usually the MIN bitrate fluctuates around 400-500Kbps, so CQ calculations are more accurate than when lowering it to 300.
Unless you're using the ULBR, where the average is very low, and also the MAX bitrate, then you can go way low on the MIN too.

-kwag

I just got done with this a couple minutes ago, and after looking at the log I'm kinda confused at what the correct cq should be ? Should I choose 80.18 or 80? I also see it chose the the same cq more than once. Here's the log

http://www.kvcd.net
CQMatic Version 1.1.12a
Copyright Softronex Corporation, 2003.
All rights reserved.
Time: 11:57:48 Date: 08/20/2003
Ready!
Project: C:\DVD\Kwag070803.tpr

Creating: CQMatic.tpr

C:\DVD\Kwag070803.m1v
Project resolution: 352x240
Execute.
Movie Time: 108
Average Bitrate: 903
Prediction Only mode
Executing Prediction Phase...
Process started at 11:58:43
On 08/20/2003
CQ set for prediction
Setting up initial sampling.
Using CQ of 60.00
Prediction cycle #1
Encoder started...
Process time: 2.55 minutes.
Encoder end.
File size difference = 1.387796
Low fence: 60.000000
High fence: 90.000000
Last CQ = 60.00
Current CQ = 83.27
CQ difference = 23.267738
Using CQ of 83.27
Prediction cycle #2
Encoder started...
Process time: 2.52 minutes.
Encoder end.
File size difference = 0.846521
Low fence: 60.000000
High fence: 83.267738
Last CQ = 83.27
Current CQ = 71.63
CQ difference = 11.633873
Using CQ of 71.63
Prediction cycle #3
Encoder started...
Process time: 2.18 minutes.
Encoder end.
File size difference = 1.243023
Low fence: 71.633865
High fence: 83.267738
Last CQ = 71.63
Current CQ = 77.45
CQ difference = 5.816940
Using CQ of 77.45
Prediction cycle #4
Encoder started...
Process time: 2.47 minutes.
Encoder end.
File size difference = 1.163526
Low fence: 77.450806
High fence: 83.267738
Last CQ = 77.45
Current CQ = 80.36
CQ difference = 2.908463
Using CQ of 80.36
Prediction cycle #5
Encoder started...
Process time: 2.22 minutes.
Encoder end.
File size difference = 0.993907
Low fence: 77.450806
High fence: 80.359268
Last CQ = 80.36
Current CQ = 78.91
CQ difference = 1.454231
Using CQ of 78.91
Prediction cycle #6
Encoder started...
Process time: 2.17 minutes.
Encoder end.
File size difference = 1.140644
Low fence: 78.905037
High fence: 80.359268
Last CQ = 78.91
Current CQ = 79.63
CQ difference = 0.727119
Using CQ of 79.63
Prediction cycle #7
Encoder started...
Process time: 2.48 minutes.
Encoder end.
File size difference = 1.061152
Low fence: 79.632156
High fence: 80.359268
Last CQ = 79.63
Current CQ = 80.00
CQ difference = 0.363556
Using CQ of 80.00
Prediction cycle #8
Encoder started...
Process time: 2.22 minutes.
Encoder end.
File size difference = 1.024969
Low fence: 79.995712
High fence: 80.359268
Last CQ = 80.00
Current CQ = 80.18
CQ difference = 0.181778
CQMatic complete!
Total minutes of process: 18.80
Process ended at 12:17:31
On 08/20/2003


David

It's 80. I've updated CQMatic to 1.1.12b, to show the final CQ ( by Phil's request ;) )
I'll upload it in a little while.

-kwag

Uploaded!
http://www.kvcd.net/CQMatic-1.1.12b.exe

-kwag

The cq of 80 was to big. CQ 80=836,318=816mb
I'm going to try testing it again and see if I get the same value.

David

Hi DKruskie.. evening all :)

If you mean testing CQM prediction, it should still remain the same. I've
done this a few times w/ other CQM versions - - so no need to.. really :!:

Also, I would imagine that if you re-encode again, w/ same params, you'll
end up w/ the same FinalSize.. I would assume :roll:

-vhelp

Is there a big in 1.2.0 where cqmatic says "CQ_VBR set for prediction" when in fact it's set for CQ? It also does prediction in CQ as I specified in my project file... Just noticed this now and not sure if it's always been there or just a fluke I spotted.

@ j-wo..

I noticed this too, a couple of weeks ago, but thought it was a bug that
was already cought, or I missed the explanation. I ignored it since :roll:

-vhelp

hmm well I think something was messed up in my project file, cause my prediction was going bonkers. I'm encoding episodes of Babylon 5, which normally settle at CQ 63. But the prediction was going up to CQ 80 then back down, but got stuck at CQ 63.01. Anyway I remade my project file from scratch and now it seems to be working fine (i.e. it says CQ set for prediction). I'll write back if I have any more problems

Kwag, a little more needed.
 

quote="kwag"
It's a piece of cake, and your aspect will always be correct :!:
Here's what you do.
Open your .d2v as "Video Source" in TMPEG. Got to "Crop" and clip out your black borders, leaving only your Film area.
You'll get this:

Now look at the top values on the top left. In my case, it's 718x358. So take those values to Moviestacker, and enter them in the "Film pixel" text boxes.
Now read the "Resize" values that MS gives you, and enter them in TMPEG's "Video Arrange Method" pixels text boxes.
You'll have this:

That's it :!:
Now your movie will have the aspect it's supposed to have, perfectly

Given the above, what modifications do I make to my AVS, either using GripCrop or using values from Movie Stacker in the script?

Re: Kwag, a little more needed.
 

In order to enter the "Film Pixels" into MS, you have to deselect "Use Gripcrop" on the first tab of MS. When you then look at the script that MS creates, you'll notice there are no GripCrop or GripBorders lines. Instead you'll see something like:
These are the lines you would then use in replace of GripCrop. The first line would go where GripCrop used to go, and the second goes where GripBorders used to be. Good luck!

Re: Kwag, a little more needed.
 

Understand. Thanks!

Kwag, probably just another dumb question..........
 

On the tmpgenc screen, you show crop checked. Is this necessary when I use moviestacker to produce script statements using the tmpgenc pixels as you have described in other posts?

Re: Kwag, probably just another dumb question..........
 

No, because the script produced by Moviestacker takes care of the cropping automatically, so it's already feeding the exact film pixels to TMPEG.

-kwag

Re: Kwag, probably just another dumb question..........
 

Great! I am processing with the MA optimum script at present. The CQMatic passes are going much faster than with the non-MA with 2.08 and I look forward to seeing the results. I assume motion should be smoother with the MA script.

addborders() error
 

Running MA optimum script with Avisynth 2.52

AddBorders(16, 33, 16, 33) gives error when TMPGEnc starts:

Evaluate: Unrecognized exception!

Is there a dll containing Addborders() different for 2.52. Only this function gives a problem.

Trying to use:

LoadPlugin("c:\video\dlls\GripFit_preview.dll")

gives me a error saying that it is not an Avisynth 2.5 plug in.

I'm trying to use movie stacker data into my avs.

hey nick,
use the word "latexxx" in the search and you get
the gripfit yv12 for avisynth 2.5x!
:wink:

thanks again(tons) latexxx!
:wink:

Here, http://www.nic.fi/~lhahne/GripFit_YV12.zip

Excuse me for opening an old topic (I am playing with the two versions of CqMatic (12xx & 13xx), and was looking for comparisons when I came across this.

Kwag - is there anyway to get those crop values (in the picture, the 704x272) in tmpg without using moviestacker?