Folks:

I'm yet another person starting a Great Project to rip all my CD's, make an online archive copy, and make the tracks playable from a media server to a player on my various computers. Many thanks to everyone who contributed their know-how and experience to these forums. It's a big help.

I'm trying to decide between ripping the entire CD to a single image (compressed with FLAC) plus cue sheet, or ripping each track to its own FLAC file, while still collecting the cue sheet. I think that the single image is the only way to capture gaps really accurately, while the separate tracks are the only way to store track-level metadata tags. Am I understanding right?

Elaborating:

The single image, with CUE sheet, is the only way to:

• Capture the exact duration of all gaps, including the gap before the first track and after the last track;
• Capture the sound content of both the gap before the first track and after the last track;
• Get the correct negative time count when playing back a CD recreated from the image

However, the single image has no way to store track-level metadata tags in general. The track title is recorded in the cue sheet. (Is the cue sheet Unicode enabled?) But taggers like the MusicBrainz PicardQT don't operate on the cue sheet, they operate on Vorbis comments embedded in the FLAC file. All the Vorbis comments in a FLAC image file apply to the entire file, which is an album, so there's no way to record a MusicBrainz track ID or PUID; or a track artist.

Recording a FLAC file for each track is the only way to get full track-level metadata tags. In such a file, the Vorbis comments apply to entire file, but it's a track. There are tags to store album-level metadata in a track file. You can have the audio extraction tool append track sound to the beginning or end of the track audio in the FLAC file, thus capturing the audio content of all gaps but one (the very first or very last gap). With determination and a cue sheet, it's possible to reconstruct, from track-level FLAC files, a CD which has the correct gap lengths, though perhaps not the correct gap content.

However, the FLAC file for a single track doesn't record the gap information separately. The extractor can put the gap before each track onto the start of the track's audio file, or it can put the gap after each track onto the end of the track's audio file. In either case, one gap gets dropped: either the gap before the first track or after the last track. Also, any player will treat the FLAC file including gap as a single piece of music, so the time display won't show negative numbers while playing the gap. Also, track lengths will appear to be longer in the FLAC file than they do in the CD, because the gaps are counted as part of the track in this approach, instead of separate.

Am I correct in understanding that this is the tradeoff that the current set of tools forces us to make?

Is there a set of tools that doesn't force this tradeoff?

Thanks for your guidance,
--Jim DeLaHunt, Vancouver, Canada

No. Gaps may be retained within individual tracks or individual files as well and there is no difference in accuracy.

Gap before the first track is also preserved if you extract indices individually or if you prepend them to the next track. Depending on your definition, "gaps" after the last track either do not exist or are extracted the exact same way regardless of the method chosen (IOW the issue is moot).

Again, this is not exclusively true for single-file images.

To reiterate, no data or gap information is ever lost when prepending gaps to the next (current) track or ripping or splitting as individual indices. Often times, track 01 index 00 information is comprised entirely of null samples in which case no data or gap information is lost when appending gaps to the previous track and creating a noncompliant sheet that includes a pregap statement. The same is true in the general case: a pregap statement is a lossless substitute for gaps comprised entirely of null samples regardless of it's position on the disc. In certain situations, a postgap statement may also be used as a lossless substitution for frames of null samples.

On a final note, many drives are not capable of retrieving non-null track 01 index 00 information.

Hi Jim

If you are concerned primarily about playback flexibility you should go with the multiple files. That way you will be able to add metadata to them separately, for playback on players which do not support cuesheets. As greynol mentioned: you do not sacrifice any data by ripping to individual tracks instead of an image file, so you should go with what is most convenient for you.

Thanks for the replies.

For what it's worth, in this thread "Using CUE sheet from EAC with files ripped by dBpowerAMP?" on the dbPowerAmp forum, one user was reporting that when ripping a particular Depeche Mode CD as individual tracks, the copy didn't the original, but when ripping as a unitary image, the copy did match. Another user couldn't reproduce that result.

--Jim DeLaHunt, Vancouver, Canada

This was probably because he didn't really know what he was doing.

Previous versions of EAC would not include a pregap statement in noncompliant CUE sheets when it was needed. Either that or the pregap before the first track contained samples that were non-null (as I already mentioned).

It's still possible to have a noncompliant CUE sheet that provides for HTOA data while still ripping tracks the standard way (with gaps at the end). Have a look at this post.