aoTuV beta 4.5 released, a new aoTuv-beta for low bitrates Options

[Josef K.]

So, b4.5 is supposed to perform better  than  b4 @ q3 and below, but what about @ q3 and better?

I'm not sure if it affect performance including Q3. According to changelog quote it seems to be tuned just below Q 3 (like Q 2,9 etc.) ???

Changelog:

aoTuV Beta4.5 [beta4 >> beta4.5]
# Reexamination of a low bit rate region, the addition of the code accompanying it, and tuning. Influence has this change below quality3.  Probably, in the especially low bit rate, it will be effective.

[lithoc]

Tested b4.5.
Notice the bitrate raised if clips contain a lot of high frequency but it maintain more detail.
I guess it must have higher priority to mid to high frequency?
But I can't hear any rumble in low frequency.

Good work aoyumi!!!

[Destroid]

Ok, took me a little while but finally got to run the test I wanted

I was using 'Lancer' aoTuv b4 "-q 1 --resample 22050" and noticed one particular a loudly-warbling sample with burbbly high-frequency artifacts.

However, for this test, I decided to re-encode using Foobar's SSRC (slow mode for testing) for both 'Lancer' aoTuv b4 and the aoTuv b4.5 binary on Aoyumi's site. This way, I could rule out the Vorbis internal resampling as a factor.

The result: waaay less HF warbling on b4.5 (or, if you prefer, a lot less annoying warbling in the HF region). Also, a nice bitrate drop with b4.5 for a 20 second sample (at 22kHz) that sounds better/less-annoying at "-q 1":
b4 = 128,571 bytes
b4.5 = 124,327 bytes

I could have ABX'ed, but what can I say? I already am impressed by the results of b4.5 at "-q 1". I still have to assume ( ) that 'Lancer' optimizations do not smear the quality of the the b4 notably enough for the most audible differences between b4 and b4.5...

edit: can not verify above assumption, Venc.exe is pain in the arse to use in FB2K

This post has been edited by Destroid: Nov 10 2005, 04:35

[yong]

This might be an off-topic...
I try to compile the aoTuV beta 4.5 source code with gcc(3.44 with msys),
but i got problem when run "configure"...
im a noob in programming/compiling...
any help is appreciated :)

CODE

long_code_here = ';
$ configure --disable-shared
checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
checking target system type... i686-pc-mingw32
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for gcc... gcc
checking for C compiler default output file name... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... .exe
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for a sed that does not truncate output... /bin/sed
checking for egrep... grep -E
checking for ld used by gcc... c:/msys/mingw/mingw32/bin/ld.exe
checking if the linker (c:/msys/mingw/mingw32/bin/ld.exe) is GNU ld... yes
checking for c:/msys/mingw/mingw32/bin/ld.exe option to reload object files... -r
checking for BSD-compatible nm... /mingw/bin/nm
checking whether ln -s works... yes
checking how to recognise dependent libraries... file_magic ^x86 archive import|^x86 DLL
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... no
checking dlfcn.h presence... no
checking for dlfcn.h... no
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking for g77... g77
checking whether we are using the GNU Fortran 77 compiler... yes
checking whether g77 accepts -g... yes
checking the maximum length of command line arguments... 8192
checking command to parse /mingw/bin/nm output from gcc object... ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking if gcc static flag works... yes
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -DDLL_EXPORT
checking if gcc PIC flag -DDLL_EXPORT works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (c:/msys/mingw/mingw32/bin/ld.exe) supports shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... Win32 ld.exe
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... no
checking whether to build static libraries... yes
configure: creating libtool
appending configuration tag "CXX" to libtool
checking for ld used by g++... c:/msys/mingw/mingw32/bin/ld.exe
checking if the linker (c:/msys/mingw/mingw32/bin/ld.exe) is GNU ld... yes
checking whether the g++ linker (c:/msys/mingw/mingw32/bin/ld.exe) supports shared libraries... yes
checking for g++ option to produce PIC... -DDLL_EXPORT
checking if g++ PIC flag -DDLL_EXPORT works... yes
checking if g++ supports -c -o file.o... yes
checking whether the g++ linker (c:/msys/mingw/mingw32/bin/ld.exe) supports shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... Win32 ld.exe
appending configuration tag "F77" to libtool
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... no
checking whether to build static libraries... yes
checking for g77 option to produce PIC... -DDLL_EXPORT
checking if g77 PIC flag -DDLL_EXPORT works... yes
checking if g77 supports -c -o file.o... yes
checking whether the g77 linker (c:/msys/mingw/mingw32/bin/ld.exe) supports shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... Win32 ld.exe
checking for memory.h... (cached) yes
checking for cos in -lm... yes
checking for pthread_create in -lpthread... no
checking for pkg-config... no
./configure: line 19440: syntax error near unexpected token `PKG_CHECK_MODULES(OGG,'
./configure: line 19440: ` PKG_CHECK_MODULES(OGG, ogg >= 1.0, HAVE_OGG=yes, HAVE_OGG=no)'

i just finished compile the vorbis source code downloaded form SVN, it didnt have this kind of problem... actually i got lot more problem when try to compile vorbis tools, but i cant ask for help in here... :)

[Mekatype]

So, b4.5 is supposed to perform better than b4 @ q3 and below, but what about @ q3 and better?

Sounds fine to me . 4 and 5 were transparent to me long before all of the tweaking with the psychoacoustics. The only major thing that really needed to corrected was some of the noise normalization issues, which are still being addressed and have been fixed. How much better can you make it possible? Aoyumi has been at it for a while now and has done a great job.

Since I use mostly Vorbis @ q6, the question was intended to let me know wether it was a good idea to replace b4 with b4.5. I apologize if it came out in an antagonizing manner.

[rudefyet]

This might be an off-topic...
I try to compile the aoTuV beta 4.5 source code with gcc(3.44 with msys),
but i got problem when run "configure"...
im a noob in programming/compiling...
any help is appreciated

CODE

long_code_here = ';
$ configure --disable-shared
checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
checking target system type... i686-pc-mingw32
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for gcc... gcc
checking for C compiler default output file name... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... .exe
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for a sed that does not truncate output... /bin/sed
checking for egrep... grep -E
checking for ld used by gcc... c:/msys/mingw/mingw32/bin/ld.exe
checking if the linker (c:/msys/mingw/mingw32/bin/ld.exe) is GNU ld... yes
checking for c:/msys/mingw/mingw32/bin/ld.exe option to reload object files... -r
checking for BSD-compatible nm... /mingw/bin/nm
checking whether ln -s works... yes
checking how to recognise dependent libraries... file_magic ^x86 archive import|^x86 DLL
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... no
checking dlfcn.h presence... no
checking for dlfcn.h... no
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking for g77... g77
checking whether we are using the GNU Fortran 77 compiler... yes
checking whether g77 accepts -g... yes
checking the maximum length of command line arguments... 8192
checking command to parse /mingw/bin/nm output from gcc object... ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking if gcc static flag  works... yes
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -DDLL_EXPORT
checking if gcc PIC flag -DDLL_EXPORT works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (c:/msys/mingw/mingw32/bin/ld.exe) supports shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... Win32 ld.exe
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... no
checking whether to build static libraries... yes
configure: creating libtool
appending configuration tag "CXX" to libtool
checking for ld used by g++... c:/msys/mingw/mingw32/bin/ld.exe
checking if the linker (c:/msys/mingw/mingw32/bin/ld.exe) is GNU ld... yes
checking whether the g++ linker (c:/msys/mingw/mingw32/bin/ld.exe) supports shared libraries... yes
checking for g++ option to produce PIC... -DDLL_EXPORT
checking if g++ PIC flag -DDLL_EXPORT works... yes
checking if g++ supports -c -o file.o... yes
checking whether the g++ linker (c:/msys/mingw/mingw32/bin/ld.exe) supports shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... Win32 ld.exe
appending configuration tag "F77" to libtool
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... no
checking whether to build static libraries... yes
checking for g77 option to produce PIC... -DDLL_EXPORT
checking if g77 PIC flag -DDLL_EXPORT works... yes
checking if g77 supports -c -o file.o... yes
checking whether the g77 linker (c:/msys/mingw/mingw32/bin/ld.exe) supports shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... Win32 ld.exe
checking for memory.h... (cached) yes
checking for cos in -lm... yes
checking for pthread_create in -lpthread... no
checking for pkg-config... no
./configure: line 19440: syntax error near unexpected token `PKG_CHECK_MODULES(OGG,'
./configure: line 19440: `  PKG_CHECK_MODULES(OGG, ogg >= 1.0, HAVE_OGG=yes, HAVE_OGG=no)'

i just finished compile the vorbis source code downloaded form SVN, it didnt have this kind of problem... actually i got lot more problem when try to compile vorbis tools, but i cant ask for help in here...

looks like you just need to install pkg-config

[john33]

Thanks John...

Could you update also libvorbis.dll with this new Aoyumi stuff ?

That, and most of the other stuff is now at Rarewares.

[rt87]

Thanks John...

Could you update also libvorbis.dll with this new Aoyumi stuff ?

That, and most of the other stuff is now at Rarewares.

Thanks John!

[Megaman]

OggDropXPd and LameDropXPd do not work on my system....I drop files but absolutely nothing seems to happen.
They did work in the past but ceased to work for no apparent reason...
What might be happening?

I run WinME at home, have OggDropXPd & LameDropXPd in the same folder with every dll you could possibly imagine (libmmd, etc.). Tried deleting/replacing the files, new versions, etc. nothing happens.
I use oggenc2.6 most of the time, but can´t stop wondering why these apps don´t work on my system.

Any clues?.

Will try libmmd 8.1 just in case I have an old version, but I don´t think so.

Thanks for compiling this new version for us!.

[MedO]

I also had this problem (only with lamedropxpd, though), it seems it doesn't work on 95/98/Me anymore. On XP everything works fine.

MedO

[john33]

OggDropXPd and LameDropXPd do not work on my system....I drop files but absolutely nothing seems to happen.
They did work in the past but ceased to work for no apparent reason...
What might be happening?

I run WinME at home, have OggDropXPd & LameDropXPd in the same folder with every dll you could possibly imagine (libmmd, etc.). Tried deleting/replacing the files, new versions, etc. nothing happens.
I use oggenc2.6 most of the time, but can´t stop wondering why these apps don´t work on my system.

Any clues?.

Will try libmmd 8.1 just in case I have an old version, but I don´t think so.

Thanks for compiling this new version for us!.

Does the generic VC6 compile of oggdropXPd aoTuVb4.5 not work either?

[HotshotGG]

I'm not sure if it affect performance including Q3. According to changelog quote it seems to be tuned just below Q 3 (like Q 2,9 etc.) ???

Yes and majority of most the tuning he continues to do will go into this region, because it's not only a xiph bounty, but making simple adjustments that effect noise biasing in terms of psychoacoustics and noise normalization can have a profound effect on some samples. Classical pieces is the easiest example I can think of. We are never going to be able to rid the world of "pre-echo". Bowed string is closely related sawtooth oscillator, which has even and odd integer harmonics. You just can't expect a discontinous function to have a convergent fourier series it doesn't happen (without going into all of the technical babble). This is why wavelet transform theoretically would be very effective, because that would eliminate the Gibbs Phenomenon "pre-echo" all together. Would I would like to know is, I really don't know a hell of a low about numerical anaylsis, but how does lancosz-sigma factor come into play with this? Is there an algorithm in any of modern codecs that's modelled after this concept? AAC? etc. The point Noise Normalization allows all of those streaming audio freak's to sigh easy, without cringing and screaming in horror when they are listening to music.

checking for cos in -lm... yes

When I am coding sometimes with GCC in a unix enviroment I always forget you need to include the -lm flag when you are using math.h. Real PITA ;-D. Most frontends for windows usually take care of the compiler, debugging, and linking setup. In Unix you need to type all of the command-line arguments, although I never understood why you would just strictly want to generate an object file?

[Megaman]

OggDropXPd and LameDropXPd do not work on my system....I drop files but absolutely nothing seems to happen.
They did work in the past but ceased to work for no apparent reason...
What might be happening?

I run WinME at home, have OggDropXPd & LameDropXPd in the same folder with every dll you could possibly imagine (libmmd, etc.). Tried deleting/replacing the files, new versions, etc. nothing happens.
I use oggenc2.6 most of the time, but can´t stop wondering why these apps don´t work on my system.

Any clues?.

Will try libmmd 8.1 just in case I have an old version, but I don´t think so.

Thanks for compiling this new version for us!.

Does the generic VC6 compile of oggdropXPd aoTuVb4.5 not work either?

Haven´t tried with generic compile....only PIII, will try soon. Thanks John.

[fpi]

In this post:
http://www.hydrogenaudio.org/forums/index....ndpost&p=341661
Serge Smirnoff tested aoTuV beta4.5 at -q7.

Results:
http://www.soundexpert.info/coders256.jsp

This post has been edited by fpi: Nov 14 2005, 13:08

[Curtor]

I run WinME at home, have OggDropXPd & LameDropXPd in the same folder with every dll you could possibly imagine (libmmd, etc.). Tried deleting/replacing the files, new versions, etc. nothing happens.
I use oggenc2.6 most of the time, but can´t stop wondering why these apps don´t work on my system.

Any clues?.

Will try libmmd 8.1 just in case I have an old version, but I don´t think so.

Does the generic VC6 compile of oggdropXPd aoTuVb4.5 not work either?

the generic complies are fine. the problem with all of the icl compiles is that they tend to not work on win9x/ME systems. i can confirm the same behaviour of the lamedrop icl compile (and would love to see a generic one).

[Aoyumi]

"aoTuV Beta4.51" is out.

This is a bug fix release. Please replace 4.5.

aoTuV page

This post has been edited by Aoyumi: Nov 18 2005, 17:55

[madoka@ex-sounds]

"aoTuV Beta4.51" is out.

This is a bug fix release.  Please replace 4.5. 

thx Aoyumi-san

[john33]

"aoTuV Beta4.51" is out.

This is a bug fix release.  Please replace 4.5. 

aoTuV page

There's a full set of compiles at Rarewares now.

[kevtronics]

There's a full set of compiles at Rarewares now.

Just wondering... is there a reason why Aoyumi's Win32 DLLs for b4.51 are so much larger than those on Rarewares? For example:

Rarewares b4.51 vorbis.dll: 140,800 bytes
Aoyumi's b4.51 vorbis.dll: 1,170,432 bytes

Rarewares b4.51 vorbisenc.dll: 64,000 bytes
Aoyumi's b4.51 vorbisenc.dll: 1,014,784 bytes

[rjamorim]

UPX, as usual.

[Megaman]

OggDropXPd generic compile doesn´t work either on my WinME system.

Thanks Aoyumi and John for the new 4.51 compile

[sh1leshk4]

And there's a new Lancer based on aoTuV b4.51 available.
Check it out. =)

[pcatiprodotnet]

Just tested Ogg Vorbis aoTuV b4.51 for Flash Player use...

Test goal : Sounds like original (to me) during Casual listening on Flash player.
Equipment : iAudio U2 Flash player with top quality Etymotic earbuds and Ultrasone headphones.
Result :
Congratulations! Ogg Vorbis -q2 passes my casual listening test (in earlier versions I required -q4 or -q5). Plus, the stereo separation is much improved. In addition to the standard killer sound samples, a decent test song is the first 8 notes of Dreams by Van Halen; when I tested at -q1 and -q1.5 the synth _echo_ is "harsh", "staticy" and "off key", and music sometimes sounds "garbly" (sorry don't know audio technical terminology). Note however, WMA v9.1 q10 also passes my test with a file size of 2323K, while the Ogg Vorbis -q2 file size is 3595K; quite a difference, especially when stuffing into a Flash player. Although, wma v9.1 q10 doesn't pass my test with Scandinavian Metal (the bass isn't as "full"), so I'll use either Ogg Vorbis -q2 or wma v9.1 q25 for it, after more testing. FYI, I am untrained in how to listen for artifacts.. just your average music enthusiast.. 38yrs old so some high-frequency hearing loss likely. I'll wager the vast majority of common listeners judge codecs like me rather than the golden-ear pros. After listening to my samples, most of my friends agree with my assessment.
Conclusion : Excellent progress for Ogg Vorbis! The recent advances in quality at smaller file sizes, combined with newer 2GB+ Flash players, means I may soon rid myself fully of M$.
[update] So impressed with -q2 that I re-encoded all flacs to it, even though it would mean ~25% fewer songs on my flash player (wma9.1 q10-25 seems to have painful ~3-6khz range that forced me to lower equalizer to unnatural levels to compensate).
-pc

This post has been edited by pcatiprodotnet: Jan 14 2006, 01:01