libsamplerate question re: CPU dependent clipping

[ikbendeman]

I'm re-installing all of my ports do to, well, a long story. But since I started using FreeBSD about 4 or 5 years ago, I've always been curious as to what the make config option in the port audio/libsamplerate

CPU_CLIP   Allow machine dependent clipping

does.

Please, no responses such as the expected "if you don't know what it does, don't 'play' with it.'" (You know who you are)

I'm running 9.2-RELEASE AMD64 with an AMD FX 8 core 4.0 GHz processor. Also I do have to use multimedia/avidemux and similar programs to transcode video often, so it seems to me this may be relevant. Thank you in advance.

 

[cpm@]

According to the API auxiliary functions, it seems that the processor can do clipping on float to int conversions. For this reason you can enable/disable tricky CPU specific clipper through the CPU_CLIP option.

Clearly audio/libsamplerate can do time varying sample rate conversion and is basically a reimplementation of the algorithm described in Julius O. Smith's "Digital Audio Resampling Home Page".

 

[ikbendeman]

So the end result doesn't affect remuxing.. just API dependencies?

 

[cpm@]

Well, float to int conversions is one of the slowest operations you can do on an x86 processor. In this context libsamplerate emulates floating-point operations. The AMD64 processors adopted Intel's SSE and SSE2 as core instructions which provides floating-point operations compatible with many other modern CPUs. See SSE instructions on X86-64.

Summarizing, the software floating-point library is used on machines which do not have hardware support for floating-point.

PS. Regarding your question, of course, it only affects to resampling.

 

[ikbendeman]

Oh, but wasn't this a problem corrected on x86 in the late 90's or early 2k? P.s. so this essentially does nothing on amd64 (ignored?)

 

[cpm@]

Yes, this library implements quality algorithms. This quality can be measured experimentally.

Let me point out the following:

The library includes code to evaluate the quality of resampling. Typical values ​​with regard to the quality of the algorithms:

According to this post on the linux-audio-dev mailing list:

SRC_SINC_FASTEST: SNR = 102.42dB, Bandwidth = 80.23%
SRC_SINC_MEDIUM_QUALITY: SNR = 98.99dB, Bandwidth = 90.68%
SRC_SINC_BEST_QUALITY: SNR = 97.43dB, Bandwidth = 96.96%

According to mpd.conf(5)() manpage:

SRC_SINC_FASTEST: SNR = 97dB, Bandwidth = 80%
SRC_SINC_MEDIUM_QUALITY: SNR = 97dB, Bandwidth = 90%
SRC_SINC_BEST_QUALITY: SNR = 97dB, Bandwidth = 96%

The linear resampling is of very poor quality as is clear from here (see page 11).

SoX (Sound eXchange) is the one that do a better job from the point of view of resampling [1]. You can compare the quality of the resampling of different software here. The best algorithms are those that produce more black background.

See also this link to resample the audio software: "An Analysis of Sample Rate Conversion in Sox".

[1] SoX is included as audio/sox in the ports tree.