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: offset issue (Read 4466 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

offset issue

i have a question, about offsets in EAC:

i ripped a brand new CD and made a copy of it. everything is ok up to this point. the CRCs on the CDR match the ones of the original after I rip the CDR to the hard drive to verify that there are no errors

when i compare the tracks off the original and the tracks off the CDR using EAC, it is reported that the CDR tracks have "1154 repeated samples" in the beginning of each track, as in "inside" the beginning of each track. i adjusted my rip offset to +1154 and ripped the CDR again. now both the original tracks and and the tracks off the CDR match precisely

my question is: where did these extra 1154 samples come from? is it a read offset or a write offset? if this is a read offset, should i just leave this value in EAC? i have ripped other CDs, made a copy, and when i compared the original and the CDR, the same thing happens -- it is reported that the copy has "1154 repeated samples"
Be healthy, be kind, grow rich and prosper

offset issue

Reply #1 –
It sounds like you haven't done offset detection so far. So most likely it's a combined read/write offset.
Let's suppose that rain washes out a picnic. Who is feeling negative? The rain? Or YOU? What's causing the negative feeling? The rain or your reaction? - Anthony De Mello

offset issue

Reply #2 –
What you found is the combined offset.
If you use it to burn cd's to cdr's it is fine.  Using the value you found you will make a 1:1 copy.
If you are ripping to hd though you want to find the read offset.
If you use the offset you found now and burn a cd later with another burner from tracks you ripped to HD you will not get a 1:1 copy.
The combied offset will have changed of course.


Conclusion: If you want to write the tracks to cdr right away using the combined offset is fine. Otherwise you want to find the read offset and the write offset seperately.

offset issue

Reply #4 –
thanks for all the replies. i'll check out satcp's site on how to find the read and write offset separately
Be healthy, be kind, grow rich and prosper

offset issue

Reply #5 –
Quote
What you found is the combined offset.
If you use it to burn cd's to cdr's it is fine.  Using the value you found you will make a 1:1 copy.

If you want to write the tracks to cdr right away using the combined offset is fine.

1:1 ?
This is what they say, but I don't agree...
You are going to lose samples whether you want it or not! 

Just remember what offsets are...
If the read offset is unknown, you'll lose a few samples of the first/last track with the above method, since the drive head's positioning is not perfect! The only thing EAC knows is that it has to 'shift' all samples by a constant 103 positions.
It's still better than doing nothing tho, since it DOES have an advantage: all intermediate tracks will start sample-correct! The loss only affects the first/last track.

Note: However I don't want to give the impression that offset correction is really indispensable, it will allways remain a matter of samples...

offset issue

Reply #6 –
Since the very start of a cd and the very end would always (probably) be silence it is a 1:1 copy when the missing samples are filled with silence.

offset issue

Reply #7 –
Quote
You are going to lose samples whether you want it or not! 

AFAIK you won't lose samples if your drive can overread into the LeadIn/LeadOut.

offset issue

Reply #8 –
Quote
Quote
You are going to lose samples whether you want it or not!  ;)

AFAIK you won't lose samples if your drive can overread into the LeadIn/LeadOut.

Correct. I'm not too sure that many drives do though. But as I wrote before you will probably get a 1:1 copy anyway; thought there is the change that you won't without overread into the LeadIn/LeadOut.

offset issue

Reply #9 –
With combined offset, you are loosing samples in theory, even if you overread.
Say that you have a read offset correction of +500, and a write offset of -1000.
The combined offset is -500.

Ripping with combined offset, you overread 500 unuseful samples into lead in, but loose the 1000 last ones all the same.

offset issue

Reply #10 –
I think CD-RW manufacturers should have the read/write offsets labeled somewhere in the packaging.  That would be much easier.

Edit: Spelling

offset issue

Reply #11 –
Sure...

Up to recently, this was not done because offsets were considered to be a non issue, and especially because there was no such thing as "offset 0".

Then came Andre Wiethoff, with EAC, and he decided himself what he would call offset 0 (Re: offset detection). At this time, there was no reason to choose this offset rather than another close one as a reference, within a margin about 1 sector wide. But the database grew up, and everyone began to use this offset as a reference.

Now, we saw that Plextor, releasing Plextools with offset correction, were wise enough to follow EAC's offset reference, and use the same one to calibrate their software. This way, the offset reference used by people being aknowledged by an official manufacturer, I think it become possible to set it as an official reference (which it has never been) for all manufacturers.

offset issue

Reply #12 –
Which parameter is this offset for cdparanoia?
--toc-offset or --sample-offset?

offset issue

Reply #13 –
Ah... Have found it by testing... it's --sample-offset

EDIT: Or maybe not?! It works for every other track than the first... I get bitidentical files with the files EAC produces with offset correction...
But when I try to rip the first track I get many errors like this:
Code: [Select]
scsi_read error: sector=-2 length=1 retry=7
Sense key: 5 ASC: 21 ASCQ: 0
Transport error: Illegal SCSI request (rejected by target)


Maybe cdparanoia tries to access sectors before the beginning of the CD or something? But why does it work with EAC?
Any ideas?

offset issue

Reply #14 –
Some CD drives support overread into leadin, EAC supports this too. I don't know about overreading features of CDParanoia and how CDParanoia behaves if it's set to overread but the drive doesn't support it - or maybe it's a Linux driver issue ...
Let's suppose that rain washes out a picnic. Who is feeling negative? The rain? Or YOU? What's causing the negative feeling? The rain or your reaction? - Anthony De Mello

offset issue

Reply #15 –
hmm how does EAC know how many samples are missing (how many should be filled with silence)?

offset issue

Reply #16 –
When you set +500 read offset correction, for example, EAC read the CD without offset correction, removes the 500 first samples, paste the 500 first of next track at the end, etc... and adds 500 samples of silence at the end of last track if the option not to overread and to fill up is selected. (at least that's how I would have made it, it's the most secure way to go)

offset issue

Reply #17 –
Quote
Some CD drives support overread into leadin, EAC supports this too. I don't know about overreading features of CDParanoia and how CDParanoia behaves if it's set to overread but the drive doesn't support it - or maybe it's a Linux driver issue ...

I think it's no driver problem... I can rip CDs with EAC or dBPowerAMP under wine....
Maybe I have to contact the cdparanoia mailinglist...