r 88.1) kHz because it is the least common multiple of those two sample rat=
es (see http://en.wikipedia.org/wiki/Sample_rate_conversion). Actually I wa=
s referring here to a previous post (http://tech.groups.yahoo.com/group/nat=
urerecordists/message/40783). So, I'm sorry for the confusion...
> Regardless... it might take more processing time, but is that additional =
processing time *really* an issue these days when running a stereo file thr=
ough an SRC? If it takes me twice as long or more, but yields a better/clea=
ner/more natural end result, I'll spend the time (unless it's a paid job an=
d I'm charging by the hour, in which case I'll inform the client of the opt=
ions and let him/her decide).
Sure, but I still doubt that there would be any benefits if one just needs =
to convert between 88.2 and 44.1 kHz.
> I was not referring to upsampling, just to the false argument that people=
use (when supporting integer sampling rate relationships), which says that=
the benefit of going from 88.2ks/s to 44.1ks/s (for example) is that you s=
imply delete every second sample. The supposed 'benefit' from this argument=
is that there will be no loss in quality because the SRC'd signal still co=
ntains the original sample values. That supposed 'benefit' is negated becau=
se the values still must be filtered (before SRC), so the sampled values in=
the 44.1ks/s stream are not the same as those in the original 88.2ks/s.
Yes, but at least in interpolation-based SRC algorithms (which can potentia=
lly introduce some distortion besides the effects of poor anti-aliasing fi=
lters), the conversion would be still be more straightforward.
Regards,
Raimund
|