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: CUETools Report - differents offsets (Read 1303 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

CUETools Report - differents offsets

Hello,

what does this CUETools report mean:

[AccurateRip ID: 002a63a6-02215b41-e110a711] found.
Track  [  CRC  |  V2  ] Status
01    [fc8518ad|62cc8270] (0+1/3) Accurately ripped
02    [ec2969c2|604a7bc5] (1+1/3) Accurately ripped
03    [7436c63a|6b8fe099] (1+1/3) Accurately ripped
04    [7e14fffe|21ffe43d] (1+1/3) Accurately ripped
05    [4cb3de15|180a7cf3] (1+1/3) Accurately ripped
06    [b4c91c7c|b97d5501] (1+1/3) Accurately ripped
07    [02e0a296|07d92f22] (1+1/3) Accurately ripped
08    [73237203|582083bb] (1+1/3) Accurately ripped
09    [0f17c6ec|b26a14dc] (1+1/3) Accurately ripped
10    [71d21280|9131a101] (1+1/3) Accurately ripped
11    [aeb5107b|2aa60148] (1+1/3) Accurately ripped
12    [af50a7c5|55d82be7] (1+1/3) Accurately ripped
13    [43fc5dd0|76a7d461] (1+1/3) Accurately ripped
14    [4dc5622f|19c61a57] (1+1/3) Accurately ripped
15    [3aa6b527|97706f6e] (1+1/3) Accurately ripped
16    [cddb9113|d3806823] (1+1/3) Accurately ripped
17    [c1ee4dab|37c70e4d] (1+1/3) Accurately ripped
Offsetted by -687:
01    [99018a66] (1/3) Accurately ripped
02    [5e4905b2] (1/3) Accurately ripped
03    [dcc18dfc] (1/3) Accurately ripped
04    [3acc5b5f] (1/3) Accurately ripped
05    [c6c06d62] (1/3) Accurately ripped
06    [8629e03a] (1/3) Accurately ripped
07    [b6463b18] (1/3) Accurately ripped
08    [273edd55] (1/3) Accurately ripped
09    [36be4a07] (1/3) Accurately ripped
10    [d4f0e552] (1/3) Accurately ripped
11    [ab93890f] (1/3) Accurately ripped
12    [0841175d] (1/3) Accurately ripped
13    [b99420e0] (1/3) Accurately ripped
14    [511a5225] (1/3) Accurately ripped
15    [bb640e2d] (1/3) Accurately ripped
16    [3846ac7d] (1/3) Accurately ripped
17    [34a244c4] (1/3) Accurately ripped


What means the first part of the report? Matches in V1 and V2.
But what means the second part with the topic: Offsetted by -687  ?


CUETools Report - differents offsets

Reply #2
http://cuetools.net/wiki/CUETools_log

I read it but still don´t understand.

There stands:
The first set of tracks listed are for this disc at zero offset ('zero' after any read offset correction was applied). Alternate database records listed below this set show 'Offsetted by xxx' that indicates the offset difference from the current 'zero' offset of this disc.

What means zero after any read offset correction was applied?
I have an Offset of 512.

I thought everybody who takes part in accurate rip has applied offset correction first.
So it doesn´t matter what offset one has.
So how can there be an entry with a deviating offset?

In dbpoweramp forum they told me it is another pressing.
That would mean the Laser starts at the same position, but because its another pressing, the distance to the data is different.
This difference is the deviance (the offset that deviates from zero)

right?

CUETools Report - differents offsets

Reply #3
The first section is saying that after ripping and applying offset correction, your audio data matched 1 rip in the ARv1 database (except for track 1), and it matched 1 rip in the ARv2 database. The second section is saying that your audio data also matched 1 rip that has all the samples shifted by 687 in one direction.

That person's CD is probably a different pressing than yours. Or it could be that someone ripped a CD-R copy, or the disc is the same as yours but the user entered a bad offset correction value in their ripper.

CUETools Report - differents offsets

Reply #4
Ok Thanks !


One question else:
I got this report:

Track [ CRC | V2 ] Status
01 [acd9b3d6|0ac7e965] (007+000/528) Accurately ripped
02 [850d250b|933e9659] (007+002/525) Accurately ripped
03 [b4de8534|094e71f1] (007+002/529) Accurately ripped
04 [5a99b657|47f4559c] (007+002/528) Accurately ripped
05 [485d6950|3e13582d] (007+002/527) Accurately ripped
06 [8eb638c9|7cece9c4] (007+002/526) Accurately ripped
07 [29e8ad91|d06060b9] (007+002/527) Accurately ripped
08 [7bb71b0b|6876b98c] (007+002/525) Accurately ripped
09 [37beaf95|5112dfa5] (007+002/527) Accurately ripped
10 [9260d49c|191b3fc9] (007+002/527) Accurately ripped
11 [13ecd9d8|7ad0ecf8] (007+002/523) Accurately ripped
12 [3ed6c94f|ffe3d788] (006+002/527) Accurately ripped

1)
Why do I only have 7+2 matches of over 500 ?
In DBPoweramp Forum they told me, its probably a different pressing!
So different pressings can appear with another offset or also with offset 0  ?

2)
It was said, that AR only works with a correct offset.
When I match rips with other offsets, how does the database know that it is the same audio data but another offset?
So why is offset correction necessery at all, when only checksums of the audio data are compared?
When I get matches with other ofsettet rips, than offset shifts are redundant!

CUETools Report - differents offsets

Reply #5
1) There's no simple answer why the pressing of the CD you have was only ripped by 9 others so far. A match is a match. Be happy.

Alternate pressings would be at different offsets. Your pressing would be without offset, 'neutral' or 'zero' if the software corrected for the hardware's read offset.

2) There are quite a few threads here and at dbpoweramp about AccurateRip and how it works. Please try searching. You can also do some reading at HAK.
korth

 
SimplePortal 1.0.0 RC1 © 2008-2021