Opus is now RFC6716, version 1.0.1 released!
Reply #93 – 2012-12-07 22:00:20
I don't think fb2k's Converter dialog yet includes an option to automatically resample Opus back to original sample rate by passing that data forward, but it's feasible in future. What would a valid use case for that be? Sounds like an option that mostly would allow people to shoot themselves in the foot. I'm not really claiming a good use case, and it's not worth any major programming time to add a feature, I'm sure, though I think fb2k does already pass on some metadata (at least a flag) to indicate when a lossy operation has occurred so it can 'dither only lossy sources' in the Convert dialogue. I think it also passes on the original bit depth when known. As an intellectual exercise, of little merit , the only performance-enhancing use-case I've thought of is suboptimal already , but knowledge of the source rate could plausibly reduce the degradation somewhat: • Imagine it is absolutely necessary to transcode from opus (as our only available source) into, let's say, mp3 for compatibility with a particular device. • As an aside, I own one for background music purposes in a café, where it sounds pretty good to be fair, though it's about to seem like a pile of $#!† in the words that follow: It's a DAB-One FM/DAB radio with mp3-on-SD-card playback that will play only mp3 files (or mp2 renamed as mp3), but never lossless, and it misbehaves by dipping the volume for a few seconds sporadically if it's fed with an AUX input on the 3.5mm stereo jack, even when it doesn't seem to peak as high as normal mp3 loudness (which I usually set to about 84.5 dB SPL Replay Gain, so not that high). • If the audio is known to contain nothing above the original sampling rate's Nyquist limit, resampling back to the original sampling rate will usually allow mp3 encoders to be more bitrate-efficient and thus produce lower bitrates for a given VBR quality, or higher quality for a given ABR/CBR bitrate target, thus reducing the transcoding degradation that might occur. I'm not sure whether such inefficiency is common to AAC or Vorbis, however. I could do that manually, and it's such a rare use case it's not worth any effort to implement just for that. Having opus-incompatible devices, where you might want to play back an opus podcast, say, might be a considerably larger use case, but still not enormous, and easy enough to over-ride manually, unless mass-converting podcasts from numerous sources with varied source sampling rates. The commandline using opusdec fed into LAME then becomes an option to automate the idea. I'm not suggesting it's an especially useful idea in general, but it would simply mirror the behaviour of the Opusdec commandline decoder (and only in Convert mode, not playback) which will decode to the exact same sample rate as the original, which is naively the 'expected behaviour' of a decoder, sometimes considered a principle of good intuitive software design to make this intuitive behaviour the default (i.e. returning the same number of samples and same file duration) unless it's noticeably harmful (the only harm is a little extra processor load). There is a population even among fb2k users that will expect the naive behaviour when converting and may cause enough annoyance on the forums to encourage its adoption in fb2k, but I somehow doubt it'll be seen as worthwhile. A non-naive user who understands what's inside the black box will happily over-ride the default if it's unnecessary to resample or deselect any pass-forward option in the Convert dialogue of fb2k. Opusdec's choice is pretty good as a defensive measure against spurious bug reports for 'unexpected behaviour' when you have a good resampler built in. It's fairly harmless as the resampler has far less distortion than a lossy codec and resampling will mostly happen for CD-sourced material with plenty of bandwidth between 20kHz and 22.05kHz, so in terms of shooting oneself in the foot, I'd argue that it's pretty much a blank round (to take the metaphor too far!). They'll find plenty of ways to hurt their feet, regardless! Xiph.org were also fairly clever about cut-off choices in the antialias filter, IIRC from reading the speex resampler source code they used in libopus, limiting bandwidth degradation from multiple lowpass filters.