Hi toots..,

Yeah, I ended up re-dvd2avi'ing. My movie "Blue Streak" was one of them
too. But, unfortunately, it took a while to do. I don't know why it takes me
forever to:

* DVD Rip - - - now @ 3.6k (instead of my past ~9k)
* DVD2AVI - - - this one takes me about an hour for each movie (or more)

All in all, I would have to wait 2 hours for a complete project. And,
that just plains sucks !! hehe..

But, I don't know what else to do. I remember my older Intel 233mhz
setup. that game me faster DVD rips 8O - - same setup, but newer and
faster MOBO and CPU - - I'm really sumpped, 8O and :screwy:

I think my K7S52A sucks for DVD riping and DVD2AVI'ing projects !!

But, I now need to re-do "Matrix" to test again in CQM.. as you've read
above, how my faulty dvd2avi cause incorrect CQM finalization :!:
This NEEDS to be done again, so that I can give the developer his singing
praises, I mean, glory, I mean, better results :wink: hehe hehe..
Just having fun :lol: 8) :lol:

However, my first attempt at "Blue Streak" was a rather successful one,
I thought.. but the real test is the ENCODE the whole movie now.. so you
understand my 8O and my :screwy: 'ness decision ?

Well, let me see what decisions I have to make, and what else I want to do.
Oh, did I mention, I'm making spagetti :)
-vhelp

vhelp wrote:
"dvd2avi - this one takes me about an hour for each movie (or more) "

i understand
:?:
8O
you need an hour or more to make one project with dvd2avi :?:
:?

hi Jorel..

Yeah, I'm w/ ya.

Oh, @ toots..
I used DVD2AVI v1.76 ( I won't use anything else !!! )

:lightbulb: - Now, a thought has ben brewing in the back of my mind..
"Why not encode a bunch of DVD rips to divX 8O yikes !!"
Well, why not ??
If the encode is done right, and maximum as possible, why not do this, for
testing ideas and things ie, CQM !!
I haven't tested this, but just HOW MANY movies can we encode to divX
(and w/ great quality, ie near dvd) and use those to test CQM with ??
For example, if we have a 30gig hard drive, how many whole divX encodes
can we have ?? ..5 movies, 10 movies 20 movies ??

anyone divX gurus, w/ knowledge and skills to share w/ us for divX encodes ??

Anyways, it was just an idea :idea:

-vhelp

is too much time vhelp!
i need ~5 minutes to do one project with dvd2avi176 :!:

when ripping,you wrote that got 3,6k...
better is check your aspi!
something is wrong in your system!


convert to divx from dvds :?:
for me is not a good idea (only my opinion)
you can got space but will loose quality.

:!:

hi jorel..

yeah, hard drive space and divXing and all that stuff :) was just an idea,
that's all.

Anyways, as far as ASPI and all, I've never touched it. So, I don't think
it should be changed.. actually, I've never seen it 8O

But, what really knocks me out, is the dvd2avi'ing to a .d2v file. That is
a LONG process. I remember it being MUCH faster too. And, as far as
my project needing to be in YUV for faster processing, is a lot of nonsense.
It's the same basic speed.. no improvements weather it's YUV or RGB, as
it doesn't matter. Anyways..

-vhelp

ok, I've decided to go with the encoding project.

TMPG's time estimates are 6 hours for.. here's the specs, case anyone wants
to compare w/ their projects of this same movie:

* Time index: ~6 hours
* Movie: "Blue Steal"
* Length: 94 min
* Frames: 135,430
* Audio: 112k
* Encode: MPEG-2 / 16x9 / 704x480 / CQM's CQ(89, max2000 ave995 min567)
* CDR: 1 cd @ 800mb size, for this project

I used vcalc (latest version) for the bitrate values, and let CQM v1.1.12a
to all the rest :)

Does anyone think it will make the 1 cdr game plan ?? CQ 89 is a rather
high value, but I'm resting in the hands of CQM for this to succeed.
Place your bets hehe..

Note, its really too bad we windows 98 users can't get a snap shot of what
the file size of our encode is during encoding, like NT and XP does :(

We are now passing the first 10 minute of encoding, with 5h 34m to go :)

-vhelp

@ all..

HAY all.. another :lightbulb: just lit up.. I got a fabulous idea about
obtaining the filesize of the encoding project, as it is running !!

I wrote this Delphi app that computes the HD space left on EACH hd (a
project I was working on for something similar) anyways..

In short, I calculate the HD space for each drive, pending on which drive
is selected for computations :)

I found, that if I encode to my capture (networked) hd, that being the
only file that gets writeen to 8O we could calculate the running jobs
filesize buy subtracting the actual hd's size. ie, 54g - 4,674,551,808
Well, anyways, I could modify my app (fmem.exe) to some degree and make
it more user friendly. In fact, I could add some features like a grid
of values ie, incremental filesize and times vs. encoding times etc.
and let it iterate in 1 minute intervals to update the grid. This could
give us windows 98 users the ability to peek inside the filesize !!
Note, this would not work under a setup if you are encoding to your Swap
file drive, cause this drive get constantly updated w/ other files and
things being writen to.

This way, we all benefit CQM in one way or another :)

Any windows 98 users like this idea ??
A great tool indeed!!

-vhelp

vhelp,
6~hours to do this job with athlon1800+ seems good!
but
that with CQ89, 704x480 with 94 minutes source
will give you a big final file size! 8O

Hay Jorel..

Tell that to Kwag.. this is his prediction 8O not mine 8O

Note, my system is acting really caka. So, I'm getting a little worried,
but I'll hang on.

-vhelp

Kwag,
this will be big!
8O

vhelp,
it's done!
:lol:
:rotf: :hihi:

Ok, I've ben testing this out (earlier)

And, here is what I have so far:


"Movie position" is the same as TMPG's.. letting you know how deep into
the movie you are.

The above was based on a rought estimate, because I did not start this
idea till project was encoding. So, I guessed an estimated filesize to start
with, and added 12mb to it. It's ben calculating ever since.

Now, I REALLY can't wait for this to finish, because I'll know if this works
or not :screwy:

Note, I had to stop TMPG from encoding a few times (but I clicked on NO, to
resume encoding)

@ Jorel..
The 6+hours is based on my XP 1700+ ( not my other 1800+ ) :wink:

@ Jorel..
Tell me, after looking at the above, what do you think about the filesize 8O
so far ??
* too big (oh my hehe)
* too small (even worse hehe)
* just right (great)

--> :screwy: <--

-vhelp

like posted,you got ~184mb for 20 minutes encoded!

after i start my "nuclear calculator" i got:
target=800mb, 94 minutes!
movie position 20 minutes=184mb!
then...

for 4 minutes=184/20*4=36,8mb
for 10 minutes=184/2=92mb
for 80 minutes=184*4=736mb
8O
4minutes+10minutes+80minutes=94minutes
36,8+92+736= ~864,8mb final size
:arrow: without audio!
8O

vhelp,
this will be too big or my "nuclear calculator" is mad!
well,you can cut the credits and burn without audio!
:lol:
(just kidding,you know)

:wink:

Hi Jorel..

Sorry, I lost internet connect a few hours ago.

That pretty much sums it up for ONE HOUR though !!
So, your NUCLEAR CALC is off a bit.

Here's the final 60 MINUTE encode (I knew I'd have to stop, so I decided
to stop at 60 minutes)

Movie: "Blue Streak"
MPEG-2 / 704x480 / 16x9
Audio: 112k
Length: 94 minutes - - - (encoded only 60 min worth for this test)
Encode Mode: ES (Video + Audio)
CQ: 89
-------------------------
* Final FileSize video: 868,040mb
* Final FileSize audio: 49,309mb

Oh well, I wonder what went wrong w/ CQM v1.1.12a for this test ??
-vhelp

Test CQMatic 1.1.12a for KDVD FULL
 

============================================
Getting closer. Now 2% over
Will test with .57 min bitrate

file: DVD 94 min 16:9
============================================
mp2 from headac3he: 88,462
abr 1283 = (1820 / 8) * 60 * 94
tmpgenc max/min 5000/300
Detect Screen Change OFF
Padding ON
KDVD 720 x 480
============================================
target m2v size: 1,283,000
m2v size: 1,308,837
m2vsample: 26,948
CQ: 67.16

bbmpeg muxed as dvd
video: 1,366,028
audio: 89,826
---------
1,455,854
(1,431,200 max allowed on 80 CD's)

MPEG2Source("h:\hunt\1.1.12a\hunt.d2v")
telecide()
decimate()
LegalClip()
unfilter(50,50)
GripCrop( 720,480 )
GripSize(resizer="BicubicResize")
STMedianFilter(8, 32, 0, 0, 8, 32)
temporalsmoother(1,2)
mergechroma(blur(1.50))
mergeluma(blur(0.1))
GripBorders()
LegalClip()

Well, what can I say kwag... I just finished encoding "The Time Machine" (PAL) using CQMatic 1.1.11. Wanted file size 800 MB (what else :wink: ). Finished, multiplexed file size turned out 799.26 MB. AMAZING :!: Talk about precise prediction. Once again, thank you for this excellent program. :D

Thanks audioslave :)

Try 1.1.12a, and just run prediction to see if the CQ found matches closely the one 1.1.11 did.

-kwag

hi audioslave,

I'm new to the Wanted and don'tWants :screwy:

But, what was your actual Video size ??
-vhelp

Ok, for those curious..

I've finished last nights 2nd encoding test of "Blue Streak" - 94min. movie.

I'm still learning things like how to balance out video/audio and things.

This morning, after 5h:34m of encoding above movie, it was 810mb. I'm
going to assume that it was just TOO big still. But, the CQ was MUCH lower 8O
I used 50, instead of 89, and it was still too big - just the video part. The
audio is perfect for this mins. @ 77.2mb - - 810+77 = 887mb 8O that's
not gonna fit an 800mb cdr. I was surprised, because the movie is only
94 minutes long.

And, anything undre CQ of 50 is tipically blocky as anything, but I've only
done a few tests in this area.

I'm still wondering why CQM v1.1.12a choose CQ of 89, in the first place 8O

So, I'm stumped :screwy:

-vhelp

@vhelp,

You are encoding as "ES Video Only" and not as "System (Video+Audio)", right :?:

-kwag

Hi Kwag..

Incorrect :(

I chose ES (Video + Audio) for two reason: :roll:

A - because memory serve me that you (after testing) found that v2.520
......was ok w/ this mode and ES (unless I miss-read you 8O)

B - because I want to save time, and not have to encode audio separately.
......if its already there, why not.. right ?

Ok, let me have it :grrr:

Tell me, that I have to re-do again, w/ same CQ's ?? :confused:

-vhelp

The average bitrate and movie time formula in CQMatic are designed for Video Stream only :!:
I haven't made any test encoding audio with TMPEG, because the quality of TMPEG's audio encoder sucks :!:
That's why CQMatic was developed for video, and not for audio :D

-kwag

Hi Kwag.. others..

FWIW...
I'm now runing my first predition test w/ my 2nd pc. Finally got most things
sorted out, and I'm now able to read (again) .d2v source files into TMPG.

I'm using ES (video only) this time around for this project.

I'm currently doing "Red Planet", but as soon as that is finished, I'll do my
"Blue Streak" again.

I'll let you all know how it fairs, ..hopefully better than my MAIN pc.
-vhelp

..update

* Movie: "Red Planet"
* CQ of 56.52
* MPEG-2 / 16x9 / 704x480

Will try "Blue Streak" now. I found out that I had Scene-Detect on, in this one.

-vhelp

Telepathy 8O
I just finished "Red Planet" about an hour ago :lol:
Encoded at 352x480 directly from .d2v (for testing CQMatic 1.1.12a at that resolution).
Wanted size: 726,338KB
Final Encoded size: 740,083KB

For +1.8% diff.
Encoded at CQ=79.51 (By CQMatic)

Wana see what it looks like, with "Zero" filters at all 8O , just KVCD's Q. Matrix :?: :cool:
http://www.kvcd.net/rp-352x480-cq-79...0-max-2500.mpg ~10 second clip (no audio)

-kwag

.
.
Zero filters is the only way to go (if you can afford it space wise.. that's
why CQM's for :wink: )

D/L'ing sample now.

Maybe I should re-do "Red Planet" again, w/ 352x480 this time 8O out of
curiosity. I expect to see some differences though, cause after doing both
test predicts on each machine, I found color space was off by one tick.. and
that means different CQ values (for me anyways)

Right after I complete predict on "Blue Streak" I'll give "Red Planet" a go !!

-vhelp

Sample looked very good :) 8) :)

Glad to see you have (seemed to have) finally met up w/ the boarders :wink:
..no blocky-bleeds :wink: IYKWIM !!

Hay, it would be interesting to see what my MPEG-2 16x9 704x480 would
look like, after CQM gets to it w/ a CQM :!: ..for comparison sakes.
Can't wait to try that out 8)

-vhelp

It will look good, but just not quite as good as the MPEG-1 version ;)

-kwag

I have found you don't need to use the 16x9 setting in TMPGEnc, but just have to set dest_anamorphic=True in gripcrop. If your source is anamorphic this will give you 16x9 output which looks great on a widescreen TV.

Downside is that on 4:3 TV it won't look quiet right and people will be squished and look skinny and stretched. Also since you are using more resolution you'll get lower CQ values.

On that note I use dest_anamorphic=true for my encodes

Hi audi2honda,

That might be true, but with the method I use now, and for 16x9 output,
weather I view on a 4:3 TV or 16x9 TV, the output will always look the
same !!

MPEG-1 can benefit this as well, and save on some bitrate/CQ and things,
if they choose 16x9 (but is tricky in some situation ie, kinds of TV and SW
viewing) But, you can cut your filtering by a lot if you use 16x9 as your
output, OR, resize properly, and totally eliminate the boarders in your
encodes, if they are with in measurement and AR calculations.

Also, if you dvd2avi w/ RGB and select TV as your final .d2v process,
you'll get better color space quality in your final MPEG-1/2 encoding.
I've outlined this on this thread somewhere in the begining. You should be
able to copy the steps as is. I have found this to be the Ultimate in final
quality. It's the best, and is what I use for maximum color quality. See
for yourlself, when you play it on your TV. Don't alwas go by what your
eyes see on your PC monitor. I've learned this well over a year ago, burn
to CD and test your final analisys. You'll see (provided you processed your
project just right) There's a balance w/ everything. The wrong key, can
throw off your final results. My LCD monitor can pick up quite a bit of
detail. I can usually tell how an encode was done, just by looking at the
samples on my LCD screen. Its a great tool (I've said this elsewhere)
In any case, these are my recommendations for best quality output.

See Kwag's latest RedPlanet sample for an example of how far he
has gone this technique :wink: (give or take a little) you know how much
he loves MPEG-1 :confused: no matter what hehe :mnkypile:

A tip from me is, if you can afford it, get rid of the boarders altogether.
They are a waist of bitrate period. You only need to figure (learn) how to
obtain the corred (or near) AR values and resizing technques. Something
that I'm STILL figuring out myself :screwy:

I'll try and show some sample clips of my MPEG-2 16x9 encodes of my
work, that I've ben using for a while now, ...when I get the chance to U/L
them. These play great on 4:3 TV (standard sets) and resize the 16x9 AR
for proper viewing and WITH boarders, ...but at the moment, I'm waiting
on testing true 16x9 widescreen TV sets - - I need one, as no one here
seems to want to let me know how mine come out on theirs.

My other issues are related to my process. Rather what settings I use. ie,
I had scene detect enabled in past predicts and encodes. These can throw
off very easily final results.

At the moment, I'm having one of those issues, unfortunately :(

-vhelp

@ Kwag..

* Movie: "Blue Streak"
* Length: 94 minutes
* Audio: 112k
* Max: 2000
* Ave: 1050
* Min: 599 ... (by vcalc)
* MPEG-2 / AR: 16x9 / Res: 704x480
* Scene Detect: unchecked
* GOP: 1,5823,2,1,24
* [x] Closed GOP

What's with this darn crawling hehe. It's driving me madly insain :confused:
I just wanna end the whole process altogether when it does this.

Using CQ of 60.00
Current CQ = 47.24
Current CQ = 43.76
Current CQ = 42.74
Current CQ = 41.78
Current CQ = 40.70
Current CQ = 39.75
Current CQ = 40.22 8O 8O 8O 8O
Current CQ = 39.98 8O 8O 8O 8O
Current CQ = 40.10 8O 8O 8O 8O

and, an hour later...

If you could add a text box [.....] so that users who suffer this crawl
can input a "bump" value, that might help reduce the:
* number of passes, and
* length of time to predict

A little intervention woudn't hurt here, I don't think.
As a user, and seeing the CUE ie, cq 47.26 and cq 43.76, that
would be my CUE to bump the CQ value, say by 5 ie, 47.26 to 42.26 or
something like that. Than see where CQM goes from their. But, instead
of waiting 1/2 hour or more for, and 5 ore more passes, and I would have
finally arrived at my final CQ anyways !

Otherwise, this would drive me :confused: waiting, when I already know what
the final CQ value will be (usually very low)
At these low values (if lower than usual) I would normally know what to expect
in quality w/ these numbers. In my expeirence, CQ 40 would be like,
the lowest I would go in CQ.

Does this make any sense so far ??

-vhelp

@vhelp,

There's no way around it :!:
The problem is the almost "Flat" line around CQ of ~40
Where a large change in CQ causes a very little change in file size. So I need many passes to find the optimal CQ. If I add an override option, then I'll get feedbacks like "My file size was way over target" or "My file size was way undet target", because of users overriding the CQ value. So I'd rather wait an hour, for 5 or 6 hours of encode, and finish with a very close file size, than Guesstimate a CQ, and wind up with a file size way off. Remember, a little file size difference on the sample, can mean a HUGE file size difference on the full encode. That's why it's so critical on the small size sample being scaled :D

-kwag

Hi Kwag..

Sorry for not responding sooner. Lightning struct one of our facilities, and
notcked out everything. No power for a while. Lost my last CQM testing
and was alost most there.. 8th pass. Shucks :(

Ok :wink: I understand, and my head does too :lol:

I did a small sample clip of "Red Planet" earlier, ..same scene as your sample,
but using my process and settings and things.

Anyways, I'll U/L them, case you wanted to see what I've encoded, based
off what I discussed previously here. As always, your input is more than
welcomed :lol:

I'll give "Red Planet" specs in a moment, followed by a sample clip based
off of CQM's result.

-vhelp

@ all..

For those who were following, as promised, below are my reading for
CQM v1.1.12a and a small sample clip based off those results.

Have a nice and remaining day all :lol:
-vhelp

Sample can be found here:
* SAMPLE Encodes..

Remember.. the sample was intended for PowerDVD users only.
Please read the PDVD notes on my SAMPLES.. thread :!:

Below were my CQMatic v1.1.12a results:

http://www.kvcd.net
CQMatic Version 1.1.12a
Copyright Softronex Corporation, 2003.
All rights reserved.
Time: 18:02:20 Date: 08/17/2003
Ready!
Project: C:\Program Files\Pegasys Inc\TMPGEnc Plus 2.5\v2.520-redplanet.107.cq(50x2000x518).av909.cqm(v1.1.12a). tpr

Creating: CQMatic.tpr

e:\2nd.redplanet.rgb.tv.1.4.m2v
Project resolution: 352x480
Execute.
Movie Time: 107
Average Bitrate: 909
Prediction Only mode
Executing Prediction Phase...
Process started at 18:02:49
On 08/17/2003
CQ set for prediction
Setting up initial sampling.
Using CQ of 60.00
Prediction cycle #1
Encoder started...
Process time: 3.92 minutes.
Encoder end.
File size difference = 1.312513
Low fence: 60.000000
High fence: 90.000000
Last CQ = 60.00
Current CQ = 78.75
CQ difference = 18.750755
Using CQ of 78.75
Prediction cycle #2
Encoder started...
Process time: 3.98 minutes.
Encoder end.
File size difference = 0.907897
Low fence: 60.000000
High fence: 78.750755
Last CQ = 78.75
Current CQ = 69.38
CQ difference = 9.375374
Using CQ of 69.38
Prediction cycle #3
Encoder started...
Process time: 3.92 minutes.
Encoder end.
File size difference = 1.148463
Low fence: 69.375381
High fence: 78.750755
Last CQ = 69.38
Current CQ = 74.06
CQ difference = 4.687683
Using CQ of 74.06
Prediction cycle #4
Encoder started...
Process time: 3.93 minutes.
Encoder end.
File size difference = 1.035555
Low fence: 74.063065
High fence: 78.750755
Last CQ = 74.06
Current CQ = 76.70
CQ difference = 2.633278
Using CQ of 76.70
Prediction cycle #5
Encoder started...
Process time: 3.97 minutes.
Encoder end.
File size difference = 0.929733
Low fence: 74.063065
High fence: 76.696342
Last CQ = 76.70
Current CQ = 75.38
CQ difference = 1.316643
Using CQ of 75.38
Prediction cycle #6
Encoder started...
Process time: 3.97 minutes.
Encoder end.
File size difference = 0.969977
Low fence: 74.063065
High fence: 75.379700
Last CQ = 75.38
Current CQ = 74.72
CQ difference = 0.658318
Using CQ of 74.72
Prediction cycle #7
Encoder started...
Process time: 3.97 minutes.
Encoder end.
CQMatic complete!
Total minutes of process: 27.72
Process ended at 18:30:32
On 08/17/2003

Looks great vhelp :D
But your aspect is not correct :!:
You encoded as "Anamorphic" output, instead on non-Anamorphic.
That would be ok if your target was DVD, but it's not the case, after seeing your VBV buffer size :cool:

-kwag

Thanks Kwag, for your comments :)

Yes, I realized that. And, I probably should have changed it. But, I was
testing, so it didn't matter so much.

Now, I'm going to try a 704x480 (DVD intended) using same (modified)
settings as prevous one used for the 352x480 above. I'm curious to see
what CQ I get for this one.

I'm contemplating on encoding the 352x480, just to see if it all goes on one
800mb CDR though.

Well, let me get to another "Red Planet" predict.
-vhelp

divx movie

wanted vs-738220
encoded vs-799565

7.6% :(

Yea 1.12 is going way over for me too on my 70%film/30%video hybrid material. I don't have any exact numbers but my last 3 encodes have been 35-50MB to big for 1CD. I've gone back to 1.11 for now.

Haven't tried any pure progressive 100% film sources yet.

.
.
Well, I'm doing "Red Planet" as we speak.

With 4 hours to go.

* MPEG-2 / 16x9 / 704x480
* CQ: 50.88
* 1 CDR @ 800mb

Here's what I have, based on my new modified HD size reader app
for Windows 98, for the currently encoding project file:

Size: - - - - - - Timed - - - - - Position in Movie:
------------------------------------------------------
172mb - - - - - 1h:07m - - - - 25 minutes

Can anyone do the math on this one ??
Will it make the 800mb 1 CDR goal ??

Quality looks pretty good, even at CQ 50+
-vhelp

Ok, I really need to know if accuracy of 1.1.11 or 1.1.12a is better. However, all reports must be consistent. That is, if everyone gets great results with 1.1.11, then that sampling is the one to be used on future versions. 1.1.12a is different. It has a longer sample window, but takes far less samples per movie. I'm still testing both, with mixed results :!:

-kwag

Hi Kwag..

I'm not sure what you mean by consistant, but..

Count me in, for my "Red Planet" project, if you can wait till 4 hours later :lol:
for the results.
You already know the stats for that movie :wink: But, see above for my
setup for CQM v1.1.12a :!:

I don't know if all these are factors in your analisis, but I'll help if I can.
Boy, am I glad I got my 2nd pc up and running again for these kinds of fun
things, while I do other fun stuff on my main pc :lol:

"Red Planet" encode project:
Size: - - - - - - Timed - - - - - Position in Movie:
------------------------------------------------------
216mb - - - - - 1h:27m - - - - 30 minutes

Does it matter for:
* source type ie, divX or DVD rip or Capture
* NTSC vs. PAL
* Film vs. Interlace
* Movie length

-vhelp