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.
_______________________________________________
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
