What "space" :?:
Isn't it to the same target space, which will always be fixed :?: (DVD-5 ~4.3GB, 800MB CD-R, etc.)

-kwag

My 2 cents...

What I usually do for a 2 film KDVD is to build a script with the 2 films I want to fit in KDVD, and with slicer. And run prediction.
I end with a Q value that is the same for both films... are they supposed to look the same quality with same Q value?. I thought yes.
Then I encode each of them separately, with the Q obtained. And each of them have a length (Kb), depending on their lenght (seconds) and bitrate (same Q for 2 different films will need different bitrates, depending on film complexity).

Is this what you all are talking about?. I'm afraid not. And maybe it is not of a help since you talk about CalcuMatic and finding out avg bitrate, and not Q. But just in case it is of a help...

The same point of view here DigiDoc.

I also just got into this subject ....

That approach is meeeeeega old and works flaweless ;)

I think what "they" try to explain is, same Bitrate doesnt mean same quality.
But If I want to have 2 Movies on one DVD-R I would also like to get a linear subjective quality on both films to be the same in their visual quality.

So whats responsable for visual quality "during the encoding" (not that avs stuff before):
Mainly the quantisation.

So if we take two movies, one action Movie with much uneasy water scenes and the other one is just a mainly dark one and do encode them using the same quantizer both will kome out at different sizes.

So what is beside other things the Goal of CQ/OVP encodings? Its the keeping of a qunatization to be at the almost same level during the whole movie = Almost constant Quality.

Take "Message in a bottle" and use in TmpgEnc a CQ at 80
+
Take "Seven" and also here do use a CQ at 80.

Seven will take almost 60-70% of the final size of "Message in a bottle" cause MessInABot. gots a lot of uneasy Waterscenes but both will have the SAME quality as we did our focus on the CQ when predicting both movies and not on the Bitrate.

Both Movies together will have an amount of needed Bitrate. So if that amount of bitrate overheads the wanted final bitrate for fitting on one DVD-R, we just lower the CQ on BOTH using the same value and we still keep both Movies at the same Quality but STILL different Bitrate.

Thats the way I did all my 2Movie DVD encodings till now and my eyes did underline that subjective recognisable constant quality when watching both movies of THAT DVD-R where they both are authored to.

So for me thats for 99& clear, ..... but every discussion is intended to maybe result in new things, so I keep watching :D

Suposse you have 2 movies * 100 min each one, one with high action scenes the other a drama.

If you want to fit any of them, twice in 1 dvd (forget audio), each one will fit 2202 Mb aprox. or so.
If you want to fit the 2 differents movies in 1 dvd, each one will fit 2202 Mb if you do calculate as usual.
If you do slicer samples with same CQ and see its final bitrates, you will see, for example that one have avg btr = 3500 and the other 2000.
If you apply calcs that the spreadsheet gives you, the target size won't be 2202 for each one. It will be big for high motion movie.

Please I beg you take a look at the spreadsheet, if you are interested in doing such kind of tool. If not I will be ahead with my one tool, and will do that I can.

Of course, and that's clear. :)
But the total size of both movies (or any total of movies) still HAS to be no larger than the size of the target media, and that's what I'm trying to make you see :!:
Remember :arrow: your target is FIXED :!:
You can add bits to one movie, and take bits from another movie, but the total number of bits MUST BE the same, because if it's not, then it will either be over or under the wanted target. That's what I'm trying to say.

-kwag

@Inc: What about 2 pass vbr encoding/encoders?

Maybe Boulder could explain it better than me.
I am not specially brillant with my english today.

I understand that.
For that you can see in my project:

http://www.digitalfaq.com/archives/i.../2005/06/9.png

last two columns avg kbps for final video and Kb for final video (forget values you see in picture, it don't reflect correct calculations).
After calculations you must to use that avg bitrate to fit that Kb for each individual film.
I don't talking about TMPGEnc or whatever CQ encoding, but 2 pass VBR ones.

Forgive me for butting in here I know im a relative noob and most of this stuff just goes over my head but looking at digitall.doc's post above could we use that method to calculate a two movie KDVD.

To find the correct Q factor could we not say split the target size for example 4482 MB and divide that by 2 to say 2241 MB per movie and use what Q factor we get from the two seperate scripts and their movies?

Just an idea, please go gentle on me and don't flame me to much. :D

Hi Michael :)
Of course you can do that.
Actually that's what I've been doing for almost 1 year.
But that's IMHO totally screwed method.
Because following your words above, if you have 1 movie with 20minutes and another one with 220minutes...
:arrow: Then your 20mins. movie encode will most probably look exactly like the original and your 220mins. will most definitly look very poor quality :arrow: bad bitrate allocation :mrgreen:.
So, what I've been saying is that we should try to share the available MB not equaly but proportionaly.
Again imagine that you have the same 20 vs 220.
You do your math and you get to the conclusion that just by looking at their duration you should target the 20mins. to 400MB and the 220mins. to 4.000MB.
BUT you forgot about something!
Since the 20mins. are (for instance) underwater action and the 220mins. are drama, you end up with a 20mins kinda ugly encode and with a veeery good drama encode.
What do you need to do then?
Spare some MB from the 220mins. encode to the 20mins encode so that you get ~750MB for action and ~3.650MB.
Maybe now you have 2 movies perfectly fitting 1 DVD-5 with almost the same quality ;-).
I really can't explain it better than this.
Cheers

And it is the better explanation I could to give (If I could express better in english, of course).

I don't know why Karl don't want to take a look at the spreadsheet.
It is very clarifier about what we are talking about.

Hey, Karl didn't say he won't look at it.
One thing we can't say about Karl is that he is not open minded.
Actually he may have already taken a look at it and spotted a mistake on it.
He is probably trying to tell us we're wrong and we're just not listening :lol:.
Looking at the spreadsheet or not we'll end up sorting out this issue, that I am sure of :).
Cheers

@rds_correia

Thank you for your clear explanation in response to my last post, now I fully understand the dynamics as there are so many variables to take into account.

So even if both movies were say an hour and a half, 3 hours in total and one was a drama and one was an action movie you would still not evenly distribute the bitrate needed in proportion.

Now I understand why these extra details need to be taken into account.

Again Rui thank you for such a clear explanation now I fully understand what is needed. :)

No need to thank Michael.
That's what we're here for :arrow: to discuss and to clear these issues and all are welcome to the discussion :).
Cheers

Sorry, I didn't want to give to think that. :oops:

And that was the key for my brain to trigger and understand what this is all about :lol:
Even though ALL movies will still have to have the average bitrate sum equal to the wanted for the final size, each movie should have a different size allocation, depending on the type.
For example, two movies on one DVD. One action and one drama.
The action movie might require 3GB, but the drama would only require 1GB.
So we need a DIFF calculation between both movies, to get a % offset for space allocation.
For example the drama's % will be 25% and the action will be 75%.
This way, the media (DVD, etc.) can be pre-splitted before CQ calculations are performed. Right :?: :D
Well, what we need is an MPEG parser/analyzer that can quickly analyze each source (VOBs, etc.), and generate that wanted % automatically.
After analyzing both movies, or more movies, it automatically decides what slice of the pie (space) will be allocated for each movie.
Guess I should crank up my dev system and run some experiments :cool:

@Rui,

Thanks for the enlightening chat on Skype ;)

-kwag

:ole:

And for that I was asking how to use a dll from VB6.
I think we need to use:

mediainfo - lib

http://sourceforge.net/projects/mediainfo/

It shows between another things, stream bitrate.

Now that is a really interesting idea Karl, and the method you described here sounds like a excellent one, I wonder how difficult this would be to put into practice, I hope not to difficult.

I hope your experiments turn out well, this could be very exciting. :D

@rds_correia

Thank you Rui, you are a real Gentleman, as are all the guys on this forum. :)

The mean approach is clear, to give space to each movie proportionally so both result in same quality.

But what do you expect by analyzing the "sources" bitrates of each?

Lets guess one source gots an average of 6000kbit and the other one only 5000kbit ... that would mean nothing as finally the 5000kbit source could be the one which needs more bits by keeping the same average quality than the 6000kbit one. ---- So the 5000kbit one was just encoded that "low" as the DVD-R did contain much more extras/motionMenue etc.

The only way is to parse out the m2v Videocontend on its included AverageQ!

Then you can make a calculation on the simple math of movietime and kbits incl. the difficult to parse out average Q of each movie.

That shows the proportion of a resulted quantisation at xxxxKbit.
But also here .... quants are different from encoder to encoder, so you would have to use the same encoder as the productioner of the DVDstream used ..... and that we also could parse ... if!! stored in the mpeg header.

Mediainfo.dll doesnt show Quantisations and the avg kbit calc is a simple math.

Take a deep breath .... and reset your thoughts ;)
2pass is NOT quality based.

2pass is exactly the opposite, as 2pass forces to reach the wanted avg Bitrate and not the wanted Quality.

Means you would have to encode slices in 2pass and parsing out the average Q and by that increasing/decreasing the avg values to obtain the Quality you want.
But thats like breaking into the locked back door of house where the main door at the front is unlocked and left open - just get in ;)

HC encoder does output the used avg quant, but as we know we shouldnt trust in that value for continous OVP usage.