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: How can I select which offset Cuetools uses when fixing offset? (Read 6680 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

How can I select which offset Cuetools uses when fixing offset?

I've been using Cuetools to fix some offsets on some CD's I incorrectly burned using EAC. It seems I didn't have the offsets set correctly. Cuetools returns several offsets.
I want to select Offsetted by 667 but Cuetools always uses Offset applied 53. I remember the offset of my CDROM was 667. EAC even returns the CRC's from that set when I rip them.
How can I select the Offsetted by 667?
THANKS

Example:
[CUETools log; Date: 1/13/2011 11:07:42 PM; Version: 2.0.9]
Offset applied: 53
[AccurateRip ID: 001f9e48-0160231a-c510650e] found.
Track  [ CRC    ] Status
01    [f2ce0fd8] (4/8) Accurately ripped
02    [cfbe9d1c] (4/8) Accurately ripped
03    [a9983a16] (4/8) Accurately ripped
04    [b3c49538] (4/8) Accurately ripped
05    [05081e72] (4/8) Accurately ripped
06    [ae17f50f] (4/8) Accurately ripped
07    [de8b10d8] (4/8) Accurately ripped
08    [f209f675] (4/8) Accurately ripped
09    [9c7a9c79] (4/8) Accurately ripped
10    [18dadcba] (4/8) Accurately ripped
11    [2d29947d] (4/8) Accurately ripped
12    [11708758] (4/8) Accurately ripped
13    [b4d5f1ce] (4/8) Accurately ripped
14    [7d525813] (4/8) Accurately ripped
Offsetted by 667:
01    [867c20c3] (4/8) Accurately ripped
02    [62a109ec] (4/8) Accurately ripped
03    [1a8fff48] (4/8) Accurately ripped
04    [0fa1c348] (4/8) Accurately ripped
05    [54c3c75a] (4/8) Accurately ripped
06    [5856b00e] (4/8) Accurately ripped
07    [9a5e696f] (4/8) Accurately ripped
08    [57c9e640] (4/8) Accurately ripped
09    [4ad889a3] (4/8) Accurately ripped
10    [139de840] (4/8) Accurately ripped
11    [8f77701c] (4/8) Accurately ripped
12    [6a9f003e] (4/8) Accurately ripped
13    [023a928e] (4/8) Accurately ripped
14    [e5eccb75] (4/8) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] [  LOG  ]
--  99.2 [281B92B1] [D8E185AE]         
01  94.7 [ED7E8A07] [61064F3E]  W/O NULL
02  99.1 [37F815FC] [7C6BB63A]  W/O NULL
03  98.9 [FE7F5C3D] [C9F3BC17]  W/O NULL
04  98.9 [82E948A9] [25F36417]  W/O NULL
05  99.1 [10E6208B] [BCA164C6]  W/O NULL
06  90.4 [C9EEB3E1] [000E1F74]  W/O NULL
07  91.6 [F9AC97A3] [4092E233]  W/O NULL
08  99.2 [71A0BEC3] [C34D3390]  W/O NULL
09  76.6 [8E815141] [910AC62E]  W/O NULL
10  99.2 [4B448DF2] [CED0C8DE]  W/O NULL
11  99.2 [EA6DEDC2] [DFE52E5E]  W/O NULL
12  91.5 [54351649] [C6B3B8E2]  W/O NULL
13  99.2 [73A89282] [C63AD4EB]  W/O NULL
14  99.2 [D08BED00] [5943CB5B]  W/O NULL

How can I select which offset Cuetools uses when fixing offset?

Reply #1 –
Just "encode" with the desired offset in the "offset box", & then recheck. (Don't use "encode"+"fix offset" which automatically fix either to nearest by default or highest if you prefer)

As far as I understand what you did, it seems unlikely that your drive offset was 667, because without any offset Cuetools obviously fixed it to nearest by +53

Quote
Offset applied: 53


So 667+53, unless I am completely wrong, your drive offset was likely +720 if you know it was higher than 53. If you're 100% sure it was 667 then you pressing is not in the database ... anyway as long as all tracks matches within a single offset, fixing offset doesn't matter, so what you did is useless. Except for a few samples shift, in your case, both pressings are identical.

How can I select which offset Cuetools uses when fixing offset?

Reply #2 –
As Kusaywa said, it was ripped without an offset correction using a drive with an offset of -667, which is fairly common.

How can I select which offset Cuetools uses when fixing offset?

Reply #3 –
I think Greynol is maybe right in that the drive offset was negative, so let's say for me it was -720! But anyway doing the math gives me headaches for no gain, so whatever it was it doesn't matter  Sorry, I just don't really care.

How can I select which offset Cuetools uses when fixing offset?

Reply #4 –
You already gave Kusaywa the necessary information for him to correct his files.

There is/was no reason to pay any attention to the pressing with an offset of 53 relative to the files as they were ripped.

How can I select which offset Cuetools uses when fixing offset?

Reply #5 –
THANKS Sauvage78, you did give me the answer I was looking for...

How can I select which offset Cuetools uses when fixing offset?

Reply #6 –
I just verified an album,which was ripped a year ago,with cuetools.

Cuetools gave me this results:

AR: offset -48, rip accurate (38/59), CTDB: verified OK, confidence 19.

What is this offset -48? Is this rip ok?

And in another album:

AR: offset 676, rip accurate (14/14), CTDB: verified OK, confidence 5. (here I am curious why it reported verified ok, because in the log it says that there were errors and also it reported suspicious positions-  how can that rip be accurate?)

What is this offset 676? Is this rip ok?

 

How can I select which offset Cuetools uses when fixing offset?

Reply #7 –
Quote
What is this offset -48?
Likely a different pressing (assuming you ripped this with the proper read offset correction).
Quote
Is this rip ok?
AR: offset -48, rip accurate (38/59), CTDB: verified OK, confidence 19.
Rip is OK and you really don't need to fix the offset.
Quote
What is this offset 676?
Likely a different pressing (assuming you ripped this with the proper read offset correction).
Quote
Is this rip ok?
AR: offset 676, rip accurate (14/14), CTDB: verified OK, confidence 5.
Rip is OK and you really don't need to fix the offset.
Quote
here I am curious why it reported verified ok, because in the log it says that there were errors and also it reported suspicious positions- how can that rip be accurate?
Even if there were problem areas on the disc that could not be read consistently after multiple retries, the final data saved was accurate with both databases. Why complain?
korth