PerfectTUNES discussion

[fastfwd]

Thanks for making PerfectTunes available. I'm enjoying it already, even in its current beta state.

I'm using beta 5 on Win7-64, running PerfectTunes AccurateRip on a library of ~17K ALAC tracks ripped with dbPoweramp. The library contains only tracks that were verified as accurate by dbPoweramp CD Ripper and tracks that were secure-ripped by dbPoweramp because they weren't in the AccurateRip database when I ripped them.

I'm seeing the same sorts of things that Porcus reported:

1. In the "48 Albums Cannot Check" section of the results, some -- maybe all -- HDCD albums show as "Cannot Check: Not Lossless CD Quality", and some complete albums show as "Cannot Check: Incomplete Album".
2. In the "23 Albums Ripping Errors" section, I see some tracks marked "Track InAccurate" even though they were AccurateRipped and contain the expected AccurateRip tags. I checked a few in fb2k and they verified as accurate; I played a few and they played perfectly.
3. In the "55 Tracks Corrupted" section of the results, a number of tracks are marked "Corrupted" even though -- like all the others -- they were AccurateRipped and they contain the expected AR tags. I played a couple and verified them in fb2k; they seem perfect.

I'm also seeing two other behaviors:

1. In the "23 Albums Ripping Errors" section, some albums are shown with one or more tracks "Unverifiable". Exporting the match details shows "Not Enough Information in AccurateRip to Verify" those unverifiable tracks, but the tracks in question were AccurateRipped and contain the expected AccurateRip tags. Again, I played a couple of them and and tested them in fb2k; no problems found. The unverifiable tracks are often, but not always, the highest-numbered tracks of the albums.
2. The "93 Albums Not Present in AccurateRip" section contains a number of albums that certainly ARE in the AccurateRip database (e.g., Paul Simon's "Graceland"). My ripped tracks from those albums were AccurateRipped and have the AR tags; the ones that I tested in fb2k verify as accurate.

[trans_lux]

Took a couple days to churn through 70k tracks.
Lots of dups, would take days to click delete on each track.
Any thoughts on a "remove all" or ??

[mickc]

Took a couple days to churn through 70k tracks.
Lots of dups, would take days to click delete on each track.
Any thoughts on a "remove all" or ??

I must admit from a personal point of view I probably won't be deleting many, if any at all. So far as I can see (I have 47,000 FLAC files so there's a bit of room for error) most duplicates exist because I have songs in, say, original albums and also in compilations. If I delete duplicates I could end up with compilation albums containing one or two tracks and I'd rather have them complete!
Only my preference, of course, and it is a very useful tool for those odd occasions when I find I've ripped an album twice and tagged them slightly differently...

Mick

[Porcus]

fastfwd:
Your first point, I suppose you have used the HDCD DSP upon ripping. That changes the signal, irreversibly (at least, no-one knows how to reverse it), and there is no way that you would be able to verify it by AccurateRip unless Spoon augments it by some HDCD-specific database.


Apart from that, then most of fastwd's and TedSmith's findings are valid here too (I have already reported that De-Dup suggests Jaco Pastorius = Mayhem ...)


And I agree with mickc's comment: I have been able to weed out a few mistags, and that has already made De-Dup very useful to me. I don't want to delete any single tracks from my CD-rips; either two CDs have the same signal (... modulo offset, right ...), or one is a subset of the other -- or I want to keep both. Preferences might vary. But now I've repeated myself already.

[Spoon]

Porcus:

Had a chance to look through those files, first off '&*916; ~ Rock Hard; Dynamit vol. 25', yes once 24 bits from HDCD it appears inaccurate to accuraterip which needs the original 16 bits to check against, it should really say not CD quality.

'&*916; ~ Loud Speaker Records' - this verified without errors, where are your files stored? on a network? I think there is an issue where files are blocked and reported corrupted, as another user reported than rescanning gave is different bunch of files reported as corrupted.

'Mazzy Star {1996} ~ Among My Swan' - this one track 2 has the disc number set to 2, where as all the other tracks has disc number as 1, disc number is used to detect separate albums.

[Spoon]

fastfwd: Please try selecting the drop database option (on the options page) and let it rescan, does the list of corrupted albums change? are your files stored on a network?

>In the "23 Albums Ripping Errors" section, I see some tracks marked "Track InAccurate" even though they were AccurateRipped and contain the expected AccurateRip tags. I checked a few in fb2k and they verified as accurate; I played a few and they played perfectly.

I would need one of these complete albums, as long as the single track is not 24 bit (ie HDCD processed that track), if you send the files individually by email please: http://www.dbpoweramp.com/email.htm

>1. In the "23 Albums Ripping Errors" section, some albums are shown with one or more tracks "Unverifiable". Exporting the match details shows "Not Enough Information in AccurateRip to Verify" those unverifiable tracks, but the tracks in question were AccurateRipped and contain the expected AccurateRip tags. Again, I played a couple of them and and tested them in fb2k; no problems found. The unverifiable tracks are often, but not always, the highest-numbered tracks of the albums.

We would need one of these albums also

>2. The "93 Albums Not Present in AccurateRip" section contains a number of albums that certainly ARE in the AccurateRip database (e.g., Paul Simon's "Graceland"). My ripped tracks from those albums were AccurateRipped and have the AR tags; the ones that I tested in fb2k verify as accurate.

...and one of these

[Porcus]

Spoon: There were two parent folders, both on an USB drive (NTFS file system) connected directly to the USB port of the laptop that ran the PerfectTunes application. 'Loud Speaker Records' was in the same parent folder as half of everything else.
In my experience, a rescan gave the same files reported as corrupted. Will try another time.


Thanks for the correction on Mazzy Star. A bit embarrassing not to see the issue, but it was track 2 that had discnumber 2, so ... :blush:

[Gundy]

Hi Spoon,

Thanks for this really nice software. I am having trouble with Album Art module. There are a lot of albums on my disk that fall into the "Low Resolution Albums" category. When selecting "Fix" for any of them I do get "Error Writing to File" every time after picking a new cover art. I have double checked the file security settings for those files, but cannot see any issues with them. Also tried running PerfectTUNES with administrator privileges (Win7 64bit), but to no avail. Any ideas?

Thanks & Best Regards,
Gundy

[Spoon]

Where are the files stored? on a Network NAS (share), or on a local hard disk?

Are the files set to read only?

[Porcus]

More reports:


- the false reports on corrupted files seem to disappear (or different ones show up) when the database is cleared and everything is rescanned. Of course, with a library that takes a week to scan, I would hope for a more robust solution in the final release.


- even with grouping by folders, it seems that various artists compilations -- with no ALBUMARTIST nor ALBUM ARTIST tag -- are inconsistently treated sometimes as one album per folder, sometimes as separate files. This time I checked the discnumber tag. (And the album titles. And that CDTOC match ...)

[fastfwd]

fastfwd: Please try selecting the drop database option (on the options page) and let it rescan, does the list of corrupted albums change?

Yes, the list of "Tracks Corrupted" does change, as does the list of "Albums Cannot Check" (because albums with "corrupted" tracks are also "incomplete"). The other lists, "Albums With Ripping Errors" and "Albums Not Present in AccurateRip", are unchanged.

are your files stored on a network?

Yes, on a NAS. It has higher sustained throughgput than my internal HDD, but I guess it has higher latency.

In the "23 Albums Ripping Errors" section, I see some tracks marked "Track InAccurate" even though they were AccurateRipped

I would need one of these complete albums, as long as the single track is not 24 bit (ie HDCD processed that track), if you send the files individually by email please: http://www.dbpoweramp.com/email.htm

In the "23 Albums Ripping Errors" section, some albums are shown with one or more tracks "Unverifiable". Exporting the match details shows "Not Enough Information in AccurateRip to Verify" those unverifiable tracks, but the tracks in question were AccurateRipped

We would need one of these albums also

The "93 Albums Not Present in AccurateRip" section contains a number of albums that certainly ARE in the AccurateRip database (e.g., Paul Simon's "Graceland")

...and one of these

Unfortunately, many of the tracks are larger than my ISP's 20MB limit for email attachments. It's no trouble for me to split them if you don't mind unsplitting them, but if you'd prefer to direct me to an FTP server, I could send them that way, too.

[Spoon]

Can you use DropBox?

[Spoon]

I have released Beta 5i for those who were getting corrupted errors (which change to different files after a rescan).

[Spoon]

Those wanting to see the log would have to trigger a database drop (rescanning all files)

[fastfwd]

Can you use DropBox?

Yes. I just emailed a link to you.

Thanks very much for investigating this issue.