quote:
hierzo kan je ze downloaden:
OggEnc:
http://homepage3.nifty.com/nyaochi/soft/di...genc_1.1rc1.zip
Ogg Dll's:
http://homepage3.nifty.com/nyaochi/soft/di..._dll_1.1rc1.zip
en dit stond er bij (wat er nieuw is!):
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
![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
Door: 
. De speler moet natuurlijk wel betrouwbaar zijn, en omdat ik nog niet zoveel heb gehoord over de h3x0 weet ik het nog niet zeker. Wat zouden jullie mij aanraden? Graag objectief advies 
Ik kan me niet voorstellen dat de H's die momenteel verkocht worden nog van een oude voorraad zijn ofzo...
Dit topic is gesloten.
