[Vorbis] Lancer 20060824 is out

[Pandu E Poluan]

:-)

Sorry to disappoint you, I may have a hand. I (and several others at HydrogenAudio) suggested to Aoyumi to no longer use the "beta" designation, and he decides to keep everthing "beta"-titled, until the last "beta" is accepted by majority, then rename the last "beta" into "Release".

So, "Release 2" will be the culmination of the currently progressing "pre-beta 5" (which will change to "beta 5" in the near time).

{p}


----- Original Message ----- 
From: Ivo Emanuel Gonçalves 
To: vorbis at xiph.org 
Sent: Friday, August 25, 2006 2:30 AM
Subject: Re: [Vorbis] Lancer 20060824 is out


I was going to say, "Hey, there's a Release 1 of aoTuV!? That's way more important to announce here, I had no idea!". But then, I went to Aoyumi's site, and all I found was:

aoTuV Release 1 (2006/08/23)  # This is the stable version. The contents are almost the same as beta4.51.

And I can't explain how disappointed I was. I guess I had bigger expectations than I should have.


On 8/24/06, pub at cyanet.jp <pub at cyanet.jp> wrote:
  Lancer 20060824 (based on aoTuV Release 1)
  - fully optimized libvorbis for x86 CPUs -
  http://homepage3.nifty.com/blacksword/

  Changes:
  2006/08/24 Lancer 20060824 
  * Lancer is based on aotuv-r1_20051117 now.
  * add SSE optiomizations to _vp_couple.
  * add the dividing code of multi channel processing to xmmlib.h.
  * _vp_quantize_couple_memo, _vp_quantize_couple_sort is multithreaded under the OpenMP. 

  2006/08/18 Lancer 20060816
  * mapping0_forward is more parallelized.
  * Buffered delay writer for Ogg stream is implemented. It makes possible that floor1_encode in the code book.* is parallelized.
  * floor1_encode is able to execute in the parallel processing now. 
  * _vp_couple is parallelized.
  * It changes so that an infinite loop may not be entered at the time of profile measurement.
  * reintroduce the build which is profiled for multi-threading.

  2006/08/15 Lancer 20060815 (for evaluation of multithread problem) 
  * The portion which is using OpenMP was separated in mapping0_forward.
  * It tunes so that OpenMP may surely use a multithread in a multithread part.
  * reduce the critical sections for speed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/vorbis/attachments/20060826/535985ab/attachment.htm