PerfectTunes AR results affected by metadata ???

[FrancescoT]

I've posted 4 Google Drive links (unapproved) of some rips. I hope the posts get approved for you to analyse. I can find plenty more examples of good and bad rips. Let me know if you need anything else.

[FrancescoT]

This is a Google Drive link of two successive and perfectly superimposable rips of a more recent CD, Hyperion CDA68146: https://drive.google.com/drive/folde...usp=share_link
Let me know if you need more

[FrancescoT]

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

[FrancescoT]

This is a Google Drive link of two successive rips of Le Chant Du Monde LDC-278885, including logs: https://drive.google.com/drive/folde...usp=share_link

[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

[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."

[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]

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.

[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.

[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?

[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.

[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.

[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.

[FrancescoT]

And that's using metaflac instead of ffmpeg?

Yes

If that's the case then your setup isn't producing accurate rips, it's not even producing consistent rips as the audio differs between rips. If XLD doesn't work then maybe fre:ac would, that or a reinstall of dBpoweramp making sure that all the existing configuration has been removed.

I've reinstalled DP, deleting all that I could find related to it. Same pattern for MK39511. Indeed my setup is flawed. The problem is: what fools DP into affirming that the rips are accurate every single time?

[GBrown]

In any case, let me say (from the outside) that this whole business needs be understood, fixed and/or - at the very least - thoroughly documented. You can't send around paid software that works like this. This looks more like experimental stuff.

There are many thousands of users with many, many years of experience with the dbPoweramp that would strongly suggest otherwise.