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?
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.
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 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.
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?)
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.
I don't care if the difference is small, it
is different and I want the track boundaries to be
correct. ???
From CueTools documentation (http://cue.tools/wiki/CUETools_Settings#.2811.29_Extra_.7Bsection.7D):
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:
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?
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:
[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:
[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.
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.