I have to say I always get annoyed when people compare linux to windows, but I am going to make a comparison. I have previously used dvd:rip to do all of my encoding of dvd(mpeg2) to xvid(mpeg4). I usually can do a two pass encoding of a movie in about 2 hours. I recently have not had linux to use so i had to find a windows alternative to encode to mgeg4. I found that the newest version of nero will do that for you. Nero also gives the choice of one or two pass encoding. Here is where I noticed a big difference, nero does each pass in half the time. The movies take about half as llong to encode. I was surprised at the time differnce that the two had. Just curious if anyone has any input to why their is such a difference?

When I get linux reinstalled(hopefully soon) I will go back to dvd:rip(transcode) even if it does take twice as long. It just feels better :-)

well, just at a guess - NERO is a commercial company. it can pay who knows how many people to sit down and work out what they think would be the fastest way to encode dvd's. they can likely afford to put them under a great deal of pressure and strain too.
it is quite clear that you do use linux (when it's available to you), so i don't think i need to explain to you that that's just not the way open-source goes about getting stuff done.

anyway, if that sounded cranky, it wasn't meant to. i just thought that it was a fairly silly question

you did not sound cranky. I was just curious if anyone had anything interesting to add.

I guess I was hoping that someone would tell me xvid was superior in its encoding.

Even if the final product is not better, it is superior because it is open source.

Well, that sounds like a nice enough reason. it probably is

Execution speed depends on quite a few things, among them: Type of compiler (and which
optimizations switched on, and how good these are), quality of used algorithms and their
implementation, type of os, that is mainly: speed and behaviour of the task scheduler, number
of processes running (because your process will get only a fraction of available cpu time - the more
processes, the less time you get, the longer your task takes). So saying "de/encoding a dvd under
(some) Linux takes x times the same job under windows" is like comparing peas and apples.
There is, however, something which you can do under Linux which you can't do (easily) under
windows and which, of course, proves linux' (and most other *NIX brand) superiority :-)
That is, change the processes' priorities (how much cpu time they will get).

1. Login as root
2. Be sure not to have any application with important data open :-)
3. Encode something and measure the time (at the console:
time xvid <whatever input> will measure the time for you)
4. Now open up a (new) console, start the same encoding job again. At the console,
type ps x and search for your process, probably xvid or something like /usr/bin/xvid. Get the
number to the far left (the processes' pid) and type renice -19 <pid>. If it returns with a
line like 0ld priority, new priority -19, then your process has the highest priority it can
have and should be finished faster.


HTH

While I have used dvd::rip too and find it a very convenient way to encode ... I was also surprised by the huge time-difference!

But not in comparsion to any windows programs but compared to other linux-tools to do this job.

dvd::rip uses transcode as the backend to actually encode the files - this is an really excellent tool and gives results that are equally excellent - but it is slow.
I use for that reason mencoder - the encoding part that is included with mplayer - which therefore in one more respect - seems to me one of the most useful and best pieces of software.

Using mencoder and encoding by using the ffmpeg-codecs (also open-source) I get results of faster than real-time-encoding (35fps)! If you do two-pass-encoding this comes down to 1.5 the time the film needs to play - while watching it.

The interface is commandline only though - but some useful scripts are included to make things easier and my results are of equally good quality as if I'd been using transcode (I also use ffmpeg as the codec there).
It's transcodes architecture which makes it slower - but you can do things with it that are not so easy in mencoder - encoding to ogm-audio for instance...it can and it has been done by me tough.