> The total output written to a CD must be a multiple of 2352, because
> you must write some number of physical sectors. In DAO mode I am less
> clear why padding would be needed, assuming that all the wav files are
> concatenated into a single "track" generated on-the-fly. I don't know if
> cdrecord is able to do this.
Part of the problem, I think, is defining where the track boundaries
are supposed to be (in the TOC and subcode). The CD format defines
track start points as being on frame (sector) boundaries - there's
no way to tell the TOC to point at any finer granularity in the file.
If you're catenating .WAV or .CDR files together on the fly, and
the files aren't all even multiples of a sector size, then _somebody_
has to make a command decision - either pad any file which isn't
a frame-multiple, or "mis-set" the corresponding track start point
in the TOC by rounding it to a frame boundary (round up, round down,
round-to-nearest-frame, or pick-one-at-random).
At the moment, it looks as if cdrecord can do only the "pad" style
of management. I don't recall offhand what cdrdao does.
> I haven't looked at audio tools in a while, but there are certainly
> some which can concatenate the tracks. Unfortunately this doubles your
> CD image disk requirements.
Right... you can do this with the soundutils (sox) package.
It would then be possible to pad the total file out to a frame
boundary, and construct a .TOC file for cdrdao which would specify
the correct ranges of the single file for each track. The TOC-
constructing program could make the "round to boundary" decisions
for any track which requires one.
This would allow for a seamless play-through of the audio. It
would, however, introduce some slight additional risk that there
would be odd effects if you were to seek to any individual track...
but this isn't a very precise operation in any case.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
