PerfectTUNES R2 discussion

[SirAtilla]

Which title is assigned to these tracks?

Hi - if this is directed to me not sure I understand? They are in category of "corrupt file"

[Spoon]

They are FLAC files?

[SirAtilla]

They are FLAC files?

Thanks for clarifying - these are all in Apple Lossless format. I do have the FLAC equivalents but am not scanning them. I used at the time XLD to convert them from FLAC to Apple Lossless.

[Spoon]

It is possible they are corrupted some how, can other programs play them? how about foobar 2000?

[SirAtilla]

they play perfectly fine so I am talking just about how PerfectTUNES R2 reports the files. I think this is false positive honestly.

[Spoon]

Please email one of the files (perhaps the smallest)

https://www.dbpoweramp.com/email.htm

[SirAtilla]

Please email one of the files (perhaps the smallest)

https://www.dbpoweramp.com/email.htm

I send you via private mail a link to grab the original FLAC file and the Apple Lossless version. FWIW I scanned the original FLAC file and PerfectTUNES R2 did not report it corrupted. I re-converted it again and still reporting it corrupted so maybe conversion is actually corrupting it but very random like in this case 1 song out of entire album.

Thanks for your help and great products.

[Spoon]

Technically these files are corrupted, in that:

stts: Atom Size: 24 Version: 0 Flag 0: 0 Flag 1: 0 Flag 2: 0 NumEntries: 1
entry 0: Count: 8400 Duration: 4096

Here the Count is 8400, yet later in the file:

stsz: Atom Size: 33624 Version: 0 Flag 0: 0 Flag 1: 0 Flag 2: 0 SampleSize: 0 NumEntries: 8401

The NumEntries is 8401, this should match the count of the previous. Other software seems to skip this indiscretion, I am not sure we should, our programs are there to show if there is a problem with the file, and there is. Played on another program it might even crash it (perhaps a hardware device). Perhaps report to XLD and they can fix.

[SirAtilla]

[QUOTE=Spoon;155637]Technically these files are corrupted, in that:

So I will report a few of these to XLD creator. I did go ahead and re-converted from original FLAC source with dbPowerAmp on Mac and now they are no longer being reported corrupt.

Thanks for the follow-up.

[Mat_Illustrate]

Hi,
while the tool is really handy when it comes to provide FLAC files with SORT Tags for the first time, it is getting a little painful using Perfect Tunes for collections which already have SORT tags.

E.g. let's assume I already own twelve CDs from Joe Cocker and for all of them I have set SORT tag to "Cocker, Joe". Really handy and time saving - great work!

Now I buy and rip CD 13 from Joe Cocker and when I run Perfect Tunes again it recognizes that the SORT tag is different for "Joe Cocker", i.e. "Cocker, Joe" and "blank". Now when I click on "Cocker, Joe" to provide correct SORT tags for CD 13 then Perfect Tunes will rewrite the SORT tag into all of the files instead of only into those files where the SORT tag is missing.

Could this be corrected as such that only those files will be corrected where the SORT tag is either missing or wrong? Imagine you have ton do this exercise with SORT tag "Various artists" or "Wolfgang Amadeus Mozart" on a huge CD collection...

[Niko]

Hi,

I recently ran the Accurate Rip test with the actual beta of Perfect Tunes 2 and examined the results of the page „Albums with ripping errors“ in detail.

Doing this I found some of the results correct, some with „question marks“ and a few which I think are due to some error within the program (might as well be incorrect in the Accurate Rip database).

Therefore I created hardcopies of the results pages and made my comments to each CD shown in the results. The comments with green background are for information only, the items I find worth questioning are commented on yellow background, and the - in my view incorrect - results are shown on red background.

To be questioned I found that some tracks are marked „Unverifiable“ - these are mainly CDs which are not widely spread. As I understand the meaning of this, these tracks can not be verified as I am the only one who reported my ripping result to the A.R. database, and all others (at least 2) excluded these trucks from their rips - but this happening with 6 CD’s seems a bit of great coincidence - however still possible, but maybe worth an investigation. Besides that, unverifiable does not a priori mean an error, it may as well prove as correct if these tracks were ripped by other users as well - therefore you may consider to move such results to another results page.

In some cases the details shown are not detailed enough to enable a prompt correction (e.g. by re-ripping): Compilations on multidisc CDs sometimes contain the same number of tracks on each CD, thus the disc number would be helpful to avoid a try and error game.

Strange I found especially the following case:
- A certain concert was recorded by the local radio company and broadcasted some weeks later. I recorded the whole broadcast from an analogue radio, cut the result into 5 tracks, converted the files to WAV and burned a CD from that.
- There exists no „official“ CD from this concert, and if the radio company created a CD (on private request and for personal use only), the quality of their source material would be significantly better than a broadcast limited to about 14 kHz. And the position where the whole recorded file was cut into pieces would be exactly the same as mine would be an unbelievable coincidence.
- I gave a copy of my CD to a friend, and he informed me that he did not rip this CD nor did he hand it over to someone else. Thus the chance of some other rips created from copies of my CD tends against zero.
- However, 2 of the 5 tracks are marked as accurate (!!! - where do the other rips come from ?), 1 as unverifiable, and there is no reference to the further 2 tracks - all other CDs show the correct sum of accurate and other tracks, this one does not.

The other problem is that 3 different tracks on 2 different compilation CDs are each shown as „2 tracks accurate“, although there is is only one track in each case (reminds me of Monty Python’s Kilimanjaro sketch ;-).

And here is a link to the commented hardcopies file:
https://dl.dropboxusercontent.com/u/...0questions.pdf

Please clarify. Regards.

[Spoon]

Click the 'i' match details button, it will show more details on the tracks.

Also check you are using the latest beta, we updated to remove the issue where it says accurate and yet still lists those discs in the errors section.

[Niko]

Click the 'i' match details button, it will show more details on the tracks.

Also check you are using the latest beta, we updated to remove the issue where it says accurate and yet still lists those discs in the errors section.

Mr. Spoon,

thank you for your recommendations. The result of updating to the latest beta and the use of the &*8218;i&*8216; button helped to improve the results in many ways, however there are still some open questions.

Firstly, the improvements:
- the "2 tracks accurate" issue vanished on the 1st run after installation of the latest beta
- Cecilia Bartoli's Mission "- track 26 has errors" vanished by renaming the track 26 to 27 (similarly by changing the track number within the metadata), since the track title was as seen in iTunes as *27. Now the complete album appears as actually ripped.
- most of the strange results on Gil Evans "It ain't necessarily so" can be referred to a fault caused by myself: Firstly, the CD contains 4 tracks only (and not 5 as reported earlier). Furthermore, since this "album" is not part of any "official" database, I had to key in all the metadata manually, and on this occasion I assigned 4/4 not only to track *4, but to track *3 as well (however, the file names the tracks were correct). This I found out from the "Match Details" file, since it claimed the file of track *3 to be unverifiable, whereas the graphical summary claimed that track *4 was unverifiable. The error source was exactly located by use of the metadata editor of dBpoweramp. Obviously the utility, which compares the calculated CRC with the A.R. data, jumped to the next album, since according to the track metadata the last track of the album was reached, although there was still another track outstanding. Maybe this part in the program can be improved by cross checking of the track count. However, sorry for possible inconveniences caused by my error.

Still unclear:
- For consistency reasons, I think a cross check between the album count of Asset UPnP and Perfect Tunes is appropriate. Actually, since the same album may be counted twice in Perfect Tunes, additional data counting such albums would be appreciated. Additionally, track counts would further improve consistency checks.
Perfect Tunes vs. Asset UPnP - Album count.jpg
- Assume that the contents of a whole album are not found in the A.R. database: Actually, such an album is entirely evidenced in two categories: Does it make sense, if a separate category "Not Present in AccurateRip" exists, to additionally show the entire album under "Accurately Ripped" ? The wording of "Not Present in AccurateRip" category seems to me self explanatory enough, since the attribute "Accurately Ripped" of a certain track means either a secure rip and a CRC compliant with the CRC of rips from other users. See the following hardcopies regarding this point.
Perfect Tunes - Accurately Ripped.jpg
Perfect Tunes - Not Present in AR.jpg
- Thus, e.g. the above Gil Evans album should entirely disappear from the category "With Ripping Errors" and shown under the following categories: "2 Tracks Accurate (of 4 Tracks)" under "Accurately Ripped" and "Tracks 3, 3 Unverifiable (of 4 Tracks)" under "Not Present in AccurateRip". Don't you agree ?
- Regarding "Unverifiable", I seem to not fully understand this attribute, therefore let's imagine the following example: Assume that I have two PC's with a built-in CD (or DVD / BD) drive each. On PC *1, I try to rip a CD with 10 tracks. At track *8, the rip slows down - potentially a CD with defects. The tracks *1-7 were marked as "Secure". As I do not want to wait for the rip to finish, I stop the rip on the PC *1 and move the CD to PC *2 and start ripping from track *1 (who knows what it may be good for ?). At track *8, nothing happens (maybe a temporary error of the CD drive in PC *1), and the rip of the entire CD finishes at a reasonable time. All tracks were marked as "Secure". With some delay, the ripping results of both PCs are submitted to the A.R. database. Sometimes later, PC *2 runs Perfect Tunes. I think that tracks *1-7 will show as "Accurately Ripped" (as they conform to the results PC *1 had submitted), whereas tracks *8-10 will be "Unverifiable" (as only the own result is present in A.R.). If PC *1 runs Perfect Tunes: Tracks *1-7 will show as "Accurately Ripped" anyway (because of what PC *2 had submitted), irrespective of tracks *8-10 being copied later to this PC (from PC *2 - and these will as well seem as "Accurately Ripped", since CRCs were submitted by another PC, i.e. *2). Is this correct ?

Having now examined other result categories as well, please explain the following:
- FLAC files are declared as "Not Lossless CD Quality". These are in same cases files, which are published e.g. from the record company as sample free of payment, but are exactly the same as if compared to the track of the CD they were copied from. Why "Not Lossless" ?
- Entire albums are also classified that way, e.g. "Somethin' Else" by Cannonball Adderley etc., available through HighResAudio (https://www.highresaudio.com/artist.php?abid=193982). Why also "Not Lossless CD Quality" (and not "Accurately Ripped", if all CRCs conform to the ones from rips by other users) ?
- I would agree if such tracks were assigned to "track not ripped from a CD" or similar meaning. But as you mentioned somewhere else, a ripped file may become corrupt, and the information is important to enable adequate measures (in this case re-download instead of re-rip), so "a qualifying info" (if CRC of respective track is compliant or not) would help to decide whether a correcting step is appropriate or not.
- In similar cases, some track from s are marked as "Incomplete Album". This does not necessarily imply that the CRC of this file does not conform to a CRC of the respective track from the original CD (so the track would have to be considered as "Accurately Ripped", if "physically" ripped and resulting in the same CRC). Typical examples are "Sampler CDs", mostly as compilations, as published from naim, Verve or other record companies. Why this ? If published as (preferably downloadable due to their smaller size) FLAC files.
- The difference between "Not Lossless" and "Incomplete Album" seems to be that downloaded FLAC files are "Not Lossless", there against ripped sample CDs (especially with each track containing in it's metadata the original CD's title (and not the title of the compilation CD) tend to get "Incomplete Album" (although all tracks of the compilation CD are present). Is that true ?
- If I record a concert e.g. with an iPod (and a better quality microphone) - similarly if I record anything from an analogue broadcast- and convert the result to WAV file(s): Such files will be classified as "Not Lossless CD Quality". If, however, I burn such WAV files to a CD and then rip it to WAV files again: Such files are qualified to be considered as "Accurately Ripped". Is that true ?

Thanks in advance for answering my questions. Regards.

[Spoon]

Perhaps you have tracks which use the format WMA, the Apple version of Asset would not read those.

The miss labelling of 'Cannot Check not in AccurateRip' we would need your database zipping up and uploading to somewhere like dropbox, open windows explorer and type:

%appdata%

the folder PerfecTUNES, right click >>Send to >> compressed zip file

> Is this correct ?

Correct

>Not Lossless CD Quality

CD is 44KHz 16 bit, if your tracks are not this then they will not be checked against AccurateRip. If you have the audio in FLAC it would be tested for corruption though.

[garym]

>Not Lossless CD Quality

CD is 44KHz 16 bit, if your tracks are not this then they will not be checked against AccurateRip. If you have the audio in FLAC it would be tested for corruption though.

keep in mind that a flac hi-res file (24/96 or 24/192) is not a cd file (which is 16/44.1). So although these files are lossless and may be equal or even better quality than the files ripped from a redbook CD, ACCURATERIP can't check them for AR database match.