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 Verify & Offsets (Read 2690 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

AccurateRip Verify & Offsets

I noticed that occasionally Foobar reports that AccurateRip matches with offsets, as shown below;
Code: [Select]
1 out of 1 tracks converted with minor problems.

Source: "cdda://01E363E3"
  Audio CD extraction setup: drive: "HL-DT-ST - DVD+-RW GU90N", sample offset: 102, security: standard
  Destination: "C:\FLAC Audio\Image.flac"
  Track converted successfully.
  AccurateRip status:
  Track  Status
  01     Not accurate - partial match with offset: 0(10).
  02     Not accurate - partial match with offset: 0(9).
  03     Not accurate - partial match with offset: 0(9).
  04     Not accurate - partial match with offset: 0(9).
  05     Not accurate - partial match with offset: 0(10).
  06     Not accurate - partial match with offset: 0(9).
  07     Not accurate - partial match with offset: 0(10).
  08     Not accurate - partial match with offset: 0(10).
  09     Not accurate - partial match with offset: 0(9).
  10     Not accurate - partial match with offset: 0(10).
  11     Not accurate - partial match with offset: 0(9).
  12     Not accurate - partial match with offset: 0(9).
  13     Not accurate - partial match with offset: 0(9).
  14     Not accurate - partial match with offset: 0(8).

So I ran a CUETools verification on the above Foobar ripped image file and CUETools reports there is only a perfect matched record reported by AccurateRip;
Code: [Select]
[CUETools log; Date: 25/08/2019 8:06:12 PM; Version: 2.1.6]
[CTDB TOCID: S5osyzyotSZ5hKIkD9sQeed7bNg-] found.
Track | CTDB Status
  1   | (15/15) Accurately ripped
  2   | (15/15) Accurately ripped
  3   | (15/15) Accurately ripped
  4   | (15/15) Accurately ripped
  5   | (15/15) Accurately ripped
  6   | (15/15) Accurately ripped
  7   | (15/15) Accurately ripped
  8   | (15/15) Accurately ripped
  9   | (15/15) Accurately ripped
 10   | (15/15) Accurately ripped
 11   | (15/15) Accurately ripped
 12   | (15/15) Accurately ripped
 13   | (15/15) Accurately ripped
 14   | (15/15) Accurately ripped
[AccurateRip ID: 0026c5e9-019f2429-ba12140e] found.
Track   [  CRC   |   V2   ] Status
 01     [cdabf0ee|4413a53b] (00+10/10) Accurately ripped
 02     [3aa572af|b9f33d18] (00+09/09) Accurately ripped
 03     [522d9ca0|e95c528a] (00+09/09) Accurately ripped
 04     [bda46749|9549d248] (00+09/09) Accurately ripped
 05     [07b0c58f|e8247569] (00+10/10) Accurately ripped
 06     [b0b4b66c|d42f890b] (00+09/09) Accurately ripped
 07     [2cf756dc|9759f41b] (00+10/10) Accurately ripped
 08     [37f27e80|f55df8c6] (00+10/10) Accurately ripped
 09     [d230ef7b|d531cdab] (00+09/09) Accurately ripped
 10     [929b399d|3ae26767] (00+10/10) Accurately ripped
 11     [42e96727|24897266] (00+09/09) Accurately ripped
 12     [3cf579d9|2feb73a2] (00+09/09) Accurately ripped
 13     [c405808b|2ffe41a1] (00+09/09) Accurately ripped
 14     [974170d1|9137cb6d] (00+08/08) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] 
 --  100.0 [675BAD61] [760A8882]           
 01  100.0 [B1C99431] [6A893290]           
 02  100.0 [262E4221] [F3E6C4C5]           
 03  100.0 [045A09C0] [EF7614D4]           
 04  100.0 [1608E81A] [87A25742]           
 05  100.0 [8172770A] [B9CA62C9]           
 06  100.0 [9FD69B01] [D1D9DF2A]           
 07  100.0 [B17EE914] [5C9FD322]  

I'm wondering why Foobar believes there is a match with sample offset when the much more detailed CUETools log doesn't report any offset adjustment in this particular pressing? When there is an offset CUETools states this in the log, something like, "Offsetted by XXX" but as you can see from the log there is no offsetted result

http://cue.tools/wiki/CUETools_log

Re: AccurateRip Verify & Offsets

Reply #1 –
CueTools supports AccurateRip V2. foo_verifier - doesn't support AccurateRip V2. And in CueTools log you can see that results for this disc are only in V2.

Quote from: westgroveg on
When there is an offset CUETools states this in the log, something like, "Offsetted by XXX"
It only do this for V1.

Re: AccurateRip Verify & Offsets

Reply #2 –
Quote from: Rollin on
CueTools supports AccurateRip V2. foo_verifier - doesn't support AccurateRip V2. And in CueTools log you can see that results for this disc are only in V2.

Quote from: westgroveg on
When there is an offset CUETools states this in the log, something like, "Offsetted by XXX"
It only do this for V1.
But Foobar IS showing results for AccurateRip V2 with an offset of "0", Foobar is showing the exact same number of results as CueTools AR V2
 

Re: AccurateRip Verify & Offsets

Reply #3 –
Maybe I'm misunderstanding the output;
Code: [Select]
Not accurate - partial match with offset: 0(10)

Does this mean that the track offset had to be adjusted for an accurate match? Or does it mean that it could only find AR V2 results thus it's a "partial" match?

I guess the latter would make most sense given the context, but the "with offset" part makes it confusing

Re: AccurateRip Verify & Offsets

Reply #4 –
Okay so here is another result:
Code: [Select]
1 out of 1 tracks converted with minor problems.

Source: "cdda://00F14D15"
  Audio CD extraction setup: drive: "HL-DT-ST - DVD+-RW GU90N", sample offset: 102, security: standard
  Destination: "C:\FLAC Audio\Image.flac"
  Track converted successfully.
  AccurateRip status:
  Track  Status
  01     Accurately ripped with offsets: 98(3), 98(2).
  02     Accurately ripped with offsets: 98(3), 98(2).
  03     Accurately ripped with offsets: 98(3), 98(2).
  04     Accurately ripped with offsets: 98(3), 98(2).
  05     Accurately ripped with offsets: 98(3), 98(2).
  06     Accurately ripped with offsets: 98(3), 98(2).
  07     Accurately ripped with offsets: 98(3), 98(2).
  08     Accurately ripped with offsets: 98(3), 98(2).
  09     Accurately ripped with offsets: 98(3), 98(2).
  10     Accurately ripped with offsets: 98(3), 98(2).
  11     Accurately ripped with offsets: 98(3), 98(2).
  12     Accurately ripped with offsets: 98(3), 98(2).
  13     Accurately ripped with offsets: 98(3), 98(2).


And CUE Tools;
Code: [Select]
[CUETools log; Date: 29/08/2019 9:28:24 PM; Version: 2.1.6]
Pregap length 00:00:32.
[CTDB TOCID: XIova9VCDLDLD3Gb5qhGwDYNwQ8-] found.
Track | CTDB Status
  1   | (18/18) Accurately ripped
  2   | (18/18) Accurately ripped
  3   | (18/18) Accurately ripped
  4   | (18/18) Accurately ripped
  5   | (18/18) Accurately ripped
  6   | (18/18) Accurately ripped
  7   | (18/18) Accurately ripped
  8   | (18/18) Accurately ripped
  9   | (18/18) Accurately ripped
 10   | (18/18) Accurately ripped
 11   | (16/18) Accurately ripped
 12   | (17/18) Accurately ripped
 13   | (16/18) Accurately ripped
[AccurateRip ID: 0013c543-00c9b923-970a030d] found.
Track   [  CRC   |   V2   ] Status
 01     [e4473d13|da68e459] (0+0/5) No match
 02     [b436dbe6|97f69215] (0+0/5) No match
 03     [c28ea9f7|14c4fdf6] (0+0/5) No match
 04     [426165a6|1a6c1eb3] (0+0/5) No match
 05     [33348d46|76aac582] (0+0/5) No match
 06     [adeb7052|0bddd5a0] (0+0/5) No match
 07     [8671128c|bdebb1bd] (0+0/5) No match
 08     [d7e96ce8|2c9cc6a2] (0+0/5) No match
 09     [a1f5ccaf|62dd01c2] (0+0/5) No match
 10     [8efb4a0c|b10311a5] (0+0/5) No match
 11     [547eb142|ce83c104] (0+0/5) No match
 12     [a1c39ecb|8e91f5ed] (0+0/5) No match
 13     [6f1e44e8|8312a4da] (0+0/5) No match
Offsetted by 98:
 01     [f7d6b1a3] (2/5) Accurately ripped
 02     [ddd799b8] (2/5) Accurately ripped
 03     [101cecca] (2/5) Accurately ripped
 04     [0f08e5c8] (2/5) Accurately ripped
 05     [fe9ee124] (2/5) Accurately ripped
 06     [34272c9e] (2/5) Accurately ripped
 07     [96268b56] (2/5) Accurately ripped
 08     [07f23f44] (2/5) Accurately ripped
 09     [4892a627] (2/5) Accurately ripped
 10     [18f76d9e] (2/5) Accurately ripped
 11     [d08fad34] (2/5) Accurately ripped
 12     [a5de67c0] (2/5) Accurately ripped
 13     [5bffc7ee] (2/5) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] 
 --  100.0 [AB2EFA68] [96AA4990]           
 01  100.0 [8D1C52FB] [414E3494]           
 02  100.0 [2351810C] [688A1143]           
 03  100.0 [A4E4F1DC] [7397FB10]           
 04  100.0 [8AF2F9D9] [46ADE079]           
 05  100.0 [F7D4F023] [85662DB8]           
 06  100.0 [28CA65CF] [B0E8D3A3]           
 07  100.0 [C86B3C7A] [9EFE8592]           
 08  100.0 [4816EC40] [33D46DCF]           
 09  100.0 [03CF1481] [791025FB]           
 10  100.0 [8E169FFE] [93E82F66]           
 11  100.0 [1511DD8F] [77C6F26D]           
 12  100.0 [1FCB45C8] [0404B392]           
 13  100.0 [2488D3C0] [4693AA2D]

So something like this in Foobar;
Accurately ripped with offsets: 98(3), 98(2).

Means Foobar found 3 ARv2 results with an offset of 98 and 2 ARv1 results with an offset of 98

The reason CUE Tools shows 2/5 for an offset of 98 is because "ARv2 is only tested at zero offset"


I still don't get why Foobar  stated "Not accurate - partial match with offset" in the original log I posted, seems like a bug, offset adjustment was not needed for a match and ARv2 should be considered accurate