I suggest trying both and comparing :). I was very surprised at how different the results of my last test were...

0 and 0.

Same here. I forgot to say that on my previous posts. :roll:

-kwag

@SansGrip and Kwag,

My spoilage settings are 0 and 20 the template default. I sure
wish I could get on the same page as you guys. I bet you both
are using settings that most, if not all, of us are unware of and
that's why the samples look so great and we can't duplicate them. :(
I'm vasilating between KVCDx3 CQ and CQ_VBR. Blockbuster
dither set to it's highest shows no effect with CQ at any setting.
This is very frustrating :? I wish I could duplicate Kwag's great
looking samples once and know how it was done step-step
to get the same results :?

-black prince

There's something wrong there black prince 8O
If you set to something like this: min_detail=1, max_detail=10, variance=50 8O you don't see the effect 8O

-kwag

We're on the same page. Just maybe not the same sentence :). I'm starting to think that there are no "best" settings, only settings that are best for a particular source. For example, I had no idea it would be possible to fit Minority Report (2h20m) on one disc at 528x480, but I managed it with CQ mode and it looks really good, much better than 352x480 CQ_VBR. This is mostly because it was filmed in Cinemascope, i.e. 2.35:1 aspect ratio. Lots of black means lots of compression :).

Right now I recommend CQ_VBR for 352x240 and 352x480 with noise or dither, and CQ for 528x480 and 704x480 without noise or dither. With CQ mode I use a spoilage of 0 0 -- I don't remember precisely why, but I know it gave the best results in one set of tests I did.

Aside from that I believe that the correct preprocessing is important for good results. I'll sometimes increase smoothing significantly if I'm having trouble getting something down to size. I find the resulting increase in CQ/CQ_VBR level compensates for the sharpness you're taking out.

I also find bilinear resize to be overall the best method. It's recommended by many people when reducing rather than enlarging, and is the most compressible of all the resizing methods.

I've not tried dither with CQ, but I know that noise doesn't have an effect until CQ goes over about 80.

Perhaps kwag could post a step-by-step along with his next sample, then we could all learn from it. I don't think mine look as good as kwag's, either :).

Ditto! :D Ditto #2 :wink: I DO see effect using dither even at 528x480.I will later tonight :wink:. I'm multitasking between the computer and real life ( wife and kids ! ) today.

Edit: I still see a small advantage by using a very small "dither" even at 528x480. Something like this: Blockbuster(method="dither", detail_min=1, detail_max=10, variance=.4, seed=1)

-kwag

@SansGrip and Kwag,

Thanks, for the explaination. It makes sense. :) One solution doesn't
fit all. Each movie seems to be different in terms of settings and
testing. The suggestions you made are very helpful. It seems each
movie requires expermenting to get the best picture quality. I
intend to buy "Signs" next and will put some of your suggestions
to good use. :)

-black prince

SansGrip,

Are you using "Fast" motion estimation, or are you using "High quality" :?:

-kwag

I'm using high quality because I found it gives smaller file sizes. I've yet to do a visual comparison though.

I think I would make two sets of samples, one with CQ_VBR and one with CQ. This way we know for each source what works best, and it should be possible to develop some guidelines for what kind of source requires what method of encoding.

As I promised earlier today, here's my latest sample. First, here's the script used:

Here's the sample: http://www.kvcd.net/k-19.cq.65.5.hig...1.dither.5.mpg

This was encoded at 528x480 using CQ mode with a value of 65.5 ( target for one CD-R ) and using "High quality" on motion estimation. Audio was encoded at 112Kbps with "Surround 2" ( Prologic II ). This sample includes audio :wink:
The complete multiplexed .mpg file size is 792,421KB :mrgreen:

SansGrip,
Let me know how this sample sound on your new receiver :D

-kwag

Just a counter-point to the bilinear resize... Lanczos gives me _much_ cleaner results, with only minimal loss in compressibility. An 11.68meg clip done with Lanczos only dropped to 11.57meg with bilinear. Granted, this adds up slightly over the course of a 700meg movie, but the tradeoff wasn't enough to give up the sharpness and clarity provided by Lanczos. Granted, this may be impacted by my source, but don't throw out Lanczos yet. (I didn't try substituting Lanczos with bilinear+blockbuster sharpen).

Hi Daagar,

At least at 528x480, which is already a high resolution, lanczos created slightly more visible artifacts than bilinear. Also, my CQ value was stepped up almost 2 point for the same target file size by changing to bilinear. I can clearly see the difference around objects and on dark backgrounds. At least that's the result I got by comparing both samples, one with lanczos, and the other one with bilinear on the movie above.

-kwag

I see the same thing -- more "stepping" in diagonals, and I find it tends to overemphasize any edge enhancement already applied to the DVD, while bilinear hides it.

Looks (and sounds :)) very good! I do notice some "flashing" blocks in backgrounds, but it almost certainly wouldn't be noticible on the TV unless one was looking for it specifically. Hardly any Gibbs...

@Kwag,

I finally noticed Blockbuster dither at variance=50, but at
variance=.4 is very subtle. I had to magnifiy the frame and then it's
not immediately noticable.

Are you using Headac3he or BeSweet for "Surround 2 (Prologic II)".
What happen to "Dual Channel" in Headac3he? :?

BTW, the sample clip was very good!! With very little Gibbs for the
file size created. :D

@SansGrip,

I took you advice about trying both CQ and CQ_VBR. The source seemed
to determine which process came out better. Guide lines for which to
use based on the source would be nice. :) Using bilinear, fluxsmooth,
and dither, compressed the final file size by 40%, so the video+audio
fits on 1 CD with great picture quality. Lanczos looked better, but the
compromise between file size/picture quality was my final decision :)

-black prince

HeadAC3he Dual Channel encoded as "Surround" 2. :wink:
There's a (Stupid) debate at the "Other" forum about "stereo" or "dual channel". I use dual channel because I don't want ANY variations from one channel to the other. In stereo, there are, and this variations "correlations" mess up surround signals on some receivers. This has been reported before by a couple of users. Using dual channel, their problems were over :wink: . :mrgreen:

-kwag

Touche... my original test was done with CQ_VBR. I redid the test and you are correct, with bilinear there is a greater amount of compression allowing a higher CQ value. Nice.

SansGrip,

Sorry for taking too long to reply - the keyboard of my computer at home just died and so I just could test the new DLL now that I'm back to work :)

The new DLL works OK with the code I posted before, I didn't even had to recompile.

:ole:

I'll create a new post in the FitCD forum, with the link to your DLL and my Delphi code, so it's both easier to Muaddib to pick it and we stop polluting the file prediction forum :)

kwag --

I've noticed this a few times testing the notch matrix. I think this might be a symptom of overflows caused by using values less than 8:

http://www.digitalfaq.com/archives/error.gif

If you look in the highlighted area (save the image and zoom in with your favourite viewer) you'll see a red-and-green striped box and to its right some purple and yellow streaks.

I also find the lower grab to be somewhat less sharp than the upper. Look in particular at the forehead of the guy on the left.

What do you think?

Hi SansGrip ,

I'll run a couple of tests to see if I can reproduce that. Maybe just setting the minimum notch area to 8 will solve the problem :idea:
Can you make that change and test that same sample and see if you see that red artifact again :?: Just change the two 6's and the 7 on the upper left corner of the matrix to 8 and run that test again on that part :?:

-kwag

Yep, I'll do that as soon as this encode is finished (1h40m) :).

I just finished the movie "The Matrix" ( Which I have encoded now around 10+ times for test purposes :lol: ), but now with KVCDx3. The results are better that anything I had previously done with that movie 8O.
Here's a minute and a half sample of what the complete 136 minute film looks like on one CD, thanks to your filters SansGrip :wink: , the new GOP, prediction, CQ=64, BETA-1 matrix ( Yes, I did it with that one, unless the 8's fix the error you pointed out and I'll have to re-encode again :x )
http://www.kvcd.net/matrix.cq.beta1mat.sample.m1v

Here's the .avs I used:

-kwag

AviSource("D:\Captures\MSMurders\capture_1.00.avi" ) + AviSource("D:\Captures\MSMurders\capture_1.01.avi" ) + AviSource("D:\Captures\MSMurders\capture_1.02.avi" ) + AviSource("D:\Captures\MSMurders\capture_1.03.avi" )

You can use

SegmentedAviSource("D:\Captures\MSMurders\capture_ 1.avi")

and it will load all four files automatically.

Remember to delete the dummy .avi file if it exists, VirtualDub creates it if you use it for capturing. It's the last file with no video content in it. If you don't delete it, you might get an access violation when using SegmentedAVISource.

@kwag

I still don't understand how you possibly get such high CQ values, ESPECIALLY with a high-action movie like The Matrix at 528x480.

The last encode I did was Jay & Silent Bob -- it's about 97 minutes, low action, at 528x480. Audio 128k (about 85 megs). Using an almost identical script (tried adding/removing BB -- this didn't make much difference), new GOP (1/12/2/1/24), Beta-1 Matrix, CQ of 50 was too much to fit on one disc -- I had to overburn. I am using scripts almost identical to yours and the same methods.

What am I missing here? I'm racking my brain. How do you do it?

What's the aspect ratio of the movie? If there's a lot of black, it compresses very well.

Yes, I know.. it's a widescreen movie, I believe 2.35:1 or 1.85:1.

Using TMPGEnc 2.58 (I heard about some issues with 2.59).

But,

with AVI_IO you don't need to worry about that.

Hey gonzopdx,

Kwag's resize for 528x480 is 496x256 and the movie is widescreen 16:9
letter box to start with. If he cuts out credits and uses heavy softening,
he could raise CQ even higher. :) The new GOP and Q-Matrix compresses
even more. I usually resize 528x480 to 496x336 and still get a CQ in the
high 50's. On STD 27" TV, Kwag's movie would look somewhat flat,
because of the heavy letterbox. :)

-black prince

But that's the original aspect for that movie :D. If I resize to something else taller, people will look streched 8)

-kwag

You guys think we were done with GOP and matrix. Think again 8O :
In theory, a GOP of 1-12-2-1-24 should compress more than 1-12-1-1-24 right :?: , WRONG 8O ( At least with TMPEG in CQ mode ). After reading the previous posts about the small "flashing" effect and always trying to optimize more on the DCT level and artifacts, I ran a test to drop the B frames from 2 to 1, but keeping the size of GOP at 24. Look at the result. I don't even need to circle with red :D , you should see clearly the difference (You might have to blow up the images):

http://www.digitalfaq.com/archives/i.../2003/01/1.png

No filters used here. Only LegalClip(). The funny thing is that with CQ=65 on the 1-12-1-1-24, the file size is actually smaller than CQ=64 with 1-12-2-1-24 8O
Sample file size for 1-12-2-1-24 = 14,430KB
Sample file size for 1-12-1-1-24 = 14,380KB

Would anyone be so kind and try this, to see if I'm still dreaming, or if it's true :?: 8)
Playing back my 1-12-1-1-24 sample, seems to be more smoother and less visible artifacts in the overall picture. Specially the background areas, where there was more movement on stills images.

Edit: This changes each GOP to IBPBPBPBPBPBPBPBPBPBPBPB instead of IBBPBBPBBPBBPBBPBBPBBPBB

-kwag

If the encoder doesn't have enough bits it simply makes macroblocks. This is often not noticible when things are moving fast, but you'll see it clearly if you freeze-frame. Of course, the problem is worse when you use very high resolutions with a low bitrate.

I just did a test encode with The Fifth Element (from AVI), 2h2m, and used a CQ of 64 at 528x480. It's very widescreen, though, probably between 1.85:1 and 2.35:1. This means big borders and lots of compression. I also used fairly heavy smoothing.

Bear in mind that kwag uses two overscan blocks when he resizes, and that makes quite a difference. Try encoding two samples, one with no overscan blocks and one with two overscan blocks. You'll see a significant difference in file size.

The new GOP compresses more but the new Q-matrix compresses less. My last encode dropped from CQ 64 to 58 with the new matrix. This is because it -- by design -- does not quantize low frequencies as aggressively as the old.

Like you I'm suspicious. B-frames are significantly smaller than both I- and P-frames: in my last encode, my I-frames were 13,985 bytes on average, my P-frames were 4,601 and my B-frames were 2,785. Based on that it should be the case that fewer B-frames means much less compression...

It's certainly a very clear difference. But where are those extra bits coming from?

I'll try it right after I run the artifact test (something came up last night)!

Did you encode the whole movie with those settings? I'd be interested to know if prediction still holds true...

Oops..I didn't notice that you used AVI_IO. My bad :oops:

@kwag

I ran the artifact test and the problem I highlighted is indeed gone when I use 8 as a minimum. That said, now I see similar artifacts in the left-hand side of the frame.

Using a lot of 8s in a frame has never worked for me -- while theoretically it should give best quality, if you single-step through the frames you'll see serious degeneration in the P- and B- frames...

Kwag, you've created another monster :twisted:

I did a quick-and-dirty test, and *drum roll*

CQ_VBR file size increased when B frames set to 1 (CQ_VBR value 17,3)

It went from 11,712 to 13219.

CQ file size decreased when B frames set to 1 (CQ value 60)

It went from 6,547 to 6,231.

Uh oh. Looks like this will be another chaotic TMPGEnc test session for you lads.

I only encoded the sampler. There is clearly a better visual experience, at least viewed on the computer. Where are the extra bits coming from :?: I agree with you. I don't know 8O
I'm going to encode 5 minutes with each GOP and see if the file sizes maintain their consistency.

-kwag

Great :mrgreen:.