Doesnt make sense

[Gabriel]

I just upgraded from 700Mz athlon 128 mg ram to XP2000 256 mg ram same hard drive and video card. When I rip a dvd with CLAD it now takes about 16 minutes for 2 hour. Used to be 40 +. When I go to encode with TMPGE it now take over 30 hours for the same movie that it used to take less than 13 hours to encode.

All right, I'm an idiot. I know I'm doing something wrong, but I have no idea where to look. Any help will be appreciated.

[vcdfreak]

How's the environmental settings? SSE and 3DNow checked? Task Priority set to Highest? Just a suggestion. I am curious why this is so too.

[vcdfreak]

Ignore the previous posting. Now I see your problem: it's just too fast to be true... How's the converted video? If it's good, I want your system...

[Nelson37]

Check the CPU and MEM speed settings in CMOS, many MOBO default to a lower speed setting, my XP1700 set at 100MHZ ran about the same speed as my old 1.4, set to 133 speed is significantly higher (duh).

assuming all program settings are the same, of course.

[Gabriel]

Duh is right. I didn't think to check that; it did default to 100 mhz. Changed to 133 and it reduces processing time from 30 hours to 22 hours. My old 700mhz did it in 13. Beginning to think I should find a new hobby.

[Nelson37]

Are you sure you are using same Program settings? Improvement in rip time indicates DMA mode OK, 13 hr to process 2hr movie on 700Mhz with TMPGenc is PDQ, are you sure comparison is valid? Same movie, no error, same length of clip, etc? I'd lay money SOMETHING in encode settings is different.

[Gabriel]

To best of my memory all settings are the same. May be some minor variations on sharpness or color adjust but nothing major. Everything about the new cpu works great except this. I tried different quality selections from fastest to slowest and the difference in time was only about an hour. It seems to me that with the old cpu it was a lot greater although I only use fastest setting for tests and use highest quality for all encoding to make a disc. I admit I'm not an expert but this one's really got me stumped; it's like, this can't happen.

[vcdfreak]

Can you give more detail on the upgrade? From which motherboard being upgraded to? The model and the make. Any OS change? Any IDE connection assignment change? The FSB and memory speed? Any reformat of hard drive done? Reinstallation of drivers?

[Lord Gaiyan]

Here's what I'd do. Download SiSoft Sandra and have it look at your system. It'll tell you if something is out of place and how to optimize your system. It's awesome. It'll also benchmark your computer's CPU and compare it to similar ones so you can compare your results to others.

If SiSoft Sandra turns out ok, then I would re-install TMPGEnc and see if it makes a difference. Also try loading a basic VCD template and encode a movie to standard VCD. My 633 Celery takes about 2-3 minutes to encode a minute of the source. Hope this helps.

Joshua.

[Nelson37]

My guess is that your 13 hour encode was made on fast motion search setting, perhaps unchanged by accident. The one hour speed difference, IF that was on a 10-15 hour encode, indicates board running pretty fast.

Do you have any saved project files from previous board, wherein you still have source and KNOW how long old board took? That will guarantee same encoder settings. You could also run some standard benchmarks to confirm correct speed.

Rip speed and quality change one-hour difference point to good speed increase. To compare adequately, you must make sure all settings are identical, otherwise comparison is useless.

[Gabriel]

Thanks to all who replied. Here's the answer. I reinstalled TMPGEnc and reencoded. And it now takes 4 hours instead of 13 on old system or 22 I was getting. When I opened TMPGEnc I got a message that said
"CPU has been reset to default since it may be a different processor from last use." Apparently the program looks at your cpu and remembers it so it must have been telling my new one to act like my old one.

Anyway, I guess the moral is don't go looking for complex solutions until you have eliminated the obvious by reinstalling the program. Thanks again everybody.

[Nelson37]

No reason, and frankly I'm not sure it's possible, for software to reset processor speed. (Inserting timing loops does not count). 700 Mhz Athlon may not have had SSE or 3dNow settings for TMPGenc, this only area of program which should have reacted to processor change. Did you check these settings as was asked earlier?

[vcdfreak]

TO my understanding, TMPGEnc will check processor settings every time it runs. Processor change will be detected instantly. Not sure whether this requires the reinstallation of TMPGEnc to detect. Maybe this is just for the latest version. I used to use version 2.02 on removable mobile rack on diferent computers. It gives the warning as you stated every time I move to different PC without any reinstallation. Latest TMPGEnc version might move the detection on every installation only. Maybe this explains the scenario.

[Nelson37]

I'm still curious what's going on here. Unless they deliberately insert timing loops just to slow down, or stop running until re-installed, the only way I could see for TMPGenc to slow down dramatically would be for it to turn off the 3dnow or sse options, or not turn them on until re-installed. Software cannot directly set processor speed.

I'm not yelling at the original poster, I just wish to understand the scenario.

[Gabriel]

Nelson,
I would like to understand it too. I haven't found an explanation that I like or that makes any sense to me either. All I can tell you for sure is that it runs great now.

One interesting side note, I had been using TMPGEnc for at least three months and my 30 day trial for MPEG2 never expired. The day after I reinstalled it, it did. Luckily I knew what to do with the registry. I'm not sure it's enough better than MPEG1 to justify $48.

[Nelson37]

Try turning OFF the 3dnow/sse checkbox and check encode speed, I know it goes slower on my rig but it would be interesting if these settings would match your observed speed loss.