Disc shows as not present in AccurateRip, then DOES after removing CD and reinserting

[joeyc410]

Hi all,

I've noticed a strange glitch that rarely (but still) occurs where I insert a disc into my drive, allow CD Ripper to load, and I see the gray X on the bottom of the page that indicates the album is not in the AR database. Depending on the album, I question whether or not it is likely that the album will be in the database. I have a few albums that, upon first insertion into my drive, originally come back as not in the database, but because that seems odd to me (given the popularity of the album), I decide to take the disc out, close CD Ripper, and try again after reopening the program. Upon my second try, the album begins showing as part of the database. I should state that this issue DOES NOT pertain to any particular album. I conclude this because why would a popular album show as not in AR when it in fact is?

My more important question is this - suppose I thought an album was not in the database, and it actually was, but because I was told by CD Ripper that it was not, I go ahead and rip it in secure mode. I get all green checks after many passes of ripping and can conclude that the program has ripped the disc without errors. Is the secure rip I just completed equal to the one in AR, IF the album actually is in AR, but is simply not showing that it is due to a glitch?

It feels like there may be an instance where the program can mislead me and I could potentially have no idea.

[sower]

Hey, I’ve noticed that too on occasion. From what I understand, a secure rip with all green checks should still be just as reliable, even if AccurateRip didn’t recognize the disc at first. It’s likely just a timing or recognition hiccup between the drive and the database. Re-inserting usually clears it up, like you said.

[garym]

secure rip is not identical to AR match, but close enough for me. Making up numbers, it is the idea that a secure rip result indicates that the rip is bit perfect with a 1 in a million chance it is not. But AR match, it is 1 in a trillion chance there is still an error. In both cases, the likelihood of a bad rip is very remote.

edit: and of course one can compare a rip later on to see if it has an AR match (PerfectTunes can do this, as well as foobar2000 or CueTools).

[inphobia]

i've seen a similar but not exact issue a few times, but with easier to isolate parameters:

with (at least) 2 cd ripper instances open, when you load a disc in drive 1 that takes long to load or just wont load (completely degraded discs where the physical drive won't even become ready) and during that struggle you insert a disc in drive 2 it won't get recognized. it will load in the second drive, it just won't have any meta nor accurip info.
-> the next time you load the disc it wlll all of the sudden remember everything.

i can also reproduce with 1 drive only: with a truly broken disk (where parts of the metal layer are missing on the top) most drives will choke when loading. depending on hardware sometimes the drive gives up says it does not detect a disc, sometimes it might show up in cdripper eventually, or the cd drive goes in a loop and you have to press the phyiscal eject button to even get it to ejectL
-> in all these 3 cases i get the same result: as soon as the disc is _ejected_ the known meta & accurip info all of the sudden appears.

the reason it is curious is because this is when the disc is ejecting. it will even remain on the cd ripper screen unril a new load happens.

it took me a while to puzzle this together, i almost always saw it when i was callibrating several drives at once: the find the accuraterip offset, another trying to see if c2 is suported, a third doing a test rip. it most often happened during c2 detection as you can imagine. when one drive had hickups i could get offset detection to work on others etc... i've stopped trying to callibrate in parallel.

to be clear: i think my use case is very niche, because who tries to callibrate 3-4 drives at the same time , more often that not with another bunch ripping as well - or a load rattle when a drive's plastic insides fail.

[inphobia]

-> the next time you load the disc it wlll all of the sudden remember everything.

2 drives in parallel: drive 1 phyisical disc not loading, drive 2 will either be very slow loading known meta during such an event or just give tracks & lenght.

-> in all these 3 cases i get the same result: as soon as the disc is _ejected_ the known meta & accurip info all of the sudden appears.

will try & make a screenshot later.

while i don't know how cdripper's architecture works, it feels like a lock is placed on the metadata when the media is loaded/unloaded. perfectly good concept. this is a moment the storageport can behave in less predictable ways & you don't want to have your write() hang when updating any of the cached files. while i would love it , the cost/benifit of a simple lock vs concurrent access to the metadata makes little sense.

the only thing that feels somewhat off is the fact is getting the data on eject, still makes sense if this is triggered by the next succesfull hardware event.

after rereading the original post. if something was blockng access to the cache files for long enough, or intercept i/o calls, this seems not unlikely. have you checked your virussscanner, /malware scanner / protected folders and all those?.the storport eventlog could also have usefull info.

[inphobia]

... lest i forget: the more features i have active that access meta information (so the more checkmarks under in perfectmeta active), the longer it will take for cd ripper to recover. in particular cd text feels like major contributor to extending the recovery. this i have not looked at closer, so it's just a feeling

[Dat Ei]

How many providers are activated on your system? Is PerfectMeta activated?

My guess is, that at least one of the activated providers has a (temporarely) problem (performance, offline etc. pp.) which will lead to a delay to get the metadata. The moment you eject the disc, the process of retrieving the metadata will terminate so that PerfectMeta can show the best metadata it received so far.


Dat Ei

[inphobia]

active: perfectmeta, dbpoweramp cache, accuraterip meta; discogs & freedb archived.
i forget if gd3 is active by default but i have it disabled, the 2 or 3 times times i actually had to wait for metadata from the network was was from gd3. cd-text i also disabled.
disabled: all the rest azre disabled

i recently bumped the cache size to 750mb.
i mostly use manual fetch from discogs (nifty feature) since i've got my stuff in there and with the correct info.
i have not changed the lookup order, so dbpoweramp cache is still highest there.


when gd3 was actiing up i seem recall that it it was show in the bottom left corner which provider was processing, would not know why else i would have looked in that direction. for this what i detailed here above it can happen with not yet cached discs , but more often than not the disc is already cached, in some cases even ripped. second hand drives tend to fail pretty quickly. so to try to keep other changes to a minimum when moving drives around or swapping them out. have a accurip keydisc; c2 disc , clean rip disc & broken disc set aside for that process.
right, get to the point: when the hangs happen it's on "fetching metadata" , never progress to any of the following. also don't think it's my cache, since if i move the disc to another drive it does not seem to make a network request