greynol

Ah, now I understand where you were coming from.

I would normally have used micro, but I thought 1,000,000 might be more tangible for those who don't know the exact meaning of the term micro. Maybe this has something to do with the fact that I come from a country that uses the English system of weights and measures.

Bytemastr

Sorry for being prickly but...

Maybe 'til this is definitely resolved EAC should be renamed to KEAC or SEAC Kinda Exact Audio Copy or Somewhat Exact Audio Copy?

A lot of people use this software because they think that if they follow the prescribed steps and have proper hardware, they're getting every last sample there is to get.

Since that's not the case, this discussion and the fact that you somewhat concede this is the case (or could very well be the case) more publicly in the EAC documentation.

greynol

As I have already stated, in some instances it is not possible, though in most instances it is. In either case and with extremely rare exceptions, the position of the reference is irrelevant.

Do you have anything useful to say, or are you just being an idiot troll?

Bytemastr

I do not think calling people names or casting aspersions puts your opinion(s) in the best light regardless of your standing on this particular forum; I don't see where you have provided any relevant output to this topic other than to say in many different ways "don't worry about it, this is trivial."

As I stated, I didn't mean to be a prick, but I think my point was valid insofar as people take the name "Exact Audio Copy" to mean exactly what it implies. The whole franchise of this program was to address the shortcomings of the other rippers and their methodologies and to account for as much hardware shortcomings as possible; To overlook this and say "it isn't important," or in your case to simply flame those who do not agree goes against the nature of what EAC tried to compensate for.

I went back over this thread a third time and found you doing nothing but expressing your opinion (and not being flamed for it, I might add) without a fraction as much data as the original poster did (which like I said Andre concedes may very well be correct).

Just because you want to regurgitate the same tired specs over and over to attempt to prove your assertion/opinion that this isn't a problem or doesn't fall under the whole premise of why EAC was conceived doesn't make the original claim any less valid.

In the meantime, I'd work on your people skills insofar as how you engage people, because it's highly unlikely you deal with people face to face like you did here with me.

I will not justify any of your future postings to me on this subject with a response.

greynol

Then remain clueless; that's fine with me. :-P

Anyhow, there is absolutely nothing stopping you from subtracting 30 from your offset correction and write samples offset. ;-)

Andre Wiethoff

I think I will now close this topic with some closing remarks:

- No program will ever exactly copy an audio CD (including all subchannels, TOC, CD-Text, pregaps and so on). This is technically not possible (but perhaps special (hardware only) CD copier)
- There is no "correct" read offset, even the second proposed offset is only proposed, there is no real "proof" that it is correct. I just believe it could be correct. Does it make that offset better than the first - I don't think so.
- Offset correction does really only matter as a combined offset. If you use a "bad" read offset, only some samples(!) (around 0,0006 seconds) of audio from the very beginning or the very end of a CD will be "wrong" (and only if there is no silence in that area, otherwise the copy _will_ be correct!)
- It is much more probable that your reader has more limitations that this, so a real exact copy would not be possible anyway (with a very high probability), so I don't think that we should care about 30 samples.
- Using the AccurateRip compatible offset has more advantages than disadvantages, perhaps(!) it will remove 0.0006 seconds of audio at the beginning of a CD, but it is able to tell you (with a probability) whether you ripped your track in burst mode ok or not...

As I said, I think most opinions here come from believe! Nothing is really proofed and the small offset is not really important (as there is no problem to use the correct combined offset).

Finally, this topic is closed!

cu, Andre