Did a test on 4 different encoders mpeg2

[frederick]

I used cce basic, cce sp, mainconcept and tmpgenc.

I found that cce sp gives the best results
mainconcept just slightly better then cce basic and last was tmpgenc.

I would like others feed back. If they had done simular tests.

[mrtristan]

I don't like the interface of CCE and Mainconcept, so I didn't get very far in my testing. I had trouble trying to match the settings in each program to be identical and gave up.

[txpharoah]

I used cce basic, cce sp, mainconcept and tmpgenc. I found that cce sp gives the best results mainconcept just slightly better then cce basic and last was tmpgenc. I would like others feed back. If they had done simular tests.

Tests like these may depend more on your expertise level and source moreso than the program. It also depends on what you look for in terms of "results".

I'd respectfully have to disagree with your findings. But if it works for you, and you like it, then keep on using it.

[MrKGB]

I agree with txpharoah.

frederick,
There are very many variables when you compare encoders: bitrate, resolution, encoding method, etc.
You can't just say encoder X is crap and encoder Y is the best. You must also give all conditions at which you encoded.

For example it is well known that tpmgenc is the best in mpeg1 (i.e. low resolution) encoding, whereas in DVD encoding there is no clear winner.

From my experience I know that CCE is very bad in mosquito noise department on low (SVCD and CVD) resolutions.

[Vejita-sama]

The thing with CCE is that the user interface sucks. You really need to know what your doing or have a front in loader (eg. DVD2SVCD) to do it for you.

Most people don't know to properly adjust GOP (or even what it is, no insult just a statement of fact). TMPGenc is great because it's cheap, for MPEG1 it's free, there are templates that basically give you what you want, nice user interface, etc.etc.

I actually like (and pretty much only use) CCE. But it took a while before I figure out how to use it to it's full potential. Never used main concept thou...

[trillium]

You are right, the interface on CCE pretty much stinks. I've been using DoCCE4U though which actually helps in demystifying some of the settings. What I usually do is then examine the .ecl file that is created to see how it is setup and do some tweaking from there.

Granted it IS a learning curve but at least it gets your started in the right direction!

[DJRumpy]

I find the interface in CCE logical, and easy to navigate. I've been using it a while though.

MrKGB, the story about CCE, and MPEG-1 isn't true (at least not in the new versions. I can't speak for the old versions). Use the proper matrix (Ultra Low Bitrate), and it looks far better than the macroblock prone output that TMPGEnc creates (this is only an opinion of course).

I also agree with txpharoah. Expertise level can get probably net you good results, out of any of these encoders. It seems to be more a matter of preference, since they all offer low cost solutions.

[SatStorm]

TMPGenc Plus 2.510 / 2.511 / 2.512 have a specific problem which creates macroblocks on 2 Pass VBR mode. The encoder doesn't response correct inserting correct amount of Intra frames on scene changes. So, any shot includes fade in and fade out creates a f*cking full of blocks result.
Overall, the quality is better so the compression, but without correct scene changes detection, it is useless.

To test yourself what I'm saying, try to insert manually Intra frames on the scene changes and then encode. The results are amazing. Better CCE (IMHO). But try do this to a movie or -the horror- on a typical music video-clip. Practically impossible.
The TMPGenc creators have to make better the "detect scene change" fuction. Also, they have to low the treshold of the automatic intra frames inserts. Okey, maybe the file gonna turn bigger (about 1 - 2%) but who cares. The quality is that counts!

With this new situation, the older rule for xCVD for example (1000 minimum 2000 average 3000 maximum) don't work good anymore. The picture is way better if you set 1600 minimum 2000 average 2400 maximum.... And looks overall even more better if you set 1800 minimum 2000 average and 2200 maximum. But that way, you are practically CBR, why waste time to encode 2 Pass ? And also if you encode with VBR the idea is to give the more bitrate to those scenes they need this extra bitrate. So close values don't give you nothing!
I never liked CQ but I done some tests in the past and i repeat them now. Well, forget values like minimum 0 maximum 3000 @ 65%. What is your desired average? Let say 2000. Well set 1700 minimum 3000 maximum @ 40% It is the only way to get quality with this mode anymore (and that not always! The problem is bigger here for the scene changes...)

Also, my latest tests show me that TMPGenc's CBR mode is clearly better CCE CBR mode. But who use CBR those days? Well, start thinking using it from now on! For clips less than 10 minutes, TMPGenc's CBR mode is the answer if you want quality with this encoder. Otherwise, it is time to change encoder....

Mainconcept is good. CCE Basic no. IMHO of course...

[DJRumpy]

Nice work on the research by the way. I wasn't aware that the macroblock problem had been identified so specifically.

But that way, you are practically CBR, why waste time to encode 2 Pass ?

You can never go wrong with more passes. I would think that even the faulty versions of TMPGenc would benefit from the additional info gained by the extra pass (although from your description, it sounds like that isn't quite true). You could always do a multi-pass CBR mode in TMPGenc, setting your min, avg, and max to the needed CBR value. The additional pass info should assist on fades, and scene changes. I'll stick with CCE. I've grown accustomed to the speed and quality

[SatStorm]

DJ, I use to state this thing long time ago:
For extra quality freaks, use min/aver/max at the same value. Better pixel alocation that way per frame, so better picture. I have it as a suggestion to my old CVD article. But I 'm not a quality freak and that difference can be noticed only on a HDTV set. On a mainstream PAL TV you need ideal equipment to detect any difference.
Just imagine that many people in the PAL Land don't see a true difference between VCD and SVCD!

Another problem with TMPGenc is that it doesn't do a good average bitrate calculation job.
How to express it in english.... Let me try:

Let's say you have a 10 min video clip which is static except a specific one minute scene which goes wild. You use 352 X 576, TMPGenc plus, 2 Pass VBR with min 1000 average 2000 and maximum 3000.

The logical thing would be that the 9 min gonna be something like 1800kb/s and that specific wild action minute could go about 2800kb/s.
With CCE that is how it goes. And that's why the picture is perfect.

But with TMPGenc, it goes like this: The 9 minutes are forced to use.... 1000kb/s just to make possible to this 1 minute to use the whole 3000kb/s highest value. That of course f#ck up the whole encoding.

Somehow, I feel that the developers of TMPGenc just focusing on CBR and CQ_VBR (with the logic I already point) and don't even bother test 2 Pass VBR in every release.
The last time they optimised the 2 Pass VBR mode, was ver 2.53 plus. almost a year ago. Since then, anything else rise except this feature. Now, with this faulse detect scene system they use, they manage to make TMPGenc's multipass VBR fuction TOO inferior compared CBR or even that CQ_VBR mode. The only way to create good quality using 2 pass mode is to use close (and equal distant) values. But that doesn't help for true the 2 Pass VBR mode.

Don't mention that for them - the TMPGenc developers-, we - the Pal users- don't really exist! Anything is optimised for NTSC and then, once in a while they do a general optimatation for PAL. Meanwhile, all we, the PAL users paid for TMPGenc plus, force to use older version to avoid ghost effects, colour problems (the red terror...), etc.
I never thought I said this but I 'm really start looking for alternatives. They don't respect me -as a Pal user and costumer- as they have to.

And it is not the first time a broken fuction of TMPGenc continues for so long time: They have a history doing this. Like the broken mpeg 2 fuction from version 12 to version 12F (as the older users remember). For about a year, version 12 (NOT 12a which everybody searching, that version was VBR broken!!!) was better any newer version of TMPGenc for mpeg 2. Untill version 12F! Same story now: They know the problems and they do nothing to solve them. Maybe, they thinking that people use only CBR and CQ, or that most users are NTSC and PAL is a secondary thing. Well, maybe this is true. We, are minority. But being a year now with a broken PAL version (2.56 was partly restored) is just not right....
Anyway...

[DJRumpy]

I would think that even with PAL, the difference between SVCD, and VCD would be obvious. It certainly is in NTSC land. I admit it. NTSC sucks. There's just no nice way to say it. We could do without interlacing, IVTC, color guessing games, and wierd framerate conversions {*sigh*}.

(Ok, I'm over my PAL resolution envy now)

It's kind of strange that encoders don't offer a multi-pass CBR mode out of the box. It can, of course, be emulated with VBR (max, min, and avg set to the same value). The IBM document even mentions a multipass CBR mode as being superior to single pass CBR, but I've never seen it implemented as a one-click encode option.

As to the VBR borrow method used by TMPGenc, I know that CCE will not take bitrate from a scene that doesn't have it available by default. It will only take from those that can 'afford' it. The exception of course, being a AVG setting that is low enough to reduce the overall quality of the entire MPEG. In that case, it would lower the overall quality (quantization) to give a more balanced output, rather than improving a single scene at the expense of the rest of the output.

TMPGenc was, and still is an amazing tool, considering the single developer source and it's freeware/shareware origins. I simply think it's outclassed by CinemaCraft, and Main Concept.

[energy80s]

Satstorm, I use Version 2.56 plus of TMPGenc in CQ mode all the time. I wouldn't waste my time (or electricity) on variable pass encoding when there is really very little difference in quality. Normally I use 2000 min / 4000 max at CQ90 for 1/2 DVD's and 4000 min / 8000 max at CQ85 for full DVD's. I agree that recent versions of TMPG are biased towards NTSC so refuse to update my copy. If it ain't broke, don't fix it!!

[energy80s]

I would think that even with PAL, the difference between SVCD, and VCD would be obvious. It certainly is in NTSC land. I admit it. NTSC sucks. There's just no nice way to say it. We could do without interlacing, IVTC, color guessing games, and wierd framerate conversions {*sigh*}.

(Ok, I'm over my PAL resolution envy now)

Although you can see a difference between VCD and SVCD on a PAL TV the difference isn't really that much. You've got to remember that most TV screens are less than 26" so picture defects aren't so noticable. I think that everyone knows that NTSC is crap. It was the first colour TV system and therefore the worst, just mention NTSC to any cameraman in here and you'll get the response "Never The Same Colour"! I think that's why the US government decided to go High Definition as the existing definition was so crap. Maybe that's why no-one in Europe gives a toss about HDTV (well, that and the cost of upgrading!)

[DJRumpy]

All I can say, is I hope you eventually get it. The hi-res modes like 1080p (1920x1080) is a sight to behold. The TV's are becomming somewhat common in the electronic's stores here. I've already purchased a widescreen HDTV. They are getting cheaper all the time. I can only assume that the dropping costs here due to competition will eventually affect world markets.

[energy80s]

It's not the cost of the TV's but the cost of upgrading TV stations that is totally prohibitive. HDTV will not happen in the next ten years as no-one can afford it, it's as simple as that. My God, very few countries even use 16:9 widescreen pictures, so I wouldn't hold my breath for High Definition.

[DJRumpy]

For once, the US Government made a decent decision, since they are requiring all broadcast content to be in HDTV within 10 years. I think they have to be completely HDTV by 2006 (I can never remember the year). I asume they can just write off the expenses, or at least part of them.

[MOVIEGEEK]

For once, the US Government made a decent decision, since they are requiring all broadcast content to be in HDTV within 10 years. I think they have to be completely HDTV by 2006 (I can never remember the year). I asume they can just write off the expenses, or at least part of them.

According to the FCC it's 2006.

@BBC
There you go again bashing NTSC and HDTV.

On topic,
I've never used CCE or Mainconcept but i've had good results using TMPGEnc Plus and 2 pass VBR.

[SatStorm]

Next year (2004) the first European HDTV channel gonna air from SES' astra satellites (19.2 East). It's gonna be a cultur style channel, DVB satellite only.
Nobody gonna watch it of course (that reminds me that 3Sat 15 years ago, from Germany. Today is a decent channel but back then... My God... Alpin Schlager everyone?

[edsmith77]

DJ_Rummpy,
I was kinda surprised by your statement

It's kind of strange that encoders don't offer a multi-pass CBR mode out of the box.

I just recently purchased CCE Basic (to broke to go for the gold), anyway, on the left pane is a radio button for 2 Pass CBR. And if not mistaken you can then either select elementary streams or system. Unfortunately, you can only set the max bit rate not a min, average, max.

When I first got the program, I was very confused by what advantages 2 pass CBR could offer. But from this forum thread and some playing around with that function, I can now see what is going on behind the scenes, so to speak. From my limited testing and personal tastes, 2 pass CBR does offer up better results than 1 pass CBR and 2 pass VBR.