kwag I don't have a clue how to compensate for those low frequency blocks, but when you come out with an optimized Q-Matrix I'll definetely start testing it!!

__________________
j3llyG0053

I'm on 256Kbps DSL, so no prob here
Downloading...

Edit: 2 minutes to go ....

-kwag

....... waiting.... for ..... reaction....

__________________
j3llyG0053

This is what I think of that sample:







That looks like a DVD . Actually I've seen worse DVD encodes
I renamed the file from .m1v to .mpg so I could see the correct aspect and play it on WinDVD. "A>W>E>S>O>M>E" I have no better words to describe that

-kwag

That's YOUR work kwag!!

We should go on testing and try to get rid of those low frequency blocks...
I'll let you know when the complete movie is done and if it fits... right now it's a little too big for 24%... well we'll see. I used "Sampler ()" and this formula for the prediction :

MPEG size = (( Total frames/MovieTimeInMinutes)/24) * (MPEG sample file size)

was that the latest for the new GOP?

__________________
j3llyG0053

Not anymore!, it's OUR work You bet!. I'm running some tests analyzing the low frequency spectrum of mpeg files
Your formula is correct. Make sure you're using 1-12-2-1-24 for your GOP.

-kwag

that's what the sample is using.

BtW: That GOP kicks ass... far better than the old ones we had!

__________________
j3llyG0053

Hey Kwag,

I included Blockbuster noise with a variance of .3 and detail_min=1,
detail_max = 10 (defaults) in my script. I changed Tmpgenc's
motion search to motion estimate search (fast). The picture
quality was just as great as before with dark areas showing no
blocking and the time to encode went from ~12hrs to ~10hrs.
I tested the above changes using 1 minute clips, but with
detail_min & max, I don't know what improvements in the
video to look for This will probably come together before
SansGrip gets back to testing. I know you'll have a Q-Matrix for
us to play with before then
This is very exciting.

-black prince

Bad news, as for the prediction... The Encoding process is at 88% and right now it looks like it's gonna be over the predicted size by 28 MB..

I just noticed what I did wrong... no wait... I'm confused now... I used "Sampler ()" is that correct or do we need to use any values? sampler took 100 mini samples, but didn't we only use 60 ? I also divided through 25 instead of 24 because framerate is 25 for PAL? what did I do wrong w/ the predicition?

__________________
j3llyG0053

Ok it's 21 MB over... That I can't even fit with overburning... Well I'll try again... Would just be good to know where my error was... any comments?

__________________
j3llyG0053

You're 100% correct . A little later tonight, as I'm currently cranking out a new Q Matrix
Will let you know. I'm still running boocoo tests on low frequency domains right now.

-kwag

Seems you didn't apply the formula correctly. It's this:
Predicted MPEG size = (( Total frames/MovieTimeInMinutes)/24) * (MPEG sample file size )

-kwag

Does this apply to PAL too? We have 25 as framerate as you know...

__________________
j3llyG0053

Maybe something interesting :

The filesize is smaller with high quality motion search than estimate fast :

CQ_VBR=8 544x576 85 seconds

estimate fast : 8193968 bytes
high quality : 7955238 bytes

diff : 238730 bytes (2.91%)

here is the script :

LegalClip()

Crop(8, 74, 692, 42

BilinearResize(512, 320)
FluxSmooth()
Blockbuster( method="noise", detail_min=1, detail_max=10, variance=.5, seed=1 )
AddBorders(16,128,16,12

LegalClip()

with CQ=64

estimate fast : 8104839 bytes
high quality : 7924119 bytes

diff : 180720 bytes (2.2%)

--
apoc

Yes. It applies to PAL too, because we're still creating a MAX frames per GOP of 24. So it's the same formula

-kwag

Hey Kwag,

The file prediction forumla used to be:

Predicted MPEG size = (( Total frames/MovieTimeInMinutes)/24) * (MPEG sample file size * .98 )

Now it's this:

Predicted MPEG size = (( Total frames/MovieTimeInMinutes)/24) * (MPEG sample file size )

Which is correct

-black prince

The second one. The prediction is now so accurate that you don't need the .98 multiplier
Predicted MPEG size = (( Total frames/MovieTimeInMinutes)/24) * MPEG sample file size

-kwag

After hours of trials and trials with different matrixes, modification, changes and whatever, I have come to the conclussion that the DCT blocks can not be removed without damaging the quality of the picture. No matter how low I change the low frequency values that work with the matrix coefficients at the low frequency domain, the DCT blocks still show. I also confirmed SansGrip's findings that adding Blockbuster "Noise" just makes the quality worse. I believe there is a treshold point to use Blockbuster. If there is enough bit rate available for an encode, then we can use Blockbuster "noise" method to our advantage. If we're trying to squeeze a very long movie on a CD-R, then we're better off just using FluxSmooth filters but not Blockbuster, because the available bits are so scatered throughout the picture that trying to add the noise to kill the DCT blocks just lowers the overall quality of the picture. So that's it
Here's the final 704x480 sample. This is what will go into one CD-R with audio at 112Kbps from the movie K-19 which is 138 minutes long. Here's the script I used:

And here's a 33 second sample, cut out of the ~11MB prediction sample:
http://www.kvcd.net/final.m1v

Enjoy ,
-kwag

mmmm I don't know kwag... I think here's still room to play around, with YOUR matrix. I encoded LOTR now, with "High Quality" Motion Search, and the quality is even better than the last sample! I'll upload it later today.

kwag, try this script for blockbuster with cq mode and your matrix... I'm sure it will give you better results...

Blockbuster( method="noise", detail_min=1, detail_max=10, variance=1, seed=1 )

__________________
j3llyG0053

I'll try to do some tests with anime - maybe (CQ + HQ search) gives less mosquitoes...