Help me to understand filters

[manisandher]

Or more specifically, the effects filters have within the audio band.

 

I hope that @Miska and @PeterSt will take time to contribute to this thread, but I’d be happy to hear others’ opinions too.

 

RME says, “In theory, a filter should have as little phase deviation as possible over the frequency range, have as short a settling time as possible, an acceptable decay time, and provide the maximum possible frequency range without deviation. The stopband attenuation should be high to prevent aliasing.”

 

Presumably, ‘minimum-phase’, ‘minimum-ringing’ and ‘non-ringing’ filters attempt to achieve this goal. I wanted to explore whether they actually do, so this is what I did…

 

1. generate 24/176.4 pink noise file

2. down-sample to 24/44.1

3. up-sample 24/44.1 file back up to 24/176.4, using various HQPlayer filters

4. null up-sampled file against original 24/176.4

 

This should give a good idea of how the filters actually affect the sound, at the bit level.

 

So, let’s look at how the various HQPlayer filters perform:

 

1. sinc-M:

 

 

The up-sampled and original files null to around -190dB from 0 to 21 kHz. So, we can say that the sinc-M filter is totally transparent within this range. There is no imaging beyond Nyquist (see inset).

 

2. FIR:

 

 

The up-sampled and original files null to around -190dB from 0 to 19 kHz. So, we can say that the humble FIR filter is totally transparent within this range. There is no imaging beyond Nyquist (see inset).

 

3. poly-sinc-lp:

 

 

The up-sampled and original files null to around -190dB from 0 to 16.5 kHz. So, we can say that the poly-sinc-lp filter is totally transparent withinthis range. There is a tiny amount of imaging beyond Nyquist (see inset).

 

4. minringFIR-lp:

 

 

The up-sampled and original files do not null. There is a reasonable amount of imaging beyond Nyquist (see inset).

 

5. polynomial-2:

 

 

The up-sampled and original files do not null. There is severe imaging beyond Nyquist (see inset).

 

6. IIR:

 

 

The up-sampled and original files do not null. There is no imaging beyond Nyquist (see inset).

 

7. poly-sinc-mp:

 

 

The up-sampled and original files do not null. There is a tiny amount of imaging beyond Nyquist (see inset).

 

8. minphaseFIR:

 

 

The up-sampled and original files do not null. There is no imaging beyond Nyquist (see inset).

 

I have repeated all the above with a 24/176.4 music file, with a dynamic range >20dB, lots of transients, and 'real' content up to 50 kHz. The results are identical.

 

I have two questions for @Miska and @PeterSt:

 

1. The ‘minimum-phase’, ‘minimum-ringing’ and ‘non-ringing’ filters are clearly not transparent in the audio band. So, what's the point of using them?

 

2. The humble FIR is essentially totally transparent from 0 to 19 kHz. So, what’s the point of using anything else?

 

Mani.

[manisandher]

Thanks Peter. I really appreciate your thoughts.

 

8 minutes ago, PeterSt said:

And [transients] don't show in any of your examples.

 

As I mentioned, I repeated the above with a 24/176.4 music file, with a dynamic range >20dB, lots of transients, and 'real' content up to 50 kHz. Here's the result with the FIR filter:

 

 

Again, we get a null of around -190dB. The down- and then up-sampled file is identical to the original from 0 to 19 kHz.

 

If the FIR filter were causing any phase or ringing issues, surely the up-sampled file would not null with the original.

 

What am I missing here?

 

Mani.

 

 

[manisandher]

Yes, the FFTs were really just to determine that I had nulled the the files correctly. I'm not sure if the FFTs can be used for anything more useful.

 

But this might be more helpful. I've taken a spectrogram of 10 seconds or so of the nulled music file, with large transients, and have increased the gain by 60dB:

 

 

A single missed sample would show up here, but there seems to be nothing below 21 kHz.

 

Mani.

 

[manisandher]

Similar to what I did before, I did the following:

 

1. take a 20 second snippet from a Referenece Recordings 24/176.4 track

2. down-sample to 24/44.1

3. up-sample 24/44.1 back up to 24/176.4, using various HQPlayer filters

4. null up-sampled file against original RR 24/176.4 track

5. take spectrogram of the nulled file

 

With an ideal filter the spectrogram would show absolutely nothing from 0 to 22.05 kHz. But achieving this further down, 0 to 19 kHz say, would still be an excellent result. Anyway, here's how (some of) the filters faired:

 

FIR:

 

The spectrogram shows a null of around -190dB below 19.5 kHz or so. But more importantly, there is nothing correlated with the music signal in this range.

 

poly-sinc-lp:

 

The spectrogram shows a null of around -190dB below 19 kHz or so. Again, there is nothing correlated with the music signal in this range.

 

poly-sinc-mp:

 

The non-nulled signal below 19 kHz is clearly correlated to the music signal.

 

minringFIR-lp:

 

Again, the non-nulled signal below 21 kHz is clearly correlated to the music signal, but at a much lower level than the poly-sinc-mp filter.

 

polynomial-2:

 

The non-nulled signal below 21 kHz is clearly correlated to the music signal, but to a slightly lesser extent than the poly-sinc-mp filter.

 

Do these prove that the FIR filter is essentially 'perfect' below 19 kHz?

 

Can anyone explain why a 'minimum phase, 'minimum ringing' or 'non-ringing' filter would still be a good thing?

 

Mani.

[manisandher]

30 minutes ago, yamamoto2002 said:

It is not possible to see real filter performance using your null-test method because frequency-phase response is not zero-phase for those filters.

 

OK, but why is zero-phase (linear-phase?) not 'good enough'? What problem are these 'minimum-phase', 'minimum-ringing' and 'non-ringing' filters fixing? I just can't see it.

 

Mani.

[manisandher]

7 hours ago, PeterSt said:

But it won't mean that those which you showed as "perfect" are that.

Perfect in this sense is no difference at all. -190dB is not the same by far.

 

But a -190dB null suggests that the difference between the resampled file and the original is 0.000001dB (I think) in the audio band. And bear in mind that the resampled file has been through both an anti-alias and a reconstruction filter.

 

OK, not quite perfect. But orders of magnitude more accurate to the original file than any of the 'minimum-phase', 'minimum-ringing' and 'non-ringing' filters.

 

Mani.

[manisandher]

4 minutes ago, fas42 said:

Which doesn't stop people loving the idea of toying with pet theories 😁

 

All I'm trying to do is to understand what problem 'minimum-phase', 'minimum-ringing' and 'non-ringing' filters are trying to solve.

 

Apart from latency, which @yamamoto2002 brought up, with a linear-phase FIR filter, there is no problem... as far as I can see. And yet almost all modern DACs, and certainly software players, offer a bunch of filters. Why?

 

Mani.

[manisandher]

Thanks Jussi, I appreciate your input.

 

4 hours ago, Miska said:

You are constantly assuming that your source data is accurate representation of the source analog signal. Which is not the case with most modern ADCs.

 

Of course, I have no idea what most of the music I listen to was created with. But I do know the provenance of the two files I've used in this thread:

 

1. The pink noise file was generated in Sound Forge Pro, so didn't pass through an ADC.

 

2. The Reference Recordings 24_176.4 music file wasn't recorded with a modern ADC. The ADC in question used a ladder-pipeline architecture, with a passive analogue filter with group delay correction.

 

Mani.

[manisandher]

4 hours ago, Miska said:

P.S. Your method seems to have trouble keeping up with sub-sample delays with linear phase filters.

 

Is this why I'm getting a null of 'only' -190dB with the linear phase filters?

 

Mani.

[manisandher]

3 hours ago, PeterSt said:

Mani, I think it would be true that this is an indication that your process somewhere and somehow is failing. I don't see any filter do this in-band (!).

 

I checked it and re-checked it. It shows the same behaviour with music file too:

 

 

I'm pretty confident it's correct.

 

Mani.

[manisandher]

2 hours ago, PeterSt said:

I don't care how much this is calculated as differences at -190dB. It will be wildly different if you would be able to look in a small bin *and* in the representative time span.

 

OK. So what about the spectrograms showing absolutely no signal correlated with the music in the audio band? Surely there would be something there if there were any phase or ringing issues introduced by the anti-alias and/or reconstruction filter?

 

As an example, here are two vinyl rips I captured simultaneously (using a splitter) with two different ADCs:

 

 

 

 

That extra blue line in the second is not a scratch on the record, and it doesn't appear in the first. It's actually caused by a single missed sample (due to a buffer issue). This hasn't been averaged out by the analysis software.

 

Mani.

[manisandher]

Hi Peter,

 

34 minutes ago, PeterSt said:

 

I only see this one (at the bottom of the picture) but this is not from a missing sample. It is a continuous tone.

 

Haha... Time flows vertically down on these spectrograms! The extra blue line is indeed a missing sample 🙂.

 

34 minutes ago, PeterSt said:

But I am not sure why you showed those both captures.

 

Yes, not really necessary to bring in new material, as I can show what I mean by manipulating the same files I've already used in this thread.

 

34 minutes ago, PeterSt said:

For fun you could shift two of the exact same files (the file you originally used) by a few dozen or so samples (make a copy of the file and cut out a few dozen samples from the beginning out of one of them). Now look at the nulling result. I am not sure what to expect, but I guess we will learn something from it ...

 

Shifting by a single sample destroys the null. But I'll shift by a dozen and show you the result...

 

Mani.

[manisandher]

33 minutes ago, PeterSt said:

So what you must set yourself to (IMHO) is finding what's wrong in the workflow at showing that the FIR is 100%.

 

I'm pretty confident that the workflow is 'correct' - there's just no way to get -190dB nulls consistently otherwise. However, I certainly bear in mind Jussi's earlier comment:

 

7 hours ago, Miska said:

P.S. Your method seems to have trouble keeping up with sub-sample delays with linear phase filters.

 

33 minutes ago, PeterSt said:

And if you are on to something, it is also OK (better actually - haha).

 

We'll see 🙂...

 

Mani.

[manisandher]

2 hours ago, PeterSt said:

For fun you could shift two of the exact same files (the file you originally used) by a few dozen or so samples (make a copy of the file and cut out a few dozen samples from the beginning out of one of them). Now look at the nulling result. I am not sure what to expect, but I guess we will learn something from it ...

 

0-sample shift

 

1-sample shift

 

12-sample shift

 

(19-second segment with transients. Time flows vertically down 🙂.)

 

 

Mani.

[manisandher]

Using the original music file (which is what I think you wanted?):

 

0-sample shift

 

1-sample shift

 

12-sample shift

 

Mani.

 

 

 

[manisandher]

18 minutes ago, PeterSt said:

I was actually interested in the -dB figure. And how that plot would look.

 

You don't like my spectrographs?

 

Anyway, here you are (using the music file with transients):

 

0-sample shift

 

1-sample shift

 

12-sample shift

 

Any insights?

 

Mani.

[manisandher]

1 hour ago, PeterSt said:

And why is the 1 sample as well as the 12 sample shift so nicely matching the line beyond 22.05 ?

 

They should!

 

Remember, this is the nulled file - the original 24/176.4 vs the down- and then up-sampled 24/176.4. During down-sampling, everything was lost above 22.05, so there is nothing above 22.05 in the up-sampled file either. It wouldn't matter by how many samples I shifted the resampled file, the null against the original wouldn't change above 22.05. That's how I see it anyway.

 

Answers to your other questions soon...

 

Mani.

[manisandher]

1 hour ago, PeterSt said:

Contestant #1 does not have the answers.

But it will be in the area of the 16 bit file not being able to discern the often close to 24 bit resolution of the 12 sample shift. Or you applied the shift in the down-sampled file ? (that would not have been the idea).

Resolution in 24 bit is 256 times that of 16 bit

 

Nah. The original and down-sampled files are 24-bit. The null file is 32-bit.

 

This is what I think...

 

The signal can be transformed into a whole bunch of sine waves. We've shifted by 12 samples, which creates a null in the sine wave with a 12-sample wavelength. 176400/12 = 14700. The 'null' should sit at 14.7 kHz... which it does!

 

So we should expect any shift from 8 samples upwards to produce a 'null' somewhere (it has to be below 22.05 kHz). I'll check it...

 

Mani.

[manisandher]

And indeed, the 10-sample shift nulls exactly where we'd expect it:

 

 

Mani.

[manisandher]

2 hours ago, PeterSt said:

And how does what we now see relate to this one ?:

 

 

No relationship at all. One was created using the FIR filter and shifting samples in the resampled file in the null. This one was created using the poly-sinc-mp filter. Why the null sits where is does, I have no idea. Perhaps part of the 'minimum-phase' element of this filter? @Miska will obviously know, but whether he'd like to divulge it is another thing.

 

Mani.

[manisandher]

@PeterSt, you were questioning the validity of my workflow, and especially the nulling process.

 

I'm not sure how valid this is, but I decreased a single sample of the up-sampled file by 0.001dB (as low as I could go). Here's the spectrogram of how the up-sampled file now nulls against the original:

 

 

The spectrogram is measuring the new 'peak' as sitting at -160dB, though I wouldn't trust this entirely. But hopefully it gives an idea of the effectiveness of my nulling approach.

 

Mani.

[manisandher]

22 minutes ago, danadam said:

I think you get "only" -190dB because that is basically your limit. You use 24-bit files, which have noise floor at around -144dB and FFT processing lowers that by 10*log(M/2), where M is the number of points in the FFT. Are your spectrum using 65'536 points by any chance? That would give about 45dB and -144 - 45 = -189.

 

Yes, 65,536 points (0.73 Hz/bin). OK, that makes sense.

 

But I can get a perfect null:

 

 

So maybe it's a case of either a perfect null, as above, or a minimum of -189dB otherwise, as you've calculated?

 

Mani.

[manisandher]

17 hours ago, Miska said:

You are constantly assuming that your source data is accurate representation of the source analog signal. Which is not the case with most modern ADCs.

 

15 hours ago, PeterSt said:

... This almost looks like "our filtering" can improve on the original as how you received it... snip...

 

It could be done though.

 

OK, this is the main purpose of this thread. One of the first questions I asked was:

 

"The humble FIR is essentially totally transparent from 0 to 19 kHz. So, what’s the point of using anything else?"

 

From another thread:

 

On 3/28/2020 at 4:45 PM, Miska said:

Apodizing filters[...] are designed to remove problems caused by decimation filters in ADC when the music has been recorded. So not altering the music signal in a negative way, but removing adverse alterations to it caused by earlier production stages, thus in a positive way.

 

I personally can't see how this could actually be achieved, but would love to learn more.

 

Mani.

[manisandher]

Thanks.

 

Could you give us an idea of what sort of problems decimation filters during ADC can cause, and how they can be improved by certain interpolation filters during DAC?

 

Mani.

[manisandher]

Well it's been fun and games for the last few hours...

 

The original process was:

 

1. take a 24/176.4 file

2. down-sample to 24/44.1, using various HQPlayer filters

3. up-sample to 24/176.4, using various HQPlayer filters

4. null up-sampled file against original 24/176.4

 

With this process, the up-sampled files created almost perfect* nulls with the originals (within the filter ranges of around 0 to 19 kHz), which surprised me.

 

(* Not quite perfect, because my setup only resolves to -189dB, no matter what I try.)

 

Today, I've been going the other way, i.e.:

 

1. take a 24/44.1 file (or 24/88.2)

2. up-sample to 24/176.4 (or 24/352.8), using various HQPlayer filters

3. down-sample back to 24/44.1 (or 24/88.2), using various HQPlayer filters

4. null down-sampled file against original

 

With this process, the down-sampled files do not null with the original - in the case of pink noise, around -70dB. I've checked and re-checked a number of times. I've gone back to the original process, and it still works.

 

So finally, I tried this:

 

1. take a 24/44.1 file (or 24/88.2)

2. up-sample to 24/176.4 (or 24/352.8), using HQPlayer's FIR

3. down-sample back to 24/44.1 (or 24/88.2), using HQPlayer's FIR

4. up-sample again to 24/176.4 (or 24/352.8), using HQPlayer's FIR

4. null first up-sampled file against second up-sampled file

 

The files now null to -189dB again (within the expected range), just as they did in the original process.

 

So what's going on here? I suspect this has something to do with the originals (the music files I used, and the pink noise files I generated) having too much energy right up to Nyquist. This seems to upset the filters during up-sampling. (They don't seem to be bothered during down-sampling.) And I noticed that most of the HQP filters do attenuate well before Nyquist.

 

Can anyone throw some light as to what might be happening here?

 

Mani.