aoTuV vs. oggenc 1.0.1 filesize, Comparing filesizes with different encoders Options

[fedetxf]

After all I confused the version number I'm using. I have libvorbis 1.1.0, but vorbistools 1.0.1. Vorbistools packs oggenc. So I was comparing older aotuv with newer aotuv, right?

[fpi]

After all I confused the version number I'm using. I have libvorbis 1.1.0, but vorbistools 1.0.1. Vorbistools packs oggenc. So I was comparing older aotuv with newer aotuv, right?

Yes. libvorbis 1.1.x is basically aoTuV beta 2 with some minor fixes.

For aoYumi: would be nice if your next release will drop the term "beta": seems to me that some users are discouraged by usi
ng aoTuV because they think that is not yet stable/optimized, when, in fact, is a lot more optimized than the xiph.org libvo
rbis.

[Aoyumi]

For aoYumi: would be nice if your next release will drop the term "beta": seems to me that some users are discouraged by usi
ng aoTuV because they think that is not yet stable/optimized, when, in fact, is a lot more optimized than the xiph.org libvo
rbis.

http://www.hydrogenaudio.org/forums/index....mp;st=125&#

[fpi]

5) Next week I'll open a ticket on launchpad.net requesting to merge aoTuV 4.51 patch in libvorbis (already discussed on Debian and Fedora ML).

Ticket opened on ubuntu's launchpad :
Should include aoTuV Release 1 patch

You are welcome to open similar ticket for other distributions (and maybe on xiph.org ML) .

[PatchWorKs]

(babelfished from lancer readme)

Size of the Ogg file which is formed differs from reference

Ogg Vorbis receives influence to the encoding result with the precision of the floating point arithmetic which is used. As for the floating point arithmetic with usual FPU in case of single precision, output size is 32 bits and in inside at 80 bit thing high accuracy being calculated, other method is compared and the accurate result is output. It becomes the reference this in x86 architecture.
With the optimization binary classified by CPU which is distributed with rarewares.org and the like Intel C++ Compiler (later ICL) with it is compiled. With the binary for CPU which had SSE floating point arithmetic from FPU it replaces to SSE scalar operation, but operational precision 32 bits for the sake of error occurs in the output result and becomes the result where contents and size of the output file differ from reference. Similar problem occurs even with the SSE optimization patch.
With the result which you investigated encoding quality is low, or sampling rate about is low seems that is the tendency which error of reference increases.
In addition, with 64 bit mode in 64 bit edition of WindowsXP being to recommend the fact that Microsoft does not use FPU at present time, there is a possibility SSE scalar use edition becoming reference.

The output result of the ogg file when the WAV file of 44.1KHz and 2ch of the reference 47275244 byte is encoded with q4
(AoTuV pb4-20050412 use)
The encoder which you use The number of bytes of ogg file which is output
GCC FPU use 4,668,312
GCC SSE use 4,668,381
ICL (P3 optimized) 4,668,483
Lancer 20050528 4,668,403

This post has been edited by PatchWorKs: Aug 28 2006, 08:29

[pepoluan]

Basically what BlackSword said in Lancer Readme is what is written in HA Wiki: Standard aoTuV uses FPU while Lancer uses SSE. They use different floating-point resolution (IIRC, FPU uses 80-bit while SSE uses 64-bit), and this is bound to cause some differences.