Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Ripping Flac: Single-File versus Track-by-Track (Read 33053 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Ripping Flac: Single-File versus Track-by-Track

Hi,

I am trying to decide if I would rather rip my CDs to a single FLAC file w/embedded cuesheet or to individual FLAC files (track-by-track).  Ripping to a single file seems to make the most sense for archiving/backup purposes -- I can easily recreate the CD and encode to other formats as needed later.  But ripping to individual track-by-track files seems to provide more options in terms of playback and tagging.

Originally I had thought I would just archive my CD collection to single FLAC files and rip MP3s from them for every day listening -- but the more I think about it (and in preperation for getting a SqueezeBox) I wonder if I shouldn't be using my FLAC files for home listening and rip smaller MP3 files for my iPod (headphone and car usage).  This would give me more space on my iPod and better quality at home -- instead of trying to get them both out of the same format.

My concern with individual FLAC files is the seperating of tracks ... espeicaly tracks that require gapless playback.  Am I going to risk/lose anything by doing this in the long run (problems with gapless playback or burning to a CD )?  Is it safer to do a single-FLAC file and sacrifice placyback options ?  Thoughts? 

Thanks,
Damon

PS: I am a Mac/Linux user.

Ripping Flac: Single-File versus Track-by-Track

Reply #1
According to a discussion I just had actually, http://www.hydrogenaudio.org/forums/index....showtopic=59343 , you need not worry about writing back to the CD without gaps even if you rip to tracks. In addition, you can create CUE sheets for tracks that preserve all the gap settings.

I only have archival purposes so images with embedded CUE sheets and album art is no problem with me. Rarely, I feel the need to listen to the images through my media player. If Q2 Vorbis tracks no longer sound good through my home system, then I will just re-encode to a higher bit rate... I would be in no rush to encode and do not have great ears to begin with.
OP can't edit initial post when a solution is determined  :'-(

Ripping Flac: Single-File versus Track-by-Track

Reply #2
According to a discussion I just had actually, http://www.hydrogenaudio.org/forums/index....showtopic=59343 , you need not worry about writing back to the CD without gaps even if you rip to tracks. In addition, you can create CUE sheets for tracks that preserve all the gap settings.


Oh ... I hadn't thought of that.  So I could write an external cuesheet for the multiple FLAC files that could be used when "re-creating" the CD ? Neat. 

I am going to play with this and see how it works.  Thanks

Ripping Flac: Single-File versus Track-by-Track

Reply #3
If you make a cuesheet to your FLAC track files, then you will retain everything in most cases. The only thing you can risk missing, is hidden tracks stored into track 01's pause area, since ussually, then ripping apps will not rip that part from CDs automatically.

If you rip with EAC, then the first track will be highlighted in red if there is such a track and then you can select to extract the hidden track additionally. Then if you later on want's to write the rip back to a CD-R, then you will have to manually edit the cuesheet to make the hidden track be placed into the correct place on the written CD-R.

Actually, there is a ripping method in EAC which will always rip hidden tracks from track 01's pause area if they exist and add them correctly to the cuesheets, but that isn't something that most people do, because it will give you an awkvard playback situation. However, keep in mind that not all drives supports ripping these possitions from CDs.

Gaplessness is only an issue with non-gapless formats like MP3 and such, but still, if you are using a newer LAME version to encode with and a player supporting to parse and make use of the LAME tag, then you will still get gappless playback from MP3s also.

Apart from the "hidden track in track 01's pause area" issue(often called 'HTOA'), then you will not gain anything by making images instead of track files with cuesheets, and in the end it simply comes down to personal preference of whatever you like the best.

I myself make WavPack images which i use for both archiving and playback, since i don't have to think about the 'HTOA' issue and also since i think that it's nicer to have a single file that represents a single CD, but again, it all comes down to how you yourself feels about this issue...

Ripping Flac: Single-File versus Track-by-Track

Reply #4
I myself make WavPack images which i use for both archiving and playback, since i don't have to think about the 'HTOA' issue and also since i think that it's nicer to have a single file that represents a single CD, but again, it all comes down to how you yourself feels about this issue...

Yea - I like the idea of having a single file for the whole album.  Seems easier to manage and archive.  I may start with that and do some quick listening tests myself to see if I notice a difference in playback of MP3 encodes -- I don't have amazing audio out equipment so I am guessing I won't hear much of a difference.  And if I can get LAME with gapless to work that would be groovy as well.

THanks

Ripping Flac: Single-File versus Track-by-Track

Reply #5
My FLAC library consists of all single-file images with embedded CUE sheet and album-art.

There is a plethora of software that can deal with these files:

burrrn for burning Audio CDs, Foobar/CUEProc to transcode them to a lossy format; just to name a few.

I am happy with this as these files are a lot easier to archive and manage and you don't risk accidentally losing any data by taking the individual tracks path.


Ripping Flac: Single-File versus Track-by-Track

Reply #7
Oops! Sorry.

WINE anyone?

Ripping Flac: Single-File versus Track-by-Track

Reply #8
single images are easy to manage when you think of tagging and storing data, because it will be a few files only. the downside on this, you might lose an entire CD if your file gets corrupted in optical media or HD, because that file got damaged, problem that would have been avoided if you had split to tracks: only one track would be damaged, at least thinking of a few corrupted sectors. the other downside is playback, it's a pain skipping tracks and trying to find where's what.

the split tracks strategy is the recommended for playback but storing data is more difficult, millions of files, and each file with its tag and coverart, so you get the idea when you have to embed album art in 2000 files.

i believe in the death of CD soon, so i don't care anymore for cuesheets or corrected gaps as long as they are ripped with appended gaps on previous track (default). music will be entirely digital in a few years.

Ripping Flac: Single-File versus Track-by-Track

Reply #9
WINE anyone?

I know!  It's not easy without Microsoft (though this is the only case you'll hear me say this without sarcasm).

i believe in the death of CD soon, so i don't care anymore for cuesheets or corrected gaps as long as they are ripped with appended gaps on previous track (default). music will be entirely digital in a few years.

Now that is a very good point.  I hadn't thought of that.  I guess my concern is more that ... well ... for example: on The Beatles' Abbey Road they have a number of tracks near the end that flow together -- during a shuffle of MP3 songs they all come apart -- which I don't care for.  So I am in the habit of joining those tracks I want to hear together into a single MP3 file.  But I guess, after these explanations, I should be able to accomplish that from either a single-file cuesheet or from multiple files.  I think I need more experimenting before I decide.

Ripping Flac: Single-File versus Track-by-Track

Reply #10
what is important is to establish a "future-proof" scheme. I personally have all Jean Michel Jarre collection in which case many tracks are blended into each other, yet I still split them in tracks - thinking ahead though - in the future more DAP players will handle FLAC and will support Gapless playback. Believe this Cuesheet deal will be over sooner than you think...

Ripping Flac: Single-File versus Track-by-Track

Reply #11
what is important is to establish a "future-proof" scheme. I personally have all Jean Michel Jarre collection in which case many tracks are blended into each other, yet I still split them in tracks - thinking ahead though - in the future more DAP players will handle FLAC and will support Gapless playback. Believe this Cuesheet deal will be over sooner than you think...


The CD may be dead but the idea of album ain't. So quite some people ( including me ) prefer to rip into a single file that you can  store or convert into other formats.

I would say the Cuesheet will stay for a while.

Ripping Flac: Single-File versus Track-by-Track

Reply #12
Perhaps we can stay on topic and suggest Mac/Linux tools that thornomad can use with single file images + cues that you all seem to be so keen on.

Ripping Flac: Single-File versus Track-by-Track

Reply #13
the other downside is playback, it's a pain skipping tracks and trying to find where's what.
Not when using an app that supports cuesheets, though...
Quote
the split tracks strategy is the recommended for playback[...]

Personally, then i agree on this statement, except in the case of when using foobar2000 for playback, as in that case then images with (embedded)cuesheets can be used for everything that track files can, and that includes full tagging capabilities. But in general speaking, then you are of course correct

Just my 2 cents

Ripping Flac: Single-File versus Track-by-Track

Reply #14
My FLAC library consists of all single-file images with embedded CUE sheet and album-art.

There is a plethora of software that can deal with these files:

burrrn for burning Audio CDs, Foobar/CUEProc to transcode them to a lossy format; just to name a few.


Just a question: is it possible to "mount" the cuesheet in a virtual CD drive and rip or play from there? Are there any virtual CD drives that support FLAC cuesheets? I have been storing a lot of albums as CD images, but it takes a lot of space.

 

Ripping Flac: Single-File versus Track-by-Track

Reply #15
and in preperation for getting a SqueezeBox



The squeezbox handles single file flac + cue pretty well. That's what I use, and then transcode to mp3 for portable use. I'm possibly going to switch to a Mac in the near future, so will need to find out what tools to use for transcoding (currently use Foobar).

-Audio Spyder

Ripping Flac: Single-File versus Track-by-Track

Reply #16
The squeezbox handles single file flac + cue pretty well.


But the Cuesheet MUST be an external file (not embedded into flac image), right?

bye

Ripping Flac: Single-File versus Track-by-Track

Reply #17
The squeezbox handles single file flac + cue pretty well.


Does it?  I asked this on the Squeezebox forums several months ago and was told it couldn't handle this (well, Slimserver couldn't).

Maybe time to reconsider the Squeezebox?

Ripping Flac: Single-File versus Track-by-Track

Reply #18
From reading the SlimServer changelog, then embedded cuesheets have been supported since atleast 2005.

Ripping Flac: Single-File versus Track-by-Track

Reply #19
Just a question: is it possible to "mount" the cuesheet in a virtual CD drive and rip or play from there? Are there any virtual CD drives that support FLAC cuesheets? I have been storing a lot of albums as CD images, but it takes a lot of space.

Yes it takes a lot of space... but if you have more than a handful of CDs backed up in this format, is another 760MB (max) of space really that much to uncompress the FLAC image into WAV?

I keep a since WAV image and CUE sheet so I can mount in Daemon and experiment with new CD audio grabbers or my a newly edited REACT.INI.
OP can't edit initial post when a solution is determined  :'-(