PerfectTunes AR results affected by metadata ???

[FrancescoT]

The thing is I've just discovered: if I rip twice in a row this CD (with the same identical settings of DP, of course: in this case TAG writing enabled) I get two sets of rips which have different md5 hashes (as output by ffmpeg). Something deeper is going on here, either with the CD, or with dBpoweramp, or with my drive, or with ffmpeg, or with any combination of them. I don't have any solid starting point any more.

[Spoon]

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.

[FrancescoT]

I ripped a disc with and without metadata to Apple Lossless and got the same hashes from ffmpeg.
Obviously our setups are very different, but you could remove ffmpeg from the mix by writing to FLAC, as this format includes an embedded MD5 that you can view using:

for filename in *.flac; do
echo -n "$filename="
metaflac --show-md5sum "$filename"
done

Ripping just a few tracks each time should be a sufficient test.

The internal MD5s should match at which point you can verify ffmpeg.

I'm now ripping to flac. Same consistent md5 mismatch across successive rips of the same CD. I've tried another old release (Columbia MK39511). dBpoweramp says the rip is accurate every time (confidence 50+), PerfectTunes says the rip is not in AR in all cases. At a wild guess it seems to be happening for old CDs (of the 80s and 90s, of which I have plenty) and not for more recent releases.

[FrancescoT]

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.

[Spoon]

So an AccurateRip submission doesn't count as being in PT?
I assume there's no point creating a CUE sheet that includes the PREGAP? Whenever I've tested PT and have removed the CUE sheet containing the PREGAP it's always verified it anyway.

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

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

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

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

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

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

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