Skip to main content
Topic: Vorbis 1.1 RC1 in SVN (Read 57932 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Vorbis 1.1 RC1 in SVN

From the vorbis mailing list

Quote
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


Vorbis 1.1 RC1 in SVN

Reply #2
Quote
  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.

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)

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.

Vorbis 1.1 RC1 in SVN

Reply #3
the DLL's = corrupt.

Vorbis 1.1 RC1 in SVN

Reply #4
Yay.  Vorbis is actually getting some movement again, which is especially great that I now own an iRiver and have started making encodes in Vorbis again.

Well it looks like I have another oggenc to play around with now
Nero AAC 1.5.1.0: -q0.45



Vorbis 1.1 RC1 in SVN

Reply #7
Quote
Code: [Select]
svn co http://svn.xiph.org/tags/vorbis1_1_public_release_candidate_1/

Many thanks!!

Vorbis 1.1 RC1 in SVN

Reply #8
On second look, it looks like SVN head (revision 7051) is currently identical to vorbis1_1_public_release_candidate_1, so checking out SVN head might be a better idea if bugfixes get merged in later.

Oh, you can choose the name of the output directory by doing something like this:
Code: [Select]
svn co http://svn.xiph.org/trunk/vorbis/ vorbis-svn-head


Vorbis 1.1 RC1 in SVN

Reply #10
Quote
the DLL's = corrupt.

Eh, the DLLs works fine with me (CDex 1.51).

Vorbis 1.1 RC1 in SVN

Reply #11
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)

Vorbis 1.1 RC1 in SVN

Reply #12
[late post]
This is great news !!  And a great move by Xiph people imho 
I feared that most people would not benefit from improvements since they were happening outside official libraries..  so it's good to know they have been integrated !
[/late post]

Vorbis 1.1 RC1 in SVN

Reply #13
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

Vorbis 1.1 RC1 in SVN

Reply #14
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. 

Given different time zones, I'll have compiles at Rarewares later in the day (my time).
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/

Vorbis 1.1 RC1 in SVN

Reply #15
perhaps a more realistic scale is needed ?
during a version change would be best to implement, anyways....

q01 - q20 ?

different abr mapped every ~16 kbps...
something like:

008 016 024 032 (x8)
040 048 056 064
080 096 112 128 (x16)
144 160 176 192
224 256 288 320 (x32)

dunno, just thinkin


later

Vorbis 1.1 RC1 in SVN

Reply #16
I disagree.  The current -2 - 10 scale works just fine.  That's just making it too much like mp3.  I'd rather have -q6 than -q16.
Nero AAC 1.5.1.0: -q0.45

Vorbis 1.1 RC1 in SVN

Reply #17
Quote
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

The nominal bitrate for -q-1 --resample 32000 files is 36, not 40 as it used to be.

-q0 and --resample 22050 seem unaffected.

Vorbis 1.1 RC1 in SVN

Reply #18
Quote
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


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(?).

Quote
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.


Might largly depend upon the new tuning numbers implemented too. ;-D.
budding I.T professional

Vorbis 1.1 RC1 in SVN

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


Is there any serious pre-echo tuning (as good as Garf or QK ones) ?

Vorbis 1.1 RC1 in SVN

Reply #20
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?)

Vorbis 1.1 RC1 in SVN

Reply #21
oggdropXPd and oggenc2.3 win32 binaries now at Rarewares.
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/

Vorbis 1.1 RC1 in SVN

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


BEST NEWS EVER!!!!!!!!!!!!!!!!!!!!!!!!!!!! .... now if iRiver would finally allow me to update my SlimX ... :|

Vorbis 1.1 RC1 in SVN

Reply #23
Quote
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. 


Yeah, but why?  Apparently the difference is not even particularly subtle.

Quote
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(?).


Resampling is not lowpassing.

Resampling is required to achieve very low bitrates in bitrate-managed modes.  For example, -b 32 is not allowed with 32 kHz resampling -- 22.05 kHz resampling is required.  But if one uses 22.05, aoTuV no longer kicks in.  Plus I bet 32 kHz resampling would sound better than 22.05.  With improved quality, I think the resampling rates should be revisited.

ff123

Vorbis 1.1 RC1 in SVN

Reply #24
Quote
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]


Those changes are on the encoder-side only. It´s just an adjustement to the bit-allocation algorithm if I understand correctly.

 
SimplePortal 1.0.0 RC1 © 2008-2018