So far, all tests I've done, the CQ version seems to give the overall best quality for the same file size as CQ_VBR. At least >528x. For the dark areas, I've seen the best results using a very low value of "dither" with Blockbuster.
This is the line I'm using witn 528x480 encodes: Blockbuster(method="dither", variance=.4, seed=1)
Results are very good, and background walls etc., are well stabilized and it helps a little with compression. With noise, I don't get the same effect on background walls and dark areas. Same tests with TMPEG's default matrix and "standard" MPEG matrix are worse

-kwag

Yes, I did.

It's like this:

Well if you're specifying the stdcall convention and I'm specifying the stdcall convention and the function names are both the same, I don't see why it wouldn't work.

Let me rebuild and repackage and upload again. Maybe I missed something last time.

@GFR

Edit: Scroll down .

I noticed the effect particularly on a fairly (but not very) dark red vinyl seat cover, which wasn't particularly undetailed in the source. Again I'd say it's a result of CQ mode compressing low frequencies too much.

I'll try it with dither and see if that helps.

Hello all,
I've been useing kwag's old 352x480 template. But here lately I read that you can fit a movie onto one cd with the x3 template and file predition. I want to try out the x3 template but not sure what filter settings to put into fitcd. Not sure what resize method to use. And should I change the matrix as you all have done? Just need to be pointed in the right direction. Sorry if this is in the wrong forum.
Thanks for any help

@GFR

Edit: See next post .

@GFR

Never mind -- adding __stdcall was the right thing to do, but now the compiler is "decorating" the function name and Delphi can't find it. I'm working on the fix right now .

@GFR

Delphi should be able to find the function with this one. Hopefully it won't crash either now we're both using stdcall .

@SansGrip,

SansGrip wrote:
It's DVD Backup for both. The CQ_VBR version was created before the
new GOP and Q-Matrix Beta's. It uses Q-Matrix Standard and
GOP (1-5823-3-1-48 ). I wonder if CQ_VBR with new GOP and Q-Matrix
settings will cause the same problem I'll use very low CQ and CQ_VBR
values to make the problem standout for viewing on PC.

-black prince

Is it very grainy in the original? I got the AC3-Guru version and it looks like someone used Blockbuster(method="noise", detail_min=1, detail_max=100, variance=3) on it .

That would be the first test I'd run. If the problem isn't there we know it's CQ mode. I have a feeling it's the culprit...

@SansGrip,

SansGrip wrote:
Nope! I viewed the vob using RadLight player and the movie is very clear
and sharp. I viewed the movie via VDub without filters and resize. Again,
it's very sharp and clear. I will select frames where the background
is a problem in CQ and compare it to CQ_VBR both using the new GOP
and Q-Matrix. Will get back to you later.

-black prince

In that case I'd say whoever encoded the 3-disc version used Blockbuster or one of my noise generator filters -- and when I say "used", I mean used .

OK, so nobody replied to my post about my problem with American Ninja.

But thanks to this thread, I believe I have now produced 95 minutes of very high action 704x480 on 1 CD that is almost indistinguishable from the DVD on my 27-inch TV. I'm using the beta 1 matrix, the new GOP (1-12-2-1-24), 3 overscan blocks, a CQ of 38, and the 704x480 template changed to MPEG-2 (because my Apex chokes on 24fps MPEG-1). I can see a little blockiness on scenes with smoke and fire and on a couple of night scenes, but it's hardly noticeable. Assuming the prediction formula still holds up for the final encode, I'm in business.

mpeg2source("Z:\american_ninja\american ninja.d2v")
LegalClip()
LanczosResize(656,336,0,0,720,480)
FluxSmooth()
AddBorders(24,72,24,72)
LegalClip()
Sampler()

My girlfriend took the Pepsi challenge and had to watch a few times before she could tell the difference. It doesn't look that good on my monitor, but hey...... that's what DivX is for.

However, I'm seeing some weirdness with CQ values, motion search precision, and file sizes. My target size for prediction was 11.8 MB. At high motion search precision, there was virtually no difference in file size at 36, 37, 38, 39, and 40, with files in the 12-12.1 range. Interestingly, 36 and 37 produced slightly larger files (12.1) than 38 and 39 (12.0).

Also, higher motion search precisions yielded smaller files, but quality decreased along with file size, except highest quality, which makes a slightly larger file than high but has more Gibbs. My best encode was at 38CQ with very fast motion search, but the file size was over 15MB.

I will let you guys hash out what all that means. I'm going to just enjoy my movie. Is this a great place or what?

@SansGrip,

SansGrip wrote: I tested 528x480, GOP (1-12-2-1-24) and Q-Matrix Beta-1, for
both CQ and CQ_VBR. I made file sizes close to the same size.
The results and the winner is CQ_VBR + Blockbuster noise

Test#1
Clip = 720 frames, 30 seconds
CQ=92
file size = 6,908,736
filters: Crop,bilinearResize, TemporalSmoother,LegalClip
Comments=walls had some noticable movement and gibbs effect

Test#2
Clip = 720 frames, 30 seconds
CQ_VBR=100
file size = 6,916,023
filters: Crop,bilinearResize, TemporalSmoother,Blockbuster noise,LegalClip
Comments=less noticable wall movement and gibbs than CQ.

CQ_VBR was a clear winner. CQ ignors Blockbuster noise until it's
>80 and most encodes for 2 CD's will never get set this high. I did try
Blockbuster dither with CQ, but did not notice any change with it.
Like Blockbuster noise you must reach a high CQ value before it
starts to work

-black prince

Well, here's something else to confuse everyone .

In the samples below, you can see highlighted in red areas where the CQ version is significantly better, and in green where the CQ_VBR version is significantly better.

Oh, I should say one other thing: the CQ_VBR version is 352x480 and the CQ version is 528x480 .





I think it's pretty obvious which mode won this test...

Yep, I've noticed this too. It's very weird.

I get a file size increase with "highest" too. I think TMPGEnc actually finds too much motion with that algorithm.

Some good testing there -- you'll be making your own Q matrix before you know it .

Gah!

Yes, CQ mode seems to ignore noise until you reach very high quality levels.

Well... What now?

I think I'll stick with CQ + BETA-1 matrix + "dither": Blockbuster(method="dither", variance=.5, seed=1)
I get the best results second to none with the above line.
Maybe if I have to encode at 352x240, I would use CQ_VBR, but over 352x480, CQ just produces less artifacts and with the help of "dither" ( maybe "noise" too? ) the overall quality is superior. At least on all my latest tests, the results have been very consistent.
So far, that's my experience. Anyone else care to comment
Same results? Different results?

-kwag

Hey SansGrip,

At what motion search precision were these samples encoded?

Racer99