opus - Dec 2015 - Beginner's questions/suggestions

Hi!

I was just trying libopus0-1.1-3.2.x86_64 and opus-tools-0.1.9-3.2.x86_64 on
openSUSE Leap, and I was wondering:

opusenc does not display the file name it processes. In Lunux when you use some
batch processing, it might be interesting! Example output for
"for f in *.wav;do opusenc --bitrate 160 $f ${f%.wav}.opus; done":
---just on file---
Encoding using libopus 1.1 (audio)
-----------------------------------------------------
   Input: 44.1kHz 2 channels
  Output: 2 channels (2 coupled)
          20ms packets, 160kbit/sec VBR
 Preskip: 356

Encoding complete
-----------------------------------------------------
       Encoded: 2 minutes and 11.98 seconds
       Runtime: 4 seconds
                (32.99x realtime)
         Wrote: 3042537 bytes, 6599 packets, 134 pages
       Bitrate: 183.292kbit/s (without overhead)
 Instant rates: 1.2kbit/s to 317.2kbit/s
                (3 to 793 bytes per packet)
      Overhead: 0.614% (container+metadata)
----
For the output, can't "Encoded:" and "Runtime:" be put
into one line? Likewise "Bitrate:", "Overhead:" and
"Wrote:". ANd the output file name could be given in
"Output:", while the input filename could be given in
"Input:".

The next thing I'm sursprised it that VBR bitrate 160 is exceeded even for
the average most of the time:
Bitrate: 170.496kbit/s (without overhead)
Bitrate: 183.803kbit/s (without overhead)
Bitrate: 169.95kbit/s (without overhead)
Bitrate: 177.964kbit/s (without overhead)
Bitrate: 168.99kbit/s (without overhead)
[...]

Regards,
Ulrich

On 21 December 2015 at 04:31, Ulrich Windl
<Ulrich.Windl at rz.uni-regensburg.de> wrote:
> opusenc does not display the file name it processes. In Lunux when you use
some batch processing, it might be interesting! Example output for
> "for f in *.wav;do opusenc --bitrate 160 $f ${f%.wav}.opus;
done":
In situations like this, i usually insert an 'echo $f;' before he
first command in the for loop.
> For the output, can't "Encoded:" and "Runtime:" be
put into one line?
Probably, although it's hard to fit all three fields in 80 columns.
> The next thing I'm sursprised it that VBR bitrate 160 is exceeded even
for the average most of the time:
The VBR encoding mode is designed to achieve comparable quality over a
large variety of audio with the requested average bitrate, by varying
that bitrate of each individual file depending on how difficult it is
to encode.

The bias you're seeing likely indicates that your audio collection
requires a few more bits to represent well than the collection the
encoder was tuned against. It's not a cause for concern.

Hope that helps, and thanks for your interest in Opus.

 -r

>>> Ralph Giles <giles at thaumas.net> schrieb am 21.12.2015 um
19:51 in Nachricht
<CAEW_RkshUM55uwdvU6DsE17pLZki651Xvvu7d2Y6jObePXZwCQ at
mail.gmail.com>:
> On 21 December 2015 at 04:31, Ulrich Windl
> <Ulrich.Windl at rz.uni-regensburg.de> wrote:
> 
>> opusenc does not display the file name it processes. In Lunux when you
use
> some batch processing, it might be interesting! Example output for
>> "for f in *.wav;do opusenc --bitrate 160 $f ${f%.wav}.opus;
done":
> 
> In situations like this, i usually insert an 'echo $f;' before he
> first command in the for loop.
> 
>> For the output, can't "Encoded:" and "Runtime:"
be put into one line?
> 
> Probably, although it's hard to fit all three fields in 80 columns.
My idea was this: It seems opusenc outputs quite a lot of stuff that looks to be
spread around lines rather arbitrary while missing the file names it's
working on. My suggestion was to rearrange and consolidate the output.
> 
>> The next thing I'm sursprised it that VBR bitrate 160 is exceeded
even for
> the average most of the time:
> 
> The VBR encoding mode is designed to achieve comparable quality over a
> large variety of audio with the requested average bitrate, by varying
> that bitrate of each individual file depending on how difficult it is
> to encode.
I thought the algorithm were using a kind of budget: I temporarily overused, the
next parts will be used using less bits. If the encoder bases the bitrate on the
complexity of the input, why try to mess with the bitrate at all? Can't we
say (like for JPEG) we want some quality (in percent), and the required bitrate
is guessed (and output at the end), or specify some maximum bitrate, and the
encoder outputs a guess of quality accieved for the given input.
I mean users should not have to know the very details of the encoding process to
perform a typical use case.
> 
> The bias you're seeing likely indicates that your audio collection
> requires a few more bits to represent well than the collection the
> encoder was tuned against. It's not a cause for concern.
> 
> Hope that helps, and thanks for your interest in Opus.
Yes & thanks!

Ulrich