PerfectTunes AR results affected by metadata ???

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

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

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

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.

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

Ok thanks. So PT is even fooled by such mistakes. Hard to believe that this should be the intended behaviour.

[Spoon]

"track : 1/17"

That is the issue, it is a 16 track disc, yet the tags have 17

[FrancescoT]

Can somebody please explain the following finding: I have an old rip of album Deutsche Grammophon 4777978, where all tracks (according to the "AccurateRipResult" tag) were ripped accurately (confidence 200). PerfectTunes reports this rip as "Incomplete" . If I now rip again this CD, all tracks are ripped accurately, the files have identical md5 hash as the old ones, and the DiscID is (of course) the same, but this time PerfectTunes says the album was ripped accurately. In enclose logs of old and new rips.

[PeterP]

Updated Mac dBpoweramp with the fix included:

https://www.dbpoweramp.com/beta/DMC-2024-05-07.dmg

[Spoon]

It is not on the macOS version yet, sorry, next update and it will be.

[FrancescoT]

Downloaded latest update of dBp (2024-05-01), which in the release notes says: "Bug Fix: CD Ripper: if a track required re-ripping of bad frames, then AccurateRip cross checking of pressings for that one track would fail"
Must report that the rip of Hyperion CDA66468 still shows exactly the same issue as before: dBp reports last track as secure but inaccurate, while PerfectTunes reports the whole rip as accurate. Rip files are identical to those already uploaded in my post n.59 Why does the text not fit on the buttons?

[FrancescoT]

I agree that there's some value in having an option that defines one DISC per folder, but if you also want to have multiple discs per folder "(of course, a folder may contain more than one whole rip)" then it needs to start using the metadata.

Yes you're right. As I said, I'm keeping one rip per folder, anyway, and that's what I was focused on.

I don't know much about classical tagging, but are you using the ALBUM tag for what would normally be stored in WORK?

No, not necessarily. Work is meant to be the name of an opus, a self contained piece of music often comprising more "movements" (tracks). An album is a larger collection, indeed often coinciding with one or more CDs (no problem there), but useful for splitting CDs when an opus spans more CDs and/or they also contain other works possibly by different composers and/or performers. Multi-CD releases (boxed sets) containing a packed collection of (often previously released individually) performances by one or more artists are a case in point.

[FrancescoT]

If you have album, discnumber and tracknumber correctly tagged, it appears that PerfectTunes does a good job in identifying individual discs and verifying them with AccurateRip, even across folders if 'Album Matching Grouped by Folder' is disabled.


Even with 'Album Matching Grouped by Folder' enabled, it looks like PerfectTunes still groups by the album tag, so if you've split a disc into multiple albums then it'll fail. It seems this option just stops PerfectTunes from attempting to merge across folders to make complete discs (whether that's by design I don't know).

In my view, it would make sense that the program looks at the album and track# tags across folders if the 'Album Matching Grouped by Folder' option is off, because this is of help to the user, who may not wish to match rips to folders. (But NOTE: it should say so in the doc, because it implies a constraint on the metadata.). But it's definitely NOT OK that it still groups by album tag if that option is on. That should mean instead that the user is free to choose whatever metadata they like (even none at all) as long as they take care of not splitting rips across folders (of course, a folder may contain more than one whole rip).

[FrancescoT]

Here's a link to an example: https://drive.google.com/file/d/1Ze3...usp=share_link

[FrancescoT]

Either all and only all the tracks of the disc have to be in the same folder, or the album name has to be identical.

That's what I wrote: I have all tracks of a physical CD in the same folder -- and only those.