so I am now going to have to re-rip all my 135cd's!!??

Yes, but you'll need to figure out if it's really 135cd's. It could be 105cd's...or...maybe 165cd's!



-brendan

I'm still a little undecided about the whole thing. I know that using either way i'll end up burning back the same data. I know from looking at the files that 30 samples is completely unimportant and there's a good chance that 100% of those samples will be null for every cd. Considering all the work people have put in to get Andre's offset right, it would be impossible to ask everyone to bump their data 30 samples. Still if I get anything out of this, I can at least fix people's offset who never used one to begin with. It's in this case that it might be important to check for missing samples, but after looking at the ridiculous amount of null samples in the hex editor, I might not even need to.

Anyway, I suppose we should all forget about this, cause there's too many people that never learned how to rip properly in the first place. That's a much bigger problem than what absolute position everyone's music should be at.

I admit I had the crazy urge to bump everything, but I guess I need to control myself. I think I have too much fun ripping and encoding sometimes.

Instead of decoding to RAW PCM samples and using a hex editor, then instead just decode to WAVs and then use a WAV editor like e.g. EACs own WAV editor or Audacity, to trim or padd the WAVs. Note that this is not to say that i would recommend that you do this, as i really wouldn't

Personally, then what i care about, is to get a secure extraction of all the audio samples of a CD-DA and that is nearly always possible, no matter if using read offset correction or not and the only audio samples we are inclined to miss, is some samples of background-noise on some old AAD discs.

Now I'm just getting increasingly confused!

Having started to re-rip with the new offset (I was going to, as I have reinstalled on that computer), my LTR-52327S is still giving Sync Errors (if not more than before) at the end of CDs, which doesn't make sense, since I have subtracted 30 samples from the drive's offset and, thus, it is actually reading earlier . . . surely?

I did previously get similar errors at the end of CDs, but assumed that they could be justified, as I was using the positive offset correction (+6). I actually assumed that I would begin to get errors at the beginning of CDs, since I was not aware that the drive could read into lead-ins, but I have not experienced such a thing yet.

In any case, I haven't seen or heard any errors in the files and, as everybody says, it's probably just silence anyway. Whether I should bother with this new offset or not is debatable . . . but still.

That's right, but this offset is itself inaccurate, since factories can use the one they want.

IpseDixit does not rely on any factory offset. He looks at the raw digital data from the CD and builds up all the relationship between the time codes and the user data, until he finds, starting from the pits and lands themselves, the exact binary sample that is in relation with an exact time code.



I don't even understand why people call them "bit-perfect", since factories not only use machines that are offsetted from this reference, which introduces a minor deviation (+/- several samples), but produce CDs greatly offsetted from each other, which introduces a bigger deviation (+/- several hundreds or thousands of samples).
So whatever offset we use, we obviously get offsetted copies, not bit-perfect ones.



Not me. I consider AccurateRip checks much more important than using the same offset as several other people in the world, whose CDRs I'll never have to re-rip anyway.

Well, I like the idea of correcting my drive's offset to this "reference zero", but the fact that many manufacturers will be using skew makes the whole thing a bit futile anyway.

I never use AccurateRip, so is there any point in me using either of the offsets? Before this I just let EAC configure the standard +6 offset by itself; now I'm just incredibly confused! The fact that I still get the Sync Errors which I mentioned above at the end of many CDs doesn't help to alleviate the confusion!

Did you disable the "Overread into Lead-in and Lead-out" parameter? If not, please do so.

Just a quick question:

If you use Andre's reference offset and you have samples that are not zero at the end, and then rerip that CD with the new offset, those 30 samples at the end will be lost (with 30 samples gained at the beginning). Thus, even if you use the new offset, perfect 1:1 copies won't be possible in all cases.

So is it possible to read out audio data from the leadin/out to a seperate file?
That way you could use any offset you like and not loose any audio data.
As a consequence you could even use Andre's reference for ripping and Accurate Rip, and then, with the leadin information, make your rip use the corrected offset without ripping twice.

That is not true as the pressing factories all use varing offsets, so your 30 offset might gain more samples on some cds, on others it will loose some in relation to andres.

Yeah, that is what i meant. Sorry if i didn't make my point clear enough with the example i gave.

Nonetheless I'd be very curious how to extract all audio data that is written on the CD independently of any offset.

One possible use:
- Rip CD only once
- Check result with Accurate Rip
- Save cue+image with the 'new' offset.

--> so you can use both AccurateRip and the corrected offset without the need to rip twice.

You will need a drive that is capable of overreading in both the lead in and lead out or two drives: one that can overread in the lead-in and one that can overread in the lead-out. Even still, you might not be able to get all the data that is there, as it is likely that your ripping program may still return an error.

So what would someone do with all this data which is probably going to be nothing but low-level noise, except when there was a serious mastering error?

After reading every thread I could find on this topic, I've concluded the following (please correct me where I am wrong -- I am new to this):

- IpseDixit has likely discovered where the "absolute zero" is on a theoretically perfect audio CD, and it's 30 samples (or 120 bytes or 5 frames) before where Andre thought it was.
- The AccurateRip database is based on Andre's offset values, so reading using the new offsets in EAC makes AccurateRip unusable.
- Spoon and Andre, for good reason, don't want to start over with AccurateRip.
- This really shouldn't matter to anyone, because a) CD's themselves are manufactured with varying start points anyway, even with the same title, b) standard audio CD players are nowhere near as precise as we're talking about, and c) we're talking about 680 freaking milliseconds
- There are always perfectionists and preservationists in the world, so many people are still upset about this.

DrazardX had the exact same idea I did. Couldn't the following work? (Forgive me if this is wrongheaded; I primarily live on a Mac and have not yet been able to try all this out on a PC.)

- Rip CD in EAC using the *new* corrected offsets to bin/cue
- Add 120 nulls to the end of the bin (I don't know enough about the bin format to know for sure if it is a linear dump of sectors; if not, then we could get the WAV instead as DrazardX did or perhaps tweak the cue sheet).
- Remove the first 120 bytes, and save them somewhere if by some chance they're not all null
- Virtually mount the modified image and let AccurateRip check it out
- If AccurateRip likes it, then put the 120 back on the beginning and remove the 120 from the end, and convert it to FLAC or AAC or whatever floats your boat.

It seems like this ought to allow the uberpurists to both rip with the "accurate" offsets and still check them with AccurateRip. As I said, I've been unable to try yet -- but would this work?

Ivan.

I prefer the term obsessive compulsives.

This whole 30 sample thing is blown way outta proportion. It's interesting to learn about but to actually determine a ripping strategy based on it is beyond me.

I use the new offset. It's pretty convenient for me, since I have a Plextor and they're "set" to it by default!

Using either Andre's or IpseDixit's reference for offset correction will not make CD-DA rips any more exact. IpseDixit's result is based on one subchannel to mainchannel skew value, but CD manufacturers skew their discs highly varying(this has been said by a mastering engineer in the thread about this issue at cdfreaks). Also, Andre's reference is not the ultimate Zero starting point of CD-DA's eihter and he has just choosen the most frequently occuring one among his tested discs(6 identical matches among all his tested discs). Personally i don't see the point in using a reference other than Andre's, since this reference is the official one(and this is actually what offset correction is all about, i.e. to adjust ones drives after a common reference - and not to make perfect rips - since that is not possible when CD manufacturers skew/offset their discs highly varying) + used with AccurateRip.

IMHO, then "perfectionism" has nothing to do with what reference should be used, but instead just simply a bit of common sence

funniest thread ever imho.

Milliseconds...or microseconds?



Er...heh.

-brendan

Microseconds. Freaking microseconds.

For the record, I believe the mastering engineer said that the skew was specified in frames, not samples.

By frames I mean 588 samples; not whatever this 6-sample variety is that Ivan X is talking about.

I'm open to clarification if I'm not understanding this properly.

Some relevant quotes :


Source : http://club.cdfreaks.com/showpost.php?p=81...mp;postcount=32


Source : http://www.digital-inn.de/96934-post1.html

IMHO, it dosen't make sence to use a Zero-skew mastered disc for the reference, but instead to rather use the most frequently occuring disc-offset instead, which is what Andre has done :


Finally, a quote from Andre Wiethoff about what offset correction's usefullness is about :


Notice that he didn't mention "bit-perfect results"

We know accuraterip is not going to make any accomodations for the people who wants to use the new offset. The question is, are there any brave pioneering souls out there willing to start a new parallel database that would take submissions from people with the new offset?

I'd made a comment some months ago stating my opinion that this should be done, but having read the threads since then, it's pretty clear there's no need to do so. Here's my reasoning:

1. Most of the time, the 30 samples will be null. Not 99.9% of the time, but most of the time.

2. When they're not null, it's quite possible they'll be fade, and therefore low-level.

3. Even if it is audible content, it's so small, and already at the expected "event horizon" of the music/no-music universe, it would never be noticeable.

OTOH, what I'd really like spoon to do is to consider adding HTOA ("extended track 01 pre-gap"?) support to accuraterip. His current plan of making an image by gluing together each of the track+gap rips, audio already covered by accuraterip, leaves me somewhat worried that he'll not do it, as the HTOA audio is outside of that currently covered zone.

-brendan

The trouble with HTOA is no standard way of reading the start of the hidden track, different drives, different software.

Some drives give errors when attempting to read audio from HTOA.
Some drives give null samples when attempting to read audio from HTOA.
Some drives give the correct audio samples when attempting to read audio from HTOA.

So, it works on some drives. That's really all that matters to me. A list of drives that supports the feature already exists, as I'm sure you know.

This is a similar situation to other features such as "accurate stream" and "c2 pointers being reliable". These also vary from drive to drive.

And two other data points, if you're not already annoyed...

EAC can detect and rip the audio on compatible drives. And Riptastic! detects and rips the audio on compatible drives...as Track 00.

-brendan