Can't rip CDs anymore with 4.0.5.1496 and 'secure read'

[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?)

[Lowlander]

How does it fail? Any error messages?

[MMuser2011]

I just get this screen:
Could I look for more errors in a log file?

[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.

[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?

[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

[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.

[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.

[Lowlander]

PS. I just tried it (to FLAC) with Secure Read and it worked for me.

[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'

[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?

[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.

[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'?

[MMuser2011]

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%.

[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.