Page 1 of 3
Can't rip CDs anymore with 4.0.5.1496 and 'secure read'
Posted: Wed Jun 06, 2012 6:27 am
by MMuser2011
Today, I have updated my MediaMonkey to the newest available version.
Now I can't rip CDs anymore with the rip-type setting "secure read (takes extra time)'. It doesn't matter, if I start MM with normal or admin-rights.
If I change the rip-type setting to "standard read", it works fine. The same for "jitter-corrected read".
What can I do to rip my CDs with "secure read"?
(Maybe it would also help, if someone could explain the different modes?)
Re: Can't rip CDs anymore with 4.0.5.1496 and 'secure read'
Posted: Wed Jun 06, 2012 10:17 am
by Lowlander
How does it fail? Any error messages?
Re: Can't rip CDs anymore with 4.0.5.1496 and 'secure read'
Posted: Wed Jun 06, 2012 10:29 am
by MMuser2011
I just get this screen:
Could I look for more errors in a log file?
Re: Can't rip CDs anymore with 4.0.5.1496 and 'secure read'
Posted: Wed Jun 06, 2012 11:04 am
by Lowlander
Are the files on the hard drive though? Then it may indicate that Secure Rip failed, but the rip did happen. Unfortunately messages like these are often not very helpful in indicating what the underlying problem is.
Re: Can't rip CDs anymore with 4.0.5.1496 and 'secure read'
Posted: Wed Jun 06, 2012 11:22 am
by MMuser2011
You are right! The files are in the target directory.
BUT if I load them into VLC, I can see different song lengths. As soon as I try to play a single song, the song length changes to the identical 4min25sec for every single song. They all seems to be "empty", I can't hear anything, really nothing. (Yes, if I play other songs, everything works fine, there is power on my speakers
).
If YOU try to rip a CD with 'secure read' and this MM version 4.0.5.1496: Does it work?
Re: Can't rip CDs anymore with 4.0.5.1496 and 'secure read'
Posted: Wed Jun 06, 2012 11:40 am
by Lowlander
I haven't done so yet, I have it disabled. You may want to create a debug log (step 4b) and send it to support:
http://www.mediamonkey.com/forum/viewtopic.php?f=7&t=69
Re: Can't rip CDs anymore with 4.0.5.1496 and 'secure read'
Posted: Wed Jun 06, 2012 12:02 pm
by MMuser2011
I try it. Where should I find this logfile (Point 4 creating a bug report)
c) For CD Burning problems, an additional log will automatically be saved to c:\hpCDE.log
There is no file at C:\ or D:\ or anywhere else. Not with the rip type 'secure read' nor with the two other working types.
Re: Can't rip CDs anymore with 4.0.5.1496 and 'secure read'
Posted: Wed Jun 06, 2012 12:11 pm
by Lowlander
Just run DBGView and let it capture the logs from the debug version of MediaMonkey. Send that log in and the developers will check it and give further instructions if they need more.
Re: Can't rip CDs anymore with 4.0.5.1496 and 'secure read'
Posted: Wed Jun 06, 2012 12:24 pm
by Lowlander
PS. I just tried it (to FLAC) with Secure Read and it worked for me.
Re: Can't rip CDs anymore with 4.0.5.1496 and 'secure read'
Posted: Wed Jun 06, 2012 12:35 pm
by MMuser2011
Thank you for the feedback!
What I found so far:
Version 1483
- 9204 Fixed [Burning / Disc Handling] Update quicktime filter license
works fine and very fast on my PC with 'secure read'
Version 1484
- 9202 Fixed [Burning / Disc Handling] Rip verification fails when 'Jitter corrected read' is selected
works, but much slower then v1483 on my PC with 'secure read'
Version 1491 fails to start with 'secure read' (see printscreen above).
No I try to step back, to find the last working version. Unfortunately, there is no more ticket in the official release history for the section [Burning / Disc Handling] for the releases between 1485-1491
-> Version 1488 is the last working version on my PC with 'secure read'
Re: Can't rip CDs anymore with 4.0.5.1496 and 'secure read'
Posted: Sun Jun 10, 2012 5:47 pm
by Ludek
Tracked here:
http://www.ventismedia.com/mantis/view.php?id=9421 although I cannot reproduce the problem.
It is strange as there wasn't any disc handling change in build 1489, the only changes were in build 1480 when 'Verify ripped tracks' is enabled.
Does the failure happen when 'Verify ripped tracks' is disabled?
Re: Can't rip CDs anymore with 4.0.5.1496 and 'secure read'
Posted: Mon Jun 11, 2012 4:36 am
by MMuser2011
Thank you for the bug ticket, Ludek.
I let the Rip-process run twice with the newest v1496:
Once with enabled 'Verify ripped tracks' and once with disabled 'Verify ripped tracks'. The only difference I see is the speed. In the first case (Verify enabled), it needs about 60 seconds for 16 tracks. In the second case, it only needs about 17 seconds for the same 16 tracks.
The "ripped" tracks itselfs are identical for both methods. Every track has a different byte length to each other track. The audio-content (between the id3tags) looks very strange for all tracks, like this:
Code: Select all
LAME3.98.4UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU LAME3.98.4UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUÿûâ`
I can't copy&paste the special chars in front and at the end of this sequence.
If I look at the debug-log, I can see this first "failed"-entry
Code: Select all
CD rip: TOC cached
00003615 11:17:48.940 [8200] ReadAudioSec(): [t: start=33, num=892], [tOver: start=0, len=0], [tOver2: start=0, len=0]
00003616 11:17:48.941 [8200] Decoder: CreateDecoder() finished successfuly
00003617 11:17:48.941 [8200] hpCDEBurn: ReadAudioSec: read failed
and then many of this entries:
Code: Select all
00003786 11:17:50.908 [8200] hpCDEBurn: Detected max read speed = 8468 KBps, CurrReadSpeed = 8468 KBps
00003787 11:17:50.908 [8200] hpCDEBurn: Working device for ripping initialized.
00003788 11:17:50.909 [8200] hpCDEBurn: ReadAudioSec: read failed
00003789 11:17:50.909 [8200] ReadAudioSec(): [t: start=15065, num=892], [tOver: start=0, len=0], [tOver2: start=0, len=0]
00003790 11:17:50.910 [8200] hpCDEBurn: ReadAudioSec: read failed
00003791 11:17:50.910 [8200] ReadAudioSec(): [t: start=15957, num=892], [tOver: start=0, len=0], [tOver2: start=0, len=0]
00003792 11:17:50.911 [8200] Thread 'EncodeSongs_Threaded' is going to callback
00003793 11:17:50.911 [8200] hpCDEBurn: ReadAudioSec: read failed
00003794 11:17:50.911 [8200] ReadAudioSec(): [t: start=16849, num=892], [tOver: start=0, len=0], [tOver2: start=0, len=0]
00003795 11:17:50.912 [8200] hpCDEBurn: ReadAudioSec: read failed
Now, I repeat this process with the last working version v1488.
Re: Can't rip CDs anymore with 4.0.5.1496 and 'secure read'
Posted: Mon Jun 11, 2012 6:10 am
by Ludek
OK, so are you sure that the problem started with 1489 and 1488 works? And that the problem appears despite the 'Verify ripped tracks'?
Re: Can't rip CDs anymore with 4.0.5.1496 and 'secure read'
Posted: Mon Jun 11, 2012 6:13 am
by MMuser2011
Ludek wrote:OK, so are you sure that the problem started with 1489 and 1488 works? And that the problem appears despite the 'Verify ripped tracks'?
Yes, 100%.
Re: Can't rip CDs anymore with 4.0.5.1496 and 'secure read'
Posted: Mon Jun 11, 2012 6:17 am
by Ludek
It is really strange as there is no change re disc handling in build 1489, it really doesn't make much sense for me :-/
Could you please try to rip into WAV format so that we can exclude that it is a format encoding problem? Although from the log it doesn't look so.
