On Mon, Nov 5, 2018 at 11:01 AM Jan Stary <hans at stare.cz> wrote: Attached I send the spectrogram (vic SoX) of the first 20 seconds> for the wav file and the opus file. Indeed, there is extra noise > for the low frequencies, but somewhere around -100 dB. > > Jan >That might be entirely due to SoX treating it as a 16-bit file, which it is not; -100dB is almost exactly the limitation of 16-bit. All Opus files are infinite-precision, and they'll encode the input at whatever precision is fed to them, but they do have a silence-detection mechanism which defaults to 16-bit in opusenc. SoX is either reading that value and erroneously assuming that's that internal precision, or just falling back on a 16-bit default because it has no information, but it would be more proper to _always_ decode to 24-bit to eliminate that broadband noise low bit depths create (except in the case of hardware limitations). As you've found, Opus is always 48kHz, never more, never less. Its resampler is very accurate, and should never introduce noise. My speakers and headphones definitely have issues with the sweep, so it's hard to isolate any differences. (I do love it though, it really gets my floor shaking; I'll keep it around for testing purposes.) The only remaining issue is the way that Opus doesn't even come close to respecting the requested bitrate for this sample. For instance, encoding it at 130 gives me a file of 210kbps. Over a wide corpus of music, I've noticed libopus almost invariably overshoots the bitrate, rather than averaging out close to it; only speech is consistently at or below it. Em -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20181105/8cd1cdd6/attachment.html>
Ulrich Windl
2018-Nov-06 06:54 UTC
[opus] Antw: Re: Antw: Re: Antw: Re: Possible bug in Opus 1.3
>>> Emily Bowman <silverbacknet at gmail.com> schrieb am 05.11.2018 um 20:46 inNachricht <CAGSVXPR6t8uHJFqDCT-1pn9otP_7ypPxgRXRasgZERunsAe0fA at mail.gmail.com>:> On Mon, Nov 5, 2018 at 11:01 AM Jan Stary <hans at stare.cz> wrote: > > Attached I send the spectrogram (vic SoX) of the first 20 seconds >> for the wav file and the opus file. Indeed, there is extra noise >> for the low frequencies, but somewhere around -100 dB. >> >> Jan >> > > That might be entirely due to SoX treating it as a 16-bit file, which it is > not; -100dB is almost exactly the limitation of 16-bit. All Opus files are > infinite-precision, and they'll encode the input at whatever precision is > fed to them, but they do have a silence-detection mechanism which defaults > to 16-bit in opusenc. SoX is either reading that value and erroneously > assuming that's that internal precision, or just falling back on a 16-bit > default because it has no information, but it would be more proper to > _always_ decode to 24-bit to eliminate that broadband noise low bit depths > create (except in the case of hardware limitations). > > As you've found, Opus is always 48kHz, never more, never less. Its > resampler is very accurate, and should never introduce noise.That's an interesting point: Why is that so? Couldn't the file size (and computing effort on encoding/decoding) be reduced when allowing different sample rates? Especially when the source has lower sampling rate, I wonder whether that isn't just a waste of bits...> > My speakers and headphones definitely have issues with the sweep, so it's > hard to isolate any differences. (I do love it though, it really gets my > floor shaking; I'll keep it around for testing purposes.) The only > remaining issue is the way that Opus doesn't even come close to respecting > the requested bitrate for this sample. For instance, encoding it at 130 > gives me a file of 210kbps. Over a wide corpus of music, I've noticed > libopus almost invariably overshoots the bitrate, rather than averaging out > close to it; only speech is consistently at or below it.Maybe there's some bug still undiscovered. Would you agree that Opus should encode a pure sinus tone efficiently? Or would it really prefer to encode white noise? Regards, Ulrich
On Mon, Nov 5, 2018 at 10:54 PM Ulrich Windl < Ulrich.Windl at rz.uni-regensburg.de> wrote:> >>> Emily Bowman <silverbacknet at gmail.com> schrieb am 05.11.2018 um 20:46 > in > Nachricht > > > > As you've found, Opus is always 48kHz, never more, never less. Its > > resampler is very accurate, and should never introduce noise. > > That's an interesting point: Why is that so? Couldn't the file size (and > computing effort on encoding/decoding) be reduced when allowing different > sample rates? Especially when the source has lower sampling rate, I wonder > whether that isn't just a waste of bits... >It significantly simplifies the internal structure, the spec, the encoder, and the decoder, without wasting any bits. OK, the collection of missing bands generates one or two bits per frame, after entropy coding, but that's not significant in any use case. Opus was specifically designed for this scenario and aggressively optimizes it. If only 4kHz is in the input, only 4kHz will end up encoded, even if it's first upsampled to 48kHz. Maybe there's some bug still undiscovered. Would you agree that Opus should> encode a pure sinus tone efficiently? Or would it really prefer to encode > white noise? >Whether efficiently encoding a continuously variable sine wave makes sense is waaaaaay outside my wheelhouse. Jean-Marc or Monty should answer that. I was just commenting on the fact that it probably needs to be re-runed at this point. Em -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20181106/12817d93/attachment.html>
Jan Stary
2018-Nov-06 14:16 UTC
[opus] Antw: Re: Antw: Re: Antw: Re: Possible bug in Opus 1.3
> > As you've found, Opus is always 48kHz, never more, never less. Its > > resampler is very accurate, and should never introduce noise.Thanks, that explains the size staying the same for "lower" rate.