Monty blogged about 1.3.4.
http://xiphmont.livejournal.com/62844.html (http://xiphmont.livejournal.com/62844.html)
Thanks to the Mozilla folks, encoder lib size is lower now.
New compiles at Rarewares?
There will be, in time, but since there are no functional changes, it will not be a top priority.
I patched this and compiled. libvorbisfile and libvorbis were roughly the same size, while libvorbisenc (which was by far the biggest) was less than half the size. Should be half again on 64 bit architectures I think. Sounds the same to me, certainly nothing horrible happened. The patch is pretty big, although blindingly simple.
Hello everyone,
i was also trying to compile the oggenc.exe with a MinGW/GCC toolchain but had no success so far. #1 libogg, #2 libvorbis seem to build as they should but #3 vorbis-tools always end up in 'checking for vorbis...yes | checking whether OV_ECTL_COUPLING_SET is declared...no | configure: error: Vorbis >=1.3.0 required !'
I really would appreciate if there's someone out there who could point me to the right direction. I have to admit that i have only very limited programming experience but i got a few other binaries (generic lame build (btw. faster than the ICL one of rarewares); fftw; xvid; ..) compiled succesfully after reading all the INSTALLs and READMEs and searching the forums/web.
Thank you
Martin
I don't know anything about MiniGW, but that is a new option introduced in 1.3.0. Due to this new option, your libvorbis and vorbis-tools both have to have a version greater than 1.3.0 in order to be compatible. That is what the error is saying and it looks like it thinks the libvorbis version is too low.
I was using all the latest packages from xiph.org, so vorbis should be v1.3.4. The path settings seem to be ok as the libogg*.dll and libvorbis*.dll were created succesfully. What i also discovered in the config.log is 'fatal error: vorbis/vorbisenc.h: No such file or directory' but this header is available everywhere in the packages or copied to the include folders. The vorbis-tools leave me puzzled...
If someone experienced a comparable issue i would be really happy to get further hints.
The reason why i try to compile a few things by myself is because i want to see a little more into this process and because i can optimize the binaries to my specific platform (bypassing the suboptimal performance of the ICL for non-Intel systems).
Martin
ICC on AMD is still usually faster than GCC/VC (http://www.behardware.com/articles/847-15/the-impact-of-compilers-on-x86-x64-cpu-architectures.html). I assume john33 compiles with just /arch:SSE2 so none of that if (CPUID=GenuineIntel) use fast code; else use slow code; dispatcher stuff applies.
The results of my testings show something different. Of course this is only valid for this specific task of audio encoding.
Generally the Intel compiler does not optimize equally as Intel also has state on their websites
(http://software.intel.com/en-us/articles/optimization-notice#opt-en).
As far as i remember the binaries from Rarewares by john33 are optimized also to a certain degree (as are mine).
Here are the results - partially quite historic systems i know, but nice to see how they cope with this:
AMD Richland APU (Piledriver arch.)
ICC 9.1 Rarewares: ~ 10,8
ICC 12.1 Rarewares: ~ 39,6
GCC 4.8.2 Generic SSE2: ~ 49,2
GCC 4.8.2 CPU specific: ~ 54,0
Intel PIII (Coppermine arch.)
ICC 9.1 Rarewares: ~ 4,5
ICC 12.1 Rarewares: ~ 8,0
GCC 4.8.2 Generic SSE: ~ 8,2
GCC 4.8.2 CPU specific: ~ 8,4
Intel Celeron M530 (Core arch.)
ICC 9.1 Rarewares: ~ 11,7
ICC 12.1 Rarewares: ~ 20,3
GCC 4.8.2 Generic SSE2: ~ 21,1
GCC 4.8.2 CPU specific: ~ 21,6
Intel Core i7 (Sandy Bridge arch.)
ICC 9.1 Rarewares: ~ 36,2
ICC 12.1 Rarewares: ~ 49,4
GCC 4.8.2 Generic SSE2: ~ 56,1
GCC 4.8.2 CPU specific: ~ 57,0
So my conclusion: GCC provides a more constistent performance across different architectures.
It can outperform the ICL clearly even with generic builds and especially on non-Intel platforms.
These testings led me to the try of compiling the vorbis-tools by myself and also to see remarkable speed gains.
But unfortunately i had no succes as written before...
No Windows binaries yet?
No - i had to surrender. Maybe i try to cross-compile from a Linux some day. Of course i am still curious
to see how Oggenc would behave when looking at my promising Lame results.
http://dropcanvas.com/sil25 (http://dropcanvas.com/sil25)
Token from TAC 0.9.5 beta (from RareWares.org before it went down), I can't get it to work with foobar2000. Try people try and let me know.
Thanks.
http://dropcanvas.com/sil25 (http://dropcanvas.com/sil25)
Token from TAC 0.9.5 beta (from RareWares.org before it went down), I can't get it to work with foobar2000. Try people try and let me know.
Thanks.
I believe the culprit is the -Q switch: http://www.hydrogenaudio.org/forums/index....mp;#entry864337 (http://www.hydrogenaudio.org/forums/index.php?showtopic=98327&st=700&p=864337&#entry864337)
I believe the culprit is the -Q switch: http://www.hydrogenaudio.org/forums/index....mp;#entry864337 (http://www.hydrogenaudio.org/forums/index.php?showtopic=98327&st=700&p=864337&#entry864337)
It's not that sorry, install a portable foobar2000, copy that file and test it. It really takes 1min.
It's not that sorry, install a portable foobar2000, copy that file and test it. It really takes 1min.
I already said I'm getting the same error as you with foobar.
But you're right, the culprit is not the -Q switch, I spoke too soon. It might be related to stdin because all others parameters are working fine in a command line. This needs further testing which I can't do at the moment.
BTW this also looks weird:
Writing library : libVorbis (Turpakäräjiin) (20140122 (Turpakäräjiin))
It is possible to test stdin with command line:
oggenc2.exe -q 4 - -o out.ogg < input.wav
...and yes, it crashes.
BTW this also looks weird:
Writing library : libVorbis (Turpakäräjiin) (20140122 (Turpakäräjiin))
Exactly, I saw that too but ozok said it was from RareWares so I didn't even say anything.
Vendor string for 1.3.3 is "Xiph.Org libVorbis I 20120203 (Omnipresent)", for 1.3.4 is "Xiph.Org libVorbis I 20140122 (Turpakäräjiin)"
Directly from info.c:
#define ENCODE_VENDOR_STRING "Xiph.Org libVorbis I 20140122 (Turpakäräjiin)"
It is possible to test stdin with command line:
oggenc2.exe -q 4 - -o out.ogg < input.wav
...and yes, it crashes.
Brazil2, lvqcl, thanks. Any way around it?
Any way around it?
a) use custom encoding settings such as "-s %r --ignorelength -Q -q4 %s -o %d"
b) use older oggenc
c) ask john33 to fix the bug...
oggenc2 compiles updated at Rarewares to fix STDIN bug.
aoTuV Beta6.03 (2014): (http://www.geocities.jp/aoyoume/aotuv/)
The latest aoTuV beta6.03 was unified with Xiph.Org's libvorbis1.3.4. The part related to sound quality is not changed from previous version.
aoTuV Beta6.03 (2014): (http://www.geocities.jp/aoyoume/aotuv/)
The latest aoTuV beta6.03 was unified with Xiph.Org's libvorbis1.3.4. The part related to sound quality is not changed from previous version.
Wow from 3.6MB to 750kB.
aoTuV Beta6.03 (2014): (http://www.geocities.jp/aoyoume/aotuv/)
The latest aoTuV beta6.03 was unified with Xiph.Org's libvorbis1.3.4. The part related to sound quality is not changed from previous version.
Wow from 3.6MB to 750kB.
Almost all down to data types being changed in the codebooks tables.
Previous venc.exe was ~1.7 MB, so only 1MB size difference.
Previous venc.exe was ~1.7 MB, so only 1MB size difference.
Did you extract the zip? http://www.rarewares.org/ogg-oggenc.php#oggenc-aotuv (http://www.rarewares.org/ogg-oggenc.php#oggenc-aotuv). Maybe it had something different, I used RareWares' version.
Thanks for the STDIN bug fix update john33.
aoTuV Beta6.03 (2014): (http://www.geocities.jp/aoyoume/aotuv/)
The latest aoTuV beta6.03 was unified with Xiph.Org's libvorbis1.3.4. The part related to sound quality is not changed from previous version.
I wonder when John33 will modify oggenc2.87 with this updated version of aoTuv6.03b?
I am currently not at home but I will look at this on my return on June 16.
I wonder when John33 will modify oggenc2.87 with this updated version of aoTuv6.03b?
Do you have issues using venc.exe?
"There are no functional changes over the previous 1.3.3 release. "
However, there is a substantial reduction in the size of the binary and in memory use.
will there be an updated lancer build as well?
Good question. The non-Lancer build is a little too slow (AAC is 2 minutes faster).
yes, i never understood why the speed optimized build does not get the attention it deserves. the difference is huge.
will there be an updated lancer build as well?
Good question.
hi, first post here. from what i could read in this thread is, that 'there are no functional changes over the previous 1.3.3 release', but i wonder why the 'standard' oggenc builds get updated, while the lancer build does not?
so i would also like to see an updated lancer build on rarewares.
libvorbis 1.3.5 (2015-03-03) -- "Xiph.Org libVorbis I 20150105 (⛄⛄⛄⛄)"
* Tolerate single-entry codebooks.
* Fix decoder crash with invalid input.
* Fix encoder crash with non-positive sample rates.
# Fix issues in vorbisfile's seek bisection code.
* Spec errata.
* Reject multiple headers of the same type.
* Various build fixes and code cleanup.
Are the improvements from Aotuv b6.03 merged in the official vorbis libraries?
Are the improvements from Aotuv b6.03 merged in the official vorbis libraries?
It's funny how this never gets ansewered, like it's a political issue. Vorbis is almost on the other side anyway, I guess who cares anymore?
It is too bad because now I need to find packages for the aotuv version under Linux instead of the ordinary every time I try out distros or wack up a system (because of trying to learn them).
libvorbis 1.3.5 (2015-03-03) -- "Xiph.Org libVorbis I 20150105 (????)"
* Tolerate single-entry codebooks.
* Fix decoder crash with invalid input.
* Fix encoder crash with non-positive sample rates.
# Fix issues in vorbisfile's seek bisection code.
* Spec errata.
* Reject multiple headers of the same type.
* Various build fixes and code cleanup.
thank you for the info. nice to see an update again. it is not dead yet
@eahm: i would also like to know, but i think such an important step would be mentioned in the changelog (at least i hope so)
I wanted to get someone mad so they could finally reply to that but it didn't work. Of course Vorbis is still huge in the gaming business especially and I would love to know that as well.
john33 can we see the new builds with 1.3.5? Thank you.
I wanted to get someone mad so they could finally reply to that but it didn't work. Of course Vorbis is still huge in the gaming business especially and I would love to know that as well.
john33 can we see the new builds with 1.3.5? Thank you.
All done and available. Sorry for the delay.
All done and available. Sorry for the delay.
Are you kidding
meus? This was super fast!
I see the aoTuV are with 1.3.4, is it worth it to update them as well?
Thank you!
edit:
Also sorry small typo: the homepage says "Intel 14.0.1" but the vorbis page "ICL 14.0.3.202".
All done and available. Sorry for the delay.
Are you kidding meus? This was super fast!
I see the aoTuV are with 1.3.4, is it worth it to update them as well?
Thank you!
edit:
Also sorry small typo: the homepage says "Intel 14.0.1" but the vorbis page "ICL 14.0.3.202".
The aoTuV/libvorbis 1.3.4 merger was done by Aoyumi (Monty was too damn lazy to do it), and is separate to the official Vorbis encoder, so upgrading to libvorbis 1.3.5 from that version wouldn't make any sense. aoTuV is better than the official version. The Lancer/aoTuV version is even better. But, of course, it always gets treated like the bastard stepchild, so nobody can be bothered to update it in a timely fashion. Odd how they much rather have a slower version of it out there then a faster version. Weird
aoTuV is better than the official version.
1) Do you have any final proof on this? I think many people are still waiting.
2) If it's that much better why doesn't Xiph integrate the improvements? Sincere question.
Thanks!
All done and available. Sorry for the delay.
Are you kidding meus? This was super fast!
I see the aoTuV are with 1.3.4, is it worth it to update them as well?
Thank you!
edit:
Also sorry small typo: the homepage says "Intel 14.0.1" but the vorbis page "ICL 14.0.3.202".
The aoTuV/libvorbis 1.3.4 merger was done by Aoyumi (Monty was too damn lazy to do it), and is separate to the official Vorbis encoder, so upgrading to libvorbis 1.3.5 from that version wouldn't make any sense. aoTuV is better than the official version. The Lancer/aoTuV version is even better. But, of course, it always gets treated like the bastard stepchild, so nobody can be bothered to update it in a timely fashion. Odd how they much rather have a slower version of it out there then a faster version. Weird
if there's got to be a aoTuV/libvorbis 1.3.5 merger first, before a new lancer build might see the light of day, this can take quite a while then i guess..
yes, not implementing aotuv is one thing, but i am even more curious to know why there is obviously no interrest in a nice gain of speed (lancer) for the official encoder? qualitywise, this should not be a huge drawback after all.
aoTuV is better than the official version. The Lancer/aoTuV version is even better. But, of course, it always gets treated like the bastard stepchild, so nobody can be bothered to update it in a timely fashion. Odd how they much rather have a slower version of it out there then a faster version. Weird
it is a pity, because merging these at a certain stage could have helped giving the vorbis encoder a not insignificant boost in popularity, i guess.
aoTuV is better than the official version.
1) Do you have any final proof on this? I think many people are still waiting.
2) If it's that much better why doesn't Xiph integrate the improvements? Sincere question.
Thanks!
The official Ogg Vorbis is about 2 minutes slower than Apple's AAC encoder. The Oggenc2.87/aoTuV 6.03 version easily beats that, and adds about a minute & change. Hydrogenaudio has recommended Aoyumi's version of the Vorbis encoder for awhile now. Read about it at their wiki.
The official Ogg Vorbis is about 2 minutes slower than Apple's AAC encoder. The Oggenc2.87/aoTuV 6.03 version easily beats that, and adds about a minute & change. Hydrogenaudio has recommended Aoyumi's version of the Vorbis encoder for awhile now. Read about it at their wiki.
Speed? Minutes? AAC? What are you talking about?
Let me try to ask again since I don't think you understood the question:
Do you have any final proof on this?
I think many people are still waiting.
Where are they?
P.S.:
HA wiki: Recommended Ogg Vorbis (http://wiki.hydrogenaud.io/index.php?title=Recommended_Ogg_Vorbis)
Xiph.org wiki: Vorbis Encoders (http://wiki.xiph.org/Vorbis_Encoders) (this page contains two links to comparisons of
official 1.1.1 with
aoTuV beta4 encoders)
"Peer-review by Hydrogenaudio enthusiasts finally decided in June 2007 that aoTuV Beta 5 are now the recommended Vorbis encoders of Hydrogenaudio." (HA wiki: Recommended Ogg Vorbis)
thanks for the links, lvqcl. interresting to see aotuv being the recommended encoder for such a long time