Re: [dvd::rip] Probably a transcode issue, but...
|
Subject: |
Re: [dvd::rip] Probably a transcode issue, but... |
|
From: |
Edmund Mergl <e.mergl@xxxxxxxx> |
|
Date: |
Mon, 24 Apr 2006 20:53:58 +0200 |
searching my notes I found this info: for ripping a well known blockbuster with
Leonardo DiCaprio and Kate Winslet I had to skip the first 275 frames. Your
mileage may vary.
Edmund
David Hull wrote:
Ahh, good call on the debug level, I've never used that one before. When I
execute this with a '-q 2', the end of the encoding gives me this:
<lots of output snipped>
[demuxer.c] (pid=8654) 524288/524288 packets discarded
[tcextract] (pid=8655) exit (decode_ac3.c@51) read error (0/2047)
[tcdecode] exit code (1)
[tcextract] exit code (0)
(dl_loader.c) audio import module error
(decoder.c) audio data read failed - end of stream
(encoder.c) import closed - buffer empty (A)
(encoder.c) encoder closed
(decoder.c) import stop requested by client=-1208706496 (main=-1208706496)
import status=0
(decoder.c) audio thread already terminated
(decoder.c) A/V import canceled (-1208706496) (-1208706496)
(decoder.c) video thread exit (ret_code=0) (status_code=4294967295)
(decoder.c) audio thread exit (ret_code=0) (status_code=13)
(decoder.c) vframe_list_lock=0
(decoder.c) aframe_list_lock=0
clean up |(frame_threads.c) audio frame processing threads canceled
(frame_threads.c) video frame processing threads canceled
frame threads |(decoder.c) unloading audio import module
(decoder.c) unloading video import module
unloading export modules
unload modules | cancel signal | internal threads | done
[transcode] encoded 0 frames (0 dropped, 0 cloned), clip length 0.00 s
[transcode] buffer released
So there does seem to be an issue with the audio track. Just not sure how to
read this or where to see around what frame it's having an issue. So if anyone
has any input, it would be gladly accepted. :)
Full output from transcode is here, if you're interested:
http://www.sapdba.com/files/transcode.log
Regards,
David.
-----Original Message-----
From: dvdrip-users-bounces@xxxxxxxxx [mailto:dvdrip-users-bounces@xxxxxxxxx] On
Behalf Of Edmund Mergl
Sent: Monday, April 24, 2006 11:46 AM
To: Jörn Reder
Cc: dvdrip-users@xxxxxxxxx
Subject: Re: [dvd::rip] Probably a transcode issue, but...
Jörn Reder wrote:
Edmund Mergl wrote:
David Hull wrote:
I'm ripping all of my DVDs to .avi, and most have gone very well, thanks
to DVD::Rip. I've had this particular a few times now, so I'd like to
find out what's going on. The first pass seems to go fine, but the
second pass finishes after a short period of time (10 minutes or so),
and it produces an unplayable .avi file that is exactly 2056 bytes each
time (with each dvd that experiences this problem). I executed the
second pass manually, and I can't seem to find any issues, other than
the lack of a file being produced, of course. Here is the output (I
generally use ffmpeg, but this case shows testing with xvid4 as output,
with the same issue)...
remove the first few frames, e.g. specify 25 as first parameter for the frame
range.
Hmm, interesting tip. Can you explain why this should help? Probably
it's worth an FAQ entry, but I like to have a bit more background
knowledge ;)
Regards,
Joern
I had this problem with less than 1% of all my DVDs. Entering the transcode
command in a command line including a certain debug level gave me sometimes
a message about CRC errors in ac3 frames. Skipping these frames worked for me.
I dont't really remember the exact number of frames, but it was always before
the movie started, so nothing was really lost. It's worth to try out different
number of frames. Maybe some kind of copy protection ?
Edmund
|
| <Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [dvd::rip] Probably a transcode issue, but..., David Hull
- RE: [dvd::rip] Probably a transcode issue, but..., David Hull
- Re: [dvd::rip] Probably a transcode issue, but...,
Edmund Mergl <=
- RE: [dvd::rip] Probably a transcode issue, but..., David Hull
- RE: [dvd::rip] Probably a transcode issue, but..., David Hull
- RE: [dvd::rip] Probably a transcode issue, but..., David Hull
|
|