[Vorbis] bitrate limits don't work with -q settings?

[Monty]

On Wed, Dec 29, 2004 at 02:25:43PM -0500, Nic Watson wrote:
> Thanks for the quick response.  To get versioning out of the way, I 
> recompiled the libraries and oggenc from mainline svn yesterday night. 
> I see the same results.
> 
> Unfortunately, I am stuck on a stupid transport.  On the IRiver players, 
> any time the bitrate dips below 96kbps, you'll hear a click or pop, and 
> the song will usually end.  -q3 -m 96 doesn't work.  Is there any way to 
> use VBR and absolutely guarantee that the bitrate won't fall below a 
> certain level?  I figured that's what the bitrate_hard_min option was 
> for, but it seems to have the opposite effect.

[btw, 'bitrate_hard_min is an option from earlier versions of Vorbis.
If you upgraded libvorbis but not vorbis-tools, the tools will still
work but the obsolete options will likely be ignored]

Are you sure it's actually the bitrate minimum that's causing the
iRiver player to reject?  It's beginning to sound like iRiver put in
on purpose...

Anyway, the --managed and minimum bitrate code in 1.1 do what you
think they do; it will not let the bitrate fall below the configured
settings, even resorting to zero-padding frames to keep things up to
size if there's nothing useful left to encode.

The details may not be working the way you expect though.

a) the bitrate tracker works in terms of discrete bytes, that is, it
works in terms of frames having a desired integer number of bytes
each.  This introduces a minimum granularity to bitrate steps.

b) there's a bitbuffer that fills and empties. Depending on the
configuration, that buffer starts out some percentage of full.
Undersized frames will 'fill' it with 'unused' bytes.  The slop space
of this buffer will affect the final size of the file by an amount no
greater than the size of the bitbuffer.  Setting the bitbuffer to a
size of zero will seriously damage the output file by making the
encoder an insane-level of twitchy.

c) the limiting is being done over a time window.  The default is a
few seconds; that means that over a window of (eg) 4 seconds, bitrate
will not be allowed to drop below bitrate_hard_min.  However, some
area within that window may be below the hard bitrate.  Again, setting
the window size to zero will pretty much destroy the output quality.

Monty