There's no big change in the core of CQmatic needed, just one pre-routine.

- Start Calcumatic. A new option in Calcumatic will be added like "count of (x) Movie streams to predict for one target". When selecting each of the (x) Sources in a List_Gadget then Calcumatic in the backround will create an avs as followed:
- Use Calcumatic to obtain the needed Value incl. the Number of Audio streams and Bitrates BUT the # of video Streams in the Number_of_VideoStreams_Gadget is now forced to only ONE video Stream. And Calcumatic uses vfw API to parse out the time of that generated (moviecollectioned) avs.
This will output the exact value used to be used in CQmatic


- CQ matic launches
- Import the MovieCollected.avs generated above in CQmatic.
CQmatic runs and after some time the resulted CQ comes out.
Now CQ Matic does delete the moviecollected.avs and encodes the both "My_first_Movie.avs" and "My_second_Movie.avs" separately one after one.

The result will be 2 mpegs incl. diff. sizes BUT SAME quality and Everything needed (Audiostreams, both mpeg encodings etc) will match on ONE DVD-R or the size of the target you did set in Calcumatic.

DO it Karl 8)

But as Karl lives in a nice shiny country which rises the mood ... here a much more individual approch:

On this approch NO temporal avs generating is needed!

Forget my post above as CQmatic wants TPR fiels to be imported!

(for making it easier at least for me *lol: Calcumatic = CM, CQmatic = CQM)


- In CM you choose in a Gadget the count of movies to be predicted for ONE target which is determined below in the target gadget.
Import each source, parsed in the way CM uses now. CM gots the total movietime result by adding all movietimes of the imported sources.
Set the numbers of audio channels where each audichannel has to be set to its INDIVIDUAL bitrate/size. Internally CM adds all kbits of the audios to one sum of audio size in total.

Finally you got a Value to be used in CQM.

- In CQM you do import in a listgadget the count of the Prebuildet TmpgEnc text project files of the movies parsed out in CM before.
Run CQM and NOW every prediction turn does predict movie1 and movie2 one after one. (Or the count of movies to be fit on one traget)
CQM looks for the resultet Bits of movie1 and movie2 where shurely the same CQ was used ... the sum of both stands for the final resulted amount of bits of THAT prediction turn.
And CQM runs its predictions in the way expl. the line above.
Finally CQM encodes theses (in this case) both movies at teh resulted CQ one by one.

Finally you got both m2vs on your disk (same quality, but diff. sizes!) which do match (incl. all the Audio etc.) exactly the size of the determined Target as set in CM.

This allows individual TPR files based on diff. matrix/GOP/DCT or whatever settings. Means if you want a DVD-R containing 1 progressive 23.976 movie at 720x480 and 2 interlaced 29.97 ones each of a size of 352x480 .... then this is possible

Enjoy.

My idea is:
To do sliced samples of all your targets, at a given Q, whatever be the encoder. Let's say all samples are 5%.
Each one of those samples, have an amount of bits related to it "complexity" or motion.
Then, sum its sizes and later divide each individual size by the sum. This will give you a proportion. Apply it to a media size (minus audio and overhead) and you will have your destination target size. Do calculations with time (or frames/fps as I want to do in my tool if I someday could finish it) and you will have an avg bitrate to use in 2pass VBR.

Hi Andrej :),
Nice seeing you on the move with this idea - not a new one for sure but I nice one to explore :).
This thread is getting much much interesting.
I've dropped Tmpgenc for quite some time.
Currently I'm mainly using HC 0.15.
For now, predictable CQ encode is almost impossible on HC, but nothing that Hank can't fix in a near future ;-).
But I'm quite sure that it works with HC in 2-pass VBR.

@Karl,
Your welcome and it's always my pleasure :)
If you find this method feasible and positive in a way that you decide to implement it on Calcumatic, would you please consider making CQMatic compliant with HC also?
I know Pedro has done a wonderfull job with DVDREasy, but that's a one click tool for just a single movie from DVD-9 to DVD-5.
Here we're talking about a video encoding prediction tool :arrow: not a single click tool.
Also here we're talking of many movies whereas DVDREasy was made for single movie.
Would you please consider that?
Please, please, please? :)
I'll be your beta tester for the rest of my live :lol:.
Cheers

In HC? 2pass?

Easy:

Do use an avs script

Slice() it!
Do encode 2pass at the "needed" avg bitrate.
Write down the used Q value out of HCs ini file.

Do encode both avs NOW separately using the resulted Q at the same slices used as before.
Watch the resulted kbs of each stream and according to the used amount of film (%) and its minutes/sec you obtain the used avg bitrate of !each one!.

Encode both separately using the resulted avg bitrates (the will be different ;) ) of each.

Hmmm,
But that means I'll be apllying the same script to both movies...
Or am I wrong :roll:?
You see, I have some movies that need higher filtering (due to visible artifacts even on the sources - bad mastereds...).
In such sense I would need different avs scripts for both movies.
Though it is a very nice way for similar movies :).
Please correct me if the above assumption is wrong.
Cheers

I am not at home right now, so I can't test this.
But it seems to me that it will be impossible to encode the same slices.
Since with the mentioned script movies are joined, my above assumption seems obvious.
Can you comment on that?
Cheers

You can merge individual script of the SAME size, SAME colorformat.

As you see I do imort 2 different avs scripts into a generic avs script incl. merging them finally

@Andrej,
Either I'm not catching up on your line of thinking or I didn't express myself correctly.
I mean, some of my sources are not as good in quality than others.
In such sence, sometimes I apply more filtering on one movie than on the other movie being encoded for the same DVD-5 backup.
With your example script, you're merging both movies using the exact same filtering for both of them, aren't you?
That means that I can't use different filtering on each movie with it.
Or maybe I'm just confused because my knowledge on avisynth is less than good.
So correct me if I'm wrong.
Cheers

You are wrong.
Your first "avs" imported is a normal avs with resize, crop and filtering for one of your movies.
Your second "avs" imported is another different normal avs adjusted to your 2nd. movie needs.

This last avs script have not another lines, only those that Incredible point you.

Inc approach is the one I suggested in my previous post.
When you apply both films the same Q (obtained through sliced prediction) each of them will make use of those bits needed to mantain the Q.
No need to find percentage of space in media. Just predicting both films together, to fit media, and obtain Q for both of them.
I see it cristal clear. I'm sorry I cannot find the proper words to explain it. Inc is explaining it far better.

We are talking about 2 differents things. I understand you perfectly. Also I understand Incredible. It seems that you don't understand me, Im sorry, my english is really very bad.
Im looking or wish a integral tool, not only to find Q values to Q encodings, but proportional space for 2pass VBR encoding. In these last ones, you need to do first sliced samples of each one, find out the proportion and apply that at de total media space (minus audio and overhead, of course).
Can you understand me?

Yep. I agree, and that will work perfectly.
Create a .d2v project of all your movies (2, 3, etc.), and then run CQMatic.
It will then predict, based on the complete footages, and find one optimal CQ value.
Use this found CQ value to encode all the movies that were loaded in the .d2v file.
The result will be a different file size for each movie, optimal in bitrate allication/quality, and the sum of all movies should be close to the target media.

-kwag

My previous post explains just that. Proportional sizes will be created for each movie, if prediction is taken into account as a whole. That is, predict with all the movies/footage as a single stream.

-kwag

If you could devellope such tool. It would give us not only a Q value, but an avg btr for each stream, in case somebody want to do a 2pass vbr encoding?

Well, not really, because the above would find the correct CQ, but there's no direct relationship of CQ vs. average bitrate.
What I described would indeed find the correct CQ value to encode each movie, but there's no way to tell what the size of each will be, until all movies are encoded.
So this is a good technique for CQ, but not for x-pass.
The only way to use x-pass with this, would be to do what I mentioned earlier, and that is to make a tool that would somehow analyze the sources activity.
And still, I think this won't be accurate, because there's no relationship from the source's activity to what the encoder will create from the source.
So for x-pass, the methods you are describing above, to sample each source and try to predict a size per movie, would be the only approach for an x-pass encode of multiple movies.

-kwag

Yes Karl, thats a ver good thought.
And I DO understand you Luis.

Read my 2pass-way suggestion:
http://www.kvcd.net/forum/viewtopic....r=asc&start=84

Thats exactly the approach.

As if you do a 2pass on all streams as ONE the bitrateallocation will be proportinally much more efficient!

So IF we got 3 Movies

1. Very calm Theatre Movie
2. A medium complex Commedy Movie
3. A high complex action movie.

Lets assume we do find out that we would need ca. 1500kbit average on ALL to fit all of them to one DVD-R.

The first movie would come out in a MUCH better Quality compared to the third as the SAME avg Bitrate was determined which causes a Q/VBR curve proportionally to the movie complexitivity and avg bitrate.

So if you would encode ALL using the same avg in ONE pice. The bitrateallocation VBR/Q curve would take the whole movie into account.

Did I got it? I think so .... I never needed 2pass so In Q mode its a technique I do already for a long time. But as it seems that (after mencoder) now 2pass is still the goal in here, so this above is the other way around for obtaining CONSTANT Quality on a number of Streams one ONE target media size.

;)

Crystal clear :)

-kwag

Don't understand.
So let's take same example.
1 - If we encode samples with same frame number (not same %), with same CQ value no matter how it be (or Q, really I don't know the difference), we will obtain 3 samples of differents KBs. All with same duration as we suppose all have same fps.
2 - This different value is doubt to different complexity or motion in the picture.
3 - Now sum (film1_KB + film2_KB + film3_KB) and divide each film_KB by the result:
film1_KB/(film1_KB + film2_KB + film3_KB)= proportion_film1
film2_KB/(film1_KB + film2_KB + film3_KB)= proportion_film2
film3_KB/(film1_KB + film2_KB + film3_KB)= proportion_film3
4 - Now take whole media size minus audio and overhead = TotalSize
and multiply it by each proportion:
TotalSize*proportion_film1=film1Size
TotalSize*proportion_film2=film2Size
TotalSize*proportion_film3=film3Size
5 - With this values you can calculate avg btr for a 2P VBR encoding for each movie, and your 3 movies will have same visual quality.

I think so, but you know about this, a lot than me.

I like CQ encodes, much than 2P VBR ones.
But there is people for all tastes, and other that don't like so TMPGEnc.
I think that people can have 1 oportunity to select whatelse of 2 methods, both obtaining best quality possible. And this is with "available space proportional allocation" (ASPA).
BTW did you like ASPA name for all this stuff? :D

And here begins the problem. Read my link above. We have to find out HOW the bitrateallocation will be don one %based Samples.
What happens if NTSC people want to author a DVD including progressive 23.976 and 29.97 content .... I mean, IF you want to give people much more encoding possibilities like ovp and 2pass, then this "same fps" issue above will already lower that approach in its purpose.

Hmmmmm .... I cant follow you still do obtain a Q based proportion out of slices using a fixed framecount? In which relation does that framecount stand to? Every Movie gots a diff. amount of frames.

I do Q based encodings using mencoder (yes), Nuenc and most of all using CCE! So nobody has to stuck with TmpgEnc (which still gots its superior tweakable settings AND a very good Quality if set correctly .... If speed doesnt care).
I have been reading in here about these prediction Issues on HC. OK that one would be a reason to encode using 2pass (if theres really an issue).
BUT that Encoder is still in Beta State and I think it makes more sense that the code author looks into the Q based encoding routines (IF theres really an issue which till now I havent testet, and for shure not proofed).

There are so many People and their unique tastes, but .... I think developements should result in the best output and there's even on HC till now not the final conclusion given, .... but anyway, this subject in here MAKES fun :)

Available space allocation?? IF then its an out of Quality based varaible Bitrate allocation, as thats the deep procedure/purpose (just IMHO - as I understood it like that ;) ).

? A name for still an approach in "thoughts" where we are just rumbling around big theoretics.

Lets wait for WELL proofed facts. Do you know how long it took for CQmatic to run in its special routines to work in a state it should be? ;)
Or till the Roba/Robshot CQ theory approach was running as it does now.

For me personally I see no sense in 2pass if time (not someone) proofs that its superior then CQ mode. Thats why I still beleive in more potential of integrating that (already known) approach of full merged movies slicing in CQmatic/Calcumatic.

This is/was NO offense to your thoughts!
Its just a reminder for "US" to still keep our feets on the ground - till things really do work! :D

@Inc: That 2 pass aproach doesn't worth as cq given in HC Encoder log file is not the correct when used in cqmaxbitrate mode as in this mode the encoder do "cut" bits that doesn't brings back to the stream.
If you use cq mode, you have a high probability that your streams can't be load in any dvd author program, neither play in any SAP.

Yep thats what I called "the issue Ive heard/read of".

So maybe that will be fixed sometime in the near future as its possible to do mpegencoding by keeping the compilancy in CQmode without "cutting" peaks afterwards .... but I do keep my head low as I dont have any clue about that complex programming of an mpegencoding engine from almost scratch.

The used avg Quant CAN be parsed afterwards by HC encoder and putted/changed in the log. Thats stored in the flow of the mpegstream somewhere I dont know exatly ... as Bitrateviewer is also able to parse the FINAL existing Q values out of a ready encoded mpeg stream. So a final last step mpeg parsing could switch that value in the log text.

You can see a tool as I was talking here:

http://www.kvcd.net/forum/viewtopic.php?t=15979

I don't understand why all about calcumatic/cqmatic is here in this thread. It seems that we don't open more threads in this subforum and I don't know why. 8O
But anyway:
@Kwag: Could you explain me this:

http://www.digitalfaq.com/archives/i.../2005/07/1.png

You can see that calculated avg bitrate = 5511.9 kbps

103' 49'' = 103,8206667 min

103,8206667 * 60 * 5511.9 / 8 = 4291868 KB

And calcumatic shows 4191088.

Similar about audio:

103,8206667 * 60 * 384 / 8 = 299003 KB

Why calcumatic does it in this way?

Because you're missing a small detail :)

( 103,820.6667 * 60 * 5511.9 / 8 ) / 1.024 = 4191277 KB

And ( 103,8206667 * 60 * 384 / 8 ) / 1.024 = 291995 KB

(Results are rounded)

That's why CalcuMatic will give you EXACT results, and you can confirm that if you do an average bitrate encode (2-pass), and then compare the file size on disk (with Windows file manager) against the size CalcuMatic gave you. The result will be almost identical ;)

-kwag

:douh:

Also I misstyped , (commas) by . (point) as in north american way.

I know :lol:
Took me a second to figure it out :mrgreen:

-kwag

Then if:

(103.8206667 * 60 * 5511.9 / 8 ) / 1.024 = 4191277 KB results are KB

what units are

(103.8206667 * 60 * 5511.9 / 8 ) = 4291868

:imstupid:

Kilobytes. Based on 1000 bytes, instead of 1024 bytes.

-kwag

Hmm...
Since you're dividing by 1024 to get to Kilobytes, it means the previous figure should be bytes based in 1000.
Am I right?

Not.
He is dividing by 1.024 (decimal number).

No he is not.
He's grouping digits :lol:.
1 Kilobyte is not == 1,024 bytes.
1 kilobyte is == 1024 bytes.
That's what Karl is doing.
He is dividing by 1024 to reach Kilobytes.
Cheers

Yes he is :-)

Karl is is dividing by 1dot024. Not 1024 (that is 1comma024).
And he does so because "5511.9" is already in 'kilo' (kbps = kilo bit per second)

The problem is : is 5511.9 in base 1000 or 1024 ? That is perhaps the question you asked Rui.

Phil,

let me answer for Rui:

in portuguese, the decimal separator is "," (comma) while the thousands separator is "." (dot) - that's why the confusion.

so one and twenty four thousenths is 1,024 ("in portuguese") and 1.024 ("in english") ;
One thousand and twenty four is 1.024 ("in portuguese") and 1,024 ("in english").

I know. That's the same in all Europe.

Ok.
I got it all wrong :lol:
Karl was really talking about 1 dot 024.
I did get confused because usually in my calcs I use bytes and not kilobytes where I divide by 1024 to reach kilobytes in the end.
Sorry guys.
BTW I don't see why doing the calcs using movie time in minutes and seconds while we can do it in frames which is a much more accurate measure.
Cheers

To avoid confusion between 23.976 and 23,976 :D

BTW Did you test and compare ProCalc, based on Boulder spreadsheet?

You joker :twisted: :lol:

Not yet.
My PC won't let me.
I mean I have downloaded ProCalc and all but it won't start even with the VB6 runtimes...
Too many DLL's all screwed up or something.
It's a miracle that I can still browse the web on FireFox.
It's slow as hell and I was blaming my ISP :lol:.
All started happening from the moment I installed avast for testing and they uninstalled it to go back to avg free :roll:.
avast uninstaller presented me with tons of errors and froze my pc.
I had to hard reset it and then I got presented with a lot of errors on boot.
I shall reinstall XP and I'll let you know then.
When will I learn that I must do some XP images for times like this when things get difficult :?
Cheers

ProCalc info minutes and seconds so in that way ASPA (Available Space Proportional Allocation) is compatible in a straight way with CQmatic, as it require min and sec as input plus avg btr and TMPGEnc project. But, "in fact" ProCalc do all calculations based on frames and fps.
You know, same than Boulder spreadsheet.