As you will know the MPC codec is a gapless one (not introducing any additional samples during encoding).
Which is not true for e.g. MP3... (everyone will know the MP3 playback issue)

Now, there is an option in EAC called "Use offset correction for encoding and decoding"


1. AFAIK the two facts mentioned above are about the same thing (but I'd lbe glad if someone could confirm this).
If your encoder is e.g. MP3, EAC offers you the opportunity to get around the offset introduced by the MP3 codec (theoretically - I know in reality you would generally not use this option). Since MPC is gapless, I would expect that disabling this option, or using an offset 0 is best, and that they are the same thing. (are they really the same thing, or is there any subtility?)

The EAC forum on www.digital-inn.de is the best place to ask.

As I understand it, (EDIT: I was wrong, see next reply below - DickD) offset correction is purely to do with the number of samples by which a CD ROM drive is ahead or behind the expected track position and has nothing to do with compression schemes.

There are databases of CD-ROM drive capabilities which may help, or if you have one of the known reference CDs, you can measure your drive's offset.

For gap killing, I personally use the MP3splice output plugin MP3splice homepage for WinAMP 2.xx, which has been excellent at preserving intended silences yet merging tracks together (it seems to be the only one that does this).

It doesn't even complain if you play an MP3 followed by an OGG Vorbis file, so if you use MPC it can still be useful to prevent the Wave device from being closed and reopened (with a resultant gap). The only thing the current version doesn't do is to allow output to the hard-disk (e.g. if you want to burn your MP3 to CD-R, correctly spliced). I guess you could try Lame's decoder with the --nogap option if you need to make WAVs for burning.

Regards,

Dick Darlington

Disabling the encoding/decoding offset or setting it to zero has the same effect.
This is the correct seeting for MPC, since it was designed to be sample-accurate :-)

Cheers.

Edit:

No no no no... this is cd-rom read offset correction, and has nothing to do with what liekloo asked.

Thank you

Indeed, NumLOCk got closer to what I actually intended to ask, but thank you anyway DickD

('Offset' just means 'shift'. When ppl talk about 'offsets' or 'detecting offsets' they usually mean the read offset of a CD-ROM drive, but there are other meanings: a drive also has a write offset, and in this case i was referring to the gap effect MP3 is notorious for)

Meanwhile I have seen that it is not the same (for those who may read this thread)