Vorbis dev - Jul 2004 - vorbis 1.1 rc 1 now tagged in SVN

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

On Thu, 8 Jul 2004 00:42:44 -0400
xiphmont@xiph.org (Monty) wrote:
> 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.
What versions of the auto-tools are required ?



--
Giuliano.

<20040710232004.71e14157.pochini@shiny.it>
Message-ID: <1089634982.17460.5.camel@dot.uniqsys.com>

On Sat, 2004-07-10 at 17:20, Giuliano Pochini wrote:
> On Thu, 8 Jul 2004 00:42:44 -0400
> xiphmont@xiph.org (Monty) wrote:
>
> > 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.
>
> What versions of the auto-tools are required ?
automake 1.7.8 and autoconf 2.57 seem to be working for me. Your mileage
may vary.

-Carsten

<20040710232004.71e14157.pochini@shiny.it>
Message-ID: <1089634982.17460.5.camel@dot.uniqsys.com>

On Sat, 2004-07-10 at 17:20, Giuliano Pochini wrote:
> On Thu, 8 Jul 2004 00:42:44 -0400
> xiphmont@xiph.org (Monty) wrote:
>
> > 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.
>
> What versions of the auto-tools are required ?
automake 1.7.8 and autoconf 2.57 seem to be working for me. Your mileage
may vary.

-Carsten

<20040710232004.71e14157.pochini@shiny.it>
<1089634982.17460.5.camel@dot.uniqsys.com>
Message-ID: <Pine.LNX.4.58.0407122248500.22445@denise.shiny.it>



On Mon, 12 Jul 2004, Carsten Haese wrote:
> > What versions of the auto-tools are required ?
>
> automake 1.7.8 and autoconf 2.57 seem to be working for me. Your mileage
> may vary.
It works, but I also had to update libtool.


--
Giuliano.

On Thu, Jul 08, 2004 at 12:42:44AM -0400, Monty wrote:
> 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
Just curious: what about Garf's tunings?
> 2) New bitrate management code
> 3) bugfixes
>
Petr Tomasek

--
Petr Tomasek, http://www.etf.cuni.cz/~tomasek/

<20040714180845.GA29983@ebed.etf.cuni.cz>
Message-ID: <20040714181517.GP19489@i.cantcode.com>
> > 1) Adoption of AoTuV and other tuning work by Vorbis developers
> >    outside of Xiph into the mainline codebase
>
> Just curious: what about Garf's tunings?
It's my understanding that they were subsumed by the AoTuV tunings
and/or the AoTuV tunings did the same things but better.

jack.

On Thu, 8 Jul 2004 00:42:44 -0400
xiphmont@xiph.org (Monty) wrote:
> 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.
Great! Just one thing. Where is it? I didn't see a URL to it in the mail and
the
xiph.org SVN page gives me a 404. :/

Regards
Oscar

<20040714214005.1f529fbb.oscar.sundbom@swipnet.se>
Message-ID: <20040714231216.GC26853@griffon>

Oscar Sundbom (oscar.sundbom@swipnet.se) wrote:
> Great! Just one thing. Where is it? I didn't see a URL to it in the
mail and the
> xiph.org SVN page gives me a 404. :/
Good question!  The web site still refers to CVS everywhere.  I went to
"svn.xiph.org", recalling seeing that domain somewhere, somewhen. 
That
worked pretty well.  Navigated through links at random, found a README
file inside the vorbis1_1_public_release_candidate_1 directory, and
even *that* still refers to CVS.

So I tried this, and it seemed to work.  This is the first time I've ever
used Subversion, so bear with me if I seem like a newbie.  It's because
I *am* one.

sudo apt-get update
sudo apt-get install subversion
cd /usr/src
svn co http://svn.xiph.org/tags/vorbis1_1_public_release_candidate_1/
cd vorbis1_1_public_release_candidate_1/
./autogen.sh --blah etc.
make

(Of course, I already have all the Ogg development packages installed;
otherwise there would have been a bunch more things to get.)

--
Greg Wooledge                  |   "Truth belongs to everybody."
greg@wooledge.org              |    - The Red Hot Chili Peppers
http://wooledge.org/~greg/     |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://lists.xiph.org/pipermail/vorbis/attachments/20040714/2d3cde56/attachment.pgp

<20040714180845.GA29983@ebed.etf.cuni.cz>
Message-ID: <40F60A60.5030805@griffith.edu.au>

vorbis-dev-bounces@xiph.org wrote:
>
>
>Just curious: what about Garf's tunings?
>
>
>
>Petr Tomasek
>
>
>
When I did the merging of the two at HA, I noticed that none of the
tunings from GT3 were in the 1.1 rc1 source code.  They cause very wild
fluctuations in bitrate so I guess Monty doesn't like that solution to
pre-echo. :)

Oh yeah, when are we going to see coupled 5.1 stereo? :)

Steve.

On Thu, 8 Jul 2004, Monty wrote:
>  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.
Don't get me wrong, I'm all for quality.  But quality -1 was pretty good
(considering) in vorbis 1.0.  With an improvement in 1.1, surely there now
is a case for an even lower bitrate mode?  I feel it's best to provide
people with the option of going below where picky people find it
acceptable, because it might be satisfactory for a given application.  The
number of quality -1 streams on the net is a case in point.  It may even be
possible to hear streams of that sonic quality on a 56k modem if we could
shave a few kbps off it.

Geoff.

<Pine.LNX.4.60.0407151701430.16854@data.home>
Message-ID: <cd6nso$26e$1@sea.gmane.org>
> Don't get me wrong, I'm all for quality.  But quality -1 was pretty
good
> (considering) in vorbis 1.0.  With an improvement in 1.1, surely there now
> is a case for an even lower bitrate mode?  I feel it's best to provide
> people with the option of going below where picky people find it
> acceptable, because it might be satisfactory for a given application.  The
> number of quality -1 streams on the net is a case in point.  It may even
be
> possible to hear streams of that sonic quality on a 56k modem if we could
> shave a few kbps off it.
I'm with you. I use quality -1 actually in a logging app I have, and being
able to get a smaller file with the same quality (wich is pretty good for
this purposes) would be great.

--
Rodrigo Gómez
http://rgomez.msa.com.mx/gallery/

"Geoff Shang" <gshang@pacific.net.au> escribió en el mensaje
news:Pine.LNX.4.60.0407151701430.16854@data.home...
> On Thu, 8 Jul 2004, Monty wrote:
>
> >  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.
>
> Don't get me wrong, I'm all for quality.  But quality -1 was pretty
good
> (considering) in vorbis 1.0.  With an improvement in 1.1, surely there now
> is a case for an even lower bitrate mode?  I feel it's best to provide
> people with the option of going below where picky people find it
> acceptable, because it might be satisfactory for a given application.  The
> number of quality -1 streams on the net is a case in point.  It may even
be
> possible to hear streams of that sonic quality on a 56k modem if we could
> shave a few kbps off it.
>
> Geoff.

>On Thu, 8 Jul 2004, Monty wrote:
>
>>  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.
When I first started using vorbis, I understood one idea was that the
audio quality at a given "q" level would always remain the same,
regardless of encoder improvements.  Thus, the approach in c) above
seems to be the wrong approach - the bitrate at -1 might decrease, but
the quality should remain the same.

I poked around the vorbis.com site, and found this reference, which
seems to support my memory:

http://www.vorbis.com/faq.psp#quality

Am I misunderstanding the situation here, or has the intent of the q
levels changed?

-Ben Blout