PerfectTUNES R2 discussion

[Niko]

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.

Hi,

firstly, my music libraries do definitively not contain any WMA files.

Thank you for clarifying that only 44,1 kHz 16 bit files are checked against AccurateRip. Thank you also, Garym, for your contribution.

Having investigated once more and deeper through the results of Perfect Tunes, there arose some more questions:
- There are more than 90 % of the albums, which show "different length", under "cannot check". About 40 % thereof contain within their metadata a "Length" tag for unknown reasons. Would this classification disappear, if I remove this tag ?
- Since "different length ..." results even from "regular" rips to MP3 with actual software: May this happen due to compression or is this a classification, which is used because no other classification applies ?
- The Yardbirds - "Roger The Engineer ... ": Only 12 of 22 album tracks present = "Incomplete". Which percentage of ripped tracks, compared to the total number of tracks of an album is necessary to avoid this classification ?
- Litsa Diamanti "Teliosan ta s'agape" (originally in Greek letters) is a CD(-R) which I created from an LP I recorded digitally = "Accurate&". I ripped it only once on a single PC only, and the chance that someone else cut the titles at the exactly same position as I did is very unlikely. Any idea how this "CD" receives "Accurate" ?

The link to the zipped Perfect Tunes in %appdata% has been sent by separate mail.

Regards.

[Mat_Illustrate]

Hi Mr. Spoon,
when I read "tag writer - if tags are already what is should be, no write" in the new beta announcement, I thought for myself "Well, could it be that this has been already fixed/enhanced?". Trying it with the composer "Georg Friedrich Händel" for an awful long time the message "Writing tags" appeared but after task has been finished, only the new files have been written with the SORT tag.

THANK YOU SO MUCH for implementing this so fast. This saves quite a lot of hassle on my side!

[SirAtilla]

Quick question - is there any thought to having the AccurateRIP report show albums with more than one disc as one album just like the Album Art component which does it correctly?

[Spoon]

No as in the accuraterip database these discs are seperate.

[SirAtilla]

Thanks - seem likes there would be something holding the "album" together even though discs are separate. Perhaps the text show says how many discs are accurate versus how many albums.

Another anomaly I wanted to report.

I have two copies of the Rush album Moving Pictures. A standard rebook and a Hi-Res version. They are located in two different folders but the Album Art report shows only one copy versus two. This is perhaps intentional but I wanted to report it.

Thanks for your hard work on these applications.

[PepsiCan]

- Litsa Diamanti "Teliosan ta s'agape" (originally in Greek letters) is a CD(-R) which I created from an LP I recorded digitally = "Accurate&". I ripped it only once on a single PC only, and the chance that someone else cut the titles at the exactly same position as I did is very unlikely. Any idea how this "CD" receives "Accurate" ?
Regards.

A long shot, but perhaps you're comparing the Rip against your own entry into the AccurateRip database? Have you got the option enabled to request two or more hits?

[PepsiCan]

Hi

I posted my original post probably in the wrong thread. Here is the link.

https://forum.dbpoweramp.com/showthr...om-ID-tag-quot

[Niko]

A long shot, but perhaps you're comparing the Rip against your own entry into the AccurateRip database? Have you got the option enabled to request two or more hits?

Hi,

probably I compare my own rip against AccurateRip-DB, but I'm not 100 % sure (not exactly knowing at this time if there is something like a unique "sender-ID" part of the AccurateRip data).

Furthermore, to set minimum hits quote to a higher level does not solve this in general for the following reasons:
- I have acutually 1 license for dBpoweramp under Windows and a family license for dBpoweramp on OS X.
- ripping began with a small "netbook" PC
- for performance reasons I moved to a stronger - but still Windows - hardware
- while the OS X version was in a beta state I moved to VMware virtual machine (thus Win 7 on a Mac) for better ability to compare settings and results
- actually I still use Win 7 under VMware and the OS X native program (both one the same Mac) and another Mac with native OS X version

Assume that something like a "motherboard ID" (compare it to Microsoft's actual licensing policy) is stored as a sender ID - than my rips may appear with 5 separate ID's, and I have no reliable information as to which CD was ripped under which hardware. And remember the effort needed if you move to another hardware and want to keep the same Microsoft product key ...

And Illustrate's order number as sender ID would not solve such problem entirely (I do have two order Nos.), but other family members' rips should not be compared against mine and vice versa, even if the same CD appears in both collections (and I presume that there will be two original CD's as well ;-).

See my post *43 (question "Is this correct ?" and Mr. Spoon's reply - "Correct"), which shows that a reliable solution for this may be not quite simple. And that led me to my question, whether there may exist another possibility how the "Accurate" qualifier might have resulted in this special case.

[PepsiCan]

Hi,

probably I compare my own rip against AccurateRip-DB, but I'm not 100 % sure (not exactly knowing at this time if there is something like a unique "sender-ID" part of the AccurateRip data).

Furthermore, to set minimum hits quote to a higher level does not solve this in general for the following reasons:
- I have acutually 1 license for dBpoweramp under Windows and a family license for dBpoweramp on OS X.
- ripping began with a small "netbook" PC
- for performance reasons I moved to a stronger - but still Windows - hardware
- while the OS X version was in a beta state I moved to VMware virtual machine (thus Win 7 on a Mac) for better ability to compare settings and results
- actually I still use Win 7 under VMware and the OS X native program (both one the same Mac) and another Mac with native OS X version

Assume that something like a "motherboard ID" (compare it to Microsoft's actual licensing policy) is stored as a sender ID - than my rips may appear with 5 separate ID's, and I have no reliable information as to which CD was ripped under which hardware. And remember the effort needed if you move to another hardware and want to keep the same Microsoft product key ...

And Illustrate's order number as sender ID would not solve such problem entirely (I do have two order Nos.), but other family members' rips should not be compared against mine and vice versa, even if the same CD appears in both collections (and I presume that there will be two original CD's as well ;-).

See my post *43 (question "Is this correct ?" and Mr. Spoon's reply - "Correct"), which shows that a reliable solution for this may be not quite simple. And that led me to my question, whether there may exist another possibility how the "Accurate" qualifier might have resulted in this special case.

There is an option in R2 beta to request two or more matches before an accuraterip is flagged. And no, there is no "sender id". That would be difficult to implement as you already outlined and also it would require a heap of (costly) additional security around the database because of EU data privacy laws. A possible way this could work technically is if a CD had a unique ID on its disc. But that is not the case.

But here is a thought: it is not necessary. What you really want is two things:
1) is my copy bit identical to the original so that there is no degradation in sound quality?
2) over time, are the bits preserved?

By comparing your rip at creation against other rips you get that certainty in case 1. By rescanning the tracks and tracing against the accuraterip database you get a confirmation of consistency. Even if you compare against your own CD, it is clear that your copy has not degraded over time. So, it is still as good as it technically can be.

[Niko]

There is an option in R2 beta to request two or more matches before an accuraterip is flagged. And no, there is no "sender id". That would be difficult to implement as you already outlined and also it would require a heap of (costly) additional security around the database because of EU data privacy laws. A possible way this could work technically is if a CD had a unique ID on its disc. But that is not the case.

But here is a thought: it is not necessary. What you really want is two things:
1) is my copy bit identical to the original so that there is no degradation in sound quality?
2) over time, are the bits preserved?

By comparing your rip at creation against other rips you get that certainty in case 1. By rescanning the tracks and tracing against the accuraterip database you get a confirmation of consistency. Even if you compare against your own CD, it is clear that your copy has not degraded over time. So, it is still as good as it technically can be.

Agreed to your point 1) - however additional information (e.g. confidence level as shown after ripping) could enhance the value of an "accurate" flag.

Agreed as well to your point 2) - if I set the a.m. option to "two or more matches" I would not get the answer that my copy has not degraded.

Regarding EU privacy laws I cannot agree - see the disclaimer on the following hardcopy:
AccurateRip data.jpg

If you look at the "Computer identification" field I would not bet that there is no "sender ID" stored within the AccurateRip database, however if there is no way for the "normal" user to gather from this value my "personal data" (like name, address, age and similar), the requirements of EU privacy laws are already met (think of this field value to be used to determine whether an INSERT or UPDATE is to be made within the database - this ability qualifies it's use and ensures a qualified meaning of the classification "accurate"). Thus there is no requirement of "(costly) additional security" measures.

(The "Computer identification" field can be compared to the "IBAN" of an account with a bank (as used with domestic and foreign payments in the EU) : Knowing how the IBAN is calculated you are able to verify it, but you do not know, whether such account really exists nor the owner, nor his nationality nor the owner's address of such account).

The meaning of the "length" tag as well as the classification of "incomplete" (see post *469 I am still unable to understand exactly.

[Niko]

Mr. Spoon,

congratulations for having added the capability of browsing by metadata, especially to choose whether sorted without the contents of / or considering the contents of the sort tag field values. This makes it far more easy to simulate the appearance within a control point app as well as for entering additional / removing unwanted sort fields.

Compared to the 1.7 version really great improvements on usability, especially in connection with the tag handling.

Since there seem to be included some functions as from Asset UPnP as well as from dBpoweramp:

I dream of a version which checks - if so set up by the user - on the occasion of collecting metadata from the internet - against the own Perfect Tunes database and to offer via drop down list boxes corrections, where e.g. a similar artist name is found. This would save a great amount of time (for correction, maybe in more than one music collection) and would follow the principle that additions to the own database should be checked before storing them. The real value of such procedures may be found only if many hours have been spent in the past to correct mistyping, redundancies and similar errors.

[Spoon]

PerfectMeta is planned for R3 when we bring in the finger printing technology.

[PepsiCan]

The meaning of the "length" tag as well as the classification of "incomplete" (see post *469 I am still unable to understand exactly.

I'm not sure if it is the answer but perhaps we have been struggling with the same problem. Better to try and fail then not try at all, right?

When DBPowerAmp rips a track, you also have the option to apply DSP. Some of these are destructive. In a different post Spoon explained that before DBA applies the DSP effects, it does the AR check. Only afterwards does it apply the DSP. So, when you do a check with PerfectTunes, the song no longer is accurate because of the DSP. Not all of them are destructive, but the ones marked "Audio CD" in my experience are. When I turned those effects off and re-ripped the CDs (which had hidden tracks and long silences), the subsequent PerfectTunes check no longer returned problems.

I think the incomplete happens for some of the following reasons:
- when you have a corrupt track and therefore the album is incomplete. But that one is obvious to spot as in the log the corrupted file is missing.
- in the case of double CDs inside one folder.
- in the case where the DSP has removed silent tracks

There may be more and it only takes one track missing or too many and you get the message.

Anyway, as I said, I may be way off. Let me know?

[Niko]

The meaning of the "length" tag as well as the classification of "incomplete" ...

Anyway, as I said, I may be way off. Let me know?

Hi,

thank you for evaluating the possible meaning of the two questions above. Let me try to explain what I found out until now and the conclusions thereof:

"length" tag:
In case of uncompressed audio (e.g. WAV), I think this tag does not make any sense. If compressed, there are two possibilities: Audio uncompressed, but data compression active (e.g. FLAC), and audio compressed itself as well (e.g. MP3).

For compressed formats I do not know whether there are binding prescriptions how trailing silence has to be declared. But one way could be to repeat in the length needed the corresponding number of zeros resulting in the track length required. The other way could be to end the track before the zeros, but to add instructions for the audio player that the track is still longer by adding a length tag to the metadata (which is, however, uncommon to WAV).

Assume that the duration of a certain track is shown on a CD cover as 2'36" and the format is FLAC (as if ripped from a CD, but you have bought it as digital file from HDtracks or so). The length tag contains the value 156321. My assumption is (based on the same formula in other similar cases) that this value represents a duration expressed in milliseconds as follows:
-> 2 (min) x 60 (sec) + 36 (sec) = 156 (sec),
-> 156 (sec) x 1000 = 156000 (milliseconds).
Since the CD cover does not indicate the duration more accurate, the idea is that the additional 321 are (further) milliseconds. In case the audio (non-zero) bytes end before that time, this could be an instruction for the audio player that it has to "play silence" until the length of 156321 milliseconds (as from the beginning of the track) is reached, and then wait for the typical 2 seconds which are usually between two tracks (if this is not a gapless CD).

This could possibly make sense but I am still searching for a reliable proof of this assumption.


"incomplete" album:
Firstly, I rip all my CD's in WAV format and do not apply any DSPs.

Further, I preserve the right to rip only a part of a CD, irrespective whether I rip the whole CD first and delete some tracks later on (which I don't want to keep), or whether I rip only the tracks that I want to keep. In both cases, I am aware that the (remaining) tracks do not represent the complete CD, but I still want to know whether such track is still accurate or not.

I have found that "incomplete" is assigned mainly for tracks from compilation CDs. There are many ways how such compilation can be made of, but let us think of typical "Sampler"s, which are yearly published by some "Quality Labels" with each track referring to a different artist. And you may find out that each track is from a separate "original" CD (with it's own album art), and the track number on the original CD will mostly be not the same as the track number on the compilation CD. The following table shows the 3 main possibilities how such CDs may be stored within your music library:
incomplete_tracks_on_compilation_CDs.jpg

The first group (line-wise) shows a CD which has "normal" path and file naming, and the only indication that it is a compilation CD is the compilation tag set to 1, which may enable that in the track title line on the control point the (track-) arist's name is also shown. Further, the album art is the one from the compilation CD (and usually none from the original albums). The track numbers correspond to the compilation CD. This will not result in the classification "incomplete".

The third group is as if each track has been ripped from the original CD. This results in different directories for each track, different album arts etc., and the track numbers will exactly be as if from the original CD. Here the classification "incomplete" may be appropriate, but this disregards whether such tracks are ripped accurately or not. The tag "compilation" should be 0 or absent, which further enhances the idea that only a single track is ripped from each original CD. This needs, however, a great effort for tag editing.

The second group is a mixture of the first and the third group: In the beginning, the whole compilation album is ripped "normally", which leads to path and file naming just as in the first group (and the "folder.jpg" album art remains unchanged). Afterwards, the following tags are edited:
-> the album title is changed to the one of the original album,
-> the track number is changed as if from the original album, and
-> the album art of the original album is applied to each track respectively.
The purpose is to better reference the information of the original CDs, and to enable that the original album art is shown when such a track is played (in the album view the compilation album's art should be shown), and to enable the access to the "more important" ROVI data (in Naim control points app), since background information on the artist and on the original album would usually be more important than the information why such tracks were combined on the compilation album.

And here is the problem that the "incomplete" classification is not appropriate, since the total tracks in the path correspond to the compilation CD, and only the tag contents refer to the original CDs, which would make a difference. But because of the tag "compilation" set to 1 (which will mostly not be the case on the original CDs) the classification "incomplete" could be avoided in such cases.

I do know that there are many different kinds of compilation albums on the market, but the examples as described above could be treated differently (but depends on the relative server-, control point- and/or player capabilities).

[eaglescout1998]

I don't know if this is an actual problem, but it's something that does seem amiss. I am using the most recent beta.

I just scanned my music drive with PerfectTUNES. Out of 126 discs, 8 are not in the AccurateRip database. That should mean that 118 discs ripped accurately (126 - 8 = 118). Yet PerfectTUNES says 125 discs ripped accurately. This does not compute. I've uploaded a screen shot.

Untitled-1.jpg