Looking for advice on glacial, on/off reading pattern with secure ripping

[artisan002]

Re: Looking for advice on glacial, on/off reading pattern with secure ripping

AccurateRip match is so much better test than C2 of a bit perfect rip. I have plenty of CDs I've ripped that did NOT get an AR match, but still ripped as "secure" and play fine (I don't hear any problems. And note that AR will not match if a few frames are off, even though those few frames are not even audible in playblack).

See, in typing it out and looking at this, it makes more sense than leaving it to just roll around as an unvoiced theory in my head. It gets muddied again, however, when I read where Spoon advocates for C2 and trusts it over running without.

Hard to tell with your posts, but to be clear, you DO understand how AR works and why it is a powerful test, correct?

I think I mostly do, the operative word there being "think". Verification by consensus of machines, which works great for repeatable events like mass produced CDs.
I do, however, have a couple CDs that didn't turn up in there. I think one may have been a very new release, though.
Now, the thing I've never known so much as presumed/predicted is how they arrive at the golden reference. It's reasonable to guess that they use a meticulous scan of a perfectly clean disc, and all that. But, since I'm not on that end of the process, I don't know exactly what or how. And, dammit, now I'm curious. LOL!

But I think you're just being OCD now.

Oh, probably. It kinda comes with the territory. I've always drifted into the very bottom of the Asperger's spectrum. It doesn't help that my music tastes run towards the obscure so much that a solid 35% of what I choose to listen to isn't on Spotify or iTunes. As a result, I logically get concerned with preservation of the weird stuff I have and want as precise an archive file as I can mange. But, I've also gotten into (semi-)professional music production and mix engineering. That kinda broke me, once. Too much mental effort spent on completing someone's song nobody said would be left to me -- and it was the opener, which sets the expectations for the whole album; after a month of wrangling with that mess (and dreaded learning-as-you-go) it was finished, but my ability to quickly recall commonly known people's names faltered and hasn't really come back in the 4+ years since. I'm sure my 2 years of cyber security training is making matters even worse. LOL!
Point is, yes/no/yes. But, if I have access and ability to make a rip even more accurate, I'm going to chase it down as much as I can. Heh... Dog:Ambulance

[garym]

Re: Looking for advice on glacial, on/off reading pattern with secure ripping

See, in typing it out and looking at this, it makes more sense than leaving it to just roll around as an unvoiced theory in my head. It gets muddied again, however, when I read where Spoon advocates for C2 and trusts it over running without.

But he doesn't advocate for it when the drive doesn't properly implement it. And he certainly doesn't argue that without C2, the AR match is not as good. The AR match is what it is. A match--and lack of C2 error checking doesn't invalidate that match.

Now, the thing I've never known so much as presumed/predicted is how they arrive at the golden reference. It's reasonable to guess that they use a meticulous scan of a perfectly clean disc, and all that. But, since I'm not on that end of the process, I don't know exactly what or how. And, dammit, now I'm curious. LOL!

No, No, No, No, and No. This statement tells me you completely misunderstand how AccurateRip works.

AR is not comparing your rip to some pristine reference disk result. It is way stronger than that. This is basically "crowd sourcing". AR is comparing *your* CD rip to the CD rip of other users out there in the world. I think the maximum matches it ever shows is 200 (even if there are more results than that in the database). But consider what this AR match means. I think one of your rips had an AR value of 31. That means that 31 other people ripped the SAME CD as you, on different computers, using different drives, using their own copies of the CD, and your rip is a bit perfect match back to all 31 of those. If that's not strong evidence, I don't know what is.

And don't get confused into thinking that an AR match of 31 is better than an AR match of, say, 2. This is because even an AR match with one other person out there is an incredible test of whether you got a bit perfect rip. Think about the odds of two different people in the world, with different physical copies of the CD, different computers, different drives, etc. getting the exact same rip. You might say, what if the other person has an error and your rip matches that error. Again, what are the odds of two people getting ripping errors with the exact same frames. Essentially impossible. Note that an AR match of only 1, may not be as informative, but only in the case where you have ripped the CD before in a program that submits it to the AR database. So in this case, your AR of 1 could be matching against your old AR submission. That's why an AR(2) is better. Then again, this AR(1) issue is not a problem if you've never ripped your CD before. In this case, an AR(1) is also evidence that you got a perfect rip.

See:

https://wiki.hydrogenaud.io/index.php?title=AccurateRip

http://www.accuraterip.com/

EDIT: Not all CDs are in AR database (they haven't been ripped perhaps). Also, it can take a while for a newly released CD to show up in the AR database. I recall that Spoon said submissions are only added to the AR database about once a month. Also note that one can check for AR match post ripping. I do this for my ripped new CDs that are not in the AR database at the time I rip. A while later, I'll run "PerfectTunes" (also an illustrate product) and get AR match information for those prior rips.

[mville]

Re: Looking for advice on glacial, on/off reading pattern with secure ripping

if I have access and ability to make a rip even more accurate, I'm going to chase it down as much as I can.

There isn't anything to chase down. You have a bit-perfect AccurateRip and there isn't anything more accurate than an AccurateRip.

[artisan002]

Re: Looking for advice on glacial, on/off reading pattern with secure ripping

But he doesn't advocate for it when the drive doesn't properly implement it. And he certainly doesn't argue that without C2, the AR match is not as good. The AR match is what it is. A match--and lack of C2 error checking doesn't invalidate that match.

Well, that much is obvious, I'd think. It's blatantly clear that my Plextor drive is worthless for that, but now (and I can't stress how weird that is) the Pioneer one seems fine. Of course, I still don't seem to find any info on either a way to verify C2 handling quality, or a table of drives on this specific matter (the annual lists of best performing drives never mentions it). I'm not super worried about it, but now just intensely curious.

AR is not comparing your rip to some pristine reference disk result.

Well, I wasn't being literal. Guess I should have put quotes around that part. But, yes.

It is way stronger than that. This is basically "crowd sourcing". AR is comparing *your* CD rip to the CD rip of other users out there in the world. I think the maximum matches it ever shows is 200 (even if there are more results than that in the database). But consider what this AR match means. I think one of your rips had an AR value of 31. That means that 31 other people ripped the SAME CD as you, on different computers, using different drives, using their own copies of the CD, and your rip is a bit perfect match back to all 31 of those.

And also yes. Back to my favorite term: A consensus of machines. Quality of a machine's work rated via other machines' work. When there's a match, it's a literal match among the results involved.
Now, the thing I've wondered but never asked about was that number value. That is very cool to know about. I think I saw a number hit around the 270s before. I've also seen something like 3, before... That has been a transient mystery to me for however many years I've been using this software.

If that's not strong evidence, I don't know what is.

Well, a certified master reference to compare against would be. LOL!
^^ Largely just being a jackass with that. ^^
But -- playing up to it anyway, because now I'm thinking about it all -- as long as the collective of results for an entry is large enough, the Accurate Rip method would easily be within a single percentage point of accuracy by comparison.

And don't get confused into thinking that an AR match of 31 is better than an AR match of, say, 2. This is because even an AR match with one other person out there is an incredible test of whether you got a bit perfect rip. Think about the odds of two different people in the world, with different physical copies of the CD, different computers, different drives, etc. getting the exact same rip. You might say, what if the other person has an error and your rip matches that error. Again, what are the odds of two people getting ripping errors with the exact same frames. Essentially impossible. Note that an AR match of only 1, may not be as informative, but only in the case where you have ripped the CD before in a program that submits it to the AR database. So in this case, your AR of 1 could be matching against your old AR submission. That's why an AR(2) is better. Then again, this AR(1) issue is not a problem if you've never ripped your CD before. In this case, an AR(1) is also evidence that you got a perfect rip.

This is probably my favorite part of this phase of the thread. Knowing what that number value means frames up absolutely everything, and it's something I wasn't even going to bug anyone about, since this whole ordeal with C2 checking (and the fact that one of the drives now works correctly since that last Windows update) has been such a mess; well, that and the mystery of that number value wasn't exactly haunting me. LOL!

See:

https://wiki.hydrogenaud.io/index.php?title=AccurateRip

http://www.accuraterip.com/

Yeah, I'll give that a look once I'm awake again. (I'm once again up and messing with this when I should be sleeping.)

EDIT: Not all CDs are in AR database (they haven't been ripped perhaps). Also, it can take a while for a newly released CD to show up in the AR database. I recall that Spoon said submissions are only added to the AR database about once a month.

This much I knew and expected. It's irrational to think everything would already be there. Almost as much so as expecting a perfect hit from every search for metadata.

Also note that one can check for AR match post ripping. I do this for my ripped new CDs that are not in the AR database at the time I rip. A while later, I'll run "PerfectTunes" (also an illustrate product) and get AR match information for those prior rips.

Yeah. I've only recently started using PerfectTunes for that function; I never worried about it past the ripping phase, though I've finally learned better. That said, I make a bit of trouble for myself with Accurate Rip in there. I intentionally eliminate disc numbers, and then number all the tracks of a multi-disc album consecutively. It's still one album, after all; and disc numbers are utterly irrelevant once the songs are off the CD. But, PerfectTunes reacts against that every time; it's not really surprising, of course. All that having been said, I have found that I need to re-rip a few albums for some other reason.

[artisan002]

Re: Looking for advice on glacial, on/off reading pattern with secure ripping

Yeah. I've only recently started using PerfectTunes for that function; I never worried about it past the ripping phase, though I've finally learned better. That said, I make a bit of trouble for myself with Accurate Rip in there. I intentionally eliminate disc numbers, and then number all the tracks of a multi-disc album consecutively. It's still one album, after all; and disc numbers are utterly irrelevant once the songs are off the CD. But, PerfectTunes reacts against that every time; it's not really surprising, of course. All that having been said, I have found that I need to re-rip a few albums for some other reason.

Actually, that may not be the case. I just looked again, since I have 47 albums that have trouble. Not all the multi-disc albums I've done that way are in that list. So, I guess ignore that part. LOL!

[artisan002]

Re: Looking for advice on glacial, on/off reading pattern with secure ripping

[SIZE=2][SIZE=4]Before I forget, thank you to all involved with this.[/SIZE]

I'm used to being able to sort stuff out myself. But, this optical drives are absolutely an area of zero expertise, and [as was glaringly obvious] I'd only gotten so far on best-effort logic and educated guesses. LOL!

Now, things are good. I'm not so hung up on the whole C2 thing, that one missing detail about Accurate Rip verification numbers makes the whole thing make dead perfect sense, and I've finally got both optical drives sorted out and operating according to the best of their abilities.

There are only lingering issues that don't matter if everything works right. Namely whatever chance Microsoft made in that May 2019 update to Windows 10 that allowed the Blu-Ray drive to behave better than it had.
The only thing that kind of nags me is when setting drives up for Secure Rip, and neither one is determined to have a cache, but the app will then recognize that it can flush the cache anyway. It's not hurt performance in any way I can perceive. So, I'm simply curious, rather than worried.

[SIZE=3]So, with all that, seriously, thank you.[/SIZE][/SIZE]

[garym]

Re: Looking for advice on glacial, on/off reading pattern with secure ripping

You're welcome. And it can't hurt to flush the cache. As Spoon notes here, using the default 1024 size is always safe:

Drive Read Cache is important in making sure that previous ripped audio is not given out on a re-rip, pressing Detect can test for a drive cache (detection for USB drives is not too good), using the default 1024 KB is a good way to not be troubled by drive Cache.

Above is from:

http://www.dbpoweramp.com/Help/dMC/CDadvanced.htm