2 cents from a comp. sci guy
i addition to being a software architect for ibm, i am a professor of computer science at bowie state university, and have been involved in science technology projects for NASA, NOAA, and the Chinese Acadamy of Sciences dealing with real-time satellite systems. the issue is the real time ability of the equipment you use, and the algorithms that equipment employs. if you are using a software conversion algorithm offline, then your chances of success are enhanced. even when dealing with multi-billion dollar satellite systems that are supposed to be able to handle any circumstance, you have data dropouts. do you really think that won't happen with a piece of equipment that only cost a few thousand?
every second your DSP takes 48,000 snapshots of your audio wherein the value is between 0..16777215, and it must convert that value to 44,100 samples per second wherein the value is 0..65535 for your CD.
so let's immediately squash the idea of recording at 16bits because 24 bits is 256 times more accurate when dealing with the variation of sound pressure between each instance of a recorded sound. even if you have to dither in the end, 256 times more accuracy when throwing the tracks into some processing algorithm is better than the one time loss of dropping the remainder in the conversion from 24 to 16 bits.
now let's take the samples per second. 48000 / 44100 = 1.088435 (reduced for brevity). that means for each 1.088435 samples, you keep 1 sample. how is that possible? you don't take the sample unless the difference between the number of samples is > 1.088435.
here's an oversimplified example:
let's say you want to convert 8 samples to 5.
sample 1 (1 - 1.6 = -0.6 so throw it out)
sample 2 (2 - 1.6 = .4 keep it and hold the remainder)
sample 3 (1.4 - 1.6 = -.2 so throw it out)
sample 4 (2.4 - 1.6 = .8 keep it & hold the remainder)
sample 5 (1.8 - 1.6 = .2 keep it & hold the remainder)
sample 6 (1.2 - 1.6 = -4)
sample 7 (2.2 - 1.6 = .6 keep it)
sample 8 (1.6 - 1.6 = 0 keep it)
see how you end up with samples 2,4,5,7 & 8? not exactly evenly spaced is it? but remember we are talking about removing 3900 samples over a pool of 48,000 samples per second. that basicly means removing 1 sample for every 12 or so samples. synopsis: if you have an algorithm that solves the time sychronization issues demonstrated in the one above, you have no reason not to record at the higher sampling rate. i used a similar algorithm for displaying GOES-9 satellite images.
final thought:
a non-real time software algorithm for sample rate conversion is the best solution. if you are using a real time DSP, you take a calculated risk. but that risk is mitigated over time, because algorithms get better and hardware gets faster.