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: Read offset – does it change the audio data in any way? (Read 3793 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Read offset – does it change the audio data in any way?

Hello there,

I just ripped a CD with EAC, but did not detect the read offset of my drive beforehand. When I compared the rip against the AccurateRip database, I got the following:

Code: [Select]
Track    [ CRC    ] Status
01    [ea975652] (00/02) No matches
02    [1cae96c1] (00/02) No matches
03    [7857410c] (00/02) No matches
04    [242f628f] (00/02) No matches

Offseted by -1273:
01    [372dafb5] (02/02) Accurately ripped as in pressing(s) #1
02    [89fd5e7b] (02/02) Accurately ripped as in pressing(s) #1
03    [118074d1] (02/02) Accurately ripped as in pressing(s) #1
04    [35ce7ea0] (02/02) Partial match to pressing(s) #1


What I'm wondering is whether the tracks are altered in any way and are they going to be different if the offset was fixed.

Read offset – does it change the audio data in any way?

Reply #1
I am no expert in any way but I can tell you this, if you compare the CRC of the audio wave only it will give you two different codes, with and without the correct CD Read Offset. So yes, even if inaudible or incomparable without a CRC checker, there is a difference. It does make difference only if you want a perfect lossless copy.

Read offset – does it change the audio data in any way?

Reply #2
Each track will start and end 29 milliseconds earlier or later with that amount of offset. Does that matter to you?

Read offset – does it change the audio data in any way?

Reply #3
Each track will start and end 29 milliseconds earlier or later with that amount of offset. Does that matter to you?

Again, don't mean to be rude but I don't think you quite get the definition of perfect.

Read offset – does it change the audio data in any way?

Reply #4
I wouldn't be so quick to assume that compliance with a semi-arbitrarily chosen reference equates to perfection.

Read offset – does it change the audio data in any way?

Reply #5
I wouldn't be so quick to assume that compliance with an semi-arbitrarily chosen reference equates to perfection.

I wasn't referring to the Read Offset quote but to the "does that matter to you?" quote. Of course the difference between perfection and bad rip sometimes is almost so irrelevant that no one can hear the difference and it almost doesn't even matter, but what the purpose of a forum like this one would be is perfection doesn't matter?

Just that, an off topic line to remember that users like me come here to learn how perfectly rip and burn tracks from originals.

Read offset – does it change the audio data in any way?

Reply #6
Then I will assume that knowing that nailing a track down to a semi-arbitrarily chosen standard does not make it any more or less perfect than nailing it down to some other semi-arbitrarily chosen standard might also matter to users who seem to be expecting black and white answers.

Read offset – does it change the audio data in any way?

Reply #7
eahm,

The problem is that there is no universally agreed upon starting point – just look at the large number of different offset values. Furthermore, there is a similar divergence among burners – both consumer equipment and mastering equipment. Unless you know the original files, you cannot know anything such as 'the right value'.


Read offset – does it change the audio data in any way?

Reply #9
Not to mention that the reference offset is 30 samples off! Just throwing that out there.

This relieves me, I get the "consumer part" of the music industry is still evolving and learning. I thought there were more "standards".

I don't want to be unrespectful to anyone, I have the hunger of the newbie.

Read offset – does it change the audio data in any way?

Reply #10
Since I just realised that no one has stated it explicitly: No, an offset does not change the audio data that is ripped.

An offset changes, by some tiny amount, where your drive begins and finishes reading the CD—and therefore precisely which portion of said data you end up with and how accurate any track times are—but it does not change the data between those points. At worst, a tiny number of samples are missed from the very beginning or ending of the CD (not of every track). As others have suggested, the degree to which one need worry about such a minuscule loss of audio (which is probably silent or otherwise content-free anyway) or difference in timing is up to the individual and/or up for debate. In any case, no samples are altered in the data that is retrieved.

Read offset – does it change the audio data in any way?

Reply #11
[db1989's reply to the OP came through as I was typing this one, so I'm just repeating what he said...]

Dario, the audio samples in your rip are all just very slightly shifted forward or backward in time, relative to where they are on the disc. This means the track boundaries are all slightly "off", but CDs aren't manufactured with precise boundaries anyway (different batches can have different offsets), and players aren't designed to seek with perfect precision either. So no, the audio isn't different at all, save for a very tiny margin of error at the very beginning and end of the disc, which is normally pure silence anyway, and those areas aren't even checked by AccurateRip at all, so it doesn't matter.

We are now fairly certain that the offset correction reference isn't actually right, so applying offset correction still doesn't get your track boundaries to perfectly match how they're mastered on the original CD. No one cares, really; they just want to know that the main body of audio data matches what other people got. The AccurateRip check you did with CUETools reveals that your rip matches 2 others, so it's fine.

Also, if your drive can't "overread", then by ripping without offset correction, you've actually got all the samples that the drive can reach. If you had ripped with correction, you'd be discarding some of those samples and filling them in with silence...which is probably all they were anyway...but just in terms of completeness, it's better to rip without correction on such drives. As you can see, it's a trade-off...do you want as many samples as possible to be read from the original CD (affecting a split-second at the beginning/end of the disc), or do you want the track boundaries to be better synchronized with those of the original CD (but still not quite perfect)?


Read offset – does it change the audio data in any way?

Reply #13
The AccurateRip check you did with CUETools reveals that your rip matches 2 others, so it's fine.

Three of the the four tracks, anyway.

In case anyone is wondering, fixing the offset is not going to make the fourth track match the other submissions.

Read offset – does it change the audio data in any way?

Reply #14
Well, I just remembered that in the log I had the CTDB plug-in saying that my rip was different by around 150 samples. I used CUETools to split it in multiple tracks and also repaired the rip. Now I get this

Code: [Select]
Track    [ CRC    ] Status
01    [ea975652] (00/02) No matches
02    [1cae96c1] (00/02) No matches
03    [7857410c] (00/02) No matches
04    [f5463c6e] (00/02) No matches
Offseted by -1273:
01    [372dafb5] (02/02) Accurately ripped as in pressing(s) #1
02    [89fd5e7b] (02/02) Accurately ripped as in pressing(s) #1
03    [118074d1] (02/02) Accurately ripped as in pressing(s) #1
04    [6531b6fa] (02/02) Accurately ripped as in pressing(s) #1

Track    [ CRC32  ]    [W/O NULL]
01    [906310BE]    [229B905F]
02    [1793204D]    [7DA3B8A4]
03    [19767234]    [2E6B40E9]
04    [A9A8472D]    [064BC97C]

so I believe that everything is fine. The fact that the rip in the AccurateRip database is offseted a bit could be because of different pressings, right? Because the album I ripped is a recent re-issue.

Thanks a lot guys, you are awesome.