PerfectTUNES R2 discussion

[Spoon]

Re: PerfectTUNES R2 discussion

Please zip up the PerfectTUNES folder in:

%appdata%

and either email:

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

or send a link to the updated files on dropbox or similar if too large for email.

[eaglescout1998]

Re: PerfectTUNES R2 discussion

No change in behavior.

[Spoon]

Re: PerfectTUNES R2 discussion

Try to do the 'Clear Database Cache' button on the main PerfectTUNES program. It could be caching the results from an older release.

[eaglescout1998]

Re: PerfectTUNES R2 discussion

I have ripped more albums in the time since I posted. The count is now at 164 total albums, with 22 not present in the database. PerfectTUNES reports 163 album accurately ripped. However, I can confirm that all but one of these 22 albums also appear in the "Accurately Ripped" list. When I counted only those albums that were Accurate, I got 142.

[Spoon]

Re: PerfectTUNES R2 discussion

Manually count the albums on Accurate Page and Cannot check page, see if the cannot check items are not present on the Accurate page.

[eaglescout1998]

Re: PerfectTUNES R2 discussion

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.

[Niko]

Re: PerfectTUNES R2 discussion

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:


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

[PepsiCan]

Re: PerfectTUNES R2 discussion

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?

[Spoon]

Re: PerfectTUNES R2 discussion

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

[Niko]

Re: PerfectTUNES R2 discussion

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.

[Niko]

Re: PerfectTUNES R2 discussion

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:


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.

[PepsiCan]

Re: PerfectTUNES R2 discussion

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]

Re: PerfectTUNES R2 discussion

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]

Re: PerfectTUNES R2 discussion

Hi

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

https://forum.dbpoweramp.com/showthread.php?36245-Use-quot-accurateripresult-from-ID-tag-quot

[PepsiCan]

Re: PerfectTUNES R2 discussion

- 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?