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: Andre's EAC Offset Calculation (Read 98955 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Andre's EAC Offset Calculation

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


Andre's EAC Offset Calculation

Reply #102
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. 

Andre's EAC Offset Calculation

Reply #103
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.

Andre's EAC Offset Calculation

Reply #104
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.

Andre's EAC Offset Calculation

Reply #105
Could you please tell me how Andre's results could ever just be an aproximation ? What i seemed to think, was that as Andre looked at discs where there where non-null samples i.e. background noise up untill the very last sample before the lead-out begun, then he actually did have the ability to calculate the precise CD offset values of the CDs that he tested, and not just an aproximation of the CD offsets used on them.


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 never understood this obsession with having a "bit perfect" audio CD copy.
Same here.


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.

So, who is thinking of adopting this new reference?


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.

Andre's EAC Offset Calculation

Reply #106
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!

Andre's EAC Offset Calculation

Reply #107
The fact that I still get the Sync Errors which I mentioned above at the end of many CDs doesn't help ..

Did you disable the "Overread into Lead-in and Lead-out" parameter? If not, please do so.
In theory, there is no difference between theory and practice. In practice there is.

Andre's EAC Offset Calculation

Reply #108
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.

Andre's EAC Offset Calculation

Reply #109
Quote
f 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.


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.

Andre's EAC Offset Calculation

Reply #110
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.

Andre's EAC Offset Calculation

Reply #111
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?

Andre's EAC Offset Calculation

Reply #112
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.

Andre's EAC Offset Calculation

Reply #113
- There are always perfectionists and preservationists in the world, so many people are still upset about this.

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.
daefeatures.co.uk

Andre's EAC Offset Calculation

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

Andre's EAC Offset Calculation

Reply #115
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

Andre's EAC Offset Calculation

Reply #116
funniest thread ever imho.
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung

Andre's EAC Offset Calculation

Reply #117
- 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


Milliseconds...or microseconds?

- There are always perfectionists and preservationists in the world, so many people are still upset about this.


Er...heh.

-brendan


Andre's EAC Offset Calculation

Reply #119
CD manufacturers skew their discs highly varying(this has been said by a mastering engineer in the thread about this issue at cdfreaks).

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.

Andre's EAC Offset Calculation

Reply #120
Some relevant quotes :

Quote
For what it's worth...

I am involved with the mastering process at huge CD/DVD factories all over the world. Our software allows the mastering engineer to set the skew (offset between main and subchannel) to whatever they like (including negative!). And, the Red Book does allow +/- 75 sectors.

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

Quote
Disc factories make discs with different "offsets" all the time (for media it's called skew, subchannel to main channel skew). They sometimes put the 1st sample of a recording in a point slightly far (+- 75 sectors skew) from the exact start of the disc (00:00.00). Wouldn't be optimal to take a disc that has no sub to main skew ("zero offset") as reference (we would have to contact mastering engineer)?

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 :

Quote
As different modells of common CD-R writer usually do not add the same offset on writing, it seems that also big CD manufactures also do not always press the same offset on their CDs. So I determined the most common offset of pressed CDs and integrated it into the offset detection routines.

Finally, a quote from Andre Wiethoff about what offset correction's usefullness is about :
Quote
'Sample Offset' is another new feature of EAC, it will help to always get the same WAVs compared to a different reader and to prevent generation losses.


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

Andre's EAC Offset Calculation

Reply #121
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?

Andre's EAC Offset Calculation

Reply #122
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

Andre's EAC Offset Calculation

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

Andre's EAC Offset Calculation

Reply #124
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