P4 optimized version of libvorbis.dll for use in BeSweet: download here

[JohnMK]

Click here to download (http://rarewares.hydrogenaudio.org/ogg.html)

Place all three files of that zip in your BeSweet directory. Your encode should proceed 40% faster now, and finally make full use of the SSE2 capabilities of your Pentium 4.

There is no need to read the rest of this thread, since this top post contains all of the latest info. The ZIP file will contain all the files that you need.

Big thanks go to john33 and DSPGuru for making this possible.

PS: For example, a file that took 2 minutes, 34 seconds to encode with the old binaries, now takes 1 minute, 50 seconds. That's 154 seconds vs. 110, a 29% drop in encode time, or a 40% increase in speed depending on how you look at it.

[Emp3r0r]

I can honestly say it seems faster to me :D

numbers later ;)

[JohnMK]

Please post your logfile. At least the part that talks about which DLL's it's using.

And yes, hard #'s would be very, very much sought after, since I can't seem to get this to work on my machine, i.e. I can't get it to use that DLL file, it always defaults to Tobias' DSF, even though I've uninstalled it? :-/ Most perplexing.

Additionially, which version of which clients are you using?

[DSPguru]

@John
check LibVorbis.dll with Dependency Walker (http://www.dependencywalker.com/). do you see any problem with one of the dependencies ?

[ChristianHJW]

Sorry John, i would test it if i had a P 4 :( ...

[kenshin]

i have five P4 systems ... i could give it whirl if it works with dvd2svcd's bundled besweet ?

all i need is step by step of installing it :)

[JohnMK]

DSPGuru,

Thank you thank you thank you thank you. You do in fact need MSVCR70.DLL.

You can download it here for the time being:
http://dikkiedik.student.utwente.nl/~marco/msvcr70.dll
Put it in c:\windows\system32\.

IT WORKS!

The speed pickup is 30%. (23 seconds for optimized DLL vs. 30 for non-optimized DLL).

I really think it would be appreciated if you would link to this stuff at your website, DSPGuru, considering how viable the P4 is finally and how many people either already have one, or might plan to get one.

[JohnMK]

Please see first post. I've modified it so people don't need to read the rest of this thread to get the important info.

[DSPguru]

Originally posted by kenshin
i have five P4 systems ... i could give it whirl if it works with dvd2svcd's bundled besweet ?this is only relevant for ogg vorbis encoding, while dvd2svcd encodes to mp2.
for faster mp2enc.dll, look here :
http://forum.doom9.org/showthread.php?s=&threadid=39932

Originally posted by JohnMK
The speed pickup is 30%. (23 seconds for optimized DLL vs. 30 for non-optimized DLL).hmm.. it would be better to estimate speed imporvement on a full-length ac3.. :o

I really think it would be appreciated if you would link to this stuff at your website, DSPGuru, considering how viable the P4 is finally and how many people either already have one, or might plan to get one. i'll add a link from my beta (http://besweet.notrace.dk/beta.html) page.

[vinks]

i had a try at using the optimised binaries, they do seem faster, i encoded the LOTR audio track (normal 3hr one) at 0.200 quality, but oddly enough, the file output i got from it was about 6 or 7 megs larger than the standard binaries. (i got a crc error from besweet so im not too sure if its to do with the optimised binary i'll try it again when i get time.) btw the encode too 27mins, previously it would have taken ~40mins to encode.

[JohnMK]

That's discouraging. Is your CPU cooled well? Are you overclocking? My CPU gets quite hot when using this compile, probably because it's finally being used in its entirety. I can honestly say, with several encodes down the shoot, I've not had any problems whatsoever with this compile. Furthermore, I have specifically looked for any size differences between P4-optimized compiles vs. standard compile, and have yet to find one; so far, files have had identical sizes. I'll try it on a few more P4 machines if I can find any around here.

[JohnMK]

I made another test, and have verified my results again:

Standard compile: 59,412,447 bytes
[00:12:52:000] <-- Transcoding Duration

P4-optimized compile: 59,411,930 bytes
[00:09:15:000] <-- Transcoding Duration

That's a difference of 0.0001% in file size. Half a kilobyte. :) Keep in mind that small differences such as this will always exist when you switch around between compilers; no two will ever produce precisely the same output for audio encodes. Further, I've seen the same compile produce consistently different output each time you encode the same file, so this ultra-tiny difference should be no concern whatsoever.

[JohnMK]

Originally posted by vinks
btw the encode too 27mins, previously it would have taken ~40mins to encode.

What speed Pentium 4 are you using? 1.5GHz?

[vinks]

Originally posted by JohnMK
What speed Pentium 4 are you using? 1.5GHz?

i'm running a 1.8ghz northwood overclocked to 2.4ghz, its been running fine for months now, it could causing the problem, i'll try encoding a few more tracks and that same track again over the next few days. btw, with the file that was a little larger, the time on it was slightly different as well, i cant remember if it was about 2mins longer or shorter, i've deleted the file so i cant check it again. but as i've said, i'll give that same clip another go (after changing my clock speed back to 1.8ghz and what not just to be sure i'm not leading you on a wild goose chase when it could just be my machine).

[vinks]

just tested the library again, on the same LOTR clip, the discrepancy is only about 700kbs, must have been my system :P

ordinary libs - 108,110kbs
p4 optimized libs - 108,875kbs

[JohnMK]

It's not a discrepency. ;) It's a normal compiler difference. Unless you use an IEEE compiler, neither result is 'correct.'

[vinks]

fair enough, enough with the semantics, i'm just happy it works and its nice and fast thanks for the binaries :)

[RathO]

Wow i must say im impressed! with the new DLL, its 40% faster!! YEAH!

Ive been using the OGGMachine 0.61, BeSweet 1.5b14 (enabling Hybridgain).

I see in my logfiles the part that talks about which DLL's it's using but its not talking about the P4 3dll.. anyway its faster!

So here i post my Logfiles....

With the new P4 DLL:

[00:00:00:000] +------- BeSweet -----
[00:00:00:000] | Input : C:\Forthebirds AC3 T02 2_0ch 192Kbps DELAY 0ms.ac3
[00:00:00:000] | Output: D:\Forthebirds AC3 T02 2_0ch 192Kbps DELAY 0ms.ogg
[00:00:00:000] | Floating-Point Process: Yes
[00:00:00:000] | PostGain normalize to : 0.97
[00:00:00:000] +-------- AZID -------
[00:00:00:000] | Input Channels Mode: 2/0, Bitrate: 192kbps
[00:00:00:000] | Output Stereo mode: Dolby surround compatible
[00:00:00:000] | Total Gain: 0.000dB, Compression: Normal
[00:00:00:000] | LFE levels: To LR -INF, To LFE 0.0dB
[00:00:00:000] | Center mix level: BSI
[00:00:00:000] | Surround mix level: BSI
[00:00:00:000] | Dialog normalization: No
[00:00:00:000] | Rear channels filtering: No
[00:00:00:000] | Source Sample-Rate: 48.0KHz
[00:00:00:000] +-------- OGG --------
[00:00:00:000] | VBR Quality : 0.350
[00:00:00:000] +---------------------
[00:03:23:936] Gain of 13.0dB had been asserted to file.
[00:03:23:936] Conversion Completed !
[00:03:23:936] Actual Avg. Bitrate : 98kbps
[00:00:16:000] <-- Transcoding Duration
Logging ends : 02/02/03 , 14:35:28.

Without the new DLL:

[00:00:00:000] +------- BeSweet -----
[00:00:00:000] | Input : C:\Forthebirds AC3 T02 2_0ch 192Kbps DELAY 0ms.ac3
[00:00:00:000] | Output: D:\Forthebirds AC3 T02 2_0ch 192Kbps DELAY 0ms without.ogg
[00:00:00:000] | Floating-Point Process: Yes
[00:00:00:000] | PostGain normalize to : 0.97
[00:00:00:000] +-------- AZID -------
[00:00:00:000] | Input Channels Mode: 2/0, Bitrate: 192kbps
[00:00:00:000] | Output Stereo mode: Dolby surround compatible
[00:00:00:000] | Total Gain: 0.000dB, Compression: Normal
[00:00:00:000] | LFE levels: To LR -INF, To LFE 0.0dB
[00:00:00:000] | Center mix level: BSI
[00:00:00:000] | Surround mix level: BSI
[00:00:00:000] | Dialog normalization: No
[00:00:00:000] | Rear channels filtering: No
[00:00:00:000] | Source Sample-Rate: 48.0KHz
[00:00:00:000] +-------- OGG --------
[00:00:00:000] | VBR Quality : 0.350
[00:00:00:000] +---------------------
[00:03:23:936] Gain of 13.0dB had been asserted to file.
[00:03:23:936] Conversion Completed !
[00:03:23:936] Actual Avg. Bitrate : 98kbps
[00:00:23:000] <-- Transcoding Duration
Logging ends : 02/02/03 , 14:38:08.

Thank You!

[TCM]

Originally posted by JohnMK
I made another test, and have verified my results again:

Standard compile: 59,412,447 bytes
[00:12:52:000] <-- Transcoding Duration

P4-optimized compile: 59,411,930 bytes
[00:09:15:000] <-- Transcoding Duration

That's a difference of 0.0001% in file size. Half a kilobyte. :) Keep in mind that small differences such as this will always exist when you switch around between compilers; no two will ever produce precisely the same output for audio encodes. Further, I've seen the same compile produce consistently different output each time you encode the same file, so this ultra-tiny difference should be no concern whatsoever.

hi,

first, sorry to jump on this thread so late, just found it while browsing around.

then, forgive my ignorance but how can this be possible? i _could_ understand a difference between a normal compile and a _hand_ optimized one. i have some more problems understanding differences between compiles from two compilers using the same source code. one compiler must be flaky then?

but one compile giving different results each time? i don't see how an algorithm, given a specific input, produces a different output each time. that is if the only input is the source file and nothing else.

can you explain please?

TCM

disclaimer: i don't code, i'm just using computers since i was 10 or so. i may not be able to output any code, but i think i have some insight in processes in and around computers. that's why this issue bothers me.

[DSPguru]

a compiler takes a C code and "converts" it into machine code (equivalent to assembly), each compiler does it his way. the intel compiler known to take advantage of new registers and ("smart") instructions offered by the P4 processor, while microsoft's compiler does not.

[TCM]

Originally posted by DSPguru
a compiler takes a C code and "converts" it into machine code (equivalent to assembly), each compiler does it his way. the intel compiler known to take advantage of new registers and ("smart") instructions offered by the P4 processor, while microsoft's compiler does not.

and this answers my question how? :)

i was talking about compiled programs processing audio data and producing a different output not only for different compiles but for the same compile

to quote again:

Keep in mind that small differences such as this will always exist when you switch around between compilers; no two will ever produce precisely the same output for audio encodes. Further, I've seen the same compile produce consistently different output each time you encode the same file, so this ultra-tiny difference should be no concern whatsoever.

still puzzled..

TCM

[DSPguru]

different encoders, read here :
http://sourceforge.net/mailarchive/forum.php?thread_id=479170&forum_id=5500

same encoder :
probably some of the process involves usage of random number generator, which iZ deterministic, but each time, starts with a different seed.

[TCM]

Originally posted by DSPguru
different encoders, read here :
http://sourceforge.net/mailarchive/forum.php?thread_id=479170&forum_id=5500


ok, as i said, i _could_ understand this, although for my taste it's still something not quite right.

same encoder :
probably some of the process involves usage of random number generator, which iZ deterministic, but each time, starts with a different seed.

of course having another input than just the audio data to process generates different output. but then, why would you have some random input when processing audio data?

sorry to ride this issue so long, i just don't get it really. quality paranoia shows here. :)

TCM

[webberg]

Hi,
Is it optimized just for Intel P4 or how will it work with my
AMD Athlon XP1800+ cpu?

[JohnMK]

Originally posted by webberg
Hi,
Is it optimized just for Intel P4 or how will it work with my
AMD Athlon XP1800+ cpu?

It will crash on your Athlon! It's P4-exclusive, sorry.

[Chez_Wimpy]

I have been using the P4 version of the ogg encoder for some time, with great results. However, the encoder is a bit out of date, using the original 20020717 build of vorbis. Is there anyone out there who could update the p4 optimized set to the current 1.0.1 set (20030909 build), which apparently removes some bugs present in the older dll?

-Chez

[tiki4]

Originally posted by Chez_Wimpy
I have been using the P4 version of the ogg encoder for some time, with great results. However, the encoder is a bit out of date, using the original 20020717 build of vorbis. Is there anyone out there who could update the p4 optimized set to the current 1.0.1 set (20030909 build), which apparently removes some bugs present in the older dll?

-Chez

Check RareWares (http://rarewares.hydrogenaudio.org). It's there already.

tiki4

[Fr4nz]

Originally posted by JohnMK
It will crash on your Athlon! It's P4-exclusive, sorry.

Please could you compile that DLL also for AMDs?

Thanks.

[Chez_Wimpy]

Originally posted by tiki4
Check RareWares (http://rarewares.hydrogenaudio.org). It's there already.

tiki4

Hmmm... I see vorbis.dll for PIV 1.0.1, but no libvorbis.dll PIV version. Since libvorbis.dll includes ogg.dll, vorbis.dll, and vorbisenc.dll I figured this was the one file we needed.

Any suggestions?

-CTB

[tiki4]

Hm, sh**!

You're right, there is only a generic version available. Sorry, I thought there's also a P4 version, but obviously this is only for HeadAC3he. Maybe you can mail to John33 or Roberto or whoever is in charge of that compiles.

tiki4

[uncola]

the link to the file is a 404, but I think its mirrored here:
http://rarewares.hydrogenaudio.org/files/libvorbis1.0.1P4.zip

this is the description on the rarewares page
libvorbis.dll using LibVorbis v1.0.1 2003-11-20
library for encoding/decoding Vorbis files.
1.0.1 (181Kb) P4 only 1.0.1 (167Kb)

[Torne]

Interestingly I tried using the P4 compile on my AMD64 machine and it segfaults, which is unfortunate. It should work (though not neccecarily optimally) as the AMD64 architecture supports SSE2; other software compiled for P4 works as expected.

[tiki4]

Possibly it's an ICL 8.0 compile. There's a new compiler switch which does the same optimizations as /axW, but makes the binary P4-exclusive (checks CPU at runtime). German c't magazine reported this in its current issue.

tiki4

P.S.: I tested normal compile vs. P4 compile on my machine and got exactly the same encoding time. It seems like I had another limiting factor in my encoding pipeline :)

[Torne]

Would someone be able to make a SSE2 compile that isn't P4 exclusive so I can test it?

[tiki4]

Sorry, I don't have the Windows compilers. Also, I'm not really sure if there isn't another problem. My last post was just a wild guess.

tiki4

[Torne]

There shouldn't be any other problems; there are no instructions that the P4 supports which an AMD64 doesn't. The only other problem would be instruction scheduling issues, but those would only cause suboptimal performance, not crashes (and will probably be pretty minimal as the AMD64 hardware instruction reordering support is quite hardcore *grin*)

[akiza]

I got the newest libvorbis.dll from rarewares ( both standard & p4 opt )

On my P4 system, libvorbis.dll(standard) run almost the same speed as libvorbis.dll(P4 optimize version)

=====

My system

[CPU] P4 celeron-D (core prescott ,L2 256KB,FSB 133Mhz )
[RAM] 512MB DDR-400
[OS] Windows XP SP2
[AP] BeSweet 1.5 b29

======

Is it happen on Prescott core P4 only ?

[kenma]

link's not working anymore, where to get the latest p4-optimized dll ? HERE (http://www.rarewares.org/files/ogg/libvorbis1.1.0P4.zip)