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!! :D

I'm on 256Kbps DSL, so no prob here :D
Downloading... 8)

Edit: 2 minutes to go ....

-kwag

....... waiting.... for ..... reaction.... :) :mrgreen:

This is what I think of that sample:
8O 8O 8O 8O 8O 8O 8O 8O 8O 8O
8O 8O 8O 8O 8O 8O 8O 8O 8O 8O
8O 8O 8O 8O 8O 8O 8O 8O 8O 8O
8O 8O 8O 8O 8O 8O 8O 8O 8O 8O
8O 8O 8O 8O 8O 8O 8O 8O 8O 8O
8O 8O 8O 8O 8O 8O 8O 8O 8O 8O

That looks like a DVD 8O . Actually I've seen worse DVD encodes 8O
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 :D 8)

-kwag

:D 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?

Not anymore!, it's OUR work :D You bet!. I'm running some tests analyzing the low frequency spectrum of mpeg files :wink:
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... :twisted: far better than the old ones we had!

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 :mrgreen:
This is very exciting. :D :D :D :D

-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.. 8O

:oops: 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?

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?

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

-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...

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, 428)

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

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 :wink:
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 :wink: ,
-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 )

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