Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: aoTuV vs. oggenc 1.0.1 filesize (Read 20335 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

aoTuV vs. oggenc 1.0.1 filesize

Reply #25
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?

aoTuV vs. oggenc 1.0.1 filesize

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

 

aoTuV vs. oggenc 1.0.1 filesize

Reply #28
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)  .

aoTuV vs. oggenc 1.0.1 filesize

Reply #29
(babelfished from lancer readme)
Quote
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

aoTuV vs. oggenc 1.0.1 filesize

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