Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Unexpectedly high bitrate? (Read 6172 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Unexpectedly high bitrate?

I am converting my lossless files into the opus format.

In most files, there is no problem, but encoding some files resulted in unexpectedly higher bitrate than the presumed bitrate.

I tried this sample with other codecs, and the result is:
OPUS (VBR; -b 128): 192 kbps
qaac (TVBR; -q 63) : 120 kbps
aoTuV 6.0.3 beta (VBR; -q 4.0): 135 kbps

I know the average bitrate in the VBR files can vary, but 1.5 times higher in this sample.

Here is the source tested: http://blogattach.naver.com/6efb72c2d28d8a...type=attachment

Is something wrong in my opusenc?

Unexpectedly high bitrate?

Reply #1
Quote
Forbidden

You don't have permission to access /6efb72c2d28d8a56789dfdc4f6176e1cb4ef11f3f0/20140916_178_blogfile/leejm516_1410868547920_qTt418_flac/buggy1.flac on this server.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
"I hear it when I see it."

Unexpectedly high bitrate?

Reply #2
Oops..

I uploaded the sample directly.

Thank you for notification.

Unexpectedly high bitrate?

Reply #3
The V in VBR stands for variable  Opus in VBR mode very specifically makes no attempt to try and provide the specified bitrate.  It is essentially a quality level that provides that average bitrate over a "large and diverse collection of audio", but could theoretically provide almost anything on a particular track, especially a short sample with a fairly constant type of sound.

If it is important to restrict the bitrate of each stream to a narrow range there is a CVBR mode which allows frame bitrates to vary but calculates the overall quality level for each track to provide (very close to) the specified bitrate.  There is also a hard CBR mode which provides the same bitrate for every frame.

Unexpectedly high bitrate?

Reply #4
With opus-tools 0.1.9 (libopus 1.1) I also get 196 kbps. With version 0.1.6 (libopus 1.0.2) I get 125 kbps.

That's the new VBR analysis code in libopus 1.1 that causes the difference, I guess.
"I hear it when I see it."

Unexpectedly high bitrate?

Reply #5
Opus contains a tonality estimator which boosts bitrate for samples like this to maintain constant quality. See here, roughly in the middle of the page. I would call the behavior expected and desired.

Btw: Musepack uses 218 kbps with q5 where it would normally average to 170 kbps.

Unexpectedly high bitrate?

Reply #6
Opus contains a tonality estimator which boosts bitrate for samples like this to maintain constant quality. See here, roughly in the middle of the page. I would call the behavior expected and desired.

Btw: Musepack uses 218 kbps with q5 where it would normally average to 170 kbps.


Oh, this smart encoder intentionally boosts bitrates for tonal sounds.
If I understood correctly, this feature is to compensate disadvantages due to the low-latency nature of Opus.

This is not an "unexpected". 

Unexpectedly high bitrate?

Reply #7
Quote
Oh, this smart encoder intentionally boosts bitrates for tonal sounds.
If I understood correctly, this feature is to compensate disadvantages due to the low-latency nature of Opus.
  I don't think latency (delay) has anything to do with it.  If you are playing a recorded file, you don't care about several milliseconds of latency.  Who cares about a few milliseconds of delay when there might have been many years of delay since that old Beatles song was recorded.... 

I don't know much about Opus, but...  Some sounds are easier to compress than others.    With "simple" sounds you can use a low bitrate and get good quality results.  Other sounds are harder to compress and you need a higher bitrate to get good quality.    If you choose a "quality" setting rather than constant-fixed bitrate, the encoder is smart enough to figure-out what bitrate is needed to get your requested audio quality.

Unexpectedly high bitrate?

Reply #8
It's not the actual latency in the playback that matters, but that Opus was designed primarily to operate efficiently in low latency applications and thus does not include long-blocks (and the signalling overhead they would incur) as an option in the bitstream.

It thus cannot use blocks in the 90-100 ms range as are available in AAC for example.

It emerges from the complicated mathematics of windowed transforms, that the longer the window (or block) in the time domain, the more narrowly it represents individual frequencies when transformed into the frequency domain. This helps concentrate the energy of tonal signals into tighter clusters of adjacent frequency-domain samples, which makes them easier to compress, and easier to reduce the bit-depth (quantization accuracy) without introducing audible variations.

If you have a long window, yet it contains a very shorty transient pulse or step response, when you transform the pulse or step into the frequency domain, its energy that was so concentrated in the time domain will be spread almost evenly among every single frequency domain component as very low energy per band, and the inverse transform will only reproduce the sharp transient pulse accurately at the correct time if you provide accuracy equivalent to lossless bitrates. If you reduce the bit-depth in the frequency domain - e.g. because you can't spare such a high bitrate - the pulse will be smeared out over a flatter, broader pulse in the time domain, causing less of a sharp click and more of a noisy hiss. Thus long blocks are really bad at efficiently encoding transient signals like clicks because you need high quantization accuracy to stop the energy of the clicks from spreading out in the time domain.

This is why transient detection and short-block switching are vital for efficient encoding.

On the flip-side if you spot a transient and switch to a short block, now time accuracy is better, but you cannot provide the bit-depth to accurately reproduce narrow frequency peaks without supplying nearly lossless bitrates (albeit, that supplying 1400 kbps for only 4 or 5 ms uses fewer bits than supplying 1400kbps for 90-100 ms).

Problem samples like fatboy (from the song Kalifornia) needed practically 1400 kbps momentarily but very frequently in codecs like Musepack to remain transparent for this sort of reason. The sample contains a succession of regular repeating transient sounds that need high time resolution combined with tonal frequencies that require adequate frequency resolution.

Likewise, for samples like harpsichords, the CELT layer of Opus needs to increase the bitrate markedly to represent the pure tones with strong harmonics accurately yet still capture the sharp plucking sound at the onset of each note. In Opus 1.1, that's what the tonality estimator does in the default VBR mode when it detects this situation.

Opus also has some other tricks to allow medium-to-long block type frequency resolution at some frequency bands while also allowing short-block type time resolution in other bands. It's explained in technical detail in the Opus Codec website and technical presentations.

For more normal degrees of tonality, where 20ms blocks are a little bit shorter than ideal, Opus also features a tuneable pre-/post- filter to preferentially improve the encoding of tonal sounds without employing either long blocks or excessive bitrates.

In the range of normal music that is most commonly encountered, this proves to be very efficient (i.e. high quality per bitrate), and it requires the encoder to spend extra bits only in relatively uncommon situations like harpsichord or certain bell sounds, yet retain the ability to be used at low latency too.

It turns out that the constraint of aiming for low latency and eliminating out-of-band signalling led the developers of CELT and Opus to some very clever and effective solutions which overcome most of the penalties expected by shooting for low latency. Only in reducing the latency further (e.g. 10ms or 5ms) does the short-block penalty become rather more significant, requiring an increase in bitrate to maintain quailty.
Dynamic – the artist formerly known as DickD

 

Unexpectedly high bitrate?

Reply #9
OK, let me correct a few facts here.

It's not the actual latency in the playback that matters, but that Opus was designed primarily to operate efficiently in low latency applications and thus does not include long-blocks (and the signalling overhead they would incur) as an option in the bitstream.


Opus does include "long blocks". The "normal frames" are 20 ms long (960 samples at 48 kHz).

Quote
It thus cannot use blocks in the 90-100 ms range as are available in AAC for example.


AAC does *not* use 90-100 ms frames (maybe in can in theory, but that would be stupid). The 100+ ms delays you see quoted are mainly due to other "filters" and tools, such as SBR, parametric stereo, etc. Similarly, Vorbis can use huge frame sizes, but in practice it generally uses frames of 23.2 ms (1024 samples at 44.1 kHz). The main difference between Opus and Vorbis/AAC in terms of frequency resolution comes from the overlap used in the transform. Vorbis and AAC use a full overlap, i.e. the actual MDCT window overlaps half of the previous frame and half of the next frame, making the actual window twice as large. In the case of Opus, the overlap is reduced to only 2.5 ms to minimize algorithmic delay. The cost is increased leakage for tones.

Another things that makes Opus slightly worse on tones is its implicit psychoacoustic model. Opus assumes that most sounds are much more complex than the mere combination of a few tones, and that allows it to save bits on the vast majority of audio signals. On the other hand, for the few really simple audio signals out there (e.g. folks that test with sine waves), Opus does worse than many other codecs.

Quote
Problem samples like fatboy (from the song Kalifornia) needed practically 1400 kbps momentarily but very frequently in codecs like Musepack to remain transparent for this sort of reason. The sample contains a succession of regular repeating transient sounds that need high time resolution combined with tonal frequencies that require adequate frequency resolution.


My understanding of Musepack is that it has very good time resolution, so I assume that if it has bit-rate issues with fatboy it's probably another problem (e.g. entropy coding of sharp transients).