There is a new aoTuv beta release(4.5) out.
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.
http://www.geocities.jp/aoyoume/aotuv/index.html (http://www.geocities.jp/aoyoume/aotuv/index.html)
Let's call together: Gu-ru-boo-lez!!!
Let's call together: Gu-ru-boo-lez!!! [a href="index.php?act=findpost&pid=339701"][{POST_SNAPBACK}][/a]
Erm.. as if Guru had big interest in low bitrate testing
Let's call together: Gu-ru-boo-lez!!!
Come on people! This is low bitrates area, you could test it yourself...
Thanks, i tried it...but sounds like metallic, the switch used is:
"-q-2" the nominal bitrate whas 32.
Any vorbis can encode at 20-25? (at 44 and stereo)
Thanks, i tried it...but sounds like metallic, the switch used is:
"-q-2" the nominal bitrate whas 32.
Any vorbis can encode at 20-25? (at 44 and stereo)
[a href="index.php?act=findpost&pid=339709"][{POST_SNAPBACK}][/a]
Did you compare it to aoTuV b4?
Is the encoding at high quality affected by this? I encoded a file at -q6 with both b4 and b4.5 and decoded again (with the same decoder), and the content of the decoded files differs (as shown by a quick md5 hashing).
MedO
Is the encoding at high quality affected by this? I encoded a file at -q6 with both b4 and b4.5 and decoded again (with the same decoder), and the content of the decoded files differs (as shown by a quick md5 hashing).
MedO
[a href="index.php?act=findpost&pid=339725"][{POST_SNAPBACK}][/a]
Can you find out 'audio difference' between them in some audio editor? How much differs the size of encoded files?
Let's call together: Gu-ru-boo-lez!!!
[a href="index.php?act=findpost&pid=339701"][{POST_SNAPBACK}][/a]
He's already busy with Nero AAC.
wow, nice works
Is the encoding at high quality affected by this? I encoded a file at -q6 with both b4 and b4.5 and decoded again (with the same decoder), and the content of the decoded files differs (as shown by a quick md5 hashing).
I've tried -q 4 , they can be considered bit identical
Beta4 = 3,489,542 bytes
Beta4.5 = 3,489,535 bytes
-q 2
Beta4 = 2,768,456 bytes
Beta4.5 = 2,805,795 bytes
The slight difference in -q4 might be bacause of the beta4 I used is P4 optimised, Optimised version might produce a file that has slight differences from non-optimised version.....this causes discrepencies in MD5, but it terms of perception quality, it is the same.
Lets wait a bit, maybe Aoyumi will give some explanations about this version and what we should expect from it. If it is OK, it would be wonderful if john33 compiles an OggDropXPd with this thingy inside. Is it possible, John ?
I will be testing this new release as well. I have high expectations about it, but aside the tuning at very low bitrates I don't suppose it's a major release, probably why it's numbered 4.5 and not 5.0
Aoyumi-san domo arigato
Ah, I wonder if one day you will try making the first known implementation of Bitrate Peeling. I know I would be happy about just better tuning at the higher bitrates, so that Vorbis could finally beat Musepack.
I use -q-2 sometimes on classical stuff for some reason. I have a symphony of 63 Minutes, which encodes @ 13.960.454 Bytes. With 32 kbps it does sound incredible!
Now I encoded it again with ao4.5.
I could not hear any differences/improvements at the problematic parts.
BUT theres a significant improvement in size:
aotuv4: 13.960.454 Bytes
aotuv4.5: 13.080.681 Bytes
Cool, I'll give this a try this evening since I use Vorbis at -q2.25 on my iFP-895 (with a hacked firmware to play Vorbis files that average less than 96 kbs.)
Cool, I'll give this a try this evening since I use Vorbis at -q2.25 on my iFP-895 (with a hacked firmware to play Vorbis files that average less than 96 kbs.)
[a href="index.php?act=findpost&pid=339810"][{POST_SNAPBACK}][/a]
Where can we find the firmware ?
Cool, I'll give this a try this evening since I use Vorbis at -q2.25 on my iFP-895 (with a hacked firmware to play Vorbis files that average less than 96 kbs.)
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=339810")
Where can we find the firmware ?
[a href="index.php?act=findpost&pid=339830"][{POST_SNAPBACK}][/a]
[a href="http://www.misticriver.net/showthread.php?t=24020]http://www.misticriver.net/showthread.php?t=24020[/url]
Any vorbis can encode at 20-25? (at 44 and stereo)
For the moment, it is impossible.
Lets wait a bit, maybe Aoyumi will give some explanations about this version and what we should expect from it.
Please hear and judge in person.
I downloaded this and compiled it. After unpacking the .tar.gz I had to do chmod +x on the configure and install-sh scripts before building and installing it. Other than that, no problems.
I encoded a few files and in general they are free of artifacts, except one: The encoder seems to have a strong preference for removing high frequencies at low quality settings. The encoded files sound as if they were downsampled or a low-pass filter was used. This effect diminishes with higher quality settings, and above -q7 I can't tell the difference anymore. At lower settings I can distinguish the vorbis file from the original because of the relatively increased bass and decreased treble.
I am just curious if this was intentional in the design of the encoder? I do think it is less annoying than other types of artifacts, so maybe it's not such a bad trade-off.
I can´t really hear the diference, is hard to say that is a big improvement, ok I only made one test (at -q 0), so I can´t really say that is not effective and I don´t have a "extreme hear" so it just only my opinion.
Lets wait a bit, maybe Aoyumi will give some explanations about this version and what we should expect from it. If it is OK, it would be wonderful if john33 compiles an OggDropXPd with this thingy inside. Is it possible, John ?
[a href="index.php?act=findpost&pid=339766"][{POST_SNAPBACK}][/a]
Yes, it's possible now I have the source, which wasn't available when I first looked.
Extract from one of the text files included:
aoTuV beta4.5 technical information
The differences from the aoTuV beta 4...
1. M4 code of beta3 was deleted. M5 is added as what is replaced with it. The advantage of this method is that the result stabilized more is obtained. Instead, the change width of the bit rate becomes large rather than before. [32/44.1/48kHz only]
2. New M4 was added. There is this for the same purpose as M1. However, it is tuned up only in the low bit rate region according to work and individual parameters. [32/44.1/48kHz only]
3. M2 code was extended. This decreases a specific noise problem. [32/44.1/48kHz only]
...and I mainly tune up tone/noise masking and noise normalization parameters.
The above change is applied below quality3.
2005/11/05
Aoyumi
----------------------------------------------------------------------------
I downloaded this and compiled it. After unpacking the .tar.gz I had to do chmod +x on the configure and install-sh scripts before building and installing it. Other than that, no problems.
Hi, n00b here. Downloaded, chmod'ed, configured & compiled... no errors.
But where is the executable ? Or do I miss something here ?
EDIT: Yes I did
It was libvorbis source. Oggenc source downloadpage gives me Error 404.
EDIT: Yes I did <_<
It was libvorbis source. Oggenc source downloadpage gives me Error 404.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=339977")
Here is what I did:
Download libogg-1.1.2.tar.gz and vorbis-tools-1.1.1.tar.gz from [a href="http://www.xiph.org/downloads/]http://www.xiph.org/downloads/[/url]
Download libvorbis-aotuv_b4.5.tar.gz.tgz from http://www.geocities.jp/aoyoume/aotuv/ (http://www.geocities.jp/aoyoume/aotuv/)
Unpack everything.
cd libogg-1.1.2
./configure
make
make install
cd ../aotuv-b4.5_20051105
chmod +x configure
chmod +x install-sh
./configure
make
make install
cd ../vorbis-tools-1.1.1
./configure
make
Run oggenc/oggenc
I can´t really hear the diference, is hard to say that is a big improvement, ok I only made one test (at -q 0), so I can´t really say that is not effective and I don´t have a "extreme hear" so it just only my opinion.
[a href="index.php?act=findpost&pid=339954"][{POST_SNAPBACK}][/a]
Which file was bigger? aoTuV b4 or aoTuV 4.5? May be this improvment affects size while keeping quality same?
By the way, did you use one of the famous 'hard samples' or any randomly chosen 'easy sample'?
Any vorbis can encode at 20-25? (at 44 and stereo)
For the moment, it is impossible.
I know this is not reccomended, but with oggdropXPd (and I think also with other programs) is possible to go down to 12 Kbps @ 44.1 KHz stereo using ABR with:
Min. Bitrate = 0
Nom. Bitrate = 12
Max. Bitrate = 0
I think Min. Bitrate and Max. Bitrate = 0 means there is no limit, thus give a higer quality than CBR @ 12 Kbps.
Any vorbis can encode at 20-25? (at 44 and stereo)
For the moment, it is impossible.
I know this is not reccomended, but with oggdropXPd (and I think also with other programs) is possible to go down to 12 Kbps @ 44.1 KHz stereo using ABR with:
Min. Bitrate = 0
Nom. Bitrate = 12
Max. Bitrate = 0
I think Min. Bitrate and Max. Bitrate = 0 means there is no limit, thus give a higer quality than CBR @ 12 Kbps.
[a href="index.php?act=findpost&pid=340024"][{POST_SNAPBACK}][/a]
Sorry, I just found that ABR @ 12 Kbps with oggdropXPd is automatically resampled to 8 KHz, while ABR @ 32 Kbps is resampled to 24 KHz.
Lets wait a bit, maybe Aoyumi will give some explanations about this version and what we should expect from it. If it is OK, it would be wonderful if john33 compiles an OggDropXPd with this thingy inside. Is it possible, John ?
[a href="index.php?act=findpost&pid=339766"][{POST_SNAPBACK}][/a]
Generic, P3 and P4 compiles of oggdropXPd now at Rarewares.
Thanks John...
Could you update also libvorbis.dll with this new Aoyumi stuff ?
Thanks John...
Could you update also libvorbis.dll with this new Aoyumi stuff ?
[a href="index.php?act=findpost&pid=340074"][{POST_SNAPBACK}][/a]
Surely, but do people want the full range of compiles, or is this considered somewhat experimental at this stage?
I didn't test it thoroughly, but it seems to me that the most important point was to increase the effectiveness of encoder by making same samples sound the same at lower bitrate. For example, I cannot distinguish one sample @ -q2 from another, but the one created with b4.5 is smaller. That's all I can say for now.
I really think that we must gather and do a couple of short tests just to show that b4.5 is better than 1.1, and then make it the recommended version. Aoyumi's work deserves it.
I can´t really hear the diference, is hard to say that is a big improvment, ok I only made one test (at -q 0), so I can´t really say that is not effective and I don´t have a "extreme hear" so it just only my opinion.
[a href="index.php?act=findpost&pid=339954"][{POST_SNAPBACK}][/a]
Which file was bigger? aoTuV b4 or aoTuV 4.5? May be this improvment affects size while keeping quality same?
By the way, did you use one of the famous 'hard samples' or any randomly chosen 'easy sample'?
[a href="index.php?act=findpost&pid=340016"][{POST_SNAPBACK}][/a]
Ok, the file created by 4.5 is smaller by a few kbytes, probably this is the improvment, same quality in smaller size... and not is not one of the famous hard samples, is a sample that I choose and probably an easy one...
Anyway great job Aoyumi, all Vorbis fans apreciate your hard work, I imagine that if wasn´t for you, we are still using the 1.0.1 version (or probablily 1.0.2 ) I think that the Xiph boys are busy in other things... like Theora...
Tried it on two samples - harpsicord and Prodigy "You'll Be Under My Wheels" (both of them require high bitrates with b4 q6. 1st one q6 average is 237 and second q6 average bitrate is 300!)
I tested them on -q -2, q 0, -q 1. b4 vs b4.5. I can't say I found out any difference. May be, JUST MAY BE, b 4.5 preserves high frequencies better but I can't be sure.
Also I tested each version against original file on -q 0 and -q 1. And it was slightly more difficult to ABX between b4.5 and original than b4 and original due mentioned possible better high freq preservation.
P. S. Harpsicord sample is not the sample others use. It is just from my collection.
And it was slightly more difficult to ABX between b4.5 and original than b4 and original due mentioned possible better high freq preservation.
I tried to ABX b4 to original and b4.5 to original in a pop sample at -q0, and I think it was harder with b4.5 when concentrating on the distortions in the main voice only. However, it was still easy when listening for a different artifact (close-to-noise parts of the sound being replaced by real noise... don't know if that makes any sense to you, I just don't know the right terminology) that is present in both.
MedO
I tried to ABX b4 to original and b4.5 to original in a pop sample at -q0, and I think it was harder with b4.5 when concentrating on the distortions in the main voice only.
MedO
[a href="index.php?act=findpost&pid=340117"][{POST_SNAPBACK}][/a]
Just a quick question here: after comparing b4 to the original and b4.5 to the original but not b4 to b4.5, is it really correct to draw any conclusions about the quality improvements from b4 to b4.5? I would call the method above a sighted test, and would only use that when the differences are very obvious... Were there obvious differences in your files between b4 and b4.5?
I tried to ABX b4 to original and b4.5 to original in a pop sample at -q0, and I think it was harder with b4.5 when concentrating on the distortions in the main voice only.
MedO
[a href="index.php?act=findpost&pid=340117"][{POST_SNAPBACK}][/a]
Just a quick question here: after comparing b4 to the original and b4.5 to the original but not b4 to b4.5, is it really correct to draw any conclusions about the quality improvements from b4 to b4.5? I would call the method above a sighted test, and would only use that when the differences are very obvious... Were there obvious differences in your files between b4 and b4.5?
[a href="index.php?act=findpost&pid=340121"][{POST_SNAPBACK}][/a]
In my test the difference was subtle. I think if we want reliable test, a listener first has to find such -q meaning (with potentially weaker encoder version) at which ABXing becomes VERY DIFFICULT. Then use the new version and encode a file which is about the same size as 1st encoding. If there are any improvements - the second encoding will not be possible to ABX. The main difficulty is an ABXer has to find a proper -q meaning for each sample. The second difficulty are improvements which affect quality at lowest bitrates and ABXing from the original becomes very easy. So maybe we should use 'very easy samples'?
[...] So maybe we should use 'very easy samples'?
[a href="index.php?act=findpost&pid=340127"][{POST_SNAPBACK}][/a]
The obvious thing to do is a blind test between two encoded files, A=v4.0 and B=v4.5, which have comparable filesizes. It doesn't matter what kind of samples you use. If you can hear a difference between the two versions, then go ahead and rate which one you find more pleasing...
Lets wait a bit, maybe Aoyumi will give some explanations about this version and what we should expect from it. If it is OK, it would be wonderful if john33 compiles an OggDropXPd with this thingy inside. Is it possible, John ?
[a href="index.php?act=findpost&pid=339766"][{POST_SNAPBACK}][/a]
And John please compile oggenc2.6 and ogg vorbis dlls using aoTuV b4.5 as well.
wow, this is amazing at q0, makes me with i had an vorbis portable, i am stuck with using q25 wma...
The obvious thing to do is a blind test between two encoded files, A=v4.0 and B=v4.5, which have comparable filesizes. It doesn't matter what kind of samples you use. If you can hear a difference between the two versions, then go ahead and rate which one you find more pleasing...
[a href="index.php?act=findpost&pid=340152"][{POST_SNAPBACK}][/a]
As I said before the difference between b4 and b4.5 is very small and I can't decide which one is better at such a low bitrate .
I hope others would.
Lets wait a bit, maybe Aoyumi will give some explanations about this version and what we should expect from it. If it is OK, it would be wonderful if john33 compiles an OggDropXPd with this thingy inside. Is it possible, John ?
[a href="index.php?act=findpost&pid=339766"][{POST_SNAPBACK}][/a]
Generic, P3 and P4 compiles of oggdropXPd now at Rarewares.
[a href="index.php?act=findpost&pid=340039"][{POST_SNAPBACK}][/a]
Сool ! Thanks mate!
BTW
Aoyumi, are you going to make tunings for high bitrate in the future versions ? Thanks for your great work.
Cheers
As I said before the difference between b4 and b4.5 is very small and I can't decide which one is better at such a low bitrate .
[a href="index.php?act=findpost&pid=340223"][{POST_SNAPBACK}][/a]
I think the question is which one makes the file smaller.
Surely, but do people want the full range of compiles, or is this considered somewhat experimental at this stage?
[a href="index.php?act=findpost&pid=340083"][{POST_SNAPBACK}][/a]
well...just libvorbis.dll is enough for testing I think. Not the full range of compiles.
I asked this because I'm not able to compile myself this library (only vorbisenc/vorbisfile/vorbis in fact w/o optimizations).
As I said before the difference between b4 and b4.5 is very small and I can't decide which one is better at such a low bitrate .
[a href="index.php?act=findpost&pid=340223"][{POST_SNAPBACK}][/a]
I think the question is which one makes the file smaller.
[a href="index.php?act=findpost&pid=340343"][{POST_SNAPBACK}][/a]
With my samples sizes are almost identical.
Uhm, waiting for a new Lancer !
Download libogg-1.1.2.tar.gz and vorbis-tools-1.1.1.tar.gz from http://www.xiph.org/downloads/ (http://www.xiph.org/downloads/)
Download libvorbis-aotuv_b4.5.tar.gz.tgz from http://www.geocities.jp/aoyoume/aotuv/ (http://www.geocities.jp/aoyoume/aotuv/)
Unpack everything.
cd libogg-1.1.2
./configure
make
make install
cd ../aotuv-b4.5_20051105
chmod +x configure
chmod +x install-sh
./configure
make
make install
cd ../vorbis-tools-1.1.1
./configure
make
Run oggenc/oggenc
And when you are using oggenc from vorbis-tools 1.1.1, how does this use aotuv4.5 ?
And when you are using oggenc from vorbis-tools 1.1.1, how does this use aotuv4.5 ?
Because oggenc uses the libvorbisenc/libvorbisfile libraries to do the encoding. So as long as you replace this library you should get the new encoding functionality.
You can also test it without installing and breaking packages:
cd aotuv-b4.5_20051105/
./configure
make
export LD_LIBRARY_PATH=./lib/.libs/
oggenc will now temporarily link against the new libraries and will encode with aotuv:
$>ldd /usr/bin/oggenc
libvorbisenc.so.2 => ./lib/.libs/libvorbisenc.so.2 (0xb7eea000)
libvorbis.so.0 => ./lib/.libs/libvorbis.so.0 (0xb7ec0000)
libOggFLAC.so.1 => /usr/lib/libOggFLAC.so.1 (0xb7ea1000)
libFLAC.so.6 => /usr/lib/libFLAC.so.6 (0xb7e6d000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7e4c000)
libogg.so.0 => /usr/lib/libogg.so.0 (0xb7e47000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d1a000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7feb000)
Because oggenc uses the libvorbisenc/libvorbisfile libraries to do the encoding. So as long as you replace this library you should get the new encoding functionality.
[a href="index.php?act=findpost&pid=340504"][{POST_SNAPBACK}][/a]
yeah it's pretty handy for packaging
from RareWares/Debian:
$ ldd /usr/bin/oggenc-aotuv
linux-gate.so.1 => (0xffffe000)
libvorbisenc.so.2 => /usr/lib/libvorbis-aotuv/libvorbisenc.so.2 (0xb7ead000)
libvorbis.so.0 => /usr/lib/libvorbis-aotuv/libvorbis.so.0 (0xb7e83000)
libOggFLAC.so.1 => /usr/lib/libOggFLAC.so.1 (0xb7e59000)
libFLAC.so.6 => /usr/lib/libFLAC.so.6 (0xb7e1c000)
libm.so.6 => /lib/tls/libm.so.6 (0xb7df7000)
libogg.so.0 => /usr/lib/libogg.so.0 (0xb7df1000)
libc.so.6 => /lib/tls/libc.so.6 (0xb7cb9000)
/lib/ld-linux.so.2 (0xb7fad000)
btw, aotuv 4.5 is at RW/Debian now
later
I think aotuv beta 4.5 is safe to use.
my logic: new Aoyumi releaze is BETA 4.5, not new TEST version.
So, b4.5 is supposed to perform better than b4 @ q3 and below, but what about @ q3 and better?
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.
So, b4.5 is supposed to perform better than b4 @ q3 and below, but what about @ q3 and better?
[a href="index.php?act=findpost&pid=340832"][{POST_SNAPBACK}][/a]
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.
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!!!
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 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 :)
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)'
[span style=\'font-size:8pt;line-height:100%\']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... :)[/span]
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.
[a href="index.php?act=findpost&pid=340836"][{POST_SNAPBACK}][/a]
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.
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
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)'
[span style=\'font-size:8pt;line-height:100%\']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... [/span]
[a href=\"index.php?act=findpost&pid=340869\"][{POST_SNAPBACK}][/a]
looks like you just need to install pkg-config
Thanks John...
Could you update also libvorbis.dll with this new Aoyumi stuff ?
[a href="index.php?act=findpost&pid=340074"][{POST_SNAPBACK}][/a]
That, and most of the other stuff is now at Rarewares.
Thanks John...
Could you update also libvorbis.dll with this new Aoyumi stuff ?
[a href="index.php?act=findpost&pid=340074"][{POST_SNAPBACK}][/a]
That, and most of the other stuff is now at Rarewares.
[a href="index.php?act=findpost&pid=341008"][{POST_SNAPBACK}][/a]
Thanks John!
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!.
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
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!.
[a href="index.php?act=findpost&pid=341115"][{POST_SNAPBACK}][/a]
Does the generic VC6 compile of oggdropXPd aoTuVb4.5 not work either?
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?
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!.
[a href="index.php?act=findpost&pid=341115"][{POST_SNAPBACK}][/a]
Does the generic VC6 compile of oggdropXPd aoTuVb4.5 not work either?
[a href="index.php?act=findpost&pid=341141"][{POST_SNAPBACK}][/a]
Haven´t tried with generic compile....only PIII, will try soon. Thanks John.
In this post:
http://www.hydrogenaudio.org/forums/index....ndpost&p=341661 (http://www.hydrogenaudio.org/forums/index.php?showtopic=37039&view=findpost&p=341661)
Serge Smirnoff tested aoTuV beta4.5 at -q7.
Results:
http://www.soundexpert.info/coders256.jsp (http://www.soundexpert.info/coders256.jsp)
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).
"aoTuV Beta4.51" is out.
This is a bug fix release. Please replace 4.5.
aoTuV page (http://www.geocities.jp/aoyoume/aotuv/)
"aoTuV Beta4.51" is out.
This is a bug fix release. Please replace 4.5.
thx Aoyumi-san
"aoTuV Beta4.51" is out.
This is a bug fix release. Please replace 4.5.
aoTuV page (http://www.geocities.jp/aoyoume/aotuv/)
[a href="index.php?act=findpost&pid=342899"][{POST_SNAPBACK}][/a]
There's a full set of compiles at Rarewares now.
There's a full set of compiles at Rarewares now.
[a href="index.php?act=findpost&pid=342962"][{POST_SNAPBACK}][/a]
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 bytesAoyumi's b4.51 vorbis.dll:
1,170,432 bytes Rarewares b4.51 vorbisenc.dll:
64,000 bytesAoyumi's b4.51 vorbisenc.dll:
1,014,784 bytes
UPX, as usual.
OggDropXPd generic compile doesn´t work either on my WinME system.
Thanks Aoyumi and John for the new 4.51 compile
And there's a new Lancer based on aoTuV b4.51 available.
Check it out (http://homepage3.nifty.com/blacksword/). =)
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