Robert LeBlanc wrote:
> (1) When ripping a DVD, most of the time the ripping process continues
> past the 100% mark, often to 120% or more (and in one case over the 200%
> mark). This naturally does strange things to the ETA (which starts
> offering estimates in negative time), but it always eventually finishes.
> When it does, however, it ends up counting a much larger number of
> frames than advertised in the TOC. Roughly speaking, the difference
> seems to be proportional to how far over 100% the rip process had to go
> to reach completion--at 200% it shows about twice as many frames as
> shown in the TOC.
TOC is determined by lsdvd (or tcprobe) which use the information stored
in the IFO files. Sometimes the IFO files lie about the real title
length. When dvd::rip rips the title it counts the _real_ frame number
and for all later processing this frame count is used (for example when
it comes to bitrate calculation and stuff).
> (2) For the most part the image-grabbing routine for "Clip & Zoom" works
> fine, but when the rips go too far past the 100% mark, the
> image-grabbing mechanism fails. In part this may be because with the
> grossly inflated frame-count, the default frame selection (i.e. 50% of
> the final frame-count) is too high to be valid, but even when a very low
> frame number is supplied (e.g. 500) the image-grabber typically fails,
> urging me to try a lower frame number.
Hmm, looks your DVD's are really strangly authored. In particular some
NTSC DVD's have a wild mix of framerates and dvd::rip (as well
transcode) don't cope with this very well. Finally dvd::rip uses a
single framerate value for it's calculations, which may lead to wrong
results.
> (3) The video seems to transcode just fine (to xvid), but the audio
> (converted to MP3) seems to be out of sync in proportion to the
> frame-count mismatch. When the rip process ends reasonably close to the
> 100% mark (e.g. 102%, 104%, etc.), the sync problem is minimal, whereas
> when the frame-count difference is large (e.g. 120%+) the sync problem
> is proportionally worse. In a couple of more extreme cases, the audio
> ends 10 minutes or more before the end of the video, so the last portion
> of the video goes without any sound.
You can try the "Inverse telecine" deinterlacer, probably that helps,
but I'm not sure.
Regards,
Jörn
--
$a=$a[8][67][9][0][42][214][82][78][0][50][69][68][69][82][0][73][78][0]
[65][0][20][16][0][68][73][77][69][78][83][73][79][78][65][76][0][65][82
][82][65][89]=sub{sub _($){print$_[@z]}($z,$i)=@_;(++$i)while!$z->[$i];$
s+=$i;_ chr($i+32);$s!=2292&&&$a($z->[$i],$c>>$e)};&$a(\@a,$d<<$f);_"\n"
pgpb6Wj1HEtdd.pgp
Description: PGP signature
|