Resampler plugin, uses SoX 14.2.0 resampling routines Options

[h34rtb1t]

Would you please add one more configuration setting, which do upsample 4x for [0, 48]kHz and 2x for (48, 96]kHz source.

Thanks.

You can do this with SoX_resampler_mod.

Just add 2 resamplers to DSP chain. First makes 4x upsampling and passes 64000,88200,96000 unmodified. Second makes 2x upsampling and passes 128000,176400,192000 unmodified.

Oh, I see. Great tip!

But, could you please provide the binary of modded version of 0.5.4.1+SSE2?

[a3aan]

SoX resampler (+mod) 0.5.4.2:
..

Thanks!

[hidn]

It is possible to do x64 bit version of plugin?

[kode54]

It is possible to do x64 bit version of plugin?

Yes, as soon as there's an x64 version of foobar2000.

[lvqcl]

It is possible to do x64 bit version of plugin?

Yes. All you need is 64-bit version of foobar2000.

[hidn]

well. request useless. 'll just wait for the mass transition to x64

This post has been edited by hidn: Jun 8 2010, 19:09

[j_b]

Try this simple plugin. It adds 2 entries to DSP: "2x upsample w/o lpf" and "2x downsample w/o lpf".

Please consider adding “2x upsample with linear interpolation” to foo_dsp_resamp.

[lvqcl]

Please consider adding “2x upsample with linear interpolation” to foo_dsp_resamp.

Why do you want it?

This post has been edited by lvqcl: Jun 9 2010, 16:36

[ArtS21]

You can do this with SoX_resampler_mod.

Just add 2 resamplers to DSP chain. First makes 4x upsampling and passes 64000,88200,96000 unmodified. Second makes 2x upsampling and passes 128000,176400,192000 unmodified.

I'm confused Mod allows upsampling only up to 48000. How come you write about 64000,88200,96000, etc?

[lvqcl]

Mod allows upsampling only up to 48000.

You can choose target samplerate. Works here flawlessly.

[rastan]

I recently modded my X-fi Prelude with removing 24mhz crystal and connecting an external clock generator with same value due to jitter. After this mod, I managed with failure of playback 44.1k files. Since that I don't know how fix this via another hardware mod, i went to resample during playback all my archive (most 44.1khz flac) to a value which X-Fi chip natively supports it (aka 48/96khz). Then I find Sox resampler here.

I wonder that is there any comparision between X-Fi's native resampler vs. Sox even I know that Sox resampler one of the best out there.

Thanks to lvpcl and Sox team for this great fb2k component anyway..

This post has been edited by rastan: Jul 17 2010, 19:53

[khaos974]

In the 0.5.4.2, what is the difference between the mod and the mod2 versions?

[lvqcl]

mod: It doesn't resample the frequencies that you enter in the text field.

mod2: It resamples only the frequencies that you enter in the field.

[Sandrine]

Thanks for the new version! Please consider releasing processor optimized versions for mod and mod2.

[kode54]

That really depends on the resampler library itself. I don't think many compilers will just automatically parallelize/vectorize the entire process and magically make things faster.

[Alex B]

I just downloaded the v. 0.5.4.3.

I have a K10 (a Phenom II). Should I use K8 or Dual Core or should I try to run my own tests?

The packaging is now different. The mod package is separate and it does not contain optimized versions. Are the mod versions "MSVS generic" ? The v. 0.5.4.2 included SSE2 mods.

[lvqcl]

I just downloaded the v. 0.5.4.3.

I have a K10 (a Phenom II). Should I use K8 or Dual Core or should I try to run my own tests?

"Core2" is for Intel Core2 Duo/Quad processors. So I suppose that you should use K8.

Anyway, the performance increase is very little (about 10% or even less), that's why

The packaging is now different. The mod package is separate and it does not contain optimized versions.

Are the mod versions "MSVS generic" ?

Yes.

[Alex B]

Thanks.

I did a quick test. I converted 25 short wav tracks (~350 MB) from 44.1. to 48k. I ran the test set five times in a row with each different compile. The sample rate conversion settings were default. Foobar used all four CPU cores.

Here are the results:

CODE

Generic
Total encoding time: 0:22.578, 93.30x realtime
Total encoding time: 0:23.625, 89.17x realtime
Total encoding time: 0:22.140, 95.15x realtime
Total encoding time: 0:22.718, 92.73x realtime
Total encoding time: 0:22.844, 92.22x realtime

Atom
Total encoding time: 0:22.765, 92.54x realtime
Total encoding time: 0:23.594, 89.28x realtime
Total encoding time: 0:22.875, 92.09x realtime
Total encoding time: 0:23.656, 89.05x realtime
Total encoding time: 0:22.922, 91.90x realtime

Core 2
Total encoding time: 0:22.375, 94.15x realtime
Total encoding time: 0:22.813, 92.34x realtime
Total encoding time: 0:22.937, 91.84x realtime
Total encoding time: 0:22.719, 92.72x realtime
Total encoding time: 0:23.203, 90.79x realtime

K8
Total encoding time: 0:23.578, 89.34x realtime
Total encoding time: 0:24.218, 86.98x realtime
Total encoding time: 0:22.734, 92.66x realtime
Total encoding time: 0:22.657, 92.98x realtime
Total encoding time: 0:23.781, 88.58x realtime

Mod
Total encoding time: 0:24.125, 87.32x realtime
Total encoding time: 0:23.891, 88.17x realtime
Total encoding time: 0:24.141, 87.26x realtime
Total encoding time: 0:23.140, 91.04x realtime
Total encoding time: 0:22.734, 92.66x realtime

I can't make any conclusions. The results are too varied.

This post has been edited by Alex B: Sep 10 2010, 16:24

[lvqcl]

You can use foo_benchmark for tests. Just use 32-bit float WAV file as an input.

For 16-bit input files, foo_hdcd and foo_input_dts.dll will also be called. This will slightly decrease actual speed.

[kode54]

For 16-bit input files, foo_hdcd and foo_input_dts.dll will also be called. This will slightly decrease actual speed.

Only for the first 5 seconds or so worth of data, unless there's anything to decode. I suppose this still has a noticeable effect on benchmarks.

[lvqcl]

wav "decoding" speed w/o foo_hdcd and foo_input_dts:
32-bit: 6000x realtime
16-bit: 10000x realtime

with both foo_hdcd and foo_input_dts:
32-bit: 6000x realtime
16-bit: 2800x realtime


Well, it seems that this difference (10000 vs. 2800) is negligible when resampling speed is only ~90x realtime.

[Steve Forte Rio]

About new sse3 test version...

Core i3 530 @ 2.94 GHz

foobar2000 1.1 Decoding Speed Test (source: 16 bit 44.1 kHz PCM, 5 passes, buffer entire file into memory, high priority, DSP: SoX 48000 Hz Very High, 95% bandpass, linear phase)

Generic 0.5.4.3 version:

Total length: 34:51.733
Info Read time: 0:00.000
Opening time: 0:00.102
Decoding time: 0:34.626
60.409x realtime

0.5.4.3 Core 2 version:

Total length: 34:51.733
Info Read time: 0:00.000
Opening time: 0:00.052
Decoding time: 0:30.648
68.251x realtime

SSE3 test version:

Total length: 34:51.733
Info Read time: 0:00.000
Opening time: 0:00.118
Decoding time: 0:23.868
87.638x realtime

This post has been edited by Steve Forte Rio: Sep 14 2010, 21:15

[lvqcl]

Thanks for testing.

[jaro1]

The version 0.5.4.3 was for all types of processor (atom, core2, K8) SSE2 version, so there are also other processor specific optimizations there, right?
Will there also be procesor specific version with SSE3 instructions enabled? Version 0.5.5, which is SSE3, is common for all procesor types. (but maybe i am completely false). Difference between v. 0.5.4.3 (K8) - definitelly faster as generic - and 0.5.5 is negligible on Athlon 64.
Thanks to lvqcl for further improvements of his component.

[lvqcl]

http://www.hydrogenaudio.org/forums/index....st&p=722827