On Monday, July 23, 2018 at 3:33:31 PM UTC-7, Timothy B. Terriberry wrote: > raycarino--- via dev-media wrote: > > 1. How does a high sample rate decoded at a lower sample rate behave? > > Example: will decode(48kHz.ogg 16kHz) === decode(16kHz.ogg, 16kHz), or can > > audio artifacts be expected? > > They won't give bit-identical results, but with some hand-waving about > the version encoded at 48 kHz having enough extra bits to make sure it > maintains the same quality for frequencies in the 0...8 kHz range, they > should sound the same. You don't have to worry about aliasing or > anything like that. The high-frequency content, if any, in 48kHz.ogg > will be removed properly. > > > 2. Similarly, how does a low sample rate decoded at a higher sample rate > > behave? Example: will decode(16kHz.ogg, 48kHz) === decode(16kHz.ogg, > > 16kHz), or can audio artifacts be expected? > > These should sound the same without any hand-waving. > > In both cases the quality loss from using the decoder API at a different > sample rate than used by the encoder API should be smaller than the loss > introduced by using lossy compression to begin with. In the first case > you will obviously also lose any HF content, but this shouldn't > introduce artifacts in what remains. > > > I'm hopeful that decoding with a different sample rate either has no > > distortion, or minimal distortion because: > > (a) Firefox always seems to decode at 48kHz > > https://github.com/mozilla/gecko-dev/blob/f822a0b61631cbb38901569e69b4967176314aa8/dom/media/ogg/OpusParser.cpp#L46 > > (b) Chrome also seems to always decode at 48kHz > > https://github.com/chromium/chromium/blob/d196d28f53d37bad65feac0c0fb87a3b2c9480e9/remoting/codec/audio_decoder_opus.cc#L25 > > "Always use 48 kHz" is a fine approach. The real reason to use lower > sampling rates is if you want to run your whole audio pipeline at the > lower rate. Sometimes for real-time conferencing that can reduce the > processing required for other parts of the pipeline, like the echo > canceler, and improve their reliability. On small embedded devices it > can avoid wasting memory and cycles and save a separate resampling step > if your ADC or DAC aren't going to be run at the higher rate anyway. > None of those are of much concern for media playback in a browser.
Thank you so much for all of your help! This all makes sense. All of my outstanding questions have been answered. _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
