PerfectTunes AR results affected by metadata ???

[GBrown]

There are over half a million independent user submissions and almost 5k drives documented for AccurateRip over a very long period of time. In the 20+ years I have been ripping my CD collection of over 2k discs I have had only a few rare occasions where the metadata wasn't found, but many where AccurateRip found errors in the rip results. No other software provides that kind of feedback. Almost all others blindly rip a disc and store whatever potentially bad results for you to later discover clicks, noise, or blanks spots.

The advantage here is that dBPoweramp at least provides some form of reporting so that you can go back to your rip and confirm if there in fact anything that needs to be fixed. Remember a single bad unrecoverable frame is reported but likely would never be heard during listening.

I find it incredible that in such a short period of time you have had as many issues as has been documented here. Either you have hardware problems that are causing this, or you have a collection of the world's most notorious poorly mastered CDs. Half a million other users are not experiencing the same problem.

[FrancescoT]

You may find it incredible, but it's all documented here. It is true that - while appreciating the software for the reasons you explained - I have raised some issues with the design and documentation of the programs, some of which have in fact been corrected. I have a first class classical music collection of original very successful and impeccably mastered CD releases (over 2k of them), first class hardware with no problems whatsoever, and four decades of experience in academic software development.

[Spoon]

There are 3 tags which have to be correct to later lookup the disc in PerfectTUNES: AccurateRip

Album Artist
Album
Track Number

if any are incorrect (album artist and artist have to match across tracks, not match the real name of the disc), then that disc cannot be looked up, it is not a case of trying to code the million possibilities someone could have, your tracks are either as they came off CD or they are not, if you change around track number / count then there is no lookup (a 20 track CD has 1.048576e+26 possible combinations of the tracks, so we are not going to try all the combination and ignore track number).

[FrancescoT]

Good to know. Apparently also total no. of tracks, even if one enables one-to-one match of album and folder. It definitely isn't as obvious as you seem to imply. Maybe it should be documented. Thanks anyway.

[MarktheRipper]

I have a related problem using PerfectTunes to validate rips. The one case that I have found to demonstrate this uses CD 48 from the Mercury Living Presence volume 1 box set. It is a 29 track CD, Antal Dorati conducting the London Symphony Orchestra, with several works by Igor Stravinsky including the complete Firebird ballet.

I rip the disc saving all files uncompressed. Metadata comes from MusicBrainz and is not altered, so the folder and filenames are as supplied.The WAV files contain a RIFF header with only a track number tag. PerfectTunes says all tracks are accurate.
I compress the tracks to FLAC, adding albumartist, track artist, title and year tags. PerfectTunes says there is an error in one track. (Not the last track.)
I use mp3Tag to change all track title tags to "Track nn", where nn is the track number. PerfectTunes says all tracks are accurate.
I use mp3Tag to copy the filenames back to the title tags. Perfect Tunes says there is an error in one track.
By shortening, or by removing parentheses from, the title tag of the track that follows the one indicated as inaccurate, I can get the "erroneous" track to change when re-checking with PerfectTunes.

I have also checked the rip using CueTools, which says all tracks are accurate and provides the same calculated results at every step.

It is pretty clear to me that something about the tags in the FLAC files is causing PerfectTunes to misread the audio data, and changing the tags changes the behavior of PerfectTunes.

I am using version 2024-06-10.