windows x64 encoder for vorbis? Options

[AshenTech]

Well, a few of us have been wanting an x64 encoder for vorbis as we all run x64 windows now, None of us have any ability/skill in compiling ourselves tho.

Anybody here know where we could find an x64 aotuv 5.7 build or who could compile one for us?

I/we are very intrested to see if vorbis will show the kinds of gains lame has shown from a native x64 compile(25% gain!!!)

[lvqcl]

I/we are very intrested to see if vorbis will show the kinds of gains lame has shown from a native x64 compile(25% gain!!!)

Is that about Lame compile from lame.bakerweb.biz? ("Testing on my machine indicates that the 64-bit version is 25% faster than the 32-bit version. Even though there is no assembly used in the 64-bit build, it is still much faster. Enjoy.")

I downloaded Lame 3.98.2 from that site and also from Rarewares. My OS is 32-bit, so I can test only 32-bit versions of Lame.
Version from Rarewares is about 30% faster than 32-bit Lame from lame.bakerweb.biz. So it should be even faster than 64-bit version.

[john33]

Slightly OT, but I did compile a 'no nasm' 64 bit compile of LAME for my own testing and on all my systems, the nasm enabled 32 bit compiles were faster, not by much, but they were faster. I haven't tried oggenc2 64 bit builds, but if I have some spare time over the next few days I'll give it a try.

[AshenTech]

Slightly OT, but I did compile a 'no nasm' 64 bit compile of LAME for my own testing and on all my systems, the nasm enabled 32 bit compiles were faster, not by much, but they were faster. I haven't tried oggenc2 64 bit builds, but if I have some spare time over the next few days I'll give it a try.

thanks, I know from what i have read that to get the gains that are shown on some compiles you need to use a newer compiler then was used in the past on early 64bit compiles.

and i cant remmber, It was sevral months back that I did the lame64 tests, It was faster then the latist builds i could find on rarewares and other sites tho, tested using large files via dbpoweramp(swaping out encoder exe to keep everything even for testing)

the musepack x64 encoder is faster then the 32bit encoder.

Also would like to see oggdrop x64(so I could recode audio books i have that are single very large files that alwase over-run the 32bit memory limmit)

[lvqcl]

Also would like to see oggdrop x64(so I could recode audio books i have that are single very large files that alwase over-run the 32bit memory limmit)

But encoders don't load whole file into memory...

[Gow]

I haven't tried oggenc2 64 bit builds, but if I have some spare time over the next few days I'll give it a try.

Nice. Can't wait to read what the difference might be on a 64 bit system as I run 64 bit Windows or 64 bit Linux on all of my computers.

[AshenTech]

Also would like to see oggdrop x64(so I could recode audio books i have that are single very large files that alwase over-run the 32bit memory limmit)

But encoders don't load whole file into memory...

32bit apps unless PAE enabled/aware cant deal with files that are over 4gb, encoding from a file that when decompressed(wav) is larger then 4gb ends up erroring, and its a pain to cut it up then have to find a joiner(cant find the good ogg joiner i use to have)

a 64bit edition shouldnt have those issues as 64bit by its nature has an almost unlimmited memory pool(depending on how much you install)

I have 6gb ram and a few audio books i have(in flac atm) will not recode to vorbis due to size, i can get them into some other formats, but vorbis fails(oggdrop and commandline)

oh and these are audio books i made using textaloud mostly)

[kode54]

32bit apps unless PAE enabled/aware cant deal with files that are over 4gb, encoding from a file that when decompressed(wav) is larger then 4gb ends up erroring, and its a pain to cut it up then have to find a joiner(cant find the good ogg joiner i use to have)

Again, unless these programs are loading the files to memory or using memory mapped I/O, there is no such limitation. Of course, WAV has its own 4GB limitation, or even 2GB depending on the software, unless the software can be told to ignore the length fields in the WAV file. You know, because WAV file structures have 32-bit length fields, so they're limited to 2 or 4GB, depending on whether the software uses signed integers.

Oh yeah, almost forgot, seeking and such can also be limited to 32-bits, depending on the file I/O API used on whatever platform the programs happen to run on. This also has nothing to do with memory addressing limits.

[TrNSZ]

http://en.wikipedia.org/wiki/RF64

[AshenTech]

32bit apps unless PAE enabled/aware cant deal with files that are over 4gb, encoding from a file that when decompressed(wav) is larger then 4gb ends up erroring, and its a pain to cut it up then have to find a joiner(cant find the good ogg joiner i use to have)

Again, unless these programs are loading the files to memory or using memory mapped I/O, there is no such limitation. Of course, WAV has its own 4GB limitation, or even 2GB depending on the software, unless the software can be told to ignore the length fields in the WAV file. You know, because WAV file structures have 32-bit length fields, so they're limited to 2 or 4GB, depending on whether the software uses signed integers.

Oh yeah, almost forgot, seeking and such can also be limited to 32-bits, depending on the file I/O API used on whatever platform the programs happen to run on. This also has nothing to do with memory addressing limits.

yes I know this, but the ONLY possible way that it could be failing is because when in WAV format(raw) the file is well over 4gb, after alot of testing and talking with people on other forums(one being dbpoweramps and another being mediacoders, others as well but those are the best known) we came to the conclusion that its failing due to filesize since i can use SOME encoders to get it down or if i split it into smaller parts i can encode to voribis, but i cant go directly into vorbis, its a real pain in the ass to be honest.

[spoon]

Wave64 (Sony) is more popular than RIFF64, any wave file that is not RIFF64 and > 4GB is invalid. Whichever program is creating the wave files might be able to write to a different format which does not have the size issue.

[AshenTech]

i typical write directly to flac anymore, if i cant directly to ogg(textaloud is working on direct vorbis support that hopefully wont have the size issues that where present in the past.)

and Spoon, I still love DBP, and have left you a wishlist wish other then a native x64 version(that i would still love to see)

[john33]

OK, you can download a 64 bit build of oggenc2 - aoTuV5.7 from here: http://www.rarewares.org/files/ogg/oggenc64-aoTuVb5.7-P4.zip

Be aware that this build does not support FLAC input as libflac contains inline asm which is not supported by the x64 compiler. This was compiled using the 64 bit Intel 11.0 compiler.

It has been tested on an E4300 based system with XP-Pro x64 on which it is about 10% faster than the 32 bit P4 compile. I tried most of the compiler optimisation options before settling on the ones used here which were, in fact, the first ones I used!

Anyway, give it a try and let us know your experiences.

[AshenTech]

just a question, is the p4 compile full amd64 or only optimized for the p4's castrated em64t? just a question as I have little to no clue how intels compiler optimizes code, I do know that core2's em64t/emt64 is far better then the p4's ever was and that when i tried x64 windows on a p4 system i had it got VERY SLOW.

just wondering(this stuff intrests me even if i cant wrap my brain around the programing side of it)

and hey, 10% is still a nice boost from just moving to 32 to 64bit

This post has been edited by AshenTech: Jul 27 2009, 16:33

[AshenTech]

ok, still trying to work out why, but it seems to crash/stop responding almost instantly using dbpoweramp or foobar2k, Not sure why, will test with mediacoder and edit this post.

works with mediacoder, will have to try and track down why it wont work with dbpoweramp tho as i find it more convenient then using mediacoder for audio.

This post has been edited by AshenTech: Jul 27 2009, 17:09

[john33]

It's a full AMD64 compile. One of the options I tried was to optimise specifically for the E4300, but it was actually slower than what you now have! I'll do some more playing when I have the time.

[AshenTech]

It's a full AMD64 compile. One of the options I tried was to optimise specifically for the E4300, but it was actually slower than what you now have! I'll do some more playing when I have the time.

nice, and thank you greatly, the only change that would have been nice is to have oggenc64 say it was the 64bit ver( makes my testing easier when comparing file sizes/output )

[nycjv321]

I did a quick test of 5 songs last night while watching tv on my pvr and oggenc64 performed an average 4.28 faster real time so yea it seems to be faster not alot faster but definetly faster. I'm going to add a second option of vorbis in foobar now I would attach an excel spreadsheet of my results but don't see option to attach files. I got the results from oggenc's output I tested 2 songs of rock, 2 of cumbia, 1 of classical vocal. I actually had 8.46 greater realtime encoding spead on one of the rock songs.... so yea that's definitely notable difference in speed.

This post has been edited by nycjv321: Jul 29 2009, 18:17

[AshenTech]

works fine here using mediacoder, faster then normal autov by a good bit when doing large batches of encodes

[PatchWorKs]

Very interesting, expecially 'cause I definetly switched to WinXP 64 last month.

Suggestion/request: why don't RareWares officially delivers x64 compiles (not only for oggenc) on its pages ?

[john33]

Very interesting, expecially 'cause I definetly switched to WinXP 64 last month.

Suggestion/request: why don't RareWares officially delivers x64 compiles (not only for oggenc) on its pages ?

Probably because the gains are that great, and I already provide a large number of variants. However, it seems to me, and where relevant, it might be worth now offering some 64 bit compiles and I'll probably drop the P3 compiles - Generic and P4 32 bit should suffice, these days, I would have thought. I'm just about to go on vacation so nothing will happen for the next couple of weeks, or so, but I'll look at it when I return. I have two systems running XP Pro 32 bit and three running XP x64 Pro, so testing isn't a problem. I do variously load Vista/Windows 7 on other systems but I hate Vista with a vengeance and, sad to say, despite the hype, I'm not convinced that Windows 7 is all that much better.

[AshenTech]

how about an oggdrop64 based on current lancer?

[PatchWorKs]

I honestly don't know if it's simple or not, but it could be a good idea to implemented (for OGGDropXPd ?) a 64bit/multicore detection to automate code switching as DarkWave Studio (a GPLv3 Digital Audio Workstation for Windows) does.

DarkWave 2.9.0 sources

...just an idea...

This post has been edited by PatchWorKs: Aug 13 2009, 10:06

[john33]

I honestly don't know if it's simple or not, but it could be a good idea to implemented (for OGGDropXPd ?) a 64bit/multicore detection to automate code switching as DarkWave Studio (a GPLv3 Digital Audio Workstation for Windows) does.

DarkWave 2.9.0 sources

...just an idea...

I've only just returned! Somewhat later than originally anticipated. I'll take a look at this over the next week, or so, thanks.

[viktor]

I honestly don't know if it's simple or not, but it could be a good idea to implemented (for OGGDropXPd ?) a 64bit/multicore detection to automate code switching as DarkWave Studio (a GPLv3 Digital Audio Workstation for Windows) does.

DarkWave 2.9.0 sources

...just an idea...

I've only just returned! Somewhat later than originally anticipated. I'll take a look at this over the next week, or so, thanks.

welcome back, and looking forward to see x64 compiles of oggenc on rarewares