Ripping of defective track: Cancelled under OS X at 63 % - and not under Win 7 ?

[Niko]

I own both licenses of dBp and actually run 15.3 under Win 7 and 15.2 under OS X 10.10.5.

I want to rip a CD consisting of 3 tracks (10min 59sec, 26min 18sec and 17min 13sec) - album title is "Chet Baker in Paris - Tune Up".
The CD is in the AccurateRip DB, and track 1 and 2 were ripped without problem and confirmed accurate (confidence 2).

The 3rd track, however, seems to be damaged - at about 48 % the ripping speed decreases from 12x to finally 0.2x, and ripping in burst mode of this track needed about 1 hour and 20 minutes. After the ultra secure passes the program said that about 13.600 frames were to be re-ripped. Despite of the obvious defects, I am interested in a result as good as possible, since this CD is currently (and will presumably be) unavailable.

Because of a automated reboot (caused by Windows Update) the program was shut down without any useful result after about 56 hours (and was then at about 11.000 frames outstanding).

To avoid such unwanted event, I tried to rip this track only under OS X. The drive setup under OS X was the same as under Windows for matching parameters, although the available parameters under Windows are at the moment far more than under OS X. Needless to say that the same CD drive was used in both cases.

After about 63 % the ripping under OS X stops during the 1st pass ("unable ..."), and the result is a (.WAV-)file of 93 KB (whereof 92 KB result from album art, and the remaining 1 KB I assume as metadata values). dBp-Ripper estimates a final size of 174 MB, so 63 % should result in a file size of about 108 MB.

So I returned to the Windows version, changed Windows Update to manual installation and started ripping again. Actually about 10 hours have passed and the 6th ultra secure pass is about to complete ...

From this experience, there arise the following questions:
- Why is such a difference between the results under Windows and OS X (I think there is not even a chance to get a burst rip under OS X) ?
- Is there a chance to locate the resulting file achieved so far (under OS X 108 MB and under Windows 174 MB - result may be insecure, but "better than nothing") ?
- Do you see a chance of restarting and finalizing of unfinished rips in a future version of dBp-ripper ?
- Does such (e.g. 2 normal passes, 13 ultra passes, frame re-rips up to 25.000) CD drive setup make sense according to your experience ?
- Is there a chance of e.g. field value overflow causing the program to hang because of these figures (13.000 frames to re-rip, 25.000 retries, 17min track duration) ?

Thank you in advance for your assistance in better understanding of this program's capabilities.

[Spoon]

Re: Ripping of defective track: Cancelled under OS X at 63 % - and not under Win 7 ?

What message was given for OS X after it ripped the track?

- Do you see a chance of restarting and finalizing of unfinished rips in a future version of dBp-ripper ?

No

- Does such (e.g. 2 normal passes, 13 ultra passes, frame re-rips up to 25.000) CD drive setup make sense according to your experience ?

13 ultra is too extreme if you ask me

[Niko]

Re: Ripping of defective track: Cancelled under OS X at 63 % - and not under Win 7 ?

Thank you for the quick response.

Ripping of 3rd track still goes on, 13th ultra pass finished about one hour ago, and currently re-ripping of frames shows about 17.000 (note that the above figure of 13.000 should probably have been 18.000). If I consider that with the 1st try something more than 24 hours resulted in re-ripped 7.000 frames, I see a chance that after another 2 days the rip should end.

I will give this rip a chance to finish "normally", and then I will retry a rip under OS X. Provided that it ends again as described above, I will be able to provide more details as to the message.

Think I'll revert in about 2 or 3 days, when the current rip has finished.

[Niko]

Re: Ripping of defective track: Cancelled under OS X at 63 % - and not under Win 7 ?

Ripping still goes on, after 120 hours re-ripping is at about 15.280 frames.

2 days ago in the evening the system seemed to hang at frame 15.385, yesterday in the evening the same frame figure was shown, but the CPU-load had increased - if there was no change until today I would have stopped ripping, but now it seems that it is going on again.

I shall keep you informed about significant changes.

[Niko]

Re: Ripping of defective track: Cancelled under OS X at 63 % - and not under Win 7 ?

CD-Grab.exe was still running (after about 176 hours there were still 15.131 frames to re-rip) when VMware had to close the Windows 7 VM "due to an unrecoverable Windows problem". So there is a very small chance to get a secure rip I think.

Meanwhile I returned to OS X, changed the secure rip setup slightly (max 5 secure rips, interpolate unrecoverable frames = yes), and the rip was cancelled again as before under OS X - this time between estimated 50 % and 55 %. The message was:
"Error converting to Wave, 'Track 3' to '/Users/niko/Music/CD-Rip/Chet Baker/In Paris - Tune Up/1-03 Chet Baker; Nicola Stilo; Karl Ratzer; Ricardo Del Fra; Al Levitt - There Will Never Be Another You.wav'
Unable to read CD, check CD disc (frame LBA 217861 ripping 26 frames track end LBA 245440) [Rip] ".

I made the following hardcopy after about 100 hours (Windows-)ripping time:

The last time I looked whether ripping still continued the red vertical progress indicator was touching the letter "a" in "frames" from the left side - I think this should be between 60 % and 65 % within the progress rectangle. This is far later than the estimated percentage based on the progress bar under OS X.

The following questions remain:
-> Why is the OS X-rip cancelled, although the Windows-rip was still working ?
-> Any chance to find / use the temporary file (e.g. in a temp-/tmp directory) Windows had ripped so far ?

EDIT:
Burst rip just ended with same message as quoted above.

-> Why Windows rip manages to complete a burst rip and OS X rip does not ?

[mville]

Re: Ripping of defective track: Cancelled under OS X at 63 % - and not under Win 7 ?

Why is the OS X-rip cancelled, although the Windows-rip was still working ?

Different optical drives, perhaps?

I'm not sure what you are trying to achieve here, the CD clearly has an unrecoverable error.

[Niko]

Re: Ripping of defective track: Cancelled under OS X at 63 % - and not under Win 7 ?

Different optical drives, perhaps?

I'm not sure what you are trying to achieve here, the CD clearly has an unrecoverable error.

No - see "... needless to say ..." in the mid of my 1st post. Same Mac hardware, same CD-player.

Why is native OS result (OS X) poorer than result under Windows (based on VMware) ?
Normally - because of more drivers etc. between CD player hardware and Mac hardware - I would have expected the opposite, but the actual results do not. What causes the difference ?

[mville]

Re: Ripping of defective track: Cancelled under OS X at 63 % - and not under Win 7 ?

No - see "... needless to say ..." in the mid of my 1st post. Same Mac hardware, same CD-player.

Why is native OS result (OS X) poorer than result under Windows (based on VMware) ?
Normally - because of more drivers etc. between CD player hardware and Mac hardware - I would have expected the opposite, but the actual results do not. What causes the difference ?

OK, but the storage controller environments, OS X and Windows (VMware), differ, hence the differing results.