Ripper not working correctly

[dbpa]

(EDIT: Ripper 64 bit)

I bought the package some months ago (under another mail account than I use for this forum), and lately, with 7.0, I encountered the following problem which now PERSISTS with 7.1:

The program asks the 3 metadata sites for the correct metadata for the current CD, that's ok. But often now, with the third site, which is MusicBrainz ("Retrieving CD Metadata, Reading: MusicBrainz"), Ripper is simply stuck, i.e. it will never display any other window then, e.g. the "Manual" window, and even when I put in another CD, I will have to first close the program and reopen it, and, according to factors I don't know, sometimes I even have to shut down and reboot my pc (W10 Pro latest English, i7, 16GB).

I had hoped the problem - which only occurred after I had ripped several hundred CDs - would vanish by the install of the update version, but it seems it's striking even more often now.

The problem seems to be bound to CDs that cannot be (easily) identified, but then, after even MusicBrainz (=the latest of the 3 sites) cannot identify it, the "reading MusicBrainz" window should be closed after some seconds or after some minutes at least, and I should have the possibility to do it "manually", with that window, instead of having to close the program and even, often, reboot the pc.

In such cases, often the MusicBrainz "reading" page even lists the tracks, but just the lengths, not the artists/titles, and pretends it's in AccurateRip, with the according symbol, but nothing then happens.

The "Reading" window then never changes to the window where at its top there are all these fields, and in which I then, if it was available, I could click on the metadata symbol in order to get the "manual" page to further proceed.

(I also discovered that the replace table just works with single replacements, i.e. I cannot replace the frequent ": " with a " - " (technically, the single ":" by 2 chars " -"), but it's either " " or "-", not both, so I always have to do this manually, and that ":" occurs very often, in compilations or "best of" discs.)

[ac16161]

I'm interested in this post as I am having a very poor experience with CD ripper at present (registered 17.1 on Windows 10). I'm working through a number of international-genre CDs, often for Greek artists, and CD ripper is hanging really badly at the disc loading stage. I've not used CD ripper much in the last few years, so wondered if this might be an issue with me now using optical drives in USB enclosures, but MakeMKV is working faultlessly with the same drives. I am getting regular Windows messages along the lines "the program has stopped responding", and the process of ripping the CDs has become a real chore. I seem to have deleted my older versions of CD ripper, which normally I retain in case a regression makes it through to the production release, so I can't say if this is a 17.1 issue. If there is a log that I can post to help with diagnostics, I'd be happy to do so.

[Spoon]

You can try unchecking MusicBrainz as a source of metadata and see if that helps speed it up for you.

@ac16 - when it is slow does it show the metadata being read at the top? which provider(s) are still being read?

[dbpa]

I could possibly make a pile of the CDs which behave this way with MusicBrainz, then discard MusicBrainz and try those discs in a row without, but the problem seems to be that the ripper HANGS after problems with MusicBrainz, instead of "giving up" after perhaps 30 (or 60 or whatever) seconds with MusicBrainz and continuing normally, which it currently does not, as explained above.

[ac16161]

You can try unchecking MusicBrainz as a source of metadata and see if that helps speed it up for you.

@ac16 - when it is slow does it show the metadata being read at the top? which provider(s) are still being read?

with apologies to the OP in case I am now starting to hijack the thread, possibly my issues are upstream at the OS level with Windows not recognising the CD's. I tinkered with the autoplay settings and Windows seems to have decided to sort itself out, and in turn CD Ripper seems more reliable.

I have found with 17.1 on a couple of dics where it has to re-read bad frames on a track with secure ripping, it it is then bailing out on the entire disc and just aborts.

[Spoon]

If you cannot end task the ripper, then it suggests there is something lowlevel which is hanging, rather than the program its self, try that test next time it hangs.

@ac potentially you have an option set which aborts the rip such as 'cancel ripping after any insecure track'

[ac16161]

If you cannot end task the ripper, then it suggests there is something lowlevel which is hanging, rather than the program its self, try that test next time it hangs.

@ac potentially you have an option set which aborts the rip such as 'cancel ripping after any insecure track'

I just checked my Secure ripping options, and everything is set to "no abort" under Secure Rip Abort and also the option "Cancel Disc Ripping After Any Insecure Track" is unchecked, but CD Ripper is still aborting the rip if it encounters a bad track.

[Spoon]

What does the secure log say about the abort? also you can try enabling debug mode (in Control Center >> Advanced) then run ripper, rip one disc which aborts then close ripper and the log will show.

[dbpa]

@Spoon: "If you cannot end task the ripper, then it suggests there is something lowlevel which is hanging, rather than the program its self, try that test next time it hangs." >

"try that test next time it hangs" you mean "try to test that next time it hangs"? how would I do that?

Anyway, it's just the ripper which hangs, everything else is ok; after restarting the ripper, it seems to work correctly after such an incident, except for the very same disc where it will hang again. I had to reboot the computer (in order for the ripper to work again) after a similar incident with 17.0, not yet with 17.1.

[Spoon]

It suggests the cd drive is at fault, restarting the ripper is fresh start, only a system restart would reset the cd drive.

[Psychoakustik]

I'm testing a trial version of dBpoweramp on a MacBook Pro 2011 with a MATSHITA DVD-R UJ-8A8 internal drive. A dBpoweramp test detects C2 Error Pointers, but I turned them off. I keep getting abort errors in the last track near the outer edge of disk, with a couple of small gouges from manufacturing. XLD re-reads forever but eventually produces a track with click sounds.

With dBpoweramp, if C2 Error Pointers are turned on, it aborts almost immediately, even though all settings are "(no abort)". With C2 Error Pointers turned off and no aborts enabled, it scans for a bit, but I still eventually get the following abort error before a proper FLAC rip can be produced:

Error converting to FLAC, 'Track 24' to 'xxx.flac'
Unable to read CD, check CD disc (frame LBA 325625 ripping 26 frames track end LBA 327087) [Rip]

@Spoon Can you offer any suggestions?

[Spoon]

You would need a different CD drive, it is the drive which is refusing to read that part of the disc.

[garym]

As a datapoint: I've ripped 770 CDs in the last month,* using Win10, Ver 17.1, and on only one of these CDs did the ripper hang while finding metadata. For this one CD, if I restarted dbpa, and unticked MusicBrainz, it found metadata and worked fine for ripping.

*One benefit of the COVID lockdown is I've had time to finally get around to finishing my re-ripping project of the last 10 years! (reripping all my CDs to FLAC instead of mp3 that I ignorantly started with many moons ago). I can see the end coming soon. Only a couple hundred to go and I'm done with existing library!

[Psychoakustik]

Thank you @Spoon. Taking your advice, I tried an external TSSTcorp BDDVDW SE-506CB. It read the last track, but it took extraordinarily long times to re-read sectors in the damaged region. It took a couple days to read ~30 sectors. I'm hoping that disc is just an anomaly. I like the dBpoweramp interface, and I want to try it with HDCDs before my trial ends.