DOCUMENTATION | dvd::rip - Copyright © Jörn Reder, All Rights Reserved |
If it's DVD related: time will come. If not: possibly never. ;) dvd::rip tries to be an easy to use but nevertheless feature rich DVD copy program. But it'll never be an extensive transcode GUI. transcode can do much more sophisticated jobs than just copying DVDs, but supporting them all in one GUI is a hard task and a big challenge for every coder out there. But not for me ;)
Some binary Perl 5.8.0 distributions have a bug (RedHat 8.0 is known to be affected, also newer Slackware releases and Debian sid). You probably can workaround this by setting the environment variable PERLIO=stdio before starting dvd::rip, e.g. export PERLIO=stdio; dvdripThanks to Ryurick M. Hristev for the hint.
First try executing the corresponding transcode command by hand. Press Ctrl+T to see all transcode commands executed by dvd::rip. Sometimes dvd::rip is unable to provide a good error message, this way you often can see, what's going wrong (and please consider the next 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 shure, you always can post your question to the dvdrip-user mailing list, but be aware that you may be pointed to the transcode list ;)
That's Ok. The corresponding messages are printed by libdvdread if you transcode files on harddisk (what's 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 if started from a directory with only VOB files in it. Just ignore these messages, and please don't report this as a bug.
This is an annoying bug in the Divx5 codec. It tries to create a file c:\trace_b.txt, which fails if you work on a vfat filesystem, because this filename is illegal under Windows. Execute the following Perl one-liner as root (thanks to Christian Marillat) to patch the codec library file (probably the location is different on your system): perl -pi -e 's|c:\\trace_b.txt|/dev/null\0\0\0\0\0|' /usr/lib/libdivxencore.so
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, what's no problem, but sometimes it's bigger, so the files won't fit on the desired number of discs. 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 finally.
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 option).
Yes it is, refer to the corresponding documentation chapter for details.
Yes, the Gtk::Gdk::Pixbuf module is part of the standard Perl Gtk distribution but installed only if you have the corresponding C library on your system. Install the appropriate RPMs (gdk-pixbuf and gdk-pixbuf-devel) and build the Perl Gtk module again. It autodetects your C libraries and will then build Gtk::Gdk::Pixbuf by default.
Yes, you can. Refer to the corresponding chapter in the installation docs.
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 whatever ;) |
| |
DOCUMENTATION | dvd::rip - Copyright © Jörn Reder, All Rights Reserved |