Hi.

I was able to determine that my drive (Matshita UJDA740) has a read offset correction of +102 and a write offset of +30. (Used reference CD's to determine read offset correction was +102. Then created test CD which was found to have an offset correction of +132, thus 132 - 102 = +30) I used the coaster factory FAQ.

I intend to be making CD-R backups of all my discs as well as encode them to lossy files. To do this, I plan on ripping my CD's to wav images with cue files. Then I will load the images in a virtual drive using Daemon Tools and rip the image to compressed lossy files.

I realized that this would result in the read offset correction being applied twice, once in the extraction to image and once in the extraction to lossy. One solution would be to constantly change the read offset correction back and forth from +102 and 0, but this would be a pain and I'm worried I would forget to do it now and then.

I realize that +102 is a fairly small offset, so I don't mind if my lossy files are slightly cut off at the end. My main concern is having accurate burned back-ups. Could I then set the read offset correction to 0, and set the write offset as +132 (102 + 30 = 132)? Am I doing that conversion correctly? This way while my images will be slightly inaccurate when being ripped to lossy, they will be perfect once burned to disc again.

Thanks

- Matt

OT: is this a notebook? If it is, what kind? That drive model looks familiar, but I'm too lazy to check.

It's a fairly new Dell Inspiron 5100 with the 24/10/24 CDRW/DVD combo drive. Matshita, or Matsushita, is another name for Panasonic IIRC.

- Matt

Ah, just looked up mine and I've got a UJDA745 in my IBM T41. I knew that looked familiar. It's also 24x10x24...probably the same drive just slightly thinner (9.5mm)?

EDIT: does yours rip slow in EAC? My old Dell D600's 24x drive ripped sooo much faster (about twice as fast, maybe a bit more). I get up to about 7x at the end of a CD, and it starts about probably around 4x.

And why not using only read offset correction of +102 when reading. Resulting copy would be offset corrected and hardware independent Easier to use when writing with another drive.

Then again simply apply (I assume you use EAC for writing, with other programs you need to stick to combined offset) +30 writing offset in EAC to get perfect copy.

Couldn't you simply use the "Split WAV By CUE Sheet" tool in EAC, after you have ripped the album to one wav file and created a cue sheet in the first place? That should give you a perfect result in one easy step.

criZZb: Ohhhh, I didn't even think about using different drive options for my cdrw drive and my virtual drive. That makes things easy. Thanks!

Chun-Yu: Yep, I get about the same speeds (4-7x). Both EAC and Feurio detected my drive as having accurate stream, but no audio cache or C2 error info. Did it detect these same settings for you?

Von: Would that still retain freedb tag information? The reason I was going to use a virtual drive was so that I could retain this info while still using my nencode+tag command line.

- Matt

I think not...

Yes, I got the same settings detected. That faster CDROM drive is the only thing I miss about that D600.