Hi folks,

We're gearing up to the next full release of the Vorbis codec; I've
just tagged a release candidate in SVN in order to encourage wider
testing toward final 1.1 release.

This release includes the following updates:

1) Adoption of AoTuV and other tuning work by Vorbis developers
  outside of Xiph into the mainline codebase
2) New bitrate management code
3) bugfixes

In more detail:

1) Adoption of AoTuV tunings

The AoTuV encoder substantially improves the basic tunings of the
1.0.1 encoder for 32,44.1 and 48 kbps input samples.  This 1.1 release
merges the AoTuV tunings into the mainline Xiph codebase along with
other tuning tweaks.  The AoTuV tunings are unchanged from the AoTuV
encoder with the following exceptions:

  a) bugfix to AoTuV code section 'M1'; after discussion with Aoyumi,
we agree that the second tuning case both triggered relatively
seldomly and did not produce the intended results when it did trigger.
The predominating first case ('partial masking') is now used for all
samples.  This should address some minor pure tone instability issues
in the AoTuV encoder.

  b) Changes to book construction, training, and on-the-fly adjustment
to allow the AoTuV tunings to work properly with bitrate management.

  c) AoTuV introduced quality ranges down to -2; the 1.1 Xiph
libvorbisenc implements the same modes but maps them down to -1 as in
previous Xiph releases.  The bitrate of quality -1 in 1.1 is similar
to quality -1 in 1.0.1 but the quality of the output is improved.

2) New bitrate management code

After use case analysis, I concluded that the 'sliding window'
approach to bitrate bounding and management in previous encoders was
not usefully more featureful than the more standard 'bit reservoir'
approach used in the rest of the industry.  In addition, the bit
reservoir approach uses substantially less memory in the encoder.  For
these reasons, the 1.1 libvorbisenc moves to implementing bitrate bounding
and management by using a bit reservoir.

The bit reservoir is also conceptually easier to understand; the
encoder has a fixed bucket size for 'slop space' in encoding.  When a
frame is smaller than the desired rate, the unused bits go into the
reservoir so that they may be used by future frames.  When a frame is
larger than target bitrate, it draws 'banked' bits out of the
reservoir.  Encoding is managed so that the reservoir never goes
negative or fills beyond a fixed limit.

The 1.1 libvorbisenc allows setting the fixed reservoir size (in bits,
defaulting to two seconds worth of requested bitrate) and 'hoarding'
behavior (whether the encoder tends to keep the bit reservoir more
full or more empty) as well as the other encoding heuristics available
through the API of 1.0.1.

3) bugfixes

See SVN for a more details; I'll collect a list for the full release.

There are vorbisenc API additions to handle the new bit reservoir
configuration; I will describe those in more detail tomorrow.  The
binary API is undisturbed; deprecated calls are are all mapped to the
new infrastructure.  I *believe* oggenc is already updated to the new
API.

Have at, have fun, report bugs.

Monty

  c) AoTuV introduced quality ranges down to -2; the 1.1 Xiph libvorbisenc implements the same modes but maps them down to -1 as in previous Xiph releases.  The bitrate of quality -1 in 1.1 is similar to quality -1 in 1.0.1 but the quality of the output is improved.

Congratulations!!!
I made a win32 binary of OggEnc (1.1rc1; MSVC2003) and Ogg Vorbis DLLs (1.1rc1; MSVC2003).

PS: You are faster than I, QuantumKnot

svn co http://svn.xiph.org/tags/vorbis1_1_public_release_candidate_1/

Code: [Select]

svn co http://svn.xiph.org/tags/vorbis1_1_public_release_candidate_1/

svn co http://svn.xiph.org/trunk/vorbis/ vorbis-svn-head

the DLL's = corrupt.

That's something I wonder. Why not allow lower bitrates than q -1? I was forced to use 22050Hz in my listening test to be able to reach 32kbps, and it seems Vorbis was considerably... erm... "handicapped" because of that (I'd better not talk much about it yet)

Roll AoTuV's -q -2 and -q -1 into libvorbis -1 (AoTuV q -2 gives
bitrate performance similar to 1.0.1's -1)

Quote

That's something I wonder. Why not allow lower bitrates than q -1? I was forced to use 22050Hz in my listening test to be able to reach 32kbps, and it seems Vorbis was considerably... erm... "handicapped" because of that (I'd better not talk much about it yet)

I'm not sure but Monty's log message says:

Quote

Roll AoTuV's -q -2 and -q -1 into libvorbis -1 (AoTuV q -2 gives
bitrate performance similar to 1.0.1's -1)

Also, is there some sort of bug which degrades quality when using the internal resampling routine?  Why does resampling with SSRC sound better?

ff123

Quote

Quote

That's something I wonder. Why not allow lower bitrates than q -1? I was forced to use 22050Hz in my listening test to be able to reach 32kbps, and it seems Vorbis was considerably... erm... "handicapped" because of that (I'd better not talk much about it yet)

I'm not sure but Monty's log message says:

Quote

Roll AoTuV's -q -2 and -q -1 into libvorbis -1 (AoTuV q -2 gives
bitrate performance similar to 1.0.1's -1)

I think Roberto meant why not allow lower bitrates than about 40 kbps when using 32 kHz resampling (which is what -q -1 will net you with that resampling rate).  I would guess that 32 kbps at 32 kHz resampling would sound as good as or maybe even better than 32 kbps at 22.05 kHz resampling.

Also, is there some sort of bug which degrades quality when using the internal resampling routine?  Why does resampling with SSRC sound better?

ff123

Some codecs that are, at least on the appearances, technically inferior to Vorbis, like WMA, accept encoding at 32kHz and even 44.1kHz at 32kbps. And being able to use 32kHz seems to have been favourable to WMA, according to preliminary results

I would guess that 32 kbps at 32 kHz resampling would sound as good as or maybe even better than 32 kbps at 22.05 kHz resampling.

Adoption of AoTuV and other tuning work by Vorbis developers
  outside of Xiph into the mainline codebase

1) Adoption of AoTuV and other tuning work by Vorbis developers
  outside of Xiph into the mainline codebase

Quote

Also, is there some sort of bug which degrades quality when using the internal resampling routine?  Why does resampling with SSRC sound better?

ff123

Because the ssrc routines are superior to the internal ones. 

Vorbis can do that.... why resample when you can just apply at 15.1 kHz lowpass filter? I think the current code does that unless I am thinking of something entirely different just ignore the fact. I think that's what the code in -q -1 area does maybe(?).

Is this bit reservoir going to break backward compatability as far as decoders go?  (i.e., will a RC3 or 1.0 decoder be able to handle 1.1 streams?)
[a href="index.php?act=findpost&pid=224092"][{POST_SNAPBACK}][/a]