I have updated my aoTuV and Lancer patches (see old thread (https://hydrogenaud.io/index.php/topic,109766.0.html) for reference) for Vorbis 1.3.7.
The patches now apply on top of the official libvorbis 1.3.7 sources and must be applied in order.
- The first patch adds the aoTuV b6.03 changes: libvorbis-1.3.7-aotuv-b6.03.patch (https://freac.org/patches/libvorbis-1.3.7-aotuv-b6.03.patch)
- The second patch adds the Lancer optimizations to that: libvorbis-1.3.7-aotuv-b6.03-lancer.patch (https://freac.org/patches/libvorbis-1.3.7-aotuv-b6.03-lancer.patch)
Also see my GitHub repository (https://github.com/enzo1982/vorbis-aotuv-lancer) with these changes.
Edit: Updated post for Vorbis 1.3.7.Edit 2: Updated patches to fix a glitch in Lancer decoder code. See the commit on GitHub (https://github.com/enzo1982/vorbis-aotuv-lancer/commit/797dc4) for more info.
Thanks. :) I'll look at these over the next few days.
Gracias por el aporte he estado esperando una actualización desde hace muchos años. :'(
that is great news, thank you enzo and john for keeping lancer alive :)
thank you!
New logical stream (#1, serial: 6c7a3d84): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: BS; LancerMod(SSE3) (based on aoTuV 6.03 (2018))
Great work, thanks!
rarewares needs to updated.
Working on it! ;) Just taking longer than expected - life getting in the way!!
Anyone has windows binaries for this? :)
You might try these ones. Patched according to enzo's note. Compiled with GCC 8.2. AVX instruction set used.
::
Thanks!
::
thank you.
Thank you very much :)
@john33, thanks for the builds.
-v shows 1.3.5.
@john33, thanks for the builds.
-v shows 1.3.5.
That's the program version string - which is wrong, the library is actually correct but I'll update the compiles to correct that. Thanks for letting me know. :)
They've now been updated. :)
Thank you
@john33, I don't follow Vorbis much, does this last version have the enzo patches and all that stuff?
Yes, it does. I haven't got to the Lancer patches yet as they don't seem to want to patch automatically and it's a large manual exercise!! It may be something I'm doing wrong, but I'll get there, eventually! ;)
Perfect, thank you :)
They've now been updated. :)
thanks a lot @john33.
do you mind updating the flac compiles with fastcrc patch as well? https://freac.org/developer-blog-mainmenu-9/14-freac/277-fastcrc
They've now been updated. :)
thanks a lot @john33.
do you mind updating the flac compiles with fastcrc patch as well? https://freac.org/developer-blog-mainmenu-9/14-freac/277-fastcrc
I assume from the site that it's merged into the current git. If so, updated compiles are available. :) If not, let me know, please! ;)
@NetRanger always updates to the latest git too https://hydrogenaud.io/index.php/topic,113391.msg962516.html#msg962516
I assume from the site that it's merged into the current git.
Yes, I can confirm that. The fast CRC patches have been merged into the official Ogg and FLAC Git repositories in April/May.
Thanks for the confirmation.
great job, thank you john33 :)
Hello, would it be possible to get the standalone Lancer patch?
Updated top post (https://hydrogenaud.io/index.php?topic=115774.0) for the Vorbis 1.3.7 release.
Updated top post (https://hydrogenaud.io/index.php?topic=115774.0) for the Vorbis 1.3.7 release.
Thank you for your kindness, that is very much appreciated.
Updated top post (https://hydrogenaud.io/index.php?topic=115774.0) for the Vorbis 1.3.7 release.
I might just be doing something wrong, but it seems to be missing xmmlib.h/xmmlib.c in the lib directory vs the previous release.
Updated top post (https://hydrogenaud.io/index.php?topic=115774.0) for the Vorbis 1.3.7 release.
I might just be doing something wrong, but it seems to be missing xmmlib.h/xmmlib.c in the lib directory vs the previous release.
They are contained in the lancer patch file, towards the end.
Two issues with Enzo's repo merging these
1) Missing xmmlib.h, xmmlib.c and cpu.c in the lib directory.
2) I compiled the Windows build using cmake, and on Ubuntu using ./autogen.h, ./configure and make. The output files have different vendor strings:
On Windows (cmake built):
AO; aoTuV 6.03 (2020) (based on libVorbis 1.3.7)
On Ubuntu (autogen, configure, make)
BS; LancerMod(SSE2) (based on aoTuV 6.03 (2018))
I think these should probably match, no? Is the Windows build missing the lancer patch? Sorry i'm pretty bad at this C toolchain stuff.
Indeed, the cpu.c and xmmlib.c/.h files were part of the patch, but missing in the repository. Fixed now.
As for the vendor strings, you'll have to build with SSE2 enabled on Windows. Otherwise the Lancer code will not be enabled. Not sure how to do that with cmake, though. I use MinGW/autotools on Windows too.
Visual Studio 2017 and newer default to SSE2 if you don't change any of the settings.
I got the included Visual Studio 2010 solution to build with some jiggering... might be worth including a disclaimer in there that the cmake system doesn't include the Lancer bits. Or just remove the cmakefiles.
The Lancer code will work with cmake just fine. You just need to make sure to tell cmake to create project files with SSE2 optimizations enabled. I don't know how to do that. Not a big fan of cmake.
Thanks enzo for the updates. All 1.3.7 and derivative builds are now on Rarewares. :)
Is it on freac?
Is it on freac?
Only in the continuous builds for Linux as of now. It will be included with fre:ac 1.1.3.
You can use the Rarewares builds with fre:ac 1.1.2b, though. To do that, replace both, Vorbis.dll and VorbisEnc.dll in fre:ac's codecs folder with the DLL from Rarewares (i.e. copy the libvorbis.dll to the codecs folder, then change its name to Vorbis.dll, then do the same again changing the name to VorbisEnc.dll, so you'll have two copies of the new DLL as Vorbis.dll and VorbisEnc.dll).
Thanks enzo for the updates. All 1.3.7 and derivative builds are now on Rarewares. :)
I don't see any reference to Lancer at Rarewares. Is it normal?
Oggenc2.88 using libVorbis v1.3.7 - aoTuVb6.03 (Lancer Builds)
oggdropXPd V.1.9.2 using libVorbis v1.3.7 - aoTuVb6.03 - Lancer
libvorbis.dll using libvorbis v1.3.7 - aoTuVb6.03 (Lancer Builds)
ogg vorbis dlls using libvorbis v1.3.7 + aoTuVb6.03 (Lancer Builds)
vorbis.dll - for HeadAC3he using libvorbis v1.3.7 - aoTuVb6.03 (Lancer Builds)
They're all there. ;)
I'd like to report something minor (cosmetic) about oggenc2.88-1.3.7-aoTuVb6.03-P4.zip on RareWares. With my previous version, oggenc2 --version gives me "OggEnc v2.88 (libvorbis 1.3.6-aoTuV-b6.03)". It's now "OggEnc v2.88 (libvorbis 1.3.6)", still 1.3.6 and not saying aoTuV.
A vorbis file encoded with it does says "Tool : AO; aoTuV 6.03 (2020) (based on libVorbis 1.3.7)" so the above is not a real problem. Just potentially confusing. Thanks!
I'd like to report something minor (cosmetic) about oggenc2.88-1.3.7-aoTuVb6.03-P4.zip on RareWares. With my previous version, oggenc2 --version gives me "OggEnc v2.88 (libvorbis 1.3.6-aoTuV-b6.03)". It's now "OggEnc v2.88 (libvorbis 1.3.6)", still 1.3.6 and not saying aoTuV.
A vorbis file encoded with it does says "Tool : AO; aoTuV 6.03 (2020) (based on libVorbis 1.3.7)" so the above is not a real problem. Just potentially confusing. Thanks!
Thanks for the notification. I'll correct and re-upload shortly. (Actually, I notice it applies to all the oggenc2 compiles!!)
Edit: Corrected compiles now at Rarewares. :)
Thanks! :D
Thank you. One question, aoTuVb6.03 has not been updated for many years, is it currently better than Xiph 1.3.4 at all bitrates? For example at 160 kbps.
another question: is
vorbis-aotuv-lancer-master.zip
the same as
libvorbis-1.3.7.zip + libvorbis-1.3.7-aotuv-b6.03.patch + libvorbis-1.3.7-aotuv-b6.03-lancer.patch ?
Oggenc2.88 using libVorbis v1.3.7 - aoTuVb6.03 (Lancer Builds)
oggdropXPd V.1.9.2 using libVorbis v1.3.7 - aoTuVb6.03 - Lancer
libvorbis.dll using libvorbis v1.3.7 - aoTuVb6.03 (Lancer Builds)
ogg vorbis dlls using libvorbis v1.3.7 + aoTuVb6.03 (Lancer Builds)
vorbis.dll - for HeadAC3he using libvorbis v1.3.7 - aoTuVb6.03 (Lancer Builds)
They're all there. ;)
Hi John,
When using the oggdropXPd V.1.9.2 builds avalaible on your website , I have noticed that encodings made with the Lancer version of the program are about 35% larger than the ones encoded with the Libvorbis version (at q4).
My understanding is that aotuv b6.03 tunings were merged with Libvorbis a while ago and that Lancer is only optimizing the encoding speed. I assume from that the output should be in the same ballpark in terms of filesize at a given q setting.
Could you please shed some light on why the aotuv Lancer version produces larger files than the libvorbis version at the same q setting?
Thank you for your help.
IIRC, the aoTuV tunings were merged into libvorbis at a much earlier level than 6.03 and, yes, the Lancer builds are about speed but they do have a small effect on the output bitrate, although I don't believe anyone has been able to discern an audible difference. I can't reproduce the large file size difference that you mention, my testing produces files that are "in the same ballpark in terms of filesize at a given q setting", as expected. If you have something that you can share that illustrates this, I'll gladly look at it.
Just to be clear, I am only the person who provides the compiles for general use. I have no input to the detail of the encoding libraries and I lack the technical knowledge so to do!! ;)
IIRC, the aoTuV tunings were merged into libvorbis at a much earlier level than 6.03 and, yes, the Lancer builds are about speed but they do have a small effect on the output bitrate, although I don't believe anyone has been able to discern an audible difference. I can't reproduce the large file size difference that you mention, my testing produces files that are "in the same ballpark in terms of filesize at a given q setting", as expected. If you have something that you can share that illustrates this, I'll gladly look at it.
Just to be clear, I am only the person who provides the compiles for general use. I have no input to the detail of the encoding libraries and I lack the technical knowledge so to do!! ;)
Hi John, thank you for your reply.
I'm PMing you a 40' flac sample with which the behavior I described can be reproduced.
Using OggdropXP v1.92 at q4, I get:
- BS; LancerMod(SSE3) (based on aoTuV 6.03 (2020)) -->229 kbps
- Xiph.Org libVorbis I 20200704 (Reducing Environment) -->170 kbps
Thanks a lot.
Hmm, interesting sample! I can confirm that I get the same results as you with that sample. The Lancer build and the standard aoTuV non-Lancer builds provide very similar results. I can only assume that with this and, no doubt, many other 'difficult' samples the aoTuV tunings provide a more generous bitrate allocation.
Thank you John.
Hi
@enzo! In updating the AUR package (https://aur.archlinux.org/packages/libvorbis-aotuv-lancer/) to v1.3.7, I am getting a segfault during `make check` for test 4:
Making check in m4
make[1]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/m4'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/m4'
Making check in include
make[1]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/include'
Making check in vorbis
make[2]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/include/vorbis'
make[2]: Nothing to be done for 'check'.
make[2]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/include/vorbis'
make[2]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/include'
make[2]: Nothing to be done for 'check-am'.
make[2]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/include'
make[1]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/include'
Making check in vq
make[1]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/vq'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/vq'
Making check in lib
make[1]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib'
Making check in modes
make[2]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/modes'
make[2]: Nothing to be done for 'check'.
make[2]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/modes'
Making check in books
make[2]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/books'
Making check in coupled
make[3]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/books/coupled'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/books/coupled'
Making check in uncoupled
make[3]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/books/uncoupled'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/books/uncoupled'
Making check in floor
make[3]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/books/floor'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/books/floor'
make[3]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/books'
make[3]: Nothing to be done for 'check-am'.
make[3]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/books'
make[2]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/books'
make[2]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib'
make[2]: Nothing to be done for 'check-am'.
make[2]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib'
./test_sharedbook
Dequant test 1... OK
Dequant test 2... OK
Dequant test 3... OK
Dequant test 4... make[1]: *** [Makefile:1033: check] Segmentation fault (core dumped)
make[1]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib'
make: *** [Makefile:530: check-recursive] Error 1
[1m[31m==> ERROR:(B[m[1m A failure occurred in check().(B[m
[1m Aborting...(B[m
I am using the following PKGBUILD:
pkgname=libvorbis-aotuv-lancer
pkgver=1.3.7
_srcname="libvorbis-${pkgver}"
pkgrel=1
_aotuv_ver=b6.03
pkgdesc='A fork of libvorbis intended to provide better quality sound at low to medium bitrates, with lancer patches to improve performance'
arch=('i686' 'x86_64')
url='https://hydrogenaud.io/index.php?topic=115774.0'
license=('BSD')
depends=('libogg.so')
conflicts=('libvorbis' 'libvorbis-aotuv')
provides=(
'libvorbis.so'
'libvorbisenc.so'
'libvorbisfile.so'
)
source=("http://downloads.xiph.org/releases/vorbis/${_srcname}.tar.gz"
"https://freac.org/patches/${_srcname}-aotuv-${_aotuv_ver}.patch"
"https://freac.org/patches/${_srcname}-aotuv-${_aotuv_ver}-lancer.patch")
sha256sums=('0e982409a9c3fc82ee06e08205b1355e5c6aa4c36bca58146ef399621b0ce5ab'
'21c9801f70fa254bb2019266ae51cdabf9b9bbf089fe91275db8722a0cfc46b6'
'db4a6698913c4e05d43cfbbd174b1deb3747f7283a8618d8e009425d93a23769')
prepare() {
cd "${_srcname}"
# apply aotuv patches
patch -p1 -i "${srcdir}/${_srcname}-aotuv-${_aotuv_ver}.patch"
# apply lancer patches
patch -p1 -i "${srcdir}/${_srcname}-aotuv-${_aotuv_ver}-lancer.patch"
}
build() {
cd "${_srcname}"
./configure \
--prefix=/usr \
--disable-static \
--enable-shared
make
}
check() {
cd "${_srcname}"
make -k check
}
package() {
cd "${_srcname}"
make DESTDIR="${pkgdir}/" install
install -Dm644 COPYING "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
}
The build log (http://ix.io/2Q1N) looks normal (external link because otherwise post exceeds character limit).
There are no issues with building the current 1.3.6 version or standard libvorbis 1.3.7 (without patches) using the same method (building in a clean chroot), however the exact same issue happens when I do a standard build from your repo's master branch.
Any idea of what might be at play here?
Thanks!
edit: I got something slightly better using the previously used `make -j1 check` (as it is in the current 1.3.6 PKBGUILD):
Making check in m4
make[1]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/m4'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/m4'
Making check in include
make[1]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/include'
Making check in vorbis
make[2]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/include/vorbis'
make[2]: Nothing to be done for 'check'.
make[2]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/include/vorbis'
make[2]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/include'
make[2]: Nothing to be done for 'check-am'.
make[2]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/include'
make[1]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/include'
Making check in vq
make[1]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/vq'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/vq'
Making check in lib
make[1]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib'
Making check in modes
make[2]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/modes'
make[2]: Nothing to be done for 'check'.
make[2]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/modes'
Making check in books
make[2]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/books'
Making check in coupled
make[3]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/books/coupled'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/books/coupled'
Making check in uncoupled
make[3]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/books/uncoupled'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/books/uncoupled'
Making check in floor
make[3]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/books/floor'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/books/floor'
make[3]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/books'
make[3]: Nothing to be done for 'check-am'.
make[3]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/books'
make[2]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/books'
make[2]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib'
make[2]: Nothing to be done for 'check-am'.
make[2]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib'
./test_sharedbook
Dequant test 1... OK
Dequant test 2... OK
Dequant test 3... OK
Dequant test 4... make[1]: *** [Makefile:1033: check] Segmentation fault (core dumped)
make[1]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib'
Making check in test
make[1]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/test'
make test
CC util.o
CC write_read.o
make[2]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/test'
CC test.o
CC util.o
CC write_read.o
CC test.o
mv: cannot move '.deps/write_read.Tpo' to '.deps/write_read.Po': No such file or directory
make[1]: *** [Makefile:385: write_read.o] Error 1
CCLD test
make[2]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/test'
make[1]: Target 'check' not remade because of errors.
make[1]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/test'
Making check in doc
make[1]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/doc'
Making check in libvorbis
make[2]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/doc/libvorbis'
make[2]: Nothing to be done for 'check'.
make[2]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/doc/libvorbis'
Making check in vorbisfile
make[2]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/doc/vorbisfile'
make[2]: Nothing to be done for 'check'.
make[2]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/doc/vorbisfile'
Making check in vorbisenc
make[2]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/doc/vorbisenc'
make[2]: Nothing to be done for 'check'.
make[2]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/doc/vorbisenc'
make[2]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/doc'
make[2]: Nothing to be done for 'check-am'.
make[2]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/doc'
make[1]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/doc'
make[1]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7'
make[1]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7'
make: *** [Makefile:530: check-recursive] Error 1
make: Target 'check' not remade because of errors.
[1m[31m==> ERROR:(B[m[1m A failure occurred in check().(B[m
[1m Aborting...(B[m
I got slightly further by adding an `./autogen.sh` step in the `prepare()` stage, although that should not (and was not) needed while building from a tarball?
Making check in m4
make[1]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/m4'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/m4'
Making check in include
make[1]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/include'
Making check in vorbis
make[2]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/include/vorbis'
make[2]: Nothing to be done for 'check'.
make[2]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/include/vorbis'
make[2]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/include'
make[2]: Nothing to be done for 'check-am'.
make[2]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/include'
make[1]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/include'
Making check in vq
make[1]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/vq'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/vq'
Making check in lib
make[1]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib'
Making check in modes
make[2]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/modes'
make[2]: Nothing to be done for 'check'.
make[2]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/modes'
Making check in books
make[2]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/books'
Making check in coupled
make[3]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/books/coupled'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/books/coupled'
Making check in uncoupled
make[3]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/books/uncoupled'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/books/uncoupled'
Making check in floor
make[3]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/books/floor'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/books/floor'
make[3]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/books'
make[3]: Nothing to be done for 'check-am'.
make[3]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/books'
make[2]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/books'
make[2]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib'
make[2]: Nothing to be done for 'check-am'.
make[2]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib'
./test_sharedbook
Dequant test 1... OK
Dequant test 2... OK
Dequant test 3... OK
Dequant test 4... make[1]: *** [Makefile:1033: check] Segmentation fault (core dumped)
make[1]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib'
Making check in test
make[1]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/test'
make test
CC write_read.o
CC test.o
CC util.o
make[2]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/test'
CC write_read.o
CC util.o
CC test.o
CCLD test
CCLD test
make[2]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/test'
./test
Testing 1 channel
<all channel tests ok up to...>
vorbis_8ch_q9.5_96000.ogg : ok
make[1]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/test'
Making check in doc
make[1]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/doc'
Making check in libvorbis
make[2]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/doc/libvorbis'
make[2]: Nothing to be done for 'check'.
make[2]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/doc/libvorbis'
Making check in vorbisfile
make[2]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/doc/vorbisfile'
make[2]: Nothing to be done for 'check'.
make[2]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/doc/vorbisfile'
Making check in vorbisenc
make[2]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/doc/vorbisenc'
make[2]: Nothing to be done for 'check'.
make[2]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/doc/vorbisenc'
make[2]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/doc'
make[2]: Nothing to be done for 'check-am'.
make[2]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/doc'
make[1]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/doc'
make[1]: Entering directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7'
make[1]: Leaving directory '/build/libvorbis-aotuv-lancer/src/libvorbis-1.3.7'
make: *** [Makefile:532: check-recursive] Error 1
make: Target 'check' not remade because of errors.
[1m[31m==> ERROR:(B[m[1m A failure occurred in check().(B[m
[1m Aborting...(B[m
The current PKGBUILD as it stands:
pkgname=libvorbis-aotuv-lancer
pkgver=1.3.7
_srcname="libvorbis-${pkgver}"
pkgrel=1
_aotuv_ver=b6.03
pkgdesc='A fork of libvorbis intended to provide better quality sound at low to medium bitrates, with lancer patches to improve performance'
arch=('i686' 'x86_64')
url='https://hydrogenaud.io/index.php?topic=115774.0'
license=('BSD')
depends=('libogg.so')
conflicts=('libvorbis' 'libvorbis-aotuv')
provides=(
'libvorbis.so'
'libvorbisenc.so'
'libvorbisfile.so'
)
source=("http://downloads.xiph.org/releases/vorbis/${_srcname}.tar.gz"
"https://freac.org/patches/${_srcname}-aotuv-${_aotuv_ver}.patch"
"https://freac.org/patches/${_srcname}-aotuv-${_aotuv_ver}-lancer.patch")
sha256sums=('0e982409a9c3fc82ee06e08205b1355e5c6aa4c36bca58146ef399621b0ce5ab'
'21c9801f70fa254bb2019266ae51cdabf9b9bbf089fe91275db8722a0cfc46b6'
'db4a6698913c4e05d43cfbbd174b1deb3747f7283a8618d8e009425d93a23769')
prepare() {
cd "${_srcname}"
./autogen.sh
# apply aotuv patches
patch -p1 -i "${srcdir}/${_srcname}-aotuv-${_aotuv_ver}.patch"
# apply lancer patches
patch -p1 -i "${srcdir}/${_srcname}-aotuv-${_aotuv_ver}-lancer.patch"
}
build() {
cd "${_srcname}"
./configure \
--prefix=/usr \
--disable-static \
--enable-shared
make
}
check() {
cd "${_srcname}"
make -k check
}
package() {
cd "${_srcname}"
make DESTDIR="${pkgdir}/" install
install -Dm644 COPYING "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
}
PS: I noticed there was no 1.3.7 release/tag on your Github repo, was it intentional?
Thanks
edit: extract from systemd journal if that may help:
févr. 20 03:48:23 kernel: test_sharedbook[68595]: segfault at 556bb0000000 ip 00007ff21fb84c9e sp 00007ffea83e76b0 error 4 in libc-2.33.so[7ff21fb1f000+14c000]
févr. 20 03:48:23 kernel: Code: a8 02 75 40 48 8b 15 d1 50 13 00 64 48 83 3a 00 0f 84 9e 00 00 00 48 8d 3d 6f 5d 13 00 a8 04 74 0c 48 89 f0 48 25 00 00 00 fc <48> 8b 38 31 d2 e8 08 c0 ff ff 64 89 2b 48 83 c4 18 5b 5d c3 66 0f
févr. 20 03:48:23 systemd[1]: Started Process Core Dump (PID 68596/UID 0).
févr. 20 03:48:23 systemd-coredump[68597]: Resource limits disable core dumping for process 68595 (test_sharedbook).
févr. 20 03:48:23 systemd-coredump[68597]: [🡕] Process 68595 (test_sharedbook) of user 1000 dumped core.
Some more lines appeared when building outside of the chroot:
Stack trace of thread 91257:
#0 0x00007f6b478c5cde __libc_free (libc.so.6 + 0x8bcde)
#1 0x0000559ea490a0e3 n/a (<buildpath>/libvorbis-aotuv-lancer/src/libvorbis-1.3.7/lib/test_sharedbook + 0x10e3)
Thank you for bringing this up,
@Isayama!
Just investigated this and found that it's a bug in the test itself, i.e. not in the library / the patches. In the test code in sharedbook.c there's a mismatched alloc and free which causes the error. The call to free in line 584 of sharedbook.c needs to be changed to _ogg_free to fix this.
I applied the fix in the enzo1982/vorbis-aotuv-lancer (https://github.com/enzo1982/vorbis-aotuv-lancer) repository and also opened a pull request (https://github.com/xiph/vorbis/pull/81) for the official xiph/libvorbis code.
I won't update the patch for this. You can either apply a custom patch or sed call in the prepare section of the packaging script or directly refer to the 6df96d98 commit (https://github.com/enzo1982/vorbis-aotuv-lancer/commit/6df96d98bbe66ab9732a7b509d1f0169a87bbbb5) from enzo1982/vorbis-aotuv-lancer instead of the original package and patch files.
Custom patch is probably the best way to apply a post-release fix to an AUR or even non-AUR package, and bump the pkgrel.
Thank you very much
@enzo for looking into this so quickly and upstreaming it. I can confirm the build completes successfully after applying your patch.
Regarding this specific AUR package, I would be in favor of directly using your repo as its source since this package pertains to "
A fork of libvorbis intended to provide better quality sound at low to medium bitrates, with lancer patches to improve performance", however as a non-development package it would require a 1.3.7 release to be made/tagged (no need to differ from upstream) to use it as a base and then apply the patch on top.
(Arch also has VCS packages (https://wiki.archlinux.org/index.php/VCS_package_guidelines), but to make proper use of it I'd need to request a package name change to *-git, although in the long run that might be a better idea...)
That's definitely nitpicking, but can you tag/make a release for 1.3.7 in enzo1982/vorbis-aotuv-lancer?
In any case thanks a lot for responding quickly to this.
Just pushed the v1.3.7 tag. Simply forgot to do that when I updated the repository for that version.
However, thinking about it, it might not be such a good idea to base the package on my repository after all. I'll likely do a force push when integrating a future libvorbis 1.3.8. This means the three commits after the 1.3.7 tag will go away and be replaced with new commits. Using patch files on top of the 1.3.7 tag will be fine, but don't reference the commit hashes directly.
Thanks! Well, if it gives you more leeway like that, I've used the upstream tarball and applied your patches on top. As an added bonus it allows to verify the integrity of the sources with the provided signature. We'll see down the road with 1.3.8 how we change it :)
Cheers
A fre:ac user sent me a sample file today that exhibits severe glitches when decoded with fre:ac, but not with other converters. The first few seconds of the sample are attached and demonstrate the issue.
Investigation revealed that this is caused by a bug (or rather two separate bugs) in the Lancer decoder optimizations. For block->dim == 4 or 8, the mid cut-off points for the iteration are calculated wrongly (with step size 4 instead of 8 ) which causes severe glitches when decoding the sample file.
There also is a bug in the code for block->dim == 2 where the wrong index is used for t in the head and tail loops. This also causes audible glitches, though not nearly as bad as the first issue.
Both issues are fixed in this commit (https://github.com/enzo1982/vorbis-aotuv-lancer/commit/797dc4) and the patches in the first post of this thread have been updated.
As the issues are already present in the original Lancer patches from 2006, everyone using a Lancer based decoder to convert or play Vorbis files should probably upgrade to a fixed version.
If anyone is concerned by this I'll look at it and recompile as necessary tomorrow.
Updated compiles now at Rarewares. :)
Thank you both enzo and john33 for your ongoing great services.
First of all I wish to thank the OP for keeping aotuv and lancer alive. I've stumbled here after a quite long search.
How hard would it be to "create" a static build of ffmpeg with this version of libvorbis? Sorry for the probably naive question.
Alternatively, does anyone have a oggenc optimized build for Linux? I mean the binary itself. I don't have any idea about how to build something and the binary linked to in the wiki gives an error (something to do about locale).
(The only one that doesn't lead to a dead link from the wiki, btw...)
Alternatively, does anyone have a oggenc optimized build for Linux? I mean the binary itself. I don't have any idea about how to build something and the binary linked to in the wiki gives an error (something to do about locale).
(The only one that doesn't lead to a dead link from the wiki, btw...)
https://formulae.brew.sh/formula/vorbis-tools
two single-line commands and you shall get what you want, the latest version for your installed distro, within a minute.
hope this helps.
alternatively:
http://archive.ubuntu.com/ubuntu/pool/universe/v/vorbis-tools/?C=M;O=D
alternatively:
http://archive.ubuntu.com/ubuntu/pool/universe/v/vorbis-tools/?C=M;O=D
Unless I'm missing something, both of your links point to regular builds, not Aotuv/Lancer ones.
alternatively:
http://archive.ubuntu.com/ubuntu/pool/universe/v/vorbis-tools/?C=M;O=D
Unless I'm missing something, both of your links point to regular builds, not Aotuv/Lancer ones.
Yes they're the normal ones. Want the Linux AoTuv build? Not the latest v5 but v4.51 aoTuV.
Here it is: https://file.io/iUsab9GxBmNi
hydrogenaud.io blurb about this one:
oggenc aoTuV beta 4.51 and libogg 1.1.3 (Static GCC 4 compile) with impulse_trigger_profile
This static GCC 4 binary was compiled by QuantumKnot.
Hope this helps!
oggenc aoTuV beta 4.51 and libogg 1.1.3 (Static GCC 4 compile) with impulse_trigger_profile
This static GCC 4 binary was compiled by QuantumKnot.
Hope this helps!
It's better than nothing and I thank you for that. Let's hope some kind soul that knows how to do it can bring an updated build with latest tunings+lancer. At least it would be useful to have it working in the wiki too.
It actually states that the file at that link has been deleted. Which underlines the sad state of Linux binaries for aotuv tunings. :-(
Is it on freac?
Only in the continuous builds for Linux as of now. It will be included with fre:ac 1.1.3.
You can use the Rarewares builds with fre:ac 1.1.2b, though. To do that, replace both, Vorbis.dll and VorbisEnc.dll in fre:ac's codecs folder with the DLL from Rarewares (i.e. copy the libvorbis.dll to the codecs folder, then change its name to Vorbis.dll, then do the same again changing the name to VorbisEnc.dll, so you'll have two copies of the new DLL as Vorbis.dll and VorbisEnc.dll).
Oh, maybe I've found a solution to my problem. Are you saying that the AppImage for fre:ac includes by default aotuv+lancer when selecting the ogg encoder?
It says here that it applies patches: https://github.com/enzo1982/freac/blob/258e97ed6ed41c39fa9ddb8baa52b291f58f0676/tools/build-codecs#L221
So yes, it seems those patches are included in the fre:ac builds.
It says here that it applies patches: https://github.com/enzo1982/freac/blob/258e97ed6ed41c39fa9ddb8baa52b291f58f0676/tools/build-codecs#L221
So yes, it seems those patches are included in the fre:ac builds.
Ok, that's great. Changelog confirms it too.
I still think it would be good to have some updated binaries to link from the Wiki but, for now, I'm set. Thanks!
FWIW, clang 15 change impacts patches -
"The -Wint-conversion warning diagnostic for implicit int <-> pointer conversions now defaults to an error in all C language modes. It may be downgraded to a warning with -Wno-error=int-conversion, or disabled entirely with -Wno-int-conversion."
https://releases.llvm.org/15.0.0/tools/clang/docs/ReleaseNotes.html
xmmlib.c:127:9: error: incompatible integer to pointer conversion assigning to 'void *' from 'size_t' (aka 'unsigned long') [-Wint-conversion]
p2[-1] = size;
^ ~~~~
2 warnings and 1 error generated.
*** [xmmlib.lo] Error code 1
oggenc aoTuV beta 4.51 and libogg 1.1.3 (Static GCC 4 compile) with impulse_trigger_profile
This static GCC 4 binary was compiled by QuantumKnot.
Hope this helps!
It actually states that the file at that link has been deleted. Which underlines the sad state of Linux binaries for aotuv tunings. :-(
Uh oh, pretty late to the party, but I just noticed your edit. That delete wasn't actually from the source, but from that transfer I shared which expires after a certain amount of downloads ;-;
I have pm'ed you a link which should help you download that file.
Oggenc2.88 using libVorbis v1.3.7 - aoTuVb6.03 (Lancer Builds)
2021-05-11
Dear
@john33, do you think it's time to update this build on Rarewares, given the posts in this thread?
Why?
There is something wrong about Lancer mod 2021-05-11 hosted on RareWares. It is unable to correctly encode WAV when its sampling rate is less or equal to 11025 Hz: SSE2 version outputs silence, SSE3 outputs heavily distorted sound. All other Vorbis encoders (original, Aotuv, Venc (https://ao-yumi.github.io/aotuv_web/) aka Aotuv 2021-03-20, FFMPEG's libvorbis) do the job as expected.
P.S. Also, Lancer mod section on the website is missing its own anchor,
<a name="oggenc-aotuv"> is used instead.
$ mediainfo in.wav
General
Complete name : in.wav
Format : Wave
Format settings : PcmWaveformat
File size : 361 KiB
Duration : 16 s 780 ms
Overall bit rate mode : Constant
Overall bit rate : 176 kb/s
Audio
Format : PCM
Format settings : Little / Signed
Codec ID : 1
Duration : 16 s 780 ms
Bit rate mode : Constant
Bit rate : 176.4 kb/s
Channel(s) : 1 channel
Sampling rate : 11.025 kHz
Bit depth : 16 bits
Stream size : 361 KiB (100%)
$ oggenc2 in.wav -q 1 out.ogg
Bytes Filename
-------- --------------------------
46 825 out.original.generic.ogg
51 187 out.original.x64.ogg
51 301 out.ffmpeg7.x64.ogg
51 301 out.ffmpeg7.x86.ogg
52 409 out.aotuv.generic.ogg
55 291 out.lancer.sse3.ogg
56 562 out.aotuv.x64.ogg
56 655 out.lancer.sse2.ogg
56 670 out.venc.x64.ogg
56 674 out.venc.x86.ogg
I'm having trouble making any progress with this. 'in.flac' does not play in foobar with the following error message:
Unrecoverable playback error: Unsupported stream format: 11025 Hz / 24-bit / 1 channels (0x4)
Yet, if I look at the Properties in foobar, it specifies 16 bit! I can encode the flac file with any of the oggenc2 variants (Windows 10 Pro x64) and the same situation exists - same error message, but properties appear correct. Decoding the flac to wav doesn't help either. Any ideas, anyone?
Sounds like you are using an exclusive mode output in foobar2000. The output bitdepth is user configurable, yours is set to 24 bps. And the error is caused by the audio interface not supporting 11 kHz playback natively.
If you wish to keep using exclusive mode, you'll need to add a resampler DSP to the playback chain. Another solution would be to switch to non-exclusive output.
Thanks, Case, you're right, of course! I'm off to Spain for 2 weeks tomorrow so my mind is elsewhere!! I don't think I will get to look at this until I return so please feel free to remind me if I should appear to have forgotten about it.
Quick update. I believe the RareWares builds are slightly out-of-date. I found more recent source that appears to fix a bug relating to low samplerates. I'll look at this in more depth when I am able. The broadband connection where I am visiting in Spain is slow and intermittent!