Ok, that would be the same result . As long as they are both the same size, then a comparison can be made.

-kwag

OK Boys and girls,

As a follow up, here are my new numbers with the Notch 2 beta Q.Matrix.

Old Numbers:
New numbers - Same encoding methods, but new Q.Matrix
So as you can see, the 2xVBR encodes didn't change much file size wise, but the CQ encodes did.

Quality wise, as I said, the 2xVBRs are great. The CQ encodes are very much improved with the 1-4-1-1-18 GOP being slightly better overall. However, it is larger than the CQ encode with a GOP of 1-5-2-1-18.

Why do I use 1-5-2-1-18 as my standard GOP ? I found that it was capable of a good balance between stability and compression. I found that Kwags GOP for the KDVD template of 1-18-3-1-18 was causing some jerky image problems as well as occasionally missing some scene changes .........

Anyway, as I said, I will now be working on bringing down the 2xVBR encodes to that same file size range as the CQ encodes .........

Later y'all ..

OK kiddies,

Have some new results here and what I'm finding, much to my own chagrin that the 2xVBR encodes that are roughly at the same file size as the CQ encodes are not as good quality wise.

Now you have to under stand, I have always been a huge supporter of xPass VBR encoding as the principle behind this approach makes perfect sense to me.

However, I'm not closed minded either & when I first came across Kwags KVCD & KDVD templates and saw that they used CQ_VBR or CQ I said OK, tried some tests comparing the various methods and settled with Kwag's way of doing things. But in the back of my mind, still thought xPass was better.

So now here we are with another challenge to KDVD and once again when your parameters are best quality for least file size, on KDVD with Kwags first Q.Matrix or the new experimental one, the CQ encoding methods do indeed appear to turn in better results.

So once again, I'm proven wrong .... But I'm happy 'cause I still get really fantastic encodes regardless of the methodology.

Anyway here's the latest numbers ....

Two sets of tests were run, using a GOP of 1-5-2-1-18 and the other using 1-4-1-1-18.

The goal wast to bring the 2xVBR encodes down to the same filesizes as the last set of CQ encode tests that I performed.

Now don't get me wrong, the encodes look very good, but even #4 from this test is not quite as clear of mosquitos as #2 from that last round of testing.

I do find that even at the cost of a larger file size, the tighter GOP produces better results, I honestly don't know yet whether it's enough of an improvement to justify the size increase .....

More testing will go on ....








P.S. Dig the new emoticons..

Hi MoovyGuy and others,
I haven't tried CQ mode, what I have doing is to use CQ_VBR mode (with GOP 1-4-1-1-18 and Kwag's matrix) and use TMpeg's built-in size predictor (Wizard) to reach the targeted size. I am pretty happy with the result so far (by using CQ_VBR mode). The wizard is pretty accurate which allows you to adjust the average bitrate.

Side issue: I had a terrible error recently, I did not know what have I done wrong (I might have checked "Output bitstream for edit") and encoded the whole movie spending 3.5 hours. when I open the m2v, PowerDVD just show me a black screen, it appeared that the movie was running (the time was moving), but the length showed in PowerDVD was only 1 minute or so. It showed the correct size in file manager.

Hey syk2c11, howz it going ??

I remember something a while back about using CQ_VBR with KDVD. Something about it being a no no.

Kwag, do you remember any issues with it ? I seem to remember that when when you switched the KVCD templates over to CQ_VBR, that some folks had trouble with the KDVD templates set that way. Something about compatibility that didn't seem to be a problem for CQ.

Can you confirm ?

Anyway, about the closed GOP. I've made many encodes where the GOP is closed and never had any issues other than the fact that the file size of the encode tends to be larger than when it is open ....

Every once in a while though, I'll do an encode & when I open it in PowerDVD it'll freeze on the first fame & not play. I can run the jog bar through the clip, but it won't play. WinDVD or Hollywood+ has no problem though ..... not a big deal, but a little annoying .....

Sorry for causing confusion. I meant GOP (1-4-1-1-1 with 2xVBR mode, I mis-typed it! As mentioned earlier, I just play around with the average bitrate and it will lead me to the targeted file size.

So, have you decided which one to use yet (CQ or 2xVBR)?

Well so far I've produced about 12 DVDr discs that have two full length movies on them, 1 with 3 movies (half-D1) and a Lord of the Rings extended edition on a single DVDr.

For every one of these encodes I have used CQ encoding.

Each time I deal with a new source, I repeat the same type of testing that I have here, comparing CQ to 2xVBR with my goal always being best quality for resonable file size. That size being around 1.8 gig. I always end up going for CQ.

The reason for my 1.8 gig target size ? This size allows for mistakes in judgement and for the average size of 350 to 400 meg for the AC3 5.1 track.

So using these parameters I usually can make a 2 in 1 DVD first time out. And of course encoding CQ is considerably faster with only the one pass.

Does this mean that I would never use xPass encoding? Not at all, I'm always comparing, testing, judging ....

Who knows, maybe I or someone else will come up with a Q.Matrix that is better suited to xPass VBR. But Kwag's most definitivly favors CQ or CQ_VBR.

Come to think of it, I do have another test that I want to run ... It's based on an SVCD template that I picked up a while ago. This template, I've found, does favor 2xPass VBR. I used it exclusivly when making pure SVCD's as I find the quality of the encodes produced to be second to none...

I'll letcha know ...