DeltaWave null-testing audio comparator (beta)

[Arpiben]

On 8/16/2019 at 1:34 PM, pkane2001 said:

 

Hi folks,

 

Life has been taking priority for a bit, interfering with fun. I've been working on the FFT Windowing in the spare moments, and have reworked most of the FFT logic in DeltaWave. Primarily this was to improve accuracy, I don't believe this will result in any significant improvement in the actual null calculation, since the errors we are talking about are well below -180dB or more. New version needs a lot of testing, so that's what's been holding up its release. I may post an early cut to get your feedback in a day or two.

 

@Arpiben, the noise you were noticing in the pure generated sine-wave is absolutely a numerical truncation/quantization error in floating point calculations. Consider that 32-bit floating point is actually about 23-bits of the actual number (mantissa) and about 7 bits of an exponent -- the precision can be less than a simple 24-bit integer format! Here's a spectrum plot of a 500Hz sine wave sampled @ 88.2k, all pure double floating point format with no conversions:

 

And now, the same exact data, but converted to 32-bit floating point (i.e., losing some precision). All the calculations are still performed using 64-bit floating point, so the only difference from above is the truncation of data when reducing sample size:

 

The only thing that can fix this is using higher-precision samples, so I added a 64-bit WAV file export option to DeltaWave.

I also added a number of new FFT Windows, some with excellent side lobe rejection, such as Kaiser and Taylor (1M point Taylor window is what's used in the plot above).

 

 

Hi Paul,

 

Just back from a tough road trip in Caucasus area and only start looking at the new release.

I agree with you on the quantization errors brought by computation ( truncation,roundings,etc...).

If one uses a linear scale for the frequency/bin one will notice that noise is uniformly distributed among frequency/bin scale.

 

The FFT computational noise floor is around -310 dB this translates into 46 bit. For audio case, bin values are far from reaching such level.

 

Back to questions on DW 1.038b:

• will it be possible to have a rectangular window ( equivalent to no window or boxcar) in spectrum settings ?
• what is the minimum sample length DW is able to deal with (16384)?
• what is Beta value used in Kaiser window? I am expecting Beta in between 14 and 20.
• what does the phase limit mean? Actually not possible to go under -200 dB ( same as previous versions)

With first tests I am having good result with windowing (Kaiser tested only). In one case dealing with only 9600 samples DW got into error, hence my question above.

 

 

[Arpiben]

1 hour ago, pkane2001 said:

 

Hi Arpiben,

 

-310db is actually a bit over 51 bits, not 46. As it happens, 52 bits is the size of mantissa for 64-bit IEEE floating point number, so pretty much what I'd expect. My answers below, in red:

 

• will it be possible to have a rectangular window ( equivalent to no window or boxcar) in spectrum settings ?
  • Possible, but rectangular window isn't good for any of the computations needed by DW for delta analysis
• what is the minimum sample length DW is able to deal with (16384)?
  • Yes, 16384 is the minimum
• what is Beta value used in Kaiser window? I am expecting Beta in between 14 and 20.
  • I'll have to check what actual value. It was set to get to about -300dB side lobe rejection
• what does the phase limit mean? Actually not possible to go under -200 dB ( same as previous versions)
  • That's not used anymore. It used to control the delta phase chart display by setting the minimum bin amplitude when plotting phase differences. Nonlinear EQ threshold is the setting that controls this in phase computations now. I'll remove it.

 

 

 

Thanks Paul.

Dealing with computational noise floor don't forget to take into account the length of the DFT window.

For a full scale sinusoid with only amplitude quantization and n bit resolution we have:

n DFT is the window size in base 2. 

Xref=1

window size = 1048576 -> nDFT=20

 

FFT length does not affect the computational noise floor

FFT length does reduce the quantization noise floor coefficients (Ak)

[Arpiben]

@pkane2001

 

1. When Reduce Spectral Leakage is applied  is it correct to say that:

- no windowing is applied whatever mentioned in the parameters

- a rectangle window is applied respecting coherent frequency sampling with fmin (sync with the period of the largest sine wave)

Fs/fmin= N/Np where Fs: frequency sampling , N number of samples (FFT window) , Np number of periods of fmin inside N.

 If such are you keeping the FFT size in settings or it may be a different value in order to comply with coherent sampling conditions?

 

The feature is working pretty well.😊

 

2. Regarding Delta Phase curve,its sign (+/-) may change depending on window applied. 

 

[Arpiben]

@pkane2001

 

Paul, many thanks to the improvements done in manual corrections 👍.

Nevertheless I have a few remarks. Please correct me, like usual, if I am wrong 😉

 

-Optimize is operating at one side from the starting value.

ex. Drift = -1 ppm  -> Optimize will start testing values greater or equal to -1ppm ( -0.9/-0.8/-0.976 ppm). Then it may jump to lower values but it will not repeat the same process. As a consequence one may miss the target.

 

- How do you estimate the accuracy of drift value for instance?

I have been trying it with single and multi tones with drifts varying from -1000 ppm to 1E-9 ppm and always  get something like -0,974 E xy ppm as optimised value for rms delta. Not complaining about the 2.5% error but finding it strange to have the same radical:

drift of -100 ppm -> -97,4 ppm from DW

drift of -1 ppm -> -0,974 ppm from DW

drift of -0,01 ppm -> - 0,00974 ppm from DW

etc...

 

 

[Arpiben]

@pkane2001

 

Hi Paul,

 

Just for keeping you busy 😉

I am encountering some regression when matching files with 1.039 vs 1.038: matrix dimension issues....

 

1.039: 

DeltaWave v1.0.39, 2019-09-19T15:23:34.5318178+02:00
Reference:  01 La même tribu.flac[L] 10068324 samples 44100Hz 16bits, stereo, MD5=00
Comparison: Meme_Tribu.wav[L] 10107533 samples 44100Hz 16bits, stereo, MD5=00
Settings: 
    Gain:True, Remove DC:True
    Non-linear Gain EQ:False    Non-linear Phase EQ: False
    EQ FFT Size:524288, EQ Frequency Cut: 0Hz - 384000Hz, EQ Threshold: -300dB
    Correct Drift:False, Precision:30
    Non-Linear drift Correction:False
    Upsample:False, Window:Hann
    Spectrum Window:Kaiser, Spectrum Size:524288
    Spectrogram Window:BlackmanHarris, Spectrogram Size:65536, Spectrogram Steps:4096
    Dither:False
    Trim Silence:False

Discarding Reference:  Start=0s, End=0s
Discarding Comparison: Start=0s, End=0s

Initial peak values Reference: -0,046dB   Comparison: -3,324dB
Initial RMS values Reference: -14,341dB   Comparison: -17,899dB

Null Depth=8,797dB
X-Correlation offset: -131110 samples
Stopped! Matrix dimensions must agree: op1 is 10068324x10068324, op2 is 9976423x1.
Signature: 82f47fb23bf804d35c3d634222ac4965

 

1.038: no issue

DeltaWave v1.0.38, 2019-09-19T15:18:48.8504173+02:00
Reference:  01 La même tribu.flac[L] 10068324 samples 44100Hz 16bits, stereo, MD5=00
Comparison: Meme_Tribu.wav[L] 10107533 samples 44100Hz 16bits, stereo, MD5=00
Settings: 
    Gain:True, Remove DC:True
    Non-linear Gain EQ:False    Non-linear Phase EQ: False
    EQ FFT Size:524288, EQ Frequency Cut: 0Hz - 384000Hz, EQ Threshold: -300dB
    Correct Drift:False, Precision:30
    Non-Linear drift Correction:False
    Upsample:False, Window:Hann
    Spectrum Window:Kaiser, Spectrum Size:524288
    Spectrogram Window:BlackmanHarris, Spectrogram Size:65536, Spectrogram Steps:4096
    Dither:False
    Trim Silence:False

Discarding Reference:  Start=0s, End=0s
Discarding Comparison: Start=0s, End=0s

Initial peak values Reference: -0,046dB   Comparison: -3,324dB
Initial RMS values Reference: -14,341dB   Comparison: -17,899dB

Null Depth=8,797dB
X-Correlation offset: -131110 samples

Trimmed 0 samples ( 0,00ms) front, 0 samples ( 0,00ms end)

Final peak values Reference: -0,046dB   Comparison: 0,173dB
Final RMS values Reference: -14,301dB   Comparison: -14,341dB

Gain= -3,5014dB (0,6682x) DC=-0,00052 Phase offset=-2973,015873ms (-131110 samples)
Difference (rms) = -34,72dB [-40,3dBA]
Correlated Null Depth=43,05dB [39,72dBA]
Clock drift: 0 ppm

Files are NOT a bit-perfect match (match=0,06%) at 16 bits
Files match @ 50,0163% when reduced to 5,66 bits

---- Phase difference (full bandwidth): 278524,872609174°
    0-10kHz: 9154,24°
    0-20kHz: 152412,03°
    0-24kHz: 278524,87°
Timing error (rms jitter): 12,4μs

RMS of the difference of spectra: -91,1411227767088dB
gn=1,49648068721509, dc=-0,000518149687148236, dr=0, of=-131110

DONE!

Signature: 30c4fe0450824012b633455044a94bde

[Arpiben]

4 minutes ago, pkane2001 said:

 

Thanks, Arpiben! I may know where this is happening but need to confirm. Does this happen on more than one set of files?

Yes Paul.

3 different set of files tested -> 3 aborted matching.

Rgds.

[Arpiben]

@pkane2001

 

Hi Paul,

 

Sorry to annoy again but it seems that there are some sign issues dealing with the Delta of spectrograms.

For convenience let's take two identical files, for such case I am expecting a 0 dBFS result, instead we are getting +100dBFs (or infinite)

If we change display range  cursors as min=0 dB or above and max>0 dB then the result is correct -> 0dBFs

If we change display range cursors as min=0dB or less and max <0 dB then the result is again correct -> 0dBFs

Please note that excepting amplitude, the delta of spectograms was already behaving like this in previous releases.

One may argue that you are subtracting the spectograms in linear scale then the infinite dB result is correct but then the result should not change with display range settings.

Rgds.

 

 

 

[Arpiben]

2 hours ago, pkane2001 said:

Thanks, Tom. I’ll take a look.

 

@TomCapraro is correct. Level EQ (Non linear calibration) is working with release 1.038 and not with 1.039 & 1.040.

Phase EQ seems to behave as previously.

Rgds.

 

[Arpiben]

One may add also:

• spectrogram improvements at extremity
• spectrogram colour palette
• and maybe some other to be discovered.

Thanks Paul 👍.

[Arpiben]

Hi Paul,

 

Do you mind having a look at phase delta artefacts/noises ? It is a minor issue but Delta Phase result is not steady at high frequencies.

This is not specific to actual release and was present before.

Comparing two identical files and pressing successively SHOW leads to slight different results at every sequence/press.

For example:

 

[Arpiben]

7 minutes ago, Arpiben said:

Hi Paul,

 

Do you mind having a look at phase delta artefacts/noises ? It is a minor issue but Delta Phase result is not steady at high frequencies.

This is not specific to actual release and was present before.

Comparing two identical files and pressing successively SHOW leads to slight different results at every sequence/press.

For example:

 

 

The last picture pasted was not zoomed properly, sorry. Here it is perfectly flat as expected.

 

[Arpiben]

Hi @TomCapraro,

 

Thanks for the files, but honestly I was not able to reproduce the problem of Delta spectra you mentioned. It may be due to different settings in terms of spectrum or other matching parameters. I use to unselect everything in order to activate only the sample offset correction at first step.

If you need to align pure tones/multitones a good workaround is to use the manual adjustment.

 

 

[Arpiben]

Hi Paul,

 

Thanks for all your improvements. 👍

With first tests, phase and spectrum 'noises' seem to have been  definitively fixed.

As a remark only, the matched Spectrum of Delta is no more limited to -300 dB. 

Therefore a perfect match will provide an averaged - 425 dB.

• with two identical files pressing Show or Match -> Spectrum of Delta -300 dB
• with two identical files with one of them having a sample offset pressing Match -> Spectrum of Delta - 425 dB

Rgds.

 

[Arpiben]

Hi Paul,

 

Please note that when dealing with pure tones results are varying depending on settings.

 

For pure tones with offset only ( same level) the best accuracy is achieved with:

 

  

 

If not DW may compute fake phase drifts or gain adjustments.

 

For pure tones with constant Time Interval Error, MATCH will crash DW 1.045.

 

Example:  sin((2*.pi*f0*t)-TIE)  fo=300Hz  TIE=10E-2

 

 

At the end for such signals I still prefer using manual corrections in DW 😉

[Arpiben]

37 minutes ago, pkane2001 said:

 

You don't have anything selected to correct? Try selecting Correct Phase Drift, as that will tell DW to make some corrections. It'll automatically skip actual drift calculation if Measure Simple Waveforms is selected. I can probably change it so selecting Measure Simple waveforms does something by itself, but right now, it'll skip all match operations if nothing else is selected.

 

Can you please post a log file for the crash?

 

Check it for example with @TomCapraro 10kHz  7 samples  file:

 

-> Correct Phase Drift & Measure Simple Waveforms leads to a fake drift and a poor spectrum delta

 

 -> ONLY Measure simple Waveforms leads to:

 

Crash logs when dealing with TIE:

2019-09-30 00:05:33.0765|DEBUG|Wave.WaveForm|Settings: 
    Gain:False, Remove DC:False
    Non-linear Gain EQ:False    Non-linear Phase EQ: False
    EQ FFT Size:524288, EQ Frequency Cut: 0Hz - 384000Hz, EQ Threshold: -300dB
    Correct Drift:False, Precision:30
    Non-Linear drift Correction:False
    Upsample:False, Window:Hann
    Spectrum Window:Kaiser, Spectrum Size:524288
    Spectrogram Window:Kaiser, Spectrogram Size:65536, Spectrogram Steps:1024
    Dither:False
    Trim Silence:False
    Enable Simple Waveform Measurement: True

2019-09-30 00:05:33.0961|INFO|Wave.WaveForm|Discarding Reference:  Start=0s, End=0s
2019-09-30 00:05:33.0961|INFO|Wave.WaveForm|Discarding Comparison: Start=0s, End=0s
2019-09-30 00:05:33.1579|INFO|Wave.WaveForm|
Initial peak values Reference: 0dB   Comparison: 0dB
2019-09-30 00:05:33.1579|INFO|Wave.WaveForm|Initial RMS values Reference: -3,01dB   Comparison: -3,01dB

2019-09-30 00:05:33.1689|INFO|Wave.WaveForm|Null Depth=62,863dB
2019-09-30 00:05:33.1689|DEBUG|Wave.WaveForm|Progress Updating Charts, , 20%
2019-09-30 00:05:33.2477|DEBUG|Wave.WaveForm|Progress Cross-correlation, , 35%
2019-09-30 00:10:01.9045|INFO|Wave.WaveForm|DeltaWave 1.0.45.0 starting up
2019-09-30 00:10:02.1076|INFO|Wave.WaveForm|Adding driver: [WASAPI]{0.0.0.00000000}.{f8793d52-f284-4752-bb2d-81282ff74d5b} | [WASAPI] Speaker/HP (Realtek High Definition Audio) 48000/32
2019-09-30 00:10:02.1232|INFO|Wave.WaveForm|Current driver: [WASAPI]{0.0.0.00000000}.{f8793d52-f284-4752-bb2d-81282ff74d5b}
2019-09-30 00:10:02.2794|INFO|Wave.WaveForm|Adding driver: [WASAPI]{0.0.0.00000000}.{f8793d52-f284-4752-bb2d-81282ff74d5b} | [WASAPI] Speaker/HP (Realtek High Definition Audio) 48000/32
2019-09-30 00:10:02.2794|INFO|Wave.WaveForm|Current driver: [WASAPI]{0.0.0.00000000}.{f8793d52-f284-4752-bb2d-81282ff74d5b}
2019-09-30 00:10:02.3106|DEBUG|Wave.WaveForm|TaskStart: Interactive=False
2019-09-30 00:10:02.3575|DEBUG|Wave.WaveForm|Settings: 

 

 

[Arpiben]

15 minutes ago, pkane2001 said:

 

Interestingly, I don't see any errors and the last entry shows that the program was just starting, not running a comparison? Is that when it crashes? It may be related to some corrupted data from previous runs, if that's the case.

 

 

It gets stuck at 35% cross correlation and always crashes with or without warning .

i tried several times to retrieve more information from logs but always get what I pasted.

 

Tom''s files:

https://audiophilestyle.com/applications/core/interface/file/attachment.php?id=60724

 

TIE files:

A.wavB.wav

 

 

 

[Arpiben]

8 hours ago, pkane2001 said:

 

 

@Arpiben, I updated v1.0.45 to properly handle smaller-sized files. The problem was with the number of samples in the file and the FFT size being the same, causing the FFT hop size to be zero, which in turn, caused an infinite loop. It will now compute the step size correctly.

 

You'll need to uninstall the previous DW version from Windows before installing the new one. The result of Tom's A/B comparison is below:

 

And delta Phase:

 

Thanks for testing!

 

(By the way, that 'Poor' fit quality indicator above is not because of poor fit but because there are too few samples to compute the proper drift value).

 

Thanks Paul for the corrected release 1.0.45.

 

1. FFT size = Number of samples (whatever sampling frequency) corrected issue acknowledged.

 BTW A&B files are from Arpiben & 10 kHz 7 samples (Left vs Right) files are from TomCapraro 😉 

 

2. Please note that I am not expecting DW to find the best automatic strategy for every cases simply because it is not possible. That is the reason I am quite happy with Manual Adjustments when dealing with extreme specific cases.

In my non Audio test cases , I had been testing pure tones with known TIE characteristics -> easy to apply the proper correction.

(ex. parabolic phase curve -> constant frequency drift)

With unknown defects ( majority of cases) it is a compromise and I guess you found the proper one for audio files.

 

I am glad and very grateful that DW can also be used for non audio comparisons.

Sincerely, congratulations Paul for the job you have been doing.

Rgds.

 

[Arpiben]

Hi Paul,

 

Please do you mind explaining how is Jitter estimated in DW ?

As far as I remember, it is calculated in Time Domain.

 

Now, again dealing with tones I have consistency issues regarding the Jitter values.

Pressing several times Show leads to at least three different values.

You can retrieve the behaviour with my previous A & B files. 

 

Ex:

Jitter values: 37 ns / 58.6 ns / 151.2 ns

All with same full bandwidth phase 0,00214601355966744° reported.

 

Rgds.

 

 

[Arpiben]

1 hour ago, esldude said:

Some observations about good results.  

 

Looking at the Diffmaker loop results at Gearslutz, my Zen Tour is currently 12th in a very long list of gear.  Yet it has a difference null of a bit more than -56 db.  

 

Unsynchronized  DAC and ADC, the March Audio Dac and my Zen Tour sit currently 3rd in a large list at about the same number.  This is a list nearly 9 years in the making. 

 

The best numbers of all are all good DACs feeding good ADCs where the DAC also provides the master clock. Top of the list is a Forsell MDAC feeding a Focusrite Blue Mastering 245 ADC.  This Focusrite is not your regular little interface it is a pro quality device.  The best of those get -81 db for the difference null.  Right behind it fractionally is an SPL Madison DAC feeding an evaluation board TI ADC.  

 

If I invoke Level EQ and Phase EQ those top two only improve to about -90 db.  If I do the same with my Zen Tour loopback and my March-Zen Tour they improve much more to the -86 db range.  So it would appear phase and FR are the main differences.  It looks like viewing the graphs in Deltawave the very low end is the biggest difference.  The top ones are flatter down to a 1hz or less, while others are starting to droop around 3 or 5 hz.  

 

Surprisingly the RME ADI is a couple db lower in results than my Zen Tour despite boasting better individual measurements of the ADC and DAC. It too improves to around -84 db difference if Level EQ and Phase EQ are used.  So is my Zen Tour really better than the RME all things considered?  Yeah, I know a couple db isn't much.

 

How are the DAC-ADC loop(s) performed ( internal/external cable/etc) ?

 

[Arpiben]

8 hours ago, esldude said:

I think I understood as you intended.  Once you've shown a difference the next question is what is causing the difference.  Your other choices for EQ, Phase and non-linear timing let us see where some differences are.  It appears most of them are FR and phase. Which isn't surprising.  Though still nice to confirm with some rigor. 

 

One interesting thing your software made easy to see.  Comparing a recording done now and a few minutes from now with nothing changed the nulls are of course very good.  Most of the remaining difference is 60 hz hum.  Everything in the process is the same, but I can't synchonize the 60 hz hum (even if below 100 dbFS) from one run to the next.  So sometimes it is closer in phase on 60 hz than other runs.  Which is visible in the Difference spectrum plot, and alters the already low numbers a few db.  Then you can of course notch out 60 hz.  

 

You may simultaneously record the AC hum and then substract it after alignment.

Well I didn't take yet my first coffee cup....😉

 

[Arpiben]

6 hours ago, pkane2001 said:

 

Hi Arpiben, 

 

I'm trying to reproduce this problem. Did you use Tom's A/B files or something else? I've tried with multiple files, and the jitter value appears to be constant on all Show button presses. 

 

Hi Paul,

 

I did not retrieve the reported behaviour with previous cases: pure tones or audio files.😟

But I have it with the following files. TIE values obtained with several shows: 3.5 ms / 4.4 ms / 5.6 ms / 7.8 ms 

 

A.wav

B.wav

 

Please do not play them !

A :1000 kHz 0 dBFs 

B: 1000 kHz 0 dBFs + TIE 100 ns sinus 0.1 Hz

 

DW Jitter estimation seems to be tricked with pure tones. Reported values are not correct for such cases.

With TIE= 1ms instead of 100 ns reported jitter values are: 83400 s / 39560 s

 

Rgds 

 

 

[Arpiben]

3 hours ago, pkane2001 said:

 

Can you please post the expression you use to generate 1000 kHz 0 dBFs + TIE 100 ns sinus 0.1 Hz?

 

I'm pretty sure I've fixed the variable jitter value when pressing 'Show' multiple times. The result I get for your A/B files is consistently 4.4ms.

 

 

A*sin(2*pi*f0*(t+TIE*z(t))

z(t)=sin(2*pi*fjitter*t) -> sinusoïdal jitter

z(t)= Gaussian (-1,1) or other statistical distribution

z(t)=1 for fixed phase error

 

B.wav file was with:

TIE=10E-7

fjitter= 0,1Hz

 

Rgds.

[Arpiben]

ZzZzZz no no no....😉

 

Hi Paul,

 

For keeping everyone awake here are a few minor remarks:

 

1 Jitter metric:

Reading your explanation about how it is calculated, a few posts back, I realized that when dealing with certain waveforms, the reported value may not relate to any physical rms Jitter. Nevertheless, the metric is very useful for improving any alignment.

I even tried it with rectangular functions but those are, in principle , not encountered in audio 😊

"A*sign(sin(2*pi*f0*(t+TIE*z(t)))"

 

Jitter metric measures the difference between two waveforms as an error in timing. Existing measures, such as RMS difference and correlated null are both related to the magnitude of the amplitude error, although correlated null is also related to timing.

This new measure computes an RMS timing error between the two waveforms. Assuming the amplitudes of the two waveforms are perfectly matched, this number would be the actual RMS jitter. Reported in seconds (microseconds, nanoseconds, picoseconds). The smaller the number, the smaller the overall match error. In effect, that's another number that can be used to judge the quality of the match.

 

2. Memory issues:

Trying to DW oversample big files ( 50 million samples)  leads to probable memory issues.

To be honest with such sizes I am also having issues with Python 😊

 

Stopped! Array dimensions exceeded supported range.

 

 

3. THD:

It seems that the Harmonic reported values (H1 ,H3, H5,...) are scaled with different parameters that the ones currently set: windowing, FFT size,...

I was expecting to retrieve more or less the levels shown in spectra but this is not the case.

 

4 Curve Overlay:

The curve overlay is static, meaning that one needs to keep same curve parameters before and after.

 

Rgds.

[Arpiben]

1 hour ago, pkane2001 said:

 

Hi Arpiben,

 

1. RMS Jitter is computed as the timing difference between samples in Reference and Comparison files. In effect, the calculation takes into account the timing difference of all the individual samples. So, yes, this metric is different than the usual jitter measurements, but it's also much more accurate, at least in theory 

 

2. Large files will be a problem due to memory constraints. This is not something I can address in the near future, as that will require significant restructuring of the logic and data handling in DW. You can always trim the file by skipping some seconds or minutes from the front or the end  of the file in DW to reduce the number of samples kept in memory.

 

3. I'll have to check, but the values for H1... H9 should be scaled the same as on the FFT chart. If they are not, this is likely a bug.

 

4. Curve overlay requires the same FFT size for both, the current, and the overlay charts. If the FFT size is different, a proper comparison would require resampling the frequency data which I didn't want to do. It's not hard, so if you can make an argument for why this might be important, I might add it

 

Regards,

 

    -Paul

 

 

 

 

1.&2. Ok.

4. No argument from my side just got tricked once or twice but now I know. 😉

 

3. Reading and calculating THD directly from spectrum chart is giving much closer results vs theory.

Ex. rectangular wave -> THD= 0,483 or -6.31 dB with all harmonics (around 0.38 up to H9) 

 

Thanks & Regards Paul.

[Arpiben]

3 hours ago, pkane2001 said:

 

Hi Arpiben,

 

Can you please give me an example where these are different? I've tried to reproduce this, but get fairly consistent results between the spectrum plot and the harmonics listed in the results tab. Here's an example, these are within 1dB of what appears on the plot (the plot labels have everything rounded up to a whole dB):

 

Comparison DR = 114.48dB

Comparison THD+N = -108.51dB

Comparison THD   = -117.2dB
    H1 (1000Hz) = -9.04dB
    H2 (2000Hz) = -130.47dB
    H3 (3000Hz) = -123.97dB
    H4 (4000Hz) = -141.98dB

 

And the plot (Kaiser 1M FFT):

 

 

With further trials I realised that THD reported values are correct until you distort the phase. Shifting by one sample or adding periodic jitter is enough to trick the estimation.

Ref=A: square 1 kHz

Comp=B: A shifted by one sample time

 

THD for comparison B is wrong:

    H1 (1000Hz) = 1,08dB
    H3 (3000Hz) = -16,69dB
    H5 (5000Hz) = -37,37dB
    H7 (7000Hz) = -52,92dB
    H9 (9000Hz) = -55,65dB

 

Swap Ref&Comp -> THD reading A -> values are correct

    H1 (1000Hz) =  2,1dB
    H3 (3000Hz) = -7,45dB
    H5 (5000Hz) = -11,9dB
    H7 (7000Hz) = -14,84dB
    H9 (9000Hz) = -17,05dB

 

 

A.wav

B.wav

 

Rgds.