MainConcept MPEG Encoder 1.4.1 is out
 

They said they got some bug fixes out, and all I can say is there definitely right, I even got CQ Mode 128 working w/o error(s), and got some good results. And there is a new feature called auto GOP with looks like it has potential, more info go here http://forum.mainconcept.com/viewtopic.php?t=1131. If you want me to I can post my new template, or you can just get my old one and just add what you want.

Going though lots of testing and yes looking very promising.

P.S. I am a MPEG-2 fan since my DVD-player is one too, so all my testing is MPEG-2.

Hi ak47:
since I'm trying to make an MPEG2 file from an analog capture, I downloaded MCE 1.4.1. And I'm new to this. I read in the forums that there's a template for MCE, like that ones for TMPGEnc (a file named ***.mef, isn't it?). Could someone post a similar kind of templates (for KDVD and for SKVCD, all MPEG2) for MCE, like those for TMPGEnc?.
And you talk about CQ in MCE. But I've been messing around the program, and didn't see where I have to set CQ mode...
As you can see, I'm really a newbie in this program (well, almost in anything) :oops: :roll: :lol: :lol:

First to change it to CQ mode you must select variable bit rate change the min bitrate to 0 and same with average. For the template use this. That you paste in the Documents and setting, user name, application data, and MCMPEGEnc folder (this is after you create a blank or some type of mpeg-2 template).
P.S. change what you want like gop and so on.

Thanx ak for your answer.
If I set min and average to 0, then CQ works with bitrate between 0 and max bitrate, am I wrong?. And, is there any figure to adjust the CQ level?. Sorry for these really newbie questions, but as you see I'm lost.
Whe also cannot work in CQ-VBR mode, isn't it?. I'm not thinking about using it yet, because I think about making use of MCE for SKVCD and KDVD, with resolutions above 352x576, and average bitrates above 1800.
In your template I see that the resolution is 544x480. Do I have to crop&resize, or just resize in my avs script and leave crop&resize as is, or better in blank?.
Do I have to set the mode like in TMPGEnc (center, full screen (keep aspect ratio),...), or will it be done automatically?.
Maybe you'll think I'd better make some tests before asking :oops: , but as I said, I'm lost.
Thankyou for your help

Right, and that's one of the crappiest features of MCE, because having a MIN of 0, will miserably fail on most standalone DVD players :!: Again, another bad feature (just like in CCE), where the increment steps are integer values. There are no decimals, so CQ resolutions are limited :!: Now you're not :) There's no such thing in MCE. Actually, it's a "CQ" type encoding, but the clasification of CQ or CQ_VBR is really defined in TMPEG.That's the way MCE really shines, and also at 352x240(288). For anything else, use TMPEG.Don't use MCE for 544x :!:
You'll get a crappy MPEG file, because MCE can't handle proper bitrate distribution at that resolution, for the needed bitrate "swing" between MIN, avg and MAX, unless you increase your MIN and average. But then you'll void the primary concept, which is to make your KVCD at a low average bitrate. Use TMPEG for that.

-kwag

And did you recognise the possible range of the integer CQ values? Not that much, right? :wink:
That's also a reason why I kicked MCE directly out of my prediction routine tests. But maybe at that time I still stuck with an older Version?? Well its 4-5 Weeks ago and at that time I used the newest.

Kwag I love MCE cause I get better results, but I have to agree with you 100%. The CQ mode is crap since you only get a choice of 0-31 and 5 and above are always going to be less quality than you want (you can only get 500MBS even on a 3 hour movie). But if you get the right CQ to match you movie then it is very superior. Yes MCE does need to change few things in there encoder, but mostly there CQ mode.Also Could you explain more on that.

It's very simple. Run CalcuMatic, and choose a movie of around 2 hours.
Now feed the average bitrate given to CalcuMatic. Use MIN=300 and MAX=2,500 and set your TMPEG project to 704x480.
Now find CQ and make a clip of a couple of minutes.
Now run MCE, and use the same MIN, AVG and MAX, and encode the same first couple of minutes.
Now playback the MCE encode, and enjoy "Rubics Cube" on action scenes :lol:
The clip created with TMPEG, will exhibit FAR FAR less blocks that the MCE encode.
Drag the mpeg files to bitrate viewer, and you'll see that the clip made with MCE doesn't have high enough bitrate on peaks, but the one created with TMPEG will :cool:

-kwag

What version was this tested on.

1.3x.
And there's no difference between that and 1.4x

-kwag

@All,

Here, this will probably clear all doubts about which encoder is best for low bitrates ;)

TMPEG v.2.51: MIN 300, MAX 2,500 CQ 50. 720x480 MPEG-2 3:2 pulldown.
http://www.kvcd.net/tmpeg-lowbitrate.mpg

MCE v1.4.1: MIN 300, MAX 2,500, AVG 900. 720x480 MPEG-2 3:2 pulldown.
http://www.kvcd.net/mce-lowbitrate.mpg
And with all these errors on the log:

As I always say: "A picture (in this case, a movie) is worth a thousand words" ;)

-kwag

Sorry Kwag (answering you in two forums, maybe too much digitall.doc for just one day :lol: ), this isn't a KVD question, but:
this happens at low bitrates, but what about an average of 1800 and high of 3000?. Still Rubik's Cube? (I loved that game, now I play KVCD :wink: )
And you talk about setting CQ, but still don´t know where.

Kwag can you tell me what VBR mode you used,like fast,Mode 1,mode 128. Because I found out that in verion 1.4.1 only worked with fast mode properly. Also try out the new feature auto gop and see what you think.

Hi ak47,

I used Mode-1. The recommended mode. The other modes are worse :lol:

-kwag

Wow I guess CQ mode finaly has an advantage. I tried all three modes on a 2 hour move and not one frame skip.

Yes it has an advatage according to quality (at those low bitrates) but the range of CQ integer values is to short so its very difficult to do a precise (manual) prediction.

Kwag have you tried a CQ of 1 2 or 3 with a simple avs script i think you change your mind.

As incredible posted, you can't do proper file prediction with MCE, because of the small integer range.

-kwag

But you can make a video with MCE with a CQ of 3 then use Tmpegenc to predict and encode the same file size. But that kinda of defeats the purpose of encoding since you can only make a 600mb or a 820mb file with MCE, compared to a 800mb right on file with Tmpegenc. MCE will produce the better Mpeg-2 file with CQ, but the fact is you will never get the size you want to make it causing worse quilty. Thats why I moved on to FFmpeg.

You never do that :!:
That's double encoding. Another layer of macro blocks over a previous generation. Results are unacceptable :!:

-kwag

No I mean use the same soure(like directly from the vob) to encode two differnt files, one with MCE and one with Tmpegenc. Not encoding to MCE then Tmpegenc, but seprate.

AK47 means, two separate encodes with the same size to do a fair comparison.

.

Yes, I know what you mean can't do accurate file prediction because you can only do integer and not decimal. MCE dosent take long time to encode you can do 2x 3x in the same time it take tmpgenc to do 1 encode. I can get filesize right doing this and still beat tmpgenc. I don't need such accurate file prediction as i do it to dvd and not cd.

When i try to save a kvcd profile in the newest MCE 1.4.01 it crashes only half creating the kvcd.mef so i recreate the kvcd.mef fully and reload MCE and i have my new profile.

I have also found with this new alpha version i can load my avs scripts fine without having to disable idshow.dll by renaming it.

I now use the Mode 1 in rate control mode instead of fast and no problem now.

MCE is slowly getting better all the time. If you post your suggestions/ problems in the MainConcept forum they will take notice.

FFMpeg which applications use FFMpeg. I know it started out under linux.

Sorry if I ask before testing it, I just ask in case you made the test...
There are several parameters to be adjusted: search range, search method, noise sensitivity, motion seach mode,... Did you notice if changing these values, we get different sized files?. This could be a way to adjust the file size, making use of a range of values for this parameters, that gives us good quality and allow to change the final file size.
... don't be cruel, it was just an idea, I still didn't test. :lol:

The parameters you suggested wont make much difference the main parameters that affect filesize are Average bitrate,CQ, and IFrames and also the bitrate for sound. The bigger the I Frames the smaller the filesize because of more compression but too many will NOT make it play right on ALL dvd players. It's fine if you play it on your own dvd player and test it for that but dont expect it to work the same on others.

Friends ... its not only that MCE only supports integer values (CCE does this too) ... its the range ... and the range provided by MCE is not enough to get a acurate final size output even on DVD-R encodings!
That means for example ... if you end up with an 3,3 Gig m2v and 3,9 would be wanted ... this means a big loss in quality so what you will receive in better speed on the other hand you have to substract to the quality!
Ok ... you could choose a bigger Q Value in MCE of its short Q range, even it would override your wanted filesize and afterwards doing a transforming on that. But thats not sexy I think ;-) But that's how Q mode could work to obtain an accurate end file size in comparison to quality. But MCEs Quality and afterwards transforming ... oh oh

But .... I also did a lot of comparisons ... MCE on low bitrate encodings like KVCD OneCD Encodings ... and the result doesent match to my opinion about quality which could be received at OneCD Encodings, but we also discussed a lot in here about this subject.

If encoding to DVD-R (for example 2 Movies on 1 DVD-R and therefore a higher AVG Bitrate) in my opinion I would choose CCE if you want more speed. Because it maybe also only accepts integer Q values but the range is much more larger than the range of MCE ... so I everytime end up with a accurate wanted end file size done by a fast manual prediction.

I agree with you thats why I said thisThe fact is MCE is better in quilty with mpeg-2 in CQ mode, but it will never work out since there isn't a wide enough range of CQ numbers. It is great speed so it would be easier to predict if you use the same method, but its pointless since you can't make the quilty you want.

Just another silly question :? , that I didn't test, but tell me what you think (or your experience) :
let's think I encode at CQ 3 and get a 700 MB file. Maybe if I raise to CQ 2, it will grow too much, isn't it?. But, what about if I now raise the average bitrate, or the maximum bitrate, or if I slightly change the resolution (704x576 to 720x576 for instance)? I'll get a bigger file size, better quality, won't I?.
I guess that this way it's difficult to fine adjust the final size, it just an idea... in case it really worth it MCE for encoding MPEG2. If not, with better stay in TMPGEnc for MPEG2 also. What do you think, friends?.

Well that is and will be a philosphy ....

I went 3 days non-stop into the deep of this MCE ... also testing its mpeg2 capturing capabilities too.
Refering to a frameserved mpeg2 encoding: MCE IMHO is still not very well developed (That's only my point of view) ... I compared mpeg2 encodings ABOVE AVG Bitrates of 2000kbit and there was not a better result like CCE provides (or TmpgEnc), maybe the same ... so I stuck with TmpgEnc for encodings done at mpeg1 and CCE for encodings done at mpeg2 above avg 2000kbit. ZigZag scanning mode of MCE is almost the same as CCE BUT the alternate scan mode is still not very well developed. There's only one thing I do like at MCE in comparison to CCE ... the better individual GOP Settings! And here I'm talking about encodings at 704(720)x480(576) mpeg2 but in case of DVD anyhow I won't get out of a GOP structure based on IBBPBBPBBPBBPBB (PAL). But as I said ... these are only my experiences and thats where my opinion bases on.
So everybody will do his own experiences. ;-)

Thanx incredible:
for people like me, that are going to start testing with MCE, and have no experiences at all, your experience is a good departure point.
I'll stay with TMPGEnc in MPEG1. And will try MCE for MPEG2 (average bitrate above 2000), and I'll have to download and test CCE.
... to begin with :lol:

Why is everybody trying to encode in CQ mode instead of 2-pass VBR? Just set min, max and average bitrate and do a 2-pass encoding and you'll get the filesize you want according to the average bitrate.

Sorry Ronnylove,

u just got in here and didn't read the history of testing and developing in here.

The 2pass Bitrate Allocation of TmpgEnc and MCE according to low Bitrates is very bad! AND TAKES MUCH MORE TIME!

And thats the point why I throwed MCE away (sorry) cause it gots a too small range to set the right CQ for a correct end file size. Not mention the Quality at low bitrates. 8O

Read the MCE Threads in here, there's explained everything.

I can't find any good thread comparing the quality of Mainconcept 2-pass encoding to CQ encoding. Most threads are about TMPGEnc. I don't care if it's slower if the quality is better (which I'm not sure of yet).

Are there any SSIM quality comparisons of MCE CQ vs 2-pass? With the SSIM avisynth plugin you can compare the quality to the original uncompressed . SSIM seems rathor good as video quality measuring tool:

http://forum.doom9.org/showthread.php?s=&threadid=61128

You can use vertical stacking with an avisynth script, and make a visual comparison, which is more realistic.
Something like this:

Then load the .avs in vdub, and analyze the frames.

-kwag