If I'm ripping my CDs in EAC using flac for computer use (playback via foobar2000), and have no intention to burn CDs as backups, is there any reason to use the gap/cue sheet features of EAC? I have read all the pertinent articles in the hydrogenaudio wiki and it looks like these features are only useful if you are interested in making perfect disc clones. Is this correct, or are there other uses that cue sheets have? From what I have read here the Action>Detect Gaps function simply allows the gaps to be correctly recorded in the log file.

My process so far has been to rip a CD using Action>Test & Copy Selected Tracks. I do not currently use the Action>Detect Gaps feature before doing test and copy. As a result I assume that the gaps are defaulting to being added to the previous tracks (since the 'Append Gaps To Previous Track' option is checked) and are added to the overall track length in the log file. Is this correct? My current EAC Drive Options>Gap Detection settings are:

Gap/Index retrieval method: Detection method B
Detection accuracy: Inaccurate

Am I correct to assume these setting don't matter for me as I don't use the gap detection features? (just wondering because the hydrogenaudio wiki is incomplete in this area)

Yes, everything you've said is correct.  So long as you're happy with the start and end points of your tracks and taking into account what else you've said, there is no reason for you to do gap detection or create a cue sheet.

EDIT: I always manage to forget an important point.  A CUE sheet is the only place to know if a CD has pre-emphasis besides EAC's main window.  I'm not sure if there are any media players that make use of this information, but if you have a rip with pre-emphasis that you did a few years back but have since forgotten, it might be a handy reminder.

Just to add to what greynol said...

In the wiki, I just today updated the intro to the article on cue sheets to better explain what they're for. A while back, I tried to beef up the EAC gap detection info, but I guess it's still not 100% clear yet.

Gap detection may be something you want to do if you are, as you say, 1. not interested in making exact copies of full CDs, and you just want tracks for listening to in random order, and 2. you want those ripped tracks to not have the usual 2+ seconds of "silence" tacked onto the ends (if that's how they are on the original CD), and 3. you're OK with giving up the ability to use AccurateRip to check if your rip matches other people's, and 4. you're aware that on some discs, with some drives, EAC has trouble figuring out where gaps are and whether they're really 100% silent or in fact are just quiet parts (tape hiss, fades) near the track boundaries. (This is why there's an option to test detected gaps to see how silent they really are). Oh and 5. you're OK with not really removing all the silence, just 1/75th-second chunks of it, and 6. the automatic silence-trimming/'gapless playback' features of certain media players or crossfading plug-ins don't meet your needs.

Personally, I do like to trim silence from random tracks I rip for streaming and shuffle-play listening. But after finding out all of EAC's limitations in this regard, I decided to just use shntool in post-processing, rather than doing it up front at rip time. The only reason I would use EAC's gap detection and a cue sheet for these kinds of tracks is if I really did want to preserve the gap info but didn't want it to actually be in the ripped files; the cue sheet could be used to tell the burner/player where to insert digital silence...not a scenario I can say has ever come up, except when I was trying to learn about the features so I could beef up the documentation

I would always generate CUE sheets, if only for the possibility to verify against AccurateRip, if you need it for some reason in the future. For example, I have a few rare CDs that are not present in the AR database currently, but I can try to verify again in a year or so, maybe they will appear, just to make sure. Same goes for new CDs, which usually take some time to appear in the database.

Gap detection may be something you want to do if you are, as you say,

Based on what you wrote, did you want to say gap may not be something you want to do?  Perhaps you really meant to say CUE sheets and not gap detection???

1. not interested in making exact copies of full CDs

Telling EAC to perform gap detection is not necessary for making exact copies of full CDs.  If you meant CUE sheets, they are still not always necessary.

2. you want those ripped tracks to not have the usual 2+ seconds of "silence" tacked onto the ends (if that's how they are on the original CD)

I would not characterize the area flagged with a 00 index this way.  This area may be silence, it may be low-level noise, it may be audio.  It may be 2+ seconds long, it may be less than 2 seconds long, it may not even be flagged at all.

3. you're OK with giving up the ability to use AccurateRip to check if your rip matches other people's

Unless you're placing gaps at the beginning of ripped tracks or eliminating them (provided they consist of nothing more than null samples!), gap detection is not necessary for AR verification.  Even still, it is the CUE sheet that is required, not gap detection.  You don't need to tell EAC to perform gap detection in order to create a CUE sheet.  It will be done automatically.

EDIT: Reading this over for a third time, now I'm wondering if you meant to say these three things are the result of telling EAC to rip tracks with gaps left out.

This is why there's an option to test detected gaps to see how silent they really are

I went just back and re-tested this function to confirm that it can report a gap as having 100% silence when it actually contains non-null samples.  It is not to be trusted!!!


Back on this notion of why telling EAC to perform gap detection (F4) is necessary:

• It is necessary if you want EAC to rip without gaps or put them at the beginning of the current track.
• It is necessary if you want the gap information shown in the GUI or in the log file.
• It is necessary if you want EAC to test gaps for silence (which is not reliable!).

Besides these three, there are no other reasons to explicitly tell EAC to perform gap detection.

I would always generate CUE sheets, if only for the possibility to verify against AccurateRip, if you need it for some reason in the future. For example, I have a few rare CDs that are not present in the AR database currently, but I can try to verify again in a year or so, maybe they will appear, just to make sure. Same goes for new CDs, which usually take some time to appear in the database.

If you're ripping in the standard default way with tracks with gaps appended to the previous track, the only information in the CUE sheet that is necessary for AR verification is the location of the 01 index for the first track.  As of EAC V0.99, this is now contained in the log file.  What's more, if your disc has a data track the the start point and length also needs to be known for AR verification.  This information is kept only in the log file, it is not available in the CUE sheet.

I would always generate CUE sheets, if only for the possibility to verify against AccurateRip, if you need it for some reason in the future. For example, I have a few rare CDs that are not present in the AR database currently, but I can try to verify again in a year or so, maybe they will appear, just to make sure. Same goes for new CDs, which usually take some time to appear in the database.

If you're ripping in the standard default way with tracks with gaps appended to the previous track, the only information in the CUE sheet that is necessary for AR verification is the location of the 01 index for the first track.  As of EAC V0.99, this is now contained in the log file.  What's more, if your disc has a data track the the start point and length also needs to be known for AR verification.  This information is kept only in the log file, it is not available in the CUE sheet.

thanks for this info, I didn't know that. I knew about the data track issue, but assumed that the individual 00 and 01 index positions are needed too, for AR verification. So if I have a standard "multiple tracks with gaps appended to previous track" rip with only a log, can it be AR verified with CueTools or foobar? Is either of those applications able to read the needed info from the log?

They may still need a CUE sheet, but the point is that the cue sheet can be created from the information found in the log.

I have some CDs that I ripped without CUE sheets and I've generated them after the fact using a simple batch script for use with CUETools (which also has a cue sheet creator).  When they don't work, I'll either look up the disc in either freedb or musibrainz to see where the first track starts and put that information in a pregap line, or I'll guess (32, 33, 37, 50, 75 are the standard values).

The OP's question, as I read it, was this: given that he was just ripping random tracks to listen to, as opposed to full/perfect CD backups, then why would he want/need to do gap detection and/or cue sheet generation?

I was trying to say that gap detection is something he might want to do if he intends to also do gap removal, i.e., omitting "silence" (scare quotes!!) from his ripped files. But I was trying to impress upon him that gap detection, at least in the way EAC does it, has a number of caveats that he should be aware of, especially if he's under the mistaken impression (like I once was) that detecting and removing gaps is a reliable or precise means to ensure "gapless playback". These caveats might make him not want to do it. I put the desire to remove gaps, plus all the caveats, into the list of things he must want or accept before he chooses to detect gaps.

Telling EAC to perform gap detection is not necessary for making exact copies of full CDs.  If you meant CUE sheets, they are still not always necessary.

Of course you're not wrong, but you're getting hung up on a red herring. No, I didn't mean cue sheets. I'll rephrase:

He said he's not making exact copies of full CDs, he's just ripping tracks to listen to. That being the case, producing gapless files might be something he wants to do. To do that, he'll need to detect the gaps first. But if he does produce gapless files, those files will not constitute a perfect copy of a full CD because they're missing data. Even if he saves the gap positions & durations in a cue sheet, there's a risk that the gaps actually only contained near-silence, so there'd be no way to simulate or produce a perfect/full copy of the CD from the files with the cue sheet. So in summary, he might want to do gap detection if, as he said, he doesn't necessarily need 100% complete copies. If he really does want complete copies, than he probably doesn't want to do gap detection, since he's probably not going to want gap removal.

2. you want those ripped tracks to not have the usual 2+ seconds of "silence" tacked onto the ends (if that's how they are on the original CD)

I would not characterize the area flagged with a 00 index this way.  This area may be silence, it may be low-level noise, it may be audio.  It may be 2+ seconds long, it may be less than 2 seconds long, it may not even be flagged at all.

...which is exactly why I put silence in scare quotes, and clarified in #4 why gaps aren't always 100% silent. Again, the list is giving him a reason to do gap detection: so those "gaps" (again, scare quotes), can be removed, if that's what he wants. It might be something he wants because he's not making complete copies, and maybe he accepts the other risks.

In my experience, 95% of the time, EAC does a pretty good job with gap detection & removal, removing only actual silence or noise I don't care about. The 1-in-20 rate of bad detections (due to peculiarities of the audio/subcode/drive/EAC/whatever) that I got when I was using it regularly was unsettling, but wasn't a dealbreaker; if the detected gaps seemed suspicious, I just chose not to remove them, and of course I'd listen to the rips or checked them out in a wave editor to make sure they were OK. However with all that verification on some rips, I figured it was no less work than than doing no removal in EAC and gaining the benefit of AccurateRip, and instead doing only pure-silence removal externally, reserving my wave editor time for the rare cases where shntool leaves behind a near-silent passage that's distractingly long.

3. you're OK with giving up the ability to use AccurateRip to check if your rip matches other people's

...EDIT: Reading this over for a third time, now I'm wondering if you meant to say these three things are the result of telling EAC to rip tracks with gaps left out.

Right; that was #2. Again the point is that if he wants/accepts not just #1 but also #2 and #3 and #4 and #5 and #6, then gap detection is something he might get some use out of.

This is why there's an option to test detected gaps to see how silent they really are

I went just back and re-tested this function to confirm that it can report a gap as having 100% silence when it actually contains non-null samples.  It is not to be trusted!!!

Yipes! I had suspected that the 100.0% silence figures weren't entirely reliable. Thanks for the confirmation!

Back on this notion of why telling EAC to perform gap detection (F4) is necessary:

• It is necessary if you want EAC to rip without gaps or put them at the beginning of the current track.
• It is necessary if you want the gap information shown in the GUI or in the log file.
• It is necessary if you want EAC to test gaps for silence (which is not reliable!).

Besides these three, there are no other reasons to explicitly tell EAC to perform gap detection.

Yeah, that's a much more concise summary.

It seems pretty clear to me that the OP knows what he is getting when gaps are not detected (they're appended to the end of the previous track) and is not interested in having them removed.

I do find it interesting to tell EAC to rip tracks without gaps and crossfade when playing them in shuffle, but wonder how often this is done.

Thanks for the clarification.

removed - old topic