I'm getting ready to encode Pearl Harbor to one cd with the LBR temp and new GOP. I encoded a test sample with no filters and the Gibbs effect was very bad- so now I'm trying out SansGrips filters for the first time!

I used this script:
It helped reduce the Gibbs effect and the DCT blocks a lot! The mean and strength values are much more radical than what everyone else is using though Does anyone have a good script for reducing Gibbs effect or for cramming 3 hours onto a cd?

btw- excellent documentation with your filters

thanks.

You're only just trying them?? I'm offended! hehe just kidding .

Those are very strong values for Blockbuster. One reason you're having to go so high might be because you're smoothing after adding noise -- generally not a good idea, since you're adding noise then taking it away again .

I generally use:

I find Blockbuster's default parameters usually are adequate. However since you're encoding such a long movie it might not hurt to up the variance a little (though I personally wouldn't go over 1.5 or 2). You might not be able to see much of a difference, but the encoder will definitely notice it.

As for sharpening, I generally don't do it. In my experience it increases the file size without any real benefit. If I think the movie could do with a little sharpening I'll usually switch to bicubic or Lanczos resizing, which result in a sharper image than bilinear.

Thanks! First time anyone's said that . I try to be as clear as possible, but it's difficult to write effective docs when you know the thing inside and out... Very easy to forget something important.

Up, up in the air, the beautiful baloons..... Yes, this is still not the final number. The ideal thing is to find constant prediction with all resolutions, and then applying the .95 as before. This will create less chaos That's what I'm doing right now, and probably won't go to sleep until I get it right

Red Planet (106 minutes) on one CD at 704x480. I still can't believe what I see

-kwag

@SansGrip and Kwag,

It would be nice to resolve the question of Avisynth vs Tmpgenc resize
effecting file size. Encoding with Tmpgenc's resize is Sloooooow!!
I even wonder if using Tmpgenc's mask for borders couldn't be corrected
from avs script. If crop is cutting borders top and left then the leakage
has to be bottom and right that Tmpgenc's mask is ignoring for file
size savings. Is there a filter to mask borders the same as Tmpgenc

-black prince

Yep. Use AddBorders if you want to, well, add borders, or Letterbox if you want to do the equivalent of TMPGEnc's "mask" feature.

Update flash

Just finished my 352x240 LBR MIN=300Kbps, MAX=1,800Kbps test with "Bug's life" for the second time today. Instead of using 100 samples at 24 frames each, I used 50 samples of 48 samples each. The file size prediction came out as follows: Wanted file size: 725,112KB. Final file size: 727,262K
That was with prediction factor at 1.0, so for safety, I'll set that now to 0.98, and that should be good enough. The previous encode with 100 samples of 24 frames each, came out to ~800MB
Now I'm encoding "Red Planet" at 704x480 with the same formula adjustments and Blockbuster noise filter. Four hours to go.....

-kwag

@SansGrip,

I believe this would mean a value of 2 instead of 5 in KVCD Predictor

-kwag

Yep. I'm sure you already know this, but for others reading: if you use 50 samples of 48 frames with a script like this:

then you can leave the KVCDP "Sample Points" setting at 100. While we are really using 50 sample points, each one is twice as long as before. Since there's (yet) no way to enter the sample length, by pretending we're using 100 1-second sample points it'll still give an accurate prediction.

@kwag

I'll try 50/48 in a moment, but I'd be interested to hear if you get even more accurate results with 100 samples of 48 frames (Sample Points set to 200, if you're using KVCDP), or whether 50 is indeed enough. Care to run another encode?

It makes sense to me that using a longer sample gives better accuracy. I think what we can take from this is that the sample length should be double the GOP length...

While the number of sample points is of course important, all it's really doing is giving us more representative material to work with than simply taking 2400 frames from the beginning of the movie. I think with almost all movies it should be adequate to sample 50 times.

Hey Kwag,

I hope your using the latest Blockbuster 0.6 with seed parm:

LoadPlugin("E:\DVD Backup\2 - DVD2SVCD\MPEG2DEC\MPEG2DEC.dll")
LoadPlugin("E:\DVD Backup\2 - DVD2SVCD\BlockBuster\BlockBuster.dll")
LoadPlugin("E:\DVD Backup\2 - DVD2SVCD\LegalClip\LegalClip.dll")
mpeg2source("D:\Temp\movie.d2v")
LegalClip()
LanczosResize(496,44
Blockbuster( method="noise", detail_min=1, detail_max=10, variance=1, seed=1 )
AddBorders(16,16,16,16)
LegalClip()

Seed uses the same frequency so that file size won't vary when using
noise. Just encoded Minority Report using 528x480, CQ_VBR=11,
audio 128kb on 2 CD's (800mb each). 1.4 GB. The quality is the best
I've seen. Even Gibbs effect had almost vanished. Fast action scenes were
near perfect. This is by far the best picture quality yet. The DVD and
the backup look the same. Since I could have used a higher CQ_VBR
to fill up the CD's, I'm going to wait until the file prediction formula
is finalized

-black prince

Sounds awesome . I was actually planning on renting that movie tomorrow with a view to buying it if it's as good as people say...

Right now I'm seeing if I can get Untouchables (1h59m) on one disc at 528x480. Maybe I'm dreaming, or maybe not.....

Exactly . I am trying to get by with this, because 100 samples of 48 frames is 200 seconds . Just a little too long for two or three sample encodes. If the 704x480 encode I'm doing right now targets the predicted size, I think the above should be enough. As you said, two complete GOP sizes per snapshot should have a pretty good prediction. Maybe 60 or 70 snapshots of 48 will do as good as 100 So maybe a compromise of more than 50 but not quite as high as 100 for fine tunning

-kwag

I'm using: Blockbuster( method="noise", detail_min=1, detail_max=10, variance=.5, seed=1 )

-kwag

I'm encoding Untouchables (1h59m) right now: 528x480, new GOP, CQ_VBR 9.25, error margin 0%, sample points 50, sample size 48. Audio: 128kb/s, 109mb. Predicted size: 803mb. Time remaining: 3h19m. I'll let you know in the morning .

9.25 (by the way, I added a decimal place in the encoding helper ) is a touch on the low side, but the samples looked pretty good to me. If the Gibbs is too noticible on the TV I'll reencode at 352x480 with the new GOP and formula.

I'm beginning to think that with the various filters you've crafted there are very few movies we can't get on one disc...

Yep, possibly. I'm still hoping that 50/48 is going to be the answer for this new GOP, since I want the whole prediction process to go as fast as possible. Who knows, maybe even less than 50 would give good results with the larger sample length... We won't know until we test .

Just so you know, because detail_min=1 and detail_max=10 are the defaults, you could simply use: Blockbuster(method="noise", variance=.5, seed=1)

Slightly less typing .

Edit: Heck, you could even use Blockbuster(method="noise", variance=.5, seed=5823)

Or maybe: Blockbuster(method="noise", variance=.5, seed=atoi("SansGrip")

-kwag

Hi SansGrip!

I've been doing that (100 snapshots of 2 seconds) for some time now.
My DVD doesn’t like mpeg1 vbr with resolutions above 352x240, so if I want anything else I have to use mpeg2. And, I don't know why, I couldn’t get accurate prediction with the default scrip (and mpeg2), so I tried exactly what you said and it gave me good accuracy.

I never tried 50 snapshots... but maybe it work good to.

heheheh

Let's see... "SansGrip" is 53616E7347726970 in hex, which in decimal is 6,008,204,819,287,927,152. Nope, wouldn't fit .

Pretty similar to my experience. Try 50 samples of 2 seconds each. Heck, try fewer than 50. The more people we have testing this the quicker we'll work out the optimal formula .

Ah! bummer!, don't you just love the users who leave the keyboard sticked on a 4 character field without boundary checks , HAHAHA Leak, leak. Then when you press "ENTER" boom!

-kwag