Skip to main content


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: Should I fix offsets even if ripped correctly (Read 443 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Should I fix offsets even if ripped correctly

I have a few CDs from non-famous artists. Some have 1 or 2 entries in the AccurateRip database. And those entries are agree with my rips with an offset of e.g. 667 samples. I am sure my drive offset is set correctly. Now, I suspect there are two reasons:

1. this user did not set their offset correctly (it happens with more famous CD, too, but 1 or 2 incorrect offsets don't matter compared to 200 correct ones)
2. those bands with their low-budget production simply burn the CDs with private CD players which have different offsets which don't agree. We could call that a different "pressing".

My question: Should I (a) keep the FLAC file from my CD as it is or (b) fix the offset by 667 samples to match the one entry in the database.

This is probably a matter of taste but do you have any recommendations or reasons for (a) or (b)?

Best, Michael


Re: Should I fix offsets even if ripped correctly

Reply #1
It is a matter of preference.
AccurateRip ignores the first 2939 and the last 2940 samples of the CD Image.

a) keep it
  • If the rip verifies as accurate even at a different offset, it is accurate, why change it?
  • Fixing the offset will delete samples from one end of the Image and pad null samples to the other
  • If you fix the offset the CRC32 hashes for Image/Tracks will be different than those shown in the extraction log
b) fix it
  • Fixing the offset will remove/pad less than 0.02 seconds of audio (667 samples) from an area of the first/last track that is probably inaudible anyway
  • AccurateRip may show higher numbers at the new offset