Starting this thread as a collection of real-life anecdotal evidence regarding quality loss pitfalls with sub-standard SRC (Sample Rate Conversion) implementations lurking in the wild that can and do bite in various expected and unexpected situations.
But first, let me share a link to an online database that allows anyone to browse and compare technical test results for the vast "zoo" of SR Converters out there (sadly, they only tested 96k to 44.1k conversion, but some converters can ruin even lower-to-higher conversion at integer multiples, such as 44.1k to 88.2k *cough*coreaudio*cough*):
https://src.infinitewave.ca
2024-NOV-01 Info: Thank you everyone, for making MC100 a resounding success. Please show Songwriting Competition 087 the same love.
SRC (Sample Rate Conversion) Pitfalls
Re: SRC (Sample Rate Conversion) Pitfalls
Sharing my recent pitfall: I had just submitted my entry to MC091 the day before (a wave file @44.1k), but when I played it back from my browser (Safari) in the morning with rested fresh ears, the mixdown sounded a bit off to me - it was still the same mix, sort of, but there was suddenly something "ear-fatiguing" going on in the top end that I didn't recall hearing the day before when I had last played it back from the DAW (Logic), and there was also some definition lost from the stereo image that I couldn't quite put my finger on
My first fear was that perhaps Logic had botched something during the final render and so my entry may have been doomed , as the Game Rules do NOT allow for any re-uploads. At this point it should be noted that my Audio Interface is running at 88.2k, and with a good reason, let me explain - almost all of Logic's stock plugins lack oversampling support; so in order to reduce aliasing, it is necessary to run Logic projects at a sampling rate of at least 88.2k or higher, and to append a low-pass filter at 20k after each instance of any non-linear stock plugin, such as compressor, gate, saturation, etc. This works fine because Logic's built-in SRC implementation is of good quality. So I did a null-test by taking my final 44.1k render and converting it back to 88.2k so I could flip the phase on it and play back side-by-side with a 88.2k render - everything nulled out perfectly. This meant that no information loss had occurred after 2 passes of Logic's SRC (i.e., going from 88.2k to 44.1k and then back to 88.2k again from there), and that my final 44.1k render was in fact OK, and that the quality loss must have occurred during playback from Safari
Then it hit me - CoreAudio SRC must have been the culprit during playback from Safari (since I had just ruled out Logic with a null test). This also meant that this playback quality loss had affected my impression of every single fellow competitor's mixdown that I had already listened to , and so I will need to set my Audio Interface to 44.1k first and THEN re-listen to all competitors' mixes again, if I want to get a more objective impression of everyone else's work.
Main takeaway for anyone listening to music on a Mac on any app that uses CoreAudio's built-in SRC (such as, but not limited to, a web browser): make sure your Audio Interface sample rate matches the sample rate of the audio file, or else there will probably be noticeable loss of audio quality!
My first fear was that perhaps Logic had botched something during the final render and so my entry may have been doomed , as the Game Rules do NOT allow for any re-uploads. At this point it should be noted that my Audio Interface is running at 88.2k, and with a good reason, let me explain - almost all of Logic's stock plugins lack oversampling support; so in order to reduce aliasing, it is necessary to run Logic projects at a sampling rate of at least 88.2k or higher, and to append a low-pass filter at 20k after each instance of any non-linear stock plugin, such as compressor, gate, saturation, etc. This works fine because Logic's built-in SRC implementation is of good quality. So I did a null-test by taking my final 44.1k render and converting it back to 88.2k so I could flip the phase on it and play back side-by-side with a 88.2k render - everything nulled out perfectly. This meant that no information loss had occurred after 2 passes of Logic's SRC (i.e., going from 88.2k to 44.1k and then back to 88.2k again from there), and that my final 44.1k render was in fact OK, and that the quality loss must have occurred during playback from Safari
Then it hit me - CoreAudio SRC must have been the culprit during playback from Safari (since I had just ruled out Logic with a null test). This also meant that this playback quality loss had affected my impression of every single fellow competitor's mixdown that I had already listened to , and so I will need to set my Audio Interface to 44.1k first and THEN re-listen to all competitors' mixes again, if I want to get a more objective impression of everyone else's work.
Main takeaway for anyone listening to music on a Mac on any app that uses CoreAudio's built-in SRC (such as, but not limited to, a web browser): make sure your Audio Interface sample rate matches the sample rate of the audio file, or else there will probably be noticeable loss of audio quality!