I've created a single FLAC file of an album with CUE using EAC's "Copy Image & create CUE sheet > Compressed".

When I attempt to embed the CUE into the FLAC file with metaflac, I get the following error:


The first part of the CUE file looks like:

It looks to me like the index is messed up. Every track has an index 00 set the 2:58:73 which is the running length of the first track.

I've tried two albums and both had the same issue. I also tried copying as WAV and and generating the CUE file on its own and the index values were the same.

I'm using EAC v.099 prebeta 4 from 23, Jan 2008 on Windows Vista 64 bit.

::

Try different settings for "EAC" - "Drive Options" - "GAP Detection".

::

looks like a weird bug. report to the author: http://www.digital-inn.de/forum271/

I don't think it's a bug; just a problem with the extraction method. There's a reason why there are three, you know.

Yeah, possibly so. With some discs I've noticed different pregap times with two out of the three gap detection methods. To get the real ones I'd probably have to detect the pregaps with at least 3 or 4 different drives using all three methods with different accuracy, then choosing the pregaps with the most matches.

Often there is no "real" value for the pregaps, or it is not possible to ascertain it with any certainty. There are two reasons for this: 1) index information does not have to be present in every frame and 2) index information has no redundancy for error correction.

Two different albums, or two copies?
Though i tend to say that greynol is right (no bug, only an extraction problem), we should consider a second possibility: copy protection.

Thanks for the all suggestions, guys. Switching the Gap Detection method to A (it was B) seems to have fixed the problem... at least metaflac isn't complaining about the values now. I thought the incorrect detection method might cause the gap values to vary, but I didn't realise it would make them invalid.


It was two different albums and neither had copy protections.

Just for the records, could you post your optical drive's model and manufacturer. It might be useful information for others searching the forum.

For the record,

After reading this old thread I tested my two Samsung drives using the system Be Positive described and found out that only the method A appears to be accurate. B produced slightly suspicious and inconsistent results and C was completely off the mark. I have set the detection accuracy to "Secure", but I have not tested if the other options would be any different.

The drives as reported in the log files:
TSSTcorpCDDVDW SH-S202J
TSSTcorpCD/DVDW SH-W162C

XP Pro, EAC v0.99pb4 using "Native Win32 interface for Win NT & 2000"

Still, the results might be different using a different disc and/or different drive.

The two mentioned drives appear to produce identical results after I switched them to use the method A. Though I have tested only a few discs with both drives.

For most of my ripped discs I have used the default method (I think it has been the B method for long time), because previously I had read from various sources that it is fine to use any method that can read the gap info at all and that I should select the fastest method if all methods work.

I wonder if the C method works with some drives correctly since it seems to produce completely wrong, impossible, results with my drives. As I said, the B results are quite close to A results, but they are not always reproducible and may differ between the two drives.

These two are not the only drive models I have, but I have not tested the other models yet.

I think a pregap detection database similar to AR for track verification would be nice for EAC... detect some disks pregaps with all methods and submit.

Sorry for the delayed reply. It's an ASUS DRW-2014L1T SATA drive.

Thank you.

I also have had this problem with a TSSTcorp drive (in a Dell laptop). Changing to method A fixed it for me too, so thanks for that advice!

X