PerfectTunes AR results affected by metadata ???

[simbun]

Yes AccurateRip submissions populate the TOC table which is used by PT to reverse lookup discs, the process is not instant.

Oh ok, I understand that there's a 4-6 week delay on new discs appearing in AccurateRip, but you made it sound like a non-standard pregap could affect that further.

If there is a non-standard pregap, and we do not hold that disc in PT for toc lookup, then PT would not be able to get the correct disc identifier for perfecttunes.

So given the disc FrancescoT ripped was from 1991 and there were 10 other submissions (including 6 with different offsets) in AccurateRip then PerfectTunes should have found it - assuming everything is working as expected?

[simbun]

FrancescoT
Assuming CD Ripper is working correctly, the only other thing I can think of - and this assumes that CD RIpper verifies the rip before it gets written to disk - is that there's a problem with your storage. (disk, cable e.t.c.). Where are you writing to, and do you have another location to try?

[Spoon]

It is impossible to dBp to confirm a rip as accurate if it is not, as it is a positive match system. Each disc would have to have 4 billion incorrect entries in the database for a bad rip to be verified as accurate, and even then we filter out the individual bad rips from ever appearing.

A dbp match vs later on PT saying the disc is not in AR, is just the missing first track offset.

[simbun]

A dbp match vs later on PT saying the disc is not in AR, is just the missing first track offset.

You make it sound like all discs with non-standard pregaps won't verify in PT, yet I've just run the Windows version of PT against 'Now That's What I Call Music! 18' (I chose this disc as I'm pretty sure it only has one pressing) that has non-standard pregaps (00:00:33) and it was correctly verified.

I even tried it with a disc with a less common pregap (00:00:05), thinking you might be trying the common ones, and it still verified.

[Spoon]

You make it sound like all discs with non-standard pregaps won't verify in PT, yet I've just run the Windows version of PT against 'Now That's What I Call Music! 18' (I chose this disc as I'm pretty sure it only has one pressing) that has non-standard pregaps (00:00:33) and it was correctly verified.

I even tried it with a disc with a less common pregap (00:00:05), thinking you might be trying the common ones, and it still verified.

Not the case, we have something like 1 million TOCs stored so we can reverse lookup based on track lengths, perhaps this disc has multiple matching pressings (with and without standard 150 frame offset) and the lookup will only work on the first 150 standard.

[FrancescoT]

FrancescoT
Assuming CD Ripper is working correctly, the only other thing I can think of - and this assumes that CD RIpper verifies the rip before it gets written to disk - is that there's a problem with your storage. (disk, cable e.t.c.). Where are you writing to, and do you have another location to try?

I'm writing to the internal SSD 2TB disk of my MacBook Pro. Never had any hint that this fails. Recent CDs rip ok, in a consistent and reproducible manner, with identcal md5 throughout. It is only older albums that fail.

[FrancescoT]

It is impossible to dBp to confirm a rip as accurate if it is not, as it is a positive match system. Each disc would have to have 4 billion incorrect entries in the database for a bad rip to be verified as accurate, and even then we filter out the individual bad rips from ever appearing.

I accept that. But then why is dBp confirming rips as accurate when they turn out to have different audio md5 and PT is affirming they're not in AR?
Why does this only happen for older albums and not (never afaIk) for recent ones?

[simbun]

Not the case, we have something like 1 million TOCs stored so we can reverse lookup based on track lengths, perhaps this disc has multiple matching pressings (with and without standard 150 frame offset) and the lookup will only work on the first 150 standard.

That could explain why one disc doesn't verify (the original release with a pregap has the same signature as a remix released years later without a pregap), but the disc would still be in the database, as it has a valid signature.

To test that it's the disc signature that drives a match I silenced all the tracks of an album (ffmpeg -i 01.01.flac -ac 2 -sample_fmt s16 -ar 44100 -af volume=0 01.flac) and removed the tags. PT did match the signature but also strangely reported:

3 Tracks Accurate, Tracks 1-6, 10 Unverifiable

[simbun]

I'm writing to the internal SSD 2TB disk of my MacBook Pro. Never had any hint that this fails. Recent CDs rip ok, in a consistent and reproducible manner, with identcal md5 throughout. It is only older albums that fail.

I think that's the first time you've confirmed that you're able to repeatedly rip any discs with matching MD5s. In that case I have absolutely no idea what's going on!

I believe it's possible for two rips of the same disc to verify that have different MD5s for the first and last track (because AccurateRip excludes a few frames from the beginning and end in its calculation) but it shouldn't be possible to contain mismatching MD5s for the others.

[FrancescoT]

I think that's the first time you've confirmed that you're able to repeatedly rip any discs with matching MD5s. In that case I have absolutely no idea what's going on!

There must be a misunderstanding. I said I've ripped thousands of CDs without any problem, and I've checked md5 consistency across rips of a number of them. But there stil are quite a number - as I say older ones - that systematically show the md5 inconsistency (not to speak of PT) I've described despite dbP saying the rip is accurate every time. So if there's a problem with my hardware setup, it is definitely interconnected with some other problem that depends on either dBp or the way the CD was pressed or a combination thereof. I am far from being an expert in the matter, but I've worked with computers and programmed scientific academic and system software for some 45 years, so I think I can tell when a piece of software is user friendly and when it is not. I'm just saying that there should be a less dismissive posture (you definitely excluded) towards user-raised issues.

[simbun]

I said I've ripped thousands of CDs without any problem, and I've checked md5 consistency across rips of a number of them. But there stil are quite a number - as I say older ones - that systematically show the md5 inconsistency (not to speak of PT) I've described despite dbP saying the rip is accurate every time.

Just so I'm clear, are you saying that you've re-ripped discs that match the MD5 of your old rips (using ffmpeg to calculate the MD5), and/or you've ripped discs twice and in some scenarios the MD5s do match? That's the bit I wasn't clear on, but either way, two rips containing mismatching MD5s shouldn't be possible if they're both classified as accurate.

The standard response in this type of situation seems to be to perform a reinstall, which strangely seems to fix things the majority of the time, which frustrates me.

[FrancescoT]

Just so I'm clear, are you saying that you've re-ripped discs that match the MD5 of your old rips (using ffmpeg to calculate the MD5), and/or you've ripped discs twice and in some scenarios the MD5s do match? That's the bit I wasn't clear on, but either way, two rips containing mismatching MD5s shouldn't be possible if they're both classified as accurate.

The standard response in this type of situation seems to be to perform a reinstall, which strangely seems to fix things the majority of the time, which frustrates me.

I''ll do further checks concerning old rips and comparison with current re-rips. What I'm saying for now is that I have plenty of examples of consistent and reproducible rips (newer albums) as well as examples of (older) albums that ripped two times consecutively in a row will give two sets of files that have different md5 hashes, while dBp says both times that the rips are accurate.
I have already re-installed dBp at least twice.

[Spoon]

You would have to post some logs, upload example files for examination.

Instead of throwing around accusations that the software is untested. AccurateRip has processed half a billion CDs, and we have never seen a situation where it was found to report as accurate when it was not, for the data it checks.

[FrancescoT]

You would have to post some logs, upload example files for examination.

Instead of throwing around accusations that the software is untested. AccurateRip has processed half a billion CDs, and we have never seen a situation where it was found to report as accurate when it was not, for the data it checks.

I'm trying to upload example logs files but I get "The attachment storage directory does not exist or is not writable."

[FrancescoT]

This is a Google Drive link of two successive rips of Columbia MK-39511, including logs: https://drive.google.com/drive/folde...usp=share_link