PerfectTunes AR results affected by metadata ???

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

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

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

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

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.

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

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

[FrancescoT]

Re: PerfectTunes AR results affected by metadata ???

Postings with attachments (or links) will be put under quarantine in most of the cases for security reasons and have to be checked by the admin.


Dat Ei

My posts being quarantined did not contain any attachment or links. And previous posts of mine which did contain attachments went online right away. What's going on?

[Dat Ei]

Re: PerfectTunes AR results affected by metadata ???

Postings with attachments (or links) will be put under quarantine in most of the cases for security reasons and have to be checked by the admin.


Dat Ei

[FrancescoT]

Re: PerfectTunes AR results affected by metadata ???

May I ask why some of my updates of yesterday to this thread, which provided additional information, are being held back and do not appear.

[FrancescoT]

Re: PerfectTunes AR results affected by metadata ???

That's because it's just looking at the tags that were written during ripping.

So you're implying that PT looks at these tags even when I disable the 'Use AccurateRip value from ID Tag' option ?

If you click on Show Details in PerfectTunes when you're verifying a failed rip is the Disc ID different to '010-00164f7a-00b43369-7e0dcd0a-6'?

The Disc ID is identical in PT and in DP logs, and is the same both when tags are written and when they are not. But in the second case PT concludes that the disc is not in AR. In the case tags are stripped, PT doesn't log any disc ID.

When you verify a rip with CUETools you can have it generate a .toc (table of contents) file (Settings > Advanced > Misc: Create TOC files). It would be interesting to see if that matched with the logs from your rip.

I'm on a MAC so no CUETools

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

[FrancescoT]

Re: PerfectTunes AR results affected by metadata ???

Ripping to lossless?

the sample count of the track has to be divisible exactly by 588 samples, that is how tracks are ripped:

https://en.wikipedia.org/wiki/Compac..._Digital_Audio

Can you please explain what has this got to do with the problem. I've ripped some 30k tracks off thousands of CDs (all purchased by me) to Apple Lossless format without any problem.

[Spoon]

Re: PerfectTunes AR results affected by metadata ???

Ripping to lossless?

the sample count of the track has to be divisible exactly by 588 samples, that is how tracks are ripped:

https://en.wikipedia.org/wiki/Compact_Disc_Digital_Audio

[FrancescoT]

Re: PerfectTunes AR results affected by metadata ???

By default PerfectTunes uses embedded AccurateRip results, which could account for some of the differences.

To turn it off:

PerfectTunes > Settings > Use AccurateRipResult from ID Tag

I thought, at the very least, that it would require TrackNumber, but I removed everything - and even named the files out of order - and it still verified the disc.

It might be useful if you included the log results of one of your rips with and without metadata.

I enclose the dBpoweramp logs of the rips done with and without metadata writing. As you can see, they're essentially superimposable save for the last track. On the first (with tags) PerfectTunes agrees with dBpoweramp, on the second (without tags) PerfectTunes says the album isn't present in AR. If I strip the tags off the first rip, PerfectTunes says it cannot check; Track Different Length Than CD original. The PerfectTunes results are identical if I uncheck the 'Use AccurateRip value from ID tag' option. I enclose a screenshot of the PT result page having placed the three rips in three different subdirectories.
Secure Ripping Log_no_tags.txtSecure Ripping Log_tags.txt