Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: AccurateRip v1/v2 verified by CUETools/Foobar2000 (Read 1894 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

AccurateRip v1/v2 verified by CUETools/Foobar2000

I noticed that an apparent ARv1 submission is gone as ARv2 submissions have emerged. Example:

The following is CUETools from five years ago; as of today, all the "(1+0/1)" are replaced by "(0+3/3)" (and fb2k agrees). @spoon , have you ran any purges?

Code: [Select]
[CUETools log; Date: 03.06.2015 07:08:38; Version: 2.1.6]
[AccurateRip ID: 0014c931-00a69f65-8d0cd70a] found.
Track   [  CRC   |   V2   ] Status
 01     [ebd48ce2|b884426c] (1+0/1) Accurately ripped
 02     [2fde232c|de791a0d] (1+0/1) Accurately ripped
 03     [53bc4c6d|d21e8d5d] (1+0/1) Accurately ripped
 04     [1fad689d|48e5d882] (1+0/1) Accurately ripped
 05     [77635632|ea029dde] (1+0/1) Accurately ripped
 06     [8eb323f8|c09bf705] (1+0/1) Accurately ripped
 07     [406f90ff|10037552] (1+0/1) Accurately ripped
 08     [29434c5e|9b1176e3] (1+0/1) Accurately ripped
 09     [74be0fae|9216d0f9] (1+0/1) Accurately ripped
 10     [96029001|8a155b13] (1+0/1) Accurately ripped

Re: AccurateRip v1/v2 verified by CUETools/Foobar2000

Reply #1 –
Possibly in limbo? If there are only 2 submissions and they don't match each other, both are moved to limbo until a new submission matches one of them. The matching submissions are moved into the database while the remaining one (that didn't match) waits in limbo for a matching submission.
korth
 

Re: AccurateRip v1/v2 verified by CUETools/Foobar2000

Reply #2 –
Quote from: korth on
If there are only 2 submissions and they don't match each other

So ARv1 checksums aren't verified behind the scenes by ARv2 rippers?

Say you got three rips, in chronology:
1) Ancient ARv1 submission
2) ARv2-aware application that makes a rip that is bit-identical to #1
3) Different CD with same TOC

... then is it really so mindless that #3 will send either #1 or #2 to limbo?
The only sensible thing to do upon rip #2 which has no ARv2 checksum is to calculate the ARv1 checksum, right?

Re: AccurateRip v1/v2 verified by CUETools/Foobar2000

Reply #3 –
There is something going on here. Another pair:

CUETools 2015:
Code: [Select]
[AccurateRip ID: 000bb5bf-004eb8a3-6308de08] found.
Track   [  CRC   |   V2   ] Status
 01     [dd4df72d|19b42014] (1+1/2) Accurately ripped
 02     [a69c257b|a88cd0b4] (1+0/2) Accurately ripped
 03     [2e5a207b|9385ba5f] (1+1/2) Accurately ripped
 04     [5fc1c62f|cd0c84e8] (1+1/2) Accurately ripped
 05     [016d444e|999374ca] (1+1/2) Accurately ripped
 06     [982765b5|f1f0b335] (1+1/2) Accurately ripped
 07     [da01eb81|d83e4297] (1+1/2) Accurately ripped
 08     [8db95720|c13f6e55] (1+1/2) Accurately ripped

CUETools 2020:
Code: [Select]
[AccurateRip ID: 000bb5bf-004eb8a3-6308de08] found.
Track   [  CRC   |   V2   ] Status
 01     [dd4df72d|19b42014] (0+3/3) Accurately ripped
 02     [a69c257b|a88cd0b4] (0+2/2) Accurately ripped
 03     [2e5a207b|9385ba5f] (0+3/3) Accurately ripped
 04     [5fc1c62f|cd0c84e8] (0+3/3) Accurately ripped
 05     [016d444e|999374ca] (0+3/3) Accurately ripped
 06     [982765b5|f1f0b335] (0+3/3) Accurately ripped
 07     [da01eb81|d83e4297] (0+3/3) Accurately ripped
 08     [8db95720|c13f6e55] (0+3/3) Accurately ripped

(CTDB confirms that out there there is one misrip of track 2.)

Re: AccurateRip v1/v2 verified by CUETools/Foobar2000

Reply #4 –
As I understand things, there are still people using older versions of programs (e.g. EAC before v1beta1) that will submit ARv1 but AFAIK current rippers only submit ARv2.
https://hydrogenaud.io/index.php?msg=677414
https://hydrogenaud.io/index.php?msg=769261
From what I've read, my understanding is that the AccurateRip server collects the submitted checksums and compares to what already exists (if any). I haven't read anything to suggest the server can convert ARv2 checksums to ARv1 or vice-versa. To my knowledge, if there is only one ARv1 checksum, it will go into the active database. If there was only one ARv2 checksum, it will go into the active database. If there is more than one ARv1 checksum for any track, unconfirmed (confidence 1) ARv1 checksums for that track are removed from the active database to await confirmation by additional rips. If there is more than one ARv2 checksum for any track, unconfirmed (confidence 1) ARv2 checksums for that track are removed from the active database to await confirmation by additional rips.

In your 2nd set of log examples, based on the numbers I may assume that there is one ARv2 checksum in limbo for track 2 and 2 full sets of ARv1 checksums may also be in limbo.
But I can only assume what happened to the ARv1 entries that no longer exist in the active database for log example set #1 or log example set #2.
The ARv1 submissions could also be removed for other reasons.
https://hydrogenaud.io/index.php?msg=721732
https://hydrogenaud.io/index.php?msg=652779
korth