>> the rate at which data arrives over s/pdif *is* the exact sample rate >> that the CD is burning at (well, unless you're insane). there is no >> need for throttling, pitch control or anything like that. you just >> buffer the data on startup to protect against latency glitches, >> convert the samples to 16bit, big-endian (the red book standard), and >> feed it to the CD recorder. end of story (other than the little >> details). > >is that rate really exactly the same? can not the clock in the device >producing the s/pdif signal have a slightly different notion of time >than the one in the cd recorder?
s/pdif is self clocking. its possible for there to be a little bit of jitter, but thats what the buffering is for. look, there is no mystery here: cdrecord can do this as well. its just a horrible (though powerful) program. if you buffer 5 seconds worth of audio before starting the burn, no amount of jitter that the signal might have will cause a problem over the duration of an audio CD. --p
