[Flac] Archiving CDs w/ Flac on Unix (and subsequent re-encoding)

David Willmore davidwillmore at gmail.com
Sun Sep 12 20:13:52 PDT 2004


On Mon, 13 Sep 2004 12:03:17 +0900 (JST), Curt Sampson <cjs at cynic.net> wrote:
> On Sun, 12 Sep 2004, Brian Willoughby wrote:
> 
> > On a related note, are there any tools which can read the Index
> > information from a CD and preserve these in some file for later
> > recreation?
> 
> cdrdao.

:)

> > The actual TOC on a CD has very little information: just the Absolute
> > Start Time of each Track.
> 
> Are you sure you're not confusing TOC and CUE here?

I think he meant the TOC of a CD, not a toc file as created by
cdrdao--the latter is very detailed as it's created by an observation
of the disk while the former is queried from the media.

> If the TOC file was created by cdrdao, it will the catalogue number,
> track and index positions (for both audio and data tracks), copy and
> pre-emphasis flags, pre-gaps, track ISRC codes, at least CD-Text
> subchannel information.

Exactly.  And it's in a nice textual format that can be used to do
many things.  I think what we're all looking for here is a program
that can capture all of that information and preserve it in a
compresses-lossless format.  If we could just roll flac and cdrdao
together.  Then we could use th .toc file to read out parts of the
.flac file and feed them into oggenc along with the freedb
metainfo....

> > Is there any documentation of the "TOC" file format that is commonly
> > used?
> 
> I think you must be confusing TOC and CUE. CUE is sidely used; TOC is
> not: only cdrdao uses it as far as I know. The TOC file format is quite
> well documented (over 400 lines of documentation, including examples) in
> the cdrdao manual page.

Quite true.  Do you know of similar documentation for the .cue format?

> > I am (slowly) working on disk burning software that supports FLAC
> > directly, without requiring the time or disk space needed for
> > uncompressing the audio before burning.
> 
> You're still going to use the time anyway; you must uncompress before
> burning. So you'll save only the diskspace for the uncompressed image.
> I personally don't think it's that worthwhile; anybody with any number
> of FLAC compressed CD images around is not going to be wanting for less
> than 800 MB of free disk space.

You assume that the repository and the burning/reading meachine are
one and the same.  Think of a nice fat server and a burner/reader
client with just an 802.11b connection.  Temporary space may be at a
premium on the actual burner/reader machine but not on the server, but
bandwidth may be an issue between them.  Multiply this by a house full
of clients and it does start to become an issue.

Really, though, this is a tiny problem.  Tell FLAC just what chunk out
of a file you want and it'll produce it.  Alternately, teach FLAC
about a particular meta-info format inside .flac files while allows it
to determine that chunk by itself.  Six of one, a half-dozen on the
other....

Cheers,
David


More information about the Flac mailing list