PerfectTunes AR results affected by metadata ???

[Spoon]

Re: PerfectTunes AR results affected by metadata ???

Because if it is not this exact length, then it is not a 1:1 rip.

Example you have a very short track, it can be:

588 samples
1176 samples
1764 samples

if it was 1000 samples, then it is not a correct rip from a CD, because it is impossible to rip 1000 samples, as everything has to be divisible by 588. Check the sample count of the track which gives a not from CD error.

[simbun]

Knowing the forum was going down I saved the following messages.

You can use ffmpeg to generate an md5 of the audio.

for filename in *.m4a; do
  echo -n $filename"="
  ffmpeg -i "$filename" -vn -f md5 - 2>/dev/null
done

Run this in your folder of tracks with metadata that do verify (with 'Use AccurateRipResult from ID Tag' unchecked) and then in your folder of tracks without metadata that don't verify.

It might be worth running the following against one of the files in the folder that doesn't match:

ffprobe -hide_banner -i "01..."

By the way you can get the sample count by using:

sox input.m4a -n stat

[simbun]

Given that both rips were reported as accurate yet have different hashes means that there's something else going on here, as they should match (on a per track basis).

If you don't have any active DSPs, the only thing I can think of would be to try a clean installation, that or try another program like XLD to see how it gets on.


Sox doesn't natively support m4a but you can pipe it through ffmpeg first:

ffmpeg -i '01.m4a' -f sox - | sox -t sox - -n stat

Use this to check that sample counts between the two rips match. 'Samples read' represents total samples (for both channels).

[FrancescoT]

Thank you. The number of samples between the two rips match, and the total samples read for each track is a multiple of 588.
Unfortunately XLD does not seem to work anymore on the latest Sonoma: it hangs detecting pregaps irrespective of whether the 'Don't detect pregaps' option is checked or unchecked.
I would like to inform that the CD I'm ripping is an original Hyperion Records release (CDA66468) of 1991.

[simbun]

Thank you. The number of samples between the two rips match, and the total samples read for each track is a multiple of 588.
Unfortunately XLD does not seem to work anymore on the latest Sonoma: it hangs detecting pregaps irrespective of whether the 'Don't detect pregaps' option is checked or unchecked.
I would like to inform that the CD I'm ripping is an original Hyperion Records release (CDA66468) of 1991.

Looking at that disc on MusicBrainz it does have a pre-gap in Track 1 (which CD Ripper doesn't store, but PerfectTunes shouldn't need), I wonder if that could be throwing the verification out? Are you having these issues with other discs?

The track 1 pregap doesn't account for the mismatch between rips though.

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

[simbun]

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.

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.

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

[simbun]

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

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

[simbun]

I'm now ripping to flac. Same consistent md5 mismatch across successive rips of the same CD.

And that's using metaflac instead of ffmpeg?
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 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.

The older CDs are more likely to contain non-standard pregaps so aren't as likely to verify with PT but the rips should still be consistent.
I found that disc (Columbia MK39511) in MusicBrainz but no one has submitted the table of contents so I'm unable to tell if it contained a pregap.

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