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: Manually fixing a rip offset (Read 3334 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Manually fixing a rip offset

I have a rip (one file per track), with the corresponding EAC log, and the drive offset hadn't been configured...
Thus, I would like to manually fix the offset of this rip, using CueTools.

The rip is found in CTDB, but not in AccurateRip (whether offsetted or not).
So, I won't be able to check if I fixed the offset in "the good direction".

The drive is a Pionner DVR-109, according to online databases, drive offset is +48.
I know the procedure is to do "Action > Encode (dropdown Default)", manually inputting the offset in "Extra > Offset".

Finally, here's my question is: should I put -48 or +48 in the box?

Re: Manually fixing a rip offset

Reply #1
Why bother fixing the offset? CTDB doesn't need the offset and you say the rip is "not present in the AccurateRip database" so what do you expect to gain?
You can verify a rip in the AccurateRip database at an offset by entering the value in that "Extra > Offset" box without modifying files.

You would enter 48.
korth

 

Re: Manually fixing a rip offset

Reply #2
I want the tracks to be perfectly cut where they should be.

(to illustrate, you know, when starting a track you hear some "click" from the previous track...)

Re: Manually fixing a rip offset

Reply #3
I want the tracks to be perfectly cut where they should be.

(to illustrate, you know, when starting a track you hear some "click" from the previous track...)

I'm not quite sure a simple offset would introduce such artefacts in an otherwise completely perfectly ripped audio CD . To wit, note that when different batches of what is supposedly the same CD are pressed at different locations or at different times, quite often the different pressings are offset with respect to each other but are otherwise identical, so your case is analogous to such a situation.

EDIT: clarification.
Lossless: flac --best --verify
Lossy: opusenc --bitrate 160

Re: Manually fixing a rip offset

Reply #4
I'm not quite sure a simple offset would introduce such artefacts in an otherwise completely perfectly ripped audio CD [...]

... and the rest of what you point out, means that if the track boundary is so way off as to be audible, the offset issue could be when the master was produced, rather than when the CD was ripped (and +48 samples @1/44100 seconds won't be that much, eh?)



Re: Manually fixing a rip offset

Reply #5
I'm not quite sure a simple offset would introduce such artefacts in an otherwise completely perfectly ripped audio CD [...]

... and the rest of what you point out, means that if the track boundary is so way off as to be audible, the offset issue could be when the master was produced, rather than when the CD was ripped (and +48 samples @1/44100 seconds won't be that much, eh?)

Yeah, I mean, when AccurateRip tells me there's a partial match because my copy has a constant offset throughout all tracks, I often don't even bother with it. It's as if I had a different pressing, that's all.
Lossless: flac --best --verify
Lossy: opusenc --bitrate 160

Re: Manually fixing a rip offset

Reply #6
I don't care if the difference is small, it is different and I want the track boundaries to be correct. ???

From CueTools documentation:
Quote
Offset {textbox}
    Offset, in samples, to apply when encoding or verifying. This value should be 0 unless you need to shift the audio in a rip that, for example, was made with an incorrect read offset correction. A positive value here will shift the audio backward (or, you can think of it as shifting the track boundaries forward) by that many samples. This will result in some samples being truncated from one end of the file and null samples added to the other end, to preserve the overall length.

from Documentation\EAC.txt:
Quote
The Plextor 14/32 has an offset value of +679 samples, which means that
679 samples usually are missing at the end of a WAV file.

So, to fix my rip I would have to input +48 in CueTools, as korth also said. Do you people confirm?

Re: Manually fixing a rip offset

Reply #7
Ok, I have fixed it by manually applying offset 48. (to confirm, I tried both -48 and +48)

Interestingly enough, AccurateRip wasn't matching with the "bad" rip, even offsetted:
Code: [Select]
[AccurateRip ID: 0010dc8f-00a07b17-ac093e0c] found.
Track   [  CRC   |   V2   ] Status
 01     [6ad7d846|1b70bc01] (0+0/4) No match
 02     [f610bde3|308faad8] (0+0/4) No match
...
 11     [d5ec9590|b84a3f4a] (0+0/4) No match
 12     [249d0cdf|b9977aa8] (0+0/4) No match
Offsetted by 48:
 01     [6ee04315] (0/4) No match (V2 was not tested)
 02     [1d194b33] (0/4) No match (V2 was not tested)
 ...
 11     [398b030b] (0/4) No match (V2 was not tested)
 12     [49eba09b] (0/4) No match (V2 was not tested)
... but with my "fixed" rip, it did match:
Code: [Select]
[AccurateRip ID: 0010dc8f-00a07b17-ac093e0c] found.
Track   [  CRC   |   V2   ] Status
 01     [6ee04315|1588843b] (0+4/4) Accurately ripped
 02     [1d194b33|4f97edd0] (0+4/4) Accurately ripped
...
 11     [398b030b|1d5aaa94] (0+4/4) Accurately ripped
 12     [49eba09b|df7b53d6] (0+4/4) Accurately ripped
(also, before verifying, I try with removing EAC log files, etc. from the folders, to not "hint" CueTools)

Long story short, my rip is fixed and I'm happy.

Re: Manually fixing a rip offset

Reply #8
Interestingly enough, AccurateRip wasn't matching with the "bad" rip, even offsetted
It's because with your "fixed" rip cuetools tested with accuraterip v2 while your "bad" rip was not tested. The second digit "4" in "(0+4/4)" is ar v2 and the first digit "0" is ar v1.