Error in D. Self-Riaa?

[gk7]

They use filter coefficents (in the source biquad.h and biquads.c), some discussion can be found here: Lost with direct-form filter equations (inverting) | Comp.DSP | DSPRelated.com
In theory it should be possible to add an inverse RIAA too, but I´m not a C programmer...

 

[Pano]

Thanks, good find. Would be nice if we could have someone build a precise inverse RIAA for SOX. There should be someone here on the forum who could.

 

[scott wurcer]

Will this file and/or the program you wrote for generating it be available along with the article in Linear Audio ?

Yes of course, I'll give the inverse RIAA a shot tomorrow, at 96K and up the coefficients are easier to compute.

Here's Bob's 96K values, note he used 50.5 Hz rather than 50.05Hz which is a trivial difference at the moment I can't find my corrections. I also optimized 20Hz to 20K rather than DC. The SoX source code shows you how to use these.

SUPPLY # POLES IN Z-PLANE
Zero # Real Imag.
1 -0.1141486 0.000000
2 0.9676817 0.000000
Pole # Real Imag.
1 0.8699137 0.000000
2 0.9966946 0.000000
MAXIMUM ERROR FROM 0.00 Hz TO 20000.00 Hz IS 0.0057028dB
MAXIMUM PHASE ERROR FROM 0.00 Hz TO 20000.00 Hz IS ~+/- 2.4 degrees

 

[h_a]

For sake of completeness to the original question about RIAA-accuracy, I post Douglas' reply

I am sure you are right about the RIAA inaccuracies of the 2 and
3-transistor configurations. I have retained the RIAA component values
chosen by the original designers, and have not attempted to optimise them.
The fact that the RIAA networks in both cases have standard values is a sure
indicator that they cannot be very accurate. There may of course be problems
with lack of open-loop gain at LF as well.

Hannes

 

[scott wurcer]

I found my files

fs = 96000
poles = {0.8699107603,.996723102}
zeros = {-.114149393,0.967681636}
+- .0055dB

fs = 192000
poles = {0.9328992971,0.9983633125}
zeros = {-.1040610965,0.9837523263}
+-.00032dB

Duh (head slap) for inverse RIAA swap the poles and zeros, same tolerance

 

[Pano]

Thanks Scott!

 

[gk7]

...for inverse RIAA swap the poles and zeros, same tolerance

This means the values given for the poles become those for the zeros and vice versa ?

 

[gk7]

Answer to myself: yes. Ok I managed to swap those and created a sweep with RIAA preemphasis that can be reverted to a linear response with the normal version of sox again.
File is here:
http://www.hal9000.at/tmp/5_Hz-22.05_Khz_RIAA.wav

What I did not accomplish yet is to add this to sox as an additional parameter (eg. "riaainv" as opposed to "riaa") with my very limited C programming knowledge. ("very limited" is actually euphemistic, it´s rather "non existent")

 

[gk7]

It works finally. Two patches for the original sox-14.3.2 source:

http://www.hal9000.at/tmp/sox-14.3.2-riaa.patch
http://www.hal9000.at/tmp/sox-14.3.2-riaainv.patch

The first one corrects the coefficents for 96kHz and adds those for 192kHz as suggested by Scott in post #45. The second one adds "riaainv" to apply RIAA preemphasis to a sound file. (Applying "riaa" to this new file results in a flat frequency response again.)

 

[h_a]

Thanks for the coefficients and the file! Hannes

 

[scott wurcer]

Looks good, a couple of things 1) it takes a little experimentation in using the pre and post processing gains in SoX to get just the right results. 2) I don't think you need to recompile the source, I think there is a filter option where you can pass the poles and zeros on the command line. 3) bear with it, some of the command line stuff can be really obtuse because they tried to accommodate everything. It took me almost an hour to get a three process pipeline to work and it turned out mingW is one of the only environments that explicitly requires you to set stdin and stdout to binary.

 

[Bonsai]

I've been browsing through the latter part of this thread the last few days - neat solution for testing RIAA conformance! I'll need to come back to this when I roll out my RIAA designs. Thanks for sharing.

 

[gk7]

Scott, what do you mean by "experimentation in using the pre and post processing gains" ?
I just used
sox -r 44100 -c 2 -n sox_sweep.wav synth 30 sine 20-20000 gain -20
to create a sweep with -20dB, and then
sox sox_sweep.wav sox_sweep_riaa.wav riaainv
and finally to test it
sox sox_sweep_riaa.wav test.wav riaa

compiling: I´m used to build RPMs at work (among other things) so this was the preferred
way for me, but for Windows users a command line probably would be easier. How would it look like ?

I have no experience with with mingW, on Linux pipes of course work as they should ;-)

 

[gk7]

Bonsai, do you have access to "real" test equipment (AP) to verify the accuracy of the sox riaa implementation ?

 

[Bonsai]

Bonsai, do you have access to "real" test equipment (AP) to verify the accuracy of the sox riaa implementation ?

Sorry no. When I was based in Tokyo, we had two AP's - an old one from circa mid 90's and a new one we bought in 2010.

The Taipei lab unfortunately is more computing and power focussed and there is no audio lab gear.

 

[scott wurcer]

Bonsai, do you have access to "real" test equipment (AP) to verify the accuracy of the sox riaa implementation ?

My memory is probably weak on the problems I had under windows, but in the end I got the pipes to work under DOS exactly as in Linux. My only linux box is at work and I'm not allowed admin privileges for obvious reasons, this makes things difficult because I'm not allowed to install any updated libs or patches.

The result checked digitally at the 32bit level, putting a DAC A/D in the chain will only make it worse. Not sure what you mean here.

 

[scott wurcer]

Here is my comparison between the exact continuous RIAA, riaa(f) = (sqrt(1+f*f*4*pi*pi*318us*318us))/((sqrt(1+f*f*4*pi*pi*3180us*3180us))*(sqrt(1+f*f*4*pi*pi*75us*75us))) and the IIR (fs = 192k) version at 100 ~1/10th octave points chosen to be nearest exact 65536 length FFT frequencies (so you use no windowing).

I also checked SoX with Baudline under Linux with the same answer. Baudline has an unwindowed FFT option which Audition does not (you can also zoom in on Baudline to see the result note the scale - micro-dB). The jaggies a low frequencies are because there is not enough frequency resolution at 65K points to do 1/10th octaves at less than 40Hz or so. There are no discontinuities in the result.

 

[grufti]

I've tried, but I haven't been able to figure out how Scott's coefficients fit into the standard biquad scheme.

sox has worked without problems for me in the Windows 7 command line environment [run cmd]. It is important though that you use directories for your files that you are authorized for.

This is an example of what I did to get a 96k RIAA sweep:

sweeps

sox -r 192000 -c 2 -n C:\Users\Public\RIAA\sox_sweep192k.wav synth 30 sine 5-80000 gain -40

sox -r 96000 -c 2 -n C:\Users\Public\RIAA\sox_sweep96k.wav synth 30 sine 5-40000 gain -40

RIAA filter

sox -G -c 2 C:\Users\Public\RIAA\sox_sweep96k.wav C:\Users\Public\RIAA\sox_sweep96kRIAA.wav rate 96k biquad 1.0000000000 -0.8535331000 -0.1104595113 1.0000000000 -1.8666083000 0.8670382873

I still need to check the accuracy. It would actually be nice, if somebody else could repeat this and check the result. I am currently limited to the software that I have on my notebok while traveling.

 

[scott wurcer]

I've tried, but I haven't been able to figure out how Scott's coefficients fit into the standard biquad scheme.

I still need to check the accuracy. It would actually be nice, if somebody else could repeat this and check the result. I am currently limited to the software that I have on my notebok while traveling.

The inline biquad uses the polynomial form of coefficients, check the source and find the function polynomial_from_poles to get the convention that SoX uses. This is a frequent point of confusion.

The function simply makes the pole/zero representation into the polynomial representation, i.e. (1-p1)*(1-p2) = 1-(p1+p2)+p1*p2 same for zeros.

EDIT - from the SoX source; static const double zeros[] = {-0.1141486, 0.9676817}; static const double poles[] = {0.8699137, 0.9966946}; That makes your comandline showing the zero polynomial first and the pole one second. Now you can substitute the new values.

 

[grufti]

Thank you, Scott. Your comment got me over the hump.

This is sox generating a 96k sweep at -7dB:

sox -r 96000 -c 2 -n C:\Users\Public\RIAA\sox_sweep96kminus7dB.wav synth 30 sine 5-40000 gain -7


This is sox generating an inverse RIAA sweep using Scott's values:

sox -G -c 2 C:\Users\Public\RIAA\sox_sweep96kminus7dB.wav C:\Users\Public\RIAA\sox_sweep96kinvRIAA.wav rate 96k biquad 1.0000000000 -1.8666338623 0.8670601515 1.0000000000 -0.853532243 -0.110460271

I am certain that the sox parameters can be optimized with regard to input and output gain and streamlined, but it seems that this is doing the job.