CCE 4pass vs TMPGEnc 2pass...done

[Twin]

Ok, here goes..
I've done some testing lately with a chapter from 'Gone in 60 Seconds', [Chapter 25, 5:50min], which includes alot of fast-motion scenes, closeups, alot of shining metalparts and also some dark scenes.

I used CCE 4pass with DVD2SVCD's default settings, and I used TMPGEnc with DVD2SVCD's default settings, I think atleast =P

Both creations took 1h10min..
Well, after the .bin files were done, I checked the size on them, and both were 105MB, which means that I could have 44min on one 700MB CD [(795/105)*5,83 = 44]. So, everything fine so far..

Then it comes to this "CCE rox TMPG in bitrates over 2000kbps.."
My settings were min. 755, avg. 2250, max. 2408. (Sound 192).

I burned both and I couldn't tell anything different. I've checked them like 30 times and I just cant see why CCE should be so much better..

Why is it that CCE is so much better?
Just curious. =P

[frenetic]

Well...you kinda already stated why.

CCE 4 pass vs TMPGEnc 2 Pass <-- CCE does 4 passes in the same time TMPGEnc can do 2 passes.

People like CCE for it's speed.

[adam]

When you say 4 passes do you mean you set the pass # to 4? If so than that's really 5 passes because the first pass is actually when it creates the .vaf file. You don't really gain any noticable quality after the 4th pass so your cce encoding time could have been much shorter and still have achieved the same level of quality. If you don't notice any quality difference than like frenetic said, cce gives the same results with a much shorter encoding time, can't beat that.

Also you should run more tests using longer footage. Much of CCE's quality improvement over TMPGenc lies in the fact that you are doing so many more passes which means better bitrate allocation. Well bitrate allocation is moot on such a short clip. If you were to encode an entire movie than I think the differerence in quality would be MUCH more noticable.

For many people, including me, cce at 4 passes does look alot better than TMPGenc at 2 passes and it takes alot less time to encode. CCE is the clear winner as far as I'm concerned.

[Jestorius]

Why should I use CCE4x if there isn't any differnt in the file size or quallity compared to Tmpgenc 2x? Tmpgenc isn't slow anymore.

[mrbass]

God gave us free agency for a reason. I suggest you exercise yours and use TMPGEnc if it makes you happy.

[Jestorius]

Ok, try this,

Set Tmpgenc environmental settings/CPU use multi-tread (even if you have only 1 cpu) ->enable all , Cache 4096MB -isn't it much faster?

[adam]

Why should I use CCE4x if there isn't any differnt in the file size or quallity compared to Tmpgenc 2x? Tmpgenc isn't slow anymore.

Ok first off I have to clarify one misconception in this thread. The encoder has no effect on filesize. Your filesize is a product of bits per sec x the number of secs in your footage. Your filesize is determined by your bitrate, period. In comparing two encoders to each other you need to compare quality and speed and really thats all there is to it.

As I stated before, for many people there IS a definite quality difference between cce and TMPGenc. Even if the encoding time were the same cce would still be the better encoder.

TMPGenc is much faster than it used to be but it is still nowhere near as fast as cce. TMPGenc @2 passes is NOT as fast as cce @4, at least not for me. If using cce at 4 passes you think the output is no higher quality than TMPGenc @2 well you still shaved off a couple hours from your encoding time.

The only reason I can think of not to use cce is the pricetag. Otherwise, on most sources, it is faster and better than TMPGenc.

[phhoth]

There are 2 reasons I like to use TMPGenc.

1. TMPGenc has a great product at a more than fair price. CCE's price tag is nuts!!! and that brings me to the next point....

2. I bet most of you who use CCE cannot afford to pay this price...
so where does this leave you.

I would rather support TMPGenc legally and give them the means to improve their product. THINK ABOUT IT!!!

[Twin]

Well...you kinda already stated why.

CCE 4 pass vs TMPGEnc 2 Pass <-- CCE does 4 passes in the same time TMPGEnc can do 2 passes.

People like CCE for it's speed.

My point was maybe badly pointed out;
CCE vs TMPG (on this clip): Same time, exactly the same quality. So I don't care that CCE did 4passes (5 really then as Adam wrote), because the output of TMPG was just as good as CCE's.

I do not know really why I started this thread, I already knew that CCE has been proved better, but these were the first tests I made myself on this issue and my point is only about this clip, I do know already that CCE mostly gives better output than TMPG, but I just had to get some comments I think, since my little test didn't match up with the "general" opinion...

[ChevyNo1]

I have done tests with dvd2svcd with both CCE ( 4pass in box, so 5pass ) to tmpgenc's 2pass. CCE is not faster, at least on my machine. I wonder if I'm missing a setting somewhere? I have an Athlon 1800+ with 512mb ram and a 60gb drive, 2mb buffer and 7200rpm with nothing else on it. I can't seem to get CCE to go nearly as fast as others can, so I always use tmpgenc.

- Vidfreek

[PimpInDaHouse]

You need to open your eyes more because CCE is like 5 times better in quality then TMPGEnc. Try doing a 2pass on only the .vaf file then encode the .mpv. That will clean up the bitrate a little. But how can you say that TMPGEnc is the same as CCE. TMPGEnc encodes audio like crap the video is grainy and it takes forever to make a movie. This is how I make my movies:

-Resize to 480*480 with VDub
-3 pass Min. 0 Avg. 2,750 Max. 4,500
-Quality settings: Q. Priority 10 Anti Noise Filter Off for 16:9 and 3 for 4:3
-Video settings: Progressive frames and Zigzag scanning and Intra DC Auto
-Audio: 384 Stereo

My movies look just like the DVD's.

[Twin]

You need to open your eyes more because CCE is like 5 times better in quality then TMPGEnc. Try doing a 2pass on only the .vaf file then encode the .mpv. That will clean up the bitrate a little. But how can you say that TMPGEnc is the same as CCE. TMPGEnc encodes audio like crap the video is grainy and it takes forever to make a movie. This is how I make my movies:

-Resize to 480*480 with VDub
-3 pass Min. 0 Avg. 2,750 Max. 4,500
-Quality settings: Q. Priority 10 Anti Noise Filter Off for 16:9 and 3 for 4:3
-Video settings: Progressive frames and Zigzag scanning and Intra DC Auto
-Audio: 384 Stereo

My movies look just like the DVD's.

Well, with those bitrates I can understand that..

[Truman]

just another cce vs. tmpg topic Both encoders are excellent MPEG encoders. If you setup TMPGEnc properly, you can reach the cce quality, possibly even better, but it takes much longer, but it is cheaper, and it has more features, but the more features the more confused I am, but actually these filters are useless, because I use a video editor, that's why I like CCE, it is very simple and easy to use, but it is buggy and it is very expensive, but actually it isn't, does cce rock tmpg at bitrates higher than 2000kbps or rather lower than 2000kbps? However, I am right.

[Malcom]

What adam says about filesize being a function of bitrate applies only to CBR.

With VBR, the encoder DOES in fact make a difference in the filesize. This is because the bitrate manipulation strategy differs from encoder to encoder. Hell, with CCE, it even varies from encode to encode depending on your configuration parameters (most notably the "Bias" setting in advanced VBR settings).

In your case, with your avg and max rates so close together (?!), the encoder's bitrate management won't make much of a difference and that's why you got file sizes the same from CCE and TMPGENC.

You are totally ignoring CCE's advanced VBR mode (see Doom9.org guide "getting the most from CCE"), which TMPGEnc does not have any equivalent function to. That feature makes all the difference. I usually set the bias low and optimize for lowest Q. factor. Then I manually go in and force max bitrate on any areas where the encoder has a higher Q. factor but did not use the max bitrate (trying to meet the average). In this way I can tell the encoder "it's okay to miss the average a little, but only if it's because of THIS specific scene,." PLUS, CCE's advanced VBR mode displays a (in my experience) very accurate encoded size estimation, so you can play w/ the VBR parameters and see the size as you go, and only encode when you are satisfied. After I used this feature the first time, I could never go back to TMPGEnc.

My personal experience? CCE is faster than TMPGENC and very noticable when encoding full length (1h +) video w/ DVD as a target (4-pass 500, 6000,9300). I still use TMPGENC for postage stamp size, 300kbit, mpeg1 web videos to share w/ friends & family (no, they're not going to install a divx codec). For my DVD-Rs, I use CCE exclusively and would never go back.

[adam]

I have done tests with dvd2svcd with both CCE ( 4pass in box, so 5pass ) to tmpgenc's 2pass. CCE is not faster

Listen to what your saying. CCE did 5 passes and TMPGenc did 2. CCE did more than twice as much processing as TMPGenc and it still probably took the same amount of time. CCE is MUCH faster on your machine than TMPGenc.

Malcom what I said most certainly does apply to vbr as well as vbr. Yes no mpeg encoder is perfect and there are always slight variations from encoder to encoder, even encode to encode but these are so slight that they are almost not even worth mentioning. In vbr encoding all encoders try to stay as close to the avg as possible and both cce and TMPGenc do a VERY good job of it. The bias setting really has nothing to do with it. If it allocates more bits to complex scenes than it will free that bitrate up somewhere else, its all relative...that is the whole point of vbr. The variation in size your talking about is maybe a couple MB's at the most, again its not even worth mentioning considering your talking about files which are over 1 gig.

My point stands, size of output is not a function of the encoder it is a function of your bitrate setting. In comparing CCE to TMPGenc it is pointless to analyze the size of the output because at the same settings the sizes should be almost identical everytime...just try it.

[Malcom]

No you're thinking of "Complexity" in another menu.

The BIAS setting I'm talking about in the advanced VBR menu controls, according to the CCE manual:
"Breaking into bit allocation strategy The encoder allocates bits
based on the original evaluation standard,so that all images have the
same visual quality.Changing the value of the Bias part breaks
into this evaluation standard.0 to 100 can be set here.The initial
value is 30.As the value becomes smaller,more bits are allocated to
complicated scenes,and at value 0,the bitrate fluctuation is largest.
As this value becomes larger,more bits are allocated to simple scenes,
and at value 100,streams closer to CBR are output."

This directly controls how much the encoder allows the bitrate to fluctuate. The lower you set it, the more the bitrate will fluctuate. Try it.

[Twin]

You are totally ignoring CCE's advanced VBR mode (see Doom9.org guide "getting the most from CCE"), which TMPGEnc does not have any equivalent function to. That feature makes all the difference. I usually set the bias low and optimize for lowest Q. factor. Then I manually go in and force max bitrate on any areas where the encoder has a higher Q. factor but did not use the max bitrate (trying to meet the average). In this way I can tell the encoder "it's okay to miss the average a little, but only if it's because of THIS specific scene,." PLUS, CCE's advanced VBR mode displays a (in my experience) very accurate encoded size estimation, so you can play w/ the VBR parameters and see the size as you go, and only encode when you are satisfied. After I used this feature the first time, I could never go back to TMPGEnc.

Please, please make a guide on this =P

[adam]

No you're thinking of "Complexity" in another menu.

The BIAS setting I'm talking about in the advanced VBR menu controls, according to the CCE manual:
"Breaking into bit allocation strategy The encoder allocates bits
based on the original evaluation standard,so that all images have the
same visual quality.Changing the value of the Bias part breaks
into this evaluation standard.0 to 100 can be set here.The initial
value is 30.As the value becomes smaller,more bits are allocated to
complicated scenes,and at value 0,the bitrate fluctuation is largest.
As this value becomes larger,more bits are allocated to simple scenes,
and at value 100,streams closer to CBR are output."

This directly controls how much the encoder allows the bitrate to fluctuate. The lower you set it, the more the bitrate will fluctuate. Try it.

Your right I was thinking of the complexity setting but I am familiar with the bias settings in the advanced tab. In changing these values you are changing the bias of one encoder and not the other. You are effectively changing your avg setting, or more accurately changing how that avg is determined. The same can be achieved in TMPGenc by simply increasing your avg or by using CQ mode and finding a comparable % value.

In changing the bias you are changing your bitrate. If you do this in one encoder than you must do it in the other, otherwise no comparison can be drawn between the two encoders.

Encode a file in cce with whatever settings you want. Now run the file through a bitrate viewer and determine the avg. Now use this avg in TMPGenc using 2-pass vbr. The files will always be the same size. Like I said filesize equals bits per sec x the number of secs. You simply can't argue with that. The encoder does not affect filesize your settings do. If you use comparable settings than the filesize will always be the same, its an inherant property of mpeg technology.

[Malcom]

This is getting old. =)

So adam, what you're saying is that two series of numbers with the same average always add up to the same sum?

I've been out of school too long to try to prove/disprove that math, but in any case, I've had enough. That's not saying that I agree, just that I don't care enough to exert the energy to continue this discussion further.

you win :P

[Malcom]

Twin --

what's wrong with this guide:

http://www.semutrangrang.com/robshot/index.html

A huge part of what I know, I learned from that.

[kinneera]

So adam, what you're saying is that two series of numbers with the same average always add up to the same sum?

All he is saying is that an average number of bits per second can be calculated from any file. If you then use that as the average in another encoder, the resulting filesize will be the same. This is behavior that is easily confirmed.

CCE multipass and TMPGEnc 2-pass conform very accurately to specified average bitrates. Single-pass VBR is an entirely different matter.

[bbb]

Speedwise, CCE is noticeably faster only using CBR mode. This is CCE's only true advantage over Tmpgenc.

In VBR modes, CCE is quite buggy and many times errors out when using VBR modes 2, 3, 4, 5, 6, etc passes (even after uninstalling and reinstalling). CCE's lack of reliability is a tremendous disadvantage, especially if it errors out in the middle of the night or while you are away from work--truly infuriating. Also, when CCE's VBR works, it makes an initial pass vaf file that takes quite some time.

Tmpgenc has improved much in stability, reliability and speed, especially the latest version. The wonderfully useful interface and numberous essential filters are also one of the most important reasons to use Tmpgenc over CCE.

With Tmpgenc, you can specify source frame range to cut a movie at the appropriate transition mark, crop out parts of the image, resize with ease, sharpen video for VCDs, IVTC, use multiple deinterlace options, use excellent external sound encoders/resamplers, and etc. (CCE requires VirtualDub to resize and whose filters are far less intuitive and many times have no preview windows to show the results.)

Qualitywise, I used to believe that CCE produces better quality (e.g., fewer blocks in fast motion sequences). However, Tmpgenc's latest version is very good at minimizing blocks. When blocks do so up, they occur in scenes with tremendous amounts of movements (e.g., scenes with a TV showing static, dancing scenes on a Disco stage with mult-colored lights) which also overwhelm CCE, causing CCE to show blocks. In other words, qualitywise, Tmpgenc and CCE are very close and are both very good when using the latest version and with good clean sources AND granted one isn't trying to squeeze >1 hour of video on 1 cdr.

Pricewise, at under $50, Tmpgenc is a tremendous deal considering its quality and flexibility.

*There are many complaints about Tmpgenc's lack of speed. This is probably due to the fact that Tmpgenc will run on slower end systems (<500 MHz) whereas CCE will not run on slower systems at all.

In other words, there are a number of people with slower systems using Tmpgenc who naturally complain about the speed of Tmpgenc instead of noting the low speed of their systems. On the other hand, people who use CCE have relatively fast systems (because CCE will not run on <500 MHz systems). Hence and ironically, Tmpgenc's greater compatiblity with slower system creates much of its own complaints.

In any case, anyone serious (including video archivalists and video hobbyists) about encoding should plan on upgrading to a relatively inexpensive new Athlon XP system or a new Celeron Tualatin system. You will save time, electricity costs, and your sanity by doing so.

[You_Are_Alive]

Oops, CCE does not work on my PII 450. I have not used it for awhile after I got a real time encoder. I use it on my other PC with an Athlon 1400. CCE requires a cpu that has SSE and PII's do not.

[Jestorius]

bbb -> you are right. Each and every word.

The problem with Tmpgenc is that you have the possibility to choose between some settings. And because most of the users aren't engineers than they are choosing what they think is giving the best result.

Asking people to choose between High and Highest , 99% gonna go for Highest quallity. And it gonna take much more time. How do you know if CCE is using the "highest" setting? During the trial periode I never made a "highest quallity" VCD only a "high" quallity DVD mpeg2. The speed was excellent but only without any preprocessing. And I never could make a multipass VBR encoding because the systemcrash. I guess it is because I never had ~2.000 $ for this software.

As I sad before, most of the studios I know are using Ligos bundled with DPS nle systems. ( never seen a tread here like "Ligos is excellent") They are producing DVD's, and the quallity is higher than you ever gonna make at home. And it is because of the original footage has the highest quallity. And the speed is ~1:2.

[mrbass]

Speedwise, CCE is noticeably faster only using CBR mode. This is CCE's only true advantage over Tmpgenc.

Here we go again yee haw.. I believe I read somewhere that the algorithms of CCE are written in assembly language thus the optimum speed.

In VBR modes, CCE is quite buggy and many times errors out when using VBR modes 2, 3, 4, 5, 6, etc passes (even after uninstalling and reinstalling). CCE's lack of reliability is a tremendous disadvantage, especially if it errors out in the middle of the night or while you are away from work--truly infuriating. Also, when CCE's VBR works, it makes an initial pass vaf file that takes quite some time.

not buggy for me. 99% of movies I've had no problems with for I dare not say how many I've done. I do around 8 a week or so on 3 separate machines. .vaf file time is equivalent to the time it takes of one pass.

Tmpgenc has improved much in stability, reliability and speed, especially the latest version. The wonderfully useful interface and numberous essential filters are also one of the most important reasons to use Tmpgenc over CCE.

that's cool...I'll have to check it out. I used to a year or so ago be into SVCDs from various groups. Each one of those were always done in TMPGEnc. Not one of the releases from 'groups' looks as good as my own backups with CCE. I still have my doubts that looks as good.
Actually I think it might with bitrates of 2200 or above for all I know. Myself I do 1600 4 pass CCE so I can fit 1hr on 1cd, 2 hr on 2cds, etc. And the results are awesome.

In other words, qualitywise, Tmpgenc and CCE are very close and are both very good when using the latest version and with good clean sources AND granted one isn't trying to squeeze >1 hour of video on 1 cdr.

yep that's me 1hr on 1 cd...thus CCE is my only choice.

Pricewise, at under $50, Tmpgenc is a tremendous deal considering its quality and flexibility.

well CCE 2.64 is like only $1,999 and the new link2 ($15?) can frameserver 2.64 so it's within budget for a company. Say if you had your own wedding video production company or whatever.

*There are many complaints about Tmpgenc's lack of speed. This is probably due to the fact that Tmpgenc will run on slower end systems (<500 MHz) whereas CCE will not run on slower systems at all.

believe me there are tons of complaints about CCE being slow. I remember doing sound of music on my PIII450Mhz CCE 3 pass and it took a whole whopping 33hours.

In any case, anyone serious (including video archivalists and video hobbyists) about encoding should plan on upgrading to a relatively inexpensive new Athlon XP system or a new Celeron Tualatin system. You will save time, electricity costs, and your sanity by doing so.

I agree...I still have my PIII450 but now have a AMD 1700 and two 1600's which I rip movies on. Can do two movies per night per machine.

[Kdiddy]

MrBass:

Thanks for writing exactly my response..LOL, you sure saved me a lot of time.

You are alive a question?

Just to let bbb and others know that you can use CCE on a machine <500. I have done so with no problems on my PII 450

.

What version of CCE are you running on a pII450?

As i have an old K6II 500 and it does not run on this.

[adam]

bbb I'm of the opinion that you really havent used cce very much at all if these are your findings. Most of what you said could not be further from the truth.

Speedwise, CCE is noticeably faster only using CBR mode. This is CCE's only true advantage over Tmpgenc.

On all hardware setups cce is signifanctly faster than TMPGenc regardless of whether your using vbr or cbr. In many cases cce can do 5 passes in the time it takes TMPGenc to do 2. How can you say there isn't a speed difference? Its blatantly obvious.

In VBR modes, CCE is quite buggy and many times errors out when using VBR modes 2, 3, 4, 5, 6, etc passes (even after uninstalling and reinstalling). CCE's lack of reliability is a tremendous disadvantage, especially if it errors out in the middle of the night or while you are away from work--truly infuriating. Also, when CCE's VBR works, it makes an initial pass vaf file that takes quite some time.

The creation of the .vaf file IS the first pass. It takes the same amount of time to create the .vaf as it does for each subsequent pass. This is not a disadvantage at all its just a fact. When you set cce to do 2 passes its actually doing 3. Saying the creation of the .vaf is a disadvantage is like saying the first pass of TMPGenc's 2-pass vbr is a disadvantage...that's just how multipass vbr works. TMPGenc's 2-pass vbr is equivalent to cce's 1 pass vbr. Your right though, cce is damn buggy on some hardware setups. There are some conventional methods that you can take, however, which bypasses almost all of these bugs. If you are having stability problems there is probably a very simple answer to your problem. For those people who have taken the time to read faqs on cce it is VERY stable.

With Tmpgenc, you can specify source frame range to cut a movie at the appropriate transition mark, crop out parts of the image, resize with ease, sharpen video for VCDs, IVTC, use multiple deinterlace options, use excellent external sound encoders/resamplers, and etc. (CCE requires VirtualDub to resize and whose filters are far less intuitive and many times have no preview windows to show the results.)

CCE does NOT require virtual dub to do ANYTHING. Anyone who uses vdub to frameserve to cce is missing out bigtime. Using avisynth one can do every single one of those things you mentioned, plus it is significantly faster than using vdub. Some people get a %100 jump in speed using avisynth, and the average jump is probably about %30. Perhaps this is why cce didn't seem as fast to you. Avisynth's filters are arguably better than TMPGenc's also, I know I have much better luck with IVTC.

bbb you are using an archaic and outdated method of frameserving in judging cce. I suggest you follow a recent guide before commenting on cce's quality as an encoder.

[uteotw]

Original question : Why is it that CCE is so much better?

Personally at VCD resolution (MPG1 or MPG2) and at 2000 kbps I can't see any difference either.

But at SVCD and DVD resolution and bitrate then CCE picture quality is better even if use only 2 pass VBR in CCE instead of 3 or 4 pass vbr.

my 2 cents.
uteotw

[mrbass]

@D_Head CCE SP 2.50 and still do. Remember PIII not PII. It needs SSE which a Pentium II does not have. I believe celerons 800Mhz and above do have SSE.

@uteotw I'll concede..perhaps 2000 or 2200 bitrate there is no difference. I'm sticking with CCE cuz it's much faster then TMPGEnc 2pass highest motion search by far. I'll do some speed tests of full movies myself in a couple of days and post the results. I'm guessing at least 2 times slower though.

TMPGEnc blows CCE out the freakin water with MPEG-1 VCD...I wouldn't even think about using CCE for VCD it sucks hardcore. There I just blasted the crap out of CCE..makes ya happy?