That's most likely due to a transcode issue related to NPTL. Try most recent
transcode versions (1.0.2 or better) and don't use NPTL with 2.4 kernels but
a recent 2.6 kernel. If that doesn't help, you can try to workaround
transcode NPTL bugs by enabling the correspondent option in dvd::rip's
First try executing the corresponding command by hand.
You can grab if from the logfile, which is presented on the Log page.
Sometimes dvd::rip is unable to provide a good error message,
this way you often can see, what's going wrong (and please consider
this FAQ item to learn what's not going wrong ;)
Most problems with specific DVDs are transcode related, so
consider quering the transcode mailing list archives resp. subscribe
to the transcode mailing list
and ask your question there.
If you're not sure, you always can post your question to the
dvdrip-user mailing list, but
be aware that you may be pointed to the transcode list ;)
Most probably the DVD is encrypted and your system isn't able to handle this. For the rest of the story please read the next FAQ item.
Copying encrypted DVD's is illegal in many countries. Also it's illegal to provide information about how this could be accomplished. So don't send any questions regarding encrypted DVD's or DVD cracking to the author of dvd::rip or to the dvd::rip mailing list. Corresponding mails will be silently ignored, correspondent posts will be removed from the mailing list archive without notification.
That's Ok. The corresponding messages are printed by libdvdread
if you transcode files on harddisk (which is the default case with
dvd::rip). You see something like this:
libdvdread: Couldn't find device name.
libdvdread: Can't open file VIDEO_TS.IFO.
but these are only (very confusing) warning messages of libdvdread,
which naturally can't find any DVD device or VIDEO_TS.IFO file
from a directory with only VOB files in it. Just ignore these
messages, and please don't report this as a bug.
First: the proprietary DivX codec often makes problems under Linux. XviD is the better alternative, so I'd always suggest to use XviD instead of DivX. If you really want to use DivX, read on, hopefully it helps.
If you're using the 2003 release of DivX (5.01, resp. 20030428) and have a Pentium IV processor, you need to downgrade to the 2002 version. The Linux versions don't make big differences here anyway. The Pentium IV bug is a known problem and ignored by divx.com, as with other fatal Linux bugs in their software.
If you're using the 2002 version (5.01, resp. 20020418) already, there is also a nasty bug.
It tries to create a file c:\trace_b.txt, which fails if you work on a
vfat filesystem, because this filename is illegal here.
For this one a workaround exists. Execute the following Perl one-liner as root (thanks to Christian Marillat) to patch the codec library file (probably the location differs on your system).
perl -pi.bak -e 's|c:\\trace_b.txt|/dev/null\0\0\0\0\0|' \
This command also creates a .bak file.
Yes, somewhat. dvd::rip has command line options which enable you to write small scripts to transcode several projects in a row. Refer to the
documentation for details.
Most likely dvd::rip does it right, but you're playing
the ripped VOB files with a movie player which is wrong.
Do a test transcode of a few hundred frames, play the resulting
movie and you'll see, that you have the right audio channel.
Note: dvd::rip always copies all audio channels
of the movie to the harddisk. It extracts only the selected
viewing angle and scans the volume of the selected audio channel
in the same run. With the volume scan information it's possible to
rescale the volume to the maximum during later transcoding.
First try the PSU core of transcode resp. enable the corresponding
checkbox on dvd::rip's Transcode page. This should fix most
NTSC A/V sync issues.
If this still doesn't work as expected, please post your issue
to the transcode mailing list and provide example material,
so the developers can reproduce the problem.
Modern video codecs (like DivX) work with variable bitrate
encoding. So the desired bitrate is in fact an average
bitrate. But currently most codecs have problems hitting
this bitrate overall. Regularly the effective bitrate is
somewhat smaller, which is no problem, but sometimes it's
bigger, so the files won't fit on the desired number of
You can enable multipass encoding for optimizing this. But
often the effective bitrate differs nevertheless. We just
can wait on better codecs, which hopefully solve this problem
Most codecs don't support frame dimensions which are not
divisible by 16. dvd::rip's presets take care of this restriction,
but because you can modify Clip & Zoom values by hand, this may still
happen. In that case you usually get strange colored shadow
or other effects.
If you followed this rule, but still get artefacts, please
report this as a bug, because this shouldn't happen anymore,
since dvd::rip takes care of the correspondent internal options
to prevent this (keyword: YUV colorspace resp. transcode's -V
Yes it is, refer to the corresponding
chapter for details.
Yes, you can. Refer to the corresponding chapter in the
Depending on the environment all names are correct. The
program in general is called dvd::rip, note
the lower case and the colons. Because the colons have
to be escaped in
most shells, the executable is called dvdrip, just
to make your life easier. dvd::rip is also an OO Perl
program, so it occupies some namespace: Video::DVDRip. From
this name the distribution file names are derived:
Video-DVDRip-version.tar.gz. That's all ;)
In short: write dvd::rip if you're talking about
dvd::rip and say dvdrip if your're talking about dvd::rip ;)
Ah, I forgot the colons. Perl uses them to separate nested
namespaces. Yes, you're right, the name dvd::rip is
obviously no Perl namespace, so this is the wrong reason.
The true reasons are: the colons look nice and this way
dvd::rip distinguishes from
many other tools, which call themselves DVDRIP, dvd-rip or