Following the suggestion in a link from Yota post, I have patched Ubuntu 7.10 (gutsy) source for vorbis with aoTuV beta 5.

To make the life of Ubuntu users easy I am making my packages available in my PPA. To use it just
add

deb http://ppa.launchpad.net/pjssilva/ubuntu gutsy main

to the /etc/apt/sources.list file. If you want the source, add

deb-src http://ppa.launchpad.net/pjssilva/ubuntu gutsy main

After that you may do a "apt-get update; apt-get upgrade" or just wait for the automatic
update manager to kick in.

Feel free to use it and, please, let me know if you find any problem.

By the way, Ubuntu libvorbis file is based on libvorbis 1.2.0, while the aoTuV patch was created againt 1.1.2. Hence, the original patch did not apply cleanly to the source (some line offsets and a trivial failure). It required some simple manual intervention. Is there an easy way to compare the a file encoded by my package with the result of static compile available at the wiki? I would like to make sure I didn't commit some stupid mistake. To test it, I have just compared the average bit-rate of my package and the static binary from the wiki and they are basically equal (as much as one can expect from floating point implementations). Is this enough?

You should perform the comparison of the encoding result after decoding ogg file. The difference of libvorbis 1.1.2 and 1.2.0 emerges to only in low sampling frequency. For example, in the source of 44.1kHz, the result of the comparison mentioned above accords.

I am not sure a completely understood your post (sorry for my English). Do you mean that the wavs I obtain from the encoded ogg should be exactly the same if the original source is 44.1kHz (like a CD)?

If this is the case I don't get that. I tried to compare the wavs using EAC "compare wav tool" and they are not the same (even though the difference is minimal, less than 0.3s of difference in a 10s sample).

Is there any better tool to do this comparison?

However, why should one expect the wavs to be the same if both come from floating point codes compiled from different compilers, possibly different optimization options, and with a slightly different source (that may result in different paths of execution, and in floating point code even the slightest difference can result in slightly different results)?

Am I missing something here?

Yes, the 2 produce the totally same result in my environment.

I use the Japanese CRC32 calculation / comparison tool.

Example (1.1.2 <=> 1.2.0)


You must not use a different compiler. Two binaries use the same compiler on the same environment and must compile it with the same option.

I have compiled libvorbis 1.1.2 and 1.2.0 (pristine, without the beta5 patch). I followed the directions from the wiki for compiling and using a local version of the libraries.

Then, I encoded a music ripped from a cd (that should be 44.1kHz). The enconded files are still not equal (they have slightly difference bitrates). The decoded wavs are not equal either. Once again, if you compare the wavs, only a few frames are different, less than 2% of the total.

Is there any option I should pass to the oggenc command?

I compile them with mingw+msys(gcc3.4.5). And I use oggenc for encoding.

For example,

Information of 1.1.2 -q0/44.1kHz.

Information of 1.2.0. -q0/44.1kHz.

Bingo!

The compiler is the "problem". I was using gcc-4.1.3 to compile the libraries (I tried with and without -fno-strict-aliasing). With gcc-4.1.3 the wavs generated by libvorbis-1.1.2 and libvorbis-1.2.0 are not the same. I went with gcc-4.1 for compilation because this is the default compiler in Ubuntu (and it is used to compile libvorbis in Gutsy, the newest Ubuntu version).

If I compile the same libraries with gcc-3.4.6 the wavs are identical!

I have only tested the result with the pristine libvorbis sources, I haven't tried the aoTuV beta 5 patch. I'll try to do this tonight or tomorrow and confirm that my patch against 1.2.0 is indeed correct. I'll post my results here.

the gcc4 issue is known:
https://trac.xiph.org/ticket/583


later

That bug should not appear if you use -fno-strict-aliasing with gcc-4. The directions on how to compile libvorbis in the wiki already mention that. As I said above, the (little) difference appears with and without this option. I have also tried to add the option -fno-inline-function that is cited in the bug discussion. No change. The wavs still different. So I believe that the problem is not explained by this bug report.

Obs: Maybe this is getting too technical... Should I open a new discussion on "Ogg Vorbis - Tech"?

I have just confirmed that if I compile my package with gcc-3.4 (see the discussion following Aoyumi reply to see why gcc-3.4 is needed) then it generates exactly the same output as the original aoTuV beta 5 compiled with the same compiler. I have confirmed that by encoding a music to vorbis and then decoding to wav. The wav files generated are exactly the same.

I can only conclude that my port of the aoTuV beta 5 patch to the Ubuntu version of libvorbis 1.2.0 is OK.

Feel free to use my package.

rsilva, can you make packages for aotuv beta 5.5?