Help - Search - Members - Calendar
Full Version: Flexibility of Cuesheets
Hydrogenaudio Forums > Lossless Audio Compression > Lossless / Other Codecs
TheSpeedoBeast
I have been looking into converting my cd collection to flac for the past day so (getting there slowly!), and I THINK that I am going to go ahead and make my whole collection into single-file flac files with a separate cuesheet.

Is there anything I should watch out for, considering the compatability of being able convert both to mp3/lossy AND burning to a cd (while making everything gapless as the original was)? I have been reading this forum and am just worried about messing something up and having days worth of ripped cd's being unable to be properly converted between formats when in the single-file flac album format. This may not make enough sense; let me know if you need a clarification blink.gif

(Basically, does single-file flac with a non-imbedded cuesheet convert PERFECTLY to both mp3/lossy and cd? And will the cd be identical to the original cd?)
TheSpeedoBeast
One more thing that I forgot about: what is the flac community's position on data tracks on cd's? Just annoyances, or should they be preserved through a long series of extra steps?
Synthetic Soul
IMHO, with tools like foobar and ACDIR to convert image files with cuesheet to track files (e.g.: MP3), a single FLAC file with cuesheet is a very good option.

If you read enough on the forum, and your head doesn't explode before you're through, you'll see that burning bit-identical CDs from a rip is not always possible. However, it is as good as you are going to get (which is 99% perfect). If you want to know what I am talking about here, search for the word "offset", and probably Pio2001 (who is an HA member with a great knowledge in this area).

Again, IMHO, I would get EAC set up well, set up the read and write offset for your drive, start ripping, and be comfortable in the knowledge that you are doing the best you can.
TheSpeedoBeast
So they won't be bitidentical, but they will at least be detected by cddb, correct? And sound the same? I am more concerned with sound quality and cddb compatability than having perfect bitidentical copy of the cd. Just SO MANY variables to mess up on with this lossless codec stuff!
Synthetic Soul
Yes, as far as my experience goes, they will be detected by CDDB/freeDB, and sound the same. The only minor concern is the possibility to miss a few samples off the beginning or end of the CD, which may have audio data. We are talking milliseconds here though, and most CDs will have silence right near the start and end anyway. So, many CDs may even be bit-identical - or near as damnit.

NB: I archive to Monkey's Audio with cuesheet, and I embed the cuesheet in the file.
TheSpeedoBeast
Is the general consensus that embedding (in flac) is too limited to bother with, and that external cuesheets are just easier to deal with? That seems to be a rather... intense point of discussion around these forums!
Synthetic Soul
There's two ways to embed in FLAC.
  1. The FLAC meta block. Can be used to split the FLAC (using FLAC.EXE) by track. People complain as it won't store PERFORMER/TITLE info.
  2. A VORBIS CUESHEET tag. You can store what you like, and I believe foobar can use it just fine, as it can Monkey's Audio and WavPack embedded cuesheets.
That said, external cuesheets are just inherently easier to use, as you don't have to worry about that sort of crap. Also, if you are burning to CD, you may need an external cuesheet - although I believe burrrn now supports embedded cuesheets - and obviously foobar does..

I embed so I only have to worry about one file - but I also keep the external cuesheet, as it's only 2-3KB.
TheSpeedoBeast
Well, if no one can else suggest anything that I could ridiculously screw up in wack/eac's settings, I am going to go ahead and start on this chore! Thanks.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2008 Invision Power Services, Inc.