What Makes Good Filtering?

[PeterSt]

This way the computational load stays constant as input sampling rate increases but MCLK stays the same.

 

Also and a bit of a thread-filler : If not read carefully, it is suggested that no matter the input rate, the clock cycles needed are always the same. Of course this is only true for the last step (input of 176.4 of this last step makes 352.8 of it). But now it also makes no sense any more. What I mean is, when 44.1 is input and the computational step that makes 88.2 of it, it is a step which consumes time. If 88.2 is input that step can be skipped and thus it does not take time either. I both cases the next step - make 176.4 out of 88.2 - takes as much time and the last step (176.4 into 352.8) ditto.

 

No way I am saying that Miska told some untruth, but you'd first have to know before you can understand.

Not that my outlays are always clear ... Or correct ...

[PeterSt]

Last time this quote :

 

44.1/48 input: (2x filter for 44.1/48) -> (2x filter for 88.2/96) -> (2x filter for 176.4/192) -> (S/H) -> (modulator)

88.2/96 input: (2x filter for 88.2/96) -> (2x filter for 176.4/192) -> (S/H) -> (modulator)

176.4/192 input: (2x filter for 176.4/192) -> (S/H) -> (modulator)

 

This way the computational load stays constant as input sampling rate increases but MCLK stays the same.

 

To the letter the last sentence is not correct because "this way" (mind that and what it refers to) is all but taking the same time.

It (how Miska tells it) suggests a hardware model for good reasons (see other posts about skipping a section). But I don't work in hardware today (same for Miska) and there is no reason to cascade filters other than for modularity (structured programming if you want) and for sure less complexity. Perhaps even for better predictable results but NOT for better accuracy (roundings over roundings).

 

I only want to say : No way that I myself work with the filtering like this, and all is one integrated filter as far as logic permits (not all can be integrated). But for sure : any of the proposed steps (see quote) for a same time of filter can be done in non-cascaded steps.

And to make it look more complicated (but I am really going to say the same), when one logical filter consists of a cascade of two, then this cascaded pair still is not going like told in the quote. So the 352.8 filter would be one cascaded pair and NOT the first 2x, then a next 2x and so on.

 

So Jud, maybe I am telling this explicitly for you, because I have seen you write this a 100 times while at least I don't do it like that.

 

Back to the last sentence of the quote : NOW the computational time stays close to constant when the output rate is constant, or at least far more constant.

Much more can be said about this like it depends on the filter whether it can easily be integrated in the first place, and how it thus also is important what filter is used which depends on what we want to achieve and so on.

 

Last note on this because it is related (to computing times needed) : When we compare e.g. 44.1 input to 176.4 input and both need to upsample to 352.8, then the 352.8 is "only" slower because of the overhead of the reading of the file (6x larger when we also incorporate 16 bits for 44.1 and 24 bits for 176.4). If this is compared to the cpu cycles needed (but better : throughput time) for the filtering then without measuring I'd say 1:100. So the "only" between quotes is because the filtering is so fast (and you can see it by the virtual 0% of cpu usage).

 

Peter

[Miska]

I wouldn't know of another way when the output rate (to the modulator in your case) stays the same ? IOW this is not related to the way filters are cascaded.

 

For PCM output, HQPlayer has various different filter possibilities, single and multi-stage. For SDM output it is always either single filter or maximum two, depending on selection. And never S/H, linear interpolation or other crap like that.

Any input -> (Nx filter) -> (modulator) -> any output

or for "-2s"

Any input -> (>= 8x filter) -> (Nx filter) -> (modulator) -> any output

 

So for example:

44.1 input -> (128x filter) -> (modulator) -> 5.6 MHz DSD

96 input -> (58.8x filter) -> (modulator) -> 5.6 MHz DSD

 

Or for the "-2s" ones:

44.1 input: (8x filter) -> (16x filter) -> (modulator)

48 input: (14.7x filter) -> (4x filter) -> (modulator)

[PeterSt]

Where I would enjoy seeing this conversation go is into a discussion of:

a) Overall filter "envelope" parameters (cut-off point, steepness, final attenuation, phase, number of taps) and what balance sounds most musically realistic (transient attack, lack of aliases, group delay, high frequency extension, etc.);

 

Hi Alex,

 

You can't put it like this, or at least I can't because of how the filtering is set up / can be set up.

Of course I could say "transient attack is achieved with no ringing" and this is how I said in my first post that all is too obvious. But, by now and for those who follow CA well, we also know that such thing can not be achieved with your "lack of aliases". Next, I think it goes too far to work out that xyz% of aliasing is allowed when someone like me could say that "all is allowed" which is some base and now referring to your current 1704 NOS set up as I understand, which *also* implies a pile of images and 0.04% distortion on 1KHz alone (read : 1KHz is easy). Read this as : so you like that ? well, in that case this is all right for you. But also : for me this is super bad. And ALSO : for someone like Miska my allowing of aliasing to some degree will make him say that THAT is super bad. While I say that going too far in serving the frequency domain is super bad because of ringing. "But ringing is OK if not preringing" Miska will tell, upon which someone like me could say "but phase linearity is super bad" and then a next comes in with "but that too can be done in linear fashion" and next ...

 

It can't work like that IMHO.

 

All (all !) is one big pile of strategic set up and I tell you that you can't form this by listening. Ah, that is why you posed the question. But there's other means like that iZotope thread you participated in (weren't you quite fresh here back at the time ?). So what you see in there is the strange "act" of everybody crossing the fs/2 limit. Just by nature. But Jud knows that I told (him) so from measuring and that my proposal of it just came down to the very same (and IIRC he was not the first expressing it - all you others did).

Is this an iZotope bug ? maybe, but I don't think so. It could be a flawed or weak means of how the filters are set up, but at least I my self can work the same. How ? Well, because I allow aliasing, remember ? So why not make that explicit.

This is what I mean with strategy and while this is mine, I could be alone. And next is that no other means really allow for what I do unless it is iZotope so some degree.

Summarized : I won't be able to give such parameters, but you almost found some key to them yourself - eh, for one means (iZotope).

 

Once you're into it and have the experience it will be more and more easy to recognize all the elementary parameters. Well, you already know. I keep on saying that you can only really learn well and efficiently when you have an R2R DAC in (hardware) NOS set up. But I think that too was already clear.

DSD is a bit of a different story, but for that too we will soon see that all applies for that just the same, which "project" already started of course (I would personally give Miska the credits). But this just started ...

[Miska]

Also and a bit of a thread-filler : If not read carefully, it is suggested that no matter the input rate, the clock cycles needed are always the same. Of course this is only true for the last step (input of 176.4 of this last step makes 352.8 of it). But now it also makes no sense any more. What I mean is, when 44.1 is input and the computational step that makes 88.2 of it, it is a step which consumes time. If 88.2 is input that step can be skipped and thus it does not take time either. I both cases the next step - make 176.4 out of 88.2 - takes as much time and the last step (176.4 into 352.8) ditto.

 

No way I am saying that Miska told some untruth, but you'd first have to know before you can understand.

Not that my outlays are always clear ... Or correct ...

 

OK, to put it other way. You have fixed MCLK. First stage 169 tap FIR takes let's say 169 MCLK cycles to process. Now if you double the input sampling rate, you have only half the number of clock cycles available per input sample. So in order to process the same 169 tap FIR for the double rate input, you'd need to double MCLK. And for quad rate (176.4/192k) input you'd need to quadruple the MCLK compared to single rate, because with fixed MCLK rate you have only 1/4th of the clock cycles available per input sample. So for these hardware implementations, you need to halve the computational load every time the rate is doubled.

 

Since the filters are fixed hardware blocks, yes you do less computations for higher input rates. Which, by the way is good way to reduce truncation errors inside the hardware DSP pipeline. So yes, in that way the overall number of calculations done for input sample goes down as sampling rate increases, by the necessity. But the number of clock cycles it takes to process a single input sample stays constant.

 

Due to algorithmic construction of FIR filters, this hardware clock limitation is less severe than it is for delta-sigma modulators. If you have MCLK running at 45.16 MHz and modulator output of 5.6 MHz, there are only 8 clock cycles per output sample for the modulator to do it's work. If you compare to Core i7 4790K (runs at 4 GHz) there you have 708 clock cycles per output sample. Almost 100x more!

 

 

Hope this clarifies?

[PeterSt]

Hope this clarifies?

 

Yes ! But as you have read in my post, I assumed you talked from the software (PC) side of matters. And the MCLK then still applies (no matter it's in the DAC).

Without knowing you talked in hardware terms it was a bit confusing.

[Miska]

And ALSO : for someone like Miska my allowing of aliasing to some degree will make him say that THAT is super bad. While I say that going too far in serving the frequency domain is super bad because of ringing. "But ringing is OK if not preringing" Miska will tell, upon which someone like me could say "but phase linearity is super bad" and then a next comes in with "but that too can be done in linear fashion" and next ...

 

Well, I provide both linear- and minimum-phase variants of the filters, otherwise the filters are exactly the same (frequency responses are identical).

 

And I've been saying that both aliases AND ringing are bad, and that's why I've spent enormous amount of time developing a way to design filters that alias as little as possible while at the same time ringing as little as possible. Of course you cannot never perfectly eliminate both simultaneously for a rate conversion filter. And RedBook is always plagued by this due to anti-alias filtering in ADC (or mastering down-conversion). Even PMD2 when used to output 44.1k uses FIR to convert from 176.4k. That's why I also consider apodizing upsampling filters important, because they allow replacing the original ringing...

[Miska]

Yes ! But as you have read in my post, I assumed you talked from the software (PC) side of matters. And the MCLK then still applies (no matter it's in the DAC).

Without knowing you talked in hardware terms it was a bit confusing.

 

No, I was talking solely about hardware implementations. On PC side, I don't care much, if you don't have enough MCLKs (processor clock cycles), you need to go and buy faster CPU.

 

The "-2s" filters are provided as an option for cases where the CPU is not quite fast enough.

[manisandher]

Even PMD2 when used to output 44.1k uses FIR to convert from 176.4k.

 

That's exactly why I record at 4fs with my PM2 - nothing to do with needing to capture higher frequencies (that I can't hear anyway), but everything to do with eliminating the decimation stage in the ADC.

 

Mani.

[PeterSt]

b) A comparison of what filter methods and parameters are being used--both in quality SRC software (SoX, iZotope, XXHighEnd, HQPlayer, AuI ConverteR, etc.) and in DACs that are not using the filter's built into the chips (I'm thinking of the various FPGA-based and discrete FIR filter DACs--Chord, PSA's DS, Miska's DSC1).

 

But how to do this with the hardware ? Looks totally impossible to me. All we could do is try to derive some merits from known properties but you will see soon that all we do is try to improve D/A converters. So for example, the poor figures on the low frequencies of the PSA will tell something. The way Miska's DCS1 is set up tells a lot but also nothing because it's just a show case and you can work a year on it to improve. Discrete FIR ? well, it's a FIR. FPGA ? I don't see that as quality work anyway. But who am I.

 

Software is more easy, but I'm afraid the "quality determination" of it can be determined by a few only and I hardly regard myself experienced. But for example, SoX ... at least it is slow. It is not my cup of tea because it shows too many anomalies without known source (call it bugs). iZotope ? OK for its one means of doing it all (SoX does more). But one means only and I would never get away with it. HQPlayer ? call it the best because someone is working on it for the best. AuI ? I personally don't see it because it is one means. XXHighEnd about the same so now *you* won't see it. But I do.

Btw there are a 100 more for offline work.

 

My main point or issue "for you guys" would be that the one is even worse over the other which is OK as long as you can measure them which you can't. Next it needs your personal strategy again like for example you like NOS in the base and how can that be improved. Or : you have an SDM based DAC (who hasn't) and now we need to "molest" its behavior so it is going to sound well. Two totally different approaches and both legit but depending on who you are.

If I had to do this without measuring I'd go crazy.

 

... which makes your questions so legitimate. But what to do.

What to do ? Use software with preset filters, maybe learn in advance how they operate to at least get some idea and listen. And learn what to listen for (can take a lot of time).

 

2c

[Miska]

That's exactly why I record at 4fs with my PM2 - nothing to do with needing to capture higher frequencies (that I can't hear anyway), but everything to do with eliminating the decimation stage in the ADC.

 

And that makes it also good candidate for upsampling to higher rate PCM or DSD, because you avoid back-and-forth conversions.

 

Another way to avoid recording time conversions is to record something with true DSD ADC (Korg, TASCAM, Grimm) and then either play it as-is, or convert it down to suitable PCM rate or up to higher DSD rate.

[PeterSt]

your current 1704 NOS set up as I understand, which *also* implies a pile of images and 0.04% distortion on 1KHz alone

 

How ? Well, because I allow aliasing, remember ? So why not make that explicit.

 

Of course I said all the wrong way around in that post. Did nobody notice ? haha

grrr

 

So of course I don't allow aliasing which is in-band.

Images are mirrors of the signal (with the mirror at sampling rate / 2) which exist beyond the audio band. I do allow those to some extend.

 

Images don't contribute to poor THD. Aliasing (back into the audio band) does.

 

Sorry for this stupid mistake.

[Miska]

The way Miska's DCS1 is set up tells a lot but also nothing because it's just a show case and you can work a year on it to improve.

 

Yeh, the first version was all done in month on my spare time!

 

<rant>

I've seen complaints about using LM317/LM337 regulators, well look at many <1k€ DACs and they use 78xx/79xx series regulators... Or some USB powered DACs that use cheap single-rail op-amps. At least I have completely separate PSUs for digital and analog sections.

Well, I should have kept using AD797's for the filter stage and some other details, but I will continue working on it when I find the time. I could have made it differential/balanced output, then it would have 64 conversion elements and double amount of analog components. Fine, DSC2 will be like that when I eventually get to do it with my copious free time...

 

I've seen some touting about elliptical analog filters for the conversion... Never looked at the phase behavior of those? Plus the related pass-band ripple... LC networks? Horrible accuracy due to poor L tolerances, try simulating worst case performance of the tolerances using Monte Carlo.

 

In any case it shows that you can do a multi-element bit-perfect DSD DAC without chips and without lot of ultrasonic noise on output. LOT of companies who do expensive (>5k€) DACs for living still use <$10 DAC chips!

 

And just for the record, I see nothing wrong with op-amps as such, as long as they are correctly selected for the place where they are used. Discrete implementation doesn't mean it's any better. I have a discrete op-amp design of my own, but didn't want to put it there because it would have increased the component count significantly. (the whole thing requires eight op-amps)

 

If I still see someone to complain about op-amps or regulators, I want them to stay out of DAC chips and FPGAs too and stay all discrete in their designs!

 

</rant>

 

Discrete FIR ? well, it's a FIR.

 

Analog FIR, or you could also say multi-element 1-bit converter with DEM. You could replace the simple shift register with FPGA and use some fancier DEM. I didn't want to put FPGA there because then everything wouldn't have been visible at one glance (you would have to look at the VHDL too). It is no different than having multiple bits in PCM DAC. In this case each bit just have equal weight, whereas PCM DAC each bit has 2x higher weight than the previous (with related obvious tolerance issues). And that analog FIR is linear phase!

 

You always need some analog filtering for reconstruction, be it PCM or DSD. For PCM you need to remove images of multiples of your sampling rate, for DSD you need to remove the noise shaping noise.

 

Or : you have an SDM based DAC (who hasn't) and now we need to "molest" its behavior so it is going to sound well.

 

There are some chips that can go from DSD to analog without digital processing. Cirrus Logic and Wolfson have the configuration option (CS can go up to DSD128 while Wolfson is limited to DSD64). And TI does it always and just let's you select from four different output stage configurations.

[PeterSt]

A separate topic--which really should be a separate thread--includes a lot of my curiosity about sigma-delta modulators (order, design, optimal rates, number of levels) and THEIR filters. Since we (mostly) live in a post-R2R world, S-D modulation is a inextricable part of the process and we might as well embrace it by doing it well at very high rates. But again, I'm looking to learn more about what "doing it well" really entails. Separate topic, and for some like Miska, I'd be asking questions a little too close to his IP.

 

This doesn't require a separate thread when we look at it like this :

 

So, I know that XXHighEnd's Arc Prediction benefits everyone. Not because I wanted it to, but because everybody started using it while back at the time it was even so that I explicitly told not to use it because it was made for the (back then) due NOS1 (1704 based). But what I never did was measuring the output of it through an SDM based DAC. Not even sure why I never did that.

But I can do it now and I will later today.

 

I think we will be in for an unpleasant surprise. Just a prediction : possibly the transients are sustained to some extend, but if so the least what will happen is that the phase is all out of order (not linear). But if *that* happens and it is the only culprit, it will be fairly easy to correct that (uhm, I think). So now I am curious myself ...

[PeterSt]

Yeh, the first version was all done in month on my spare time!

 

<rant> [...]

 

Hey Miska,

 

Although I tried my best, I still expected you to respond like that, just because I touched the subject. But I really really (really) did not want to make any negative comment of some sort.

You now mentioned a few components, and I just know that each of them can imply a month of reading data sheets, combinations with the other components, start all over with reading datasheets, find the real merits of them (like the Maxim example earlier in the thread) and ... after a year all is still on the drawing board. I know ...

(or must I say three years).

So that is how I meant it and nothing else.

 

I would even have the advice to spend your free time on free time, because if you are as you are you will come up with crazy different solutions under way (and will start over again). You will define new standards all for the better, utilize the (your) software as well as possible also and there's no end to it all.

With DSD (PDM !) you can do all you know ...

 

Regards,

Peter

[PeterSt]

I hope to stay on topic :

 

There are some chips that can go from DSD to analog without digital processing. Cirrus Logic and Wolfson have the configuration option (CS can go up to DSD128 while Wolfson is limited to DSD64). And TI does it always and just let's you select from four different output stage configurations.

 

Yes, but who has implemented that ?

I can tell you, it is already d*mn difficult to even see one would want it hence why. Today maybe, but not 10-15 years ago (I am referring to existing D/A converters now of which we can see that the filter has been shut off in "circumstances").

The 1792 vs 1794 is an even better example for those who tried to look into it. Both can shut off the filter, but only for the 1794 it will work in practice. And then still with a lot of trial and error and persistence because the datasheet tells it can be done. Try with the 1792 first (which will be the obvious one to use) and you'll be dead.

 

So now the other way around : We have a 1794 based DAC and it can do DSD. Will the filter have been shut off ?

I'm afraid only when you or me made it.

When it does PCM chances are higher but still it must be from the last year (before that nobody managed that I know of) and the designer concerned must be into NOS in the first place.

 

All 'n all what I wanted to say : not much hope for existing DACs.

 

 

PS: Small disclaimer : There are so many "datasheet numbers" in my head that it is easy to confuse a few (like I see you mention the 1795 somewhere for probably the same reasons).

[Miska]

Yes, but who has implemented that ?

 

I've been using CS4398 in quite many different ways. Maybe because I still have one tube full of those left. And I've written MCU software to configure it over SPI...

 

(I could have implemented DSC1 using it too, but then people would have to read the MCU assembler code too to see how it was implemented, and someone would have opinion one way or the other what happens inside and how. Plus it wouldn't support DSD256 and DSD512 like it does now.)

 

So now the other way around : We have a 1794 based DAC and it can do DSD. Will the filter have been shut off ?

 

Now there's at least TEAC UD-501 where you can do it. And I believe the iFi iDSD Micro has similar option.

 

UD-501 is PCM1795 so it can take in 32-bit PCM data. I don't now remember what TI chip model was used in iDSD Micro.

 

For DSD, quite a bunch of SACD players use a TI chip, like my Pioneer and Sony.

[Jud]

All three are distinct filters, typically the next one about half shorter than previous. It is constructed as a pipeline, where higher rates get short-cut to a later step. So it works like a factory assembly line.

 

If you dig out datasheet of the old Burr-Brown DF1700 digital filter, there's a description in "Theory of operation" part. First filter is 153 taps, second is 29 taps and third is 17 taps. So not exactly half, but you get the idea.

 

The NPC's SM5847A digital filter uses 169, 29 and 17 taps, explained in similar way on the datasheet.

 

I only want to say : No way that I myself work with the filtering like this, and all is one integrated filter as far as logic permits (not all can be integrated). But for sure : any of the proposed steps (see quote) for a same time of filter can be done in non-cascaded steps.

And to make it look more complicated (but I am really going to say the same), when one logical filter consists of a cascade of two, then this cascaded pair still is not going like told in the quote. So the 352.8 filter would be one cascaded pair and NOT the first 2x, then a next 2x and so on.

 

So Jud, maybe I am telling this explicitly for you, because I have seen you write this a 100 times while at least I don't do it like that.

 

 

Yes, but only when discussing cascaded filters in the DAC chip; I *contrast* this to the way you do it, and the way (sticking with PCM for the moment) Miska usually does.

 

But of course "sticking with PCM for the moment" isn't the way my DAC or most others does things; the product of upsampling/filtering in PCM then gets sent to the SDM. I'll be interested to read what a hash gets made of your AP filtering when it's run through an SDM.

 

... which makes your questions so legitimate. But what to do.

What to do ? Use software with preset filters, maybe learn in advance how they operate to at least get some idea and listen. And learn what to listen for (can take a lot of time).

 

"What to listen for" is a question of some interest, because I don't know of reasonably affordable measuring tools for someone like me, and of course at this point I wouldn't have a decent idea what to measure. I already did relate (in this thread or another?) that when comparing iZotope parameters I'd set up by ear with AP, yours seemed to come from a much quieter background. Later I had the chance to look at the frequency response of my parameters in a demo version of iZotope RX3, and it looked like I was getting aliasing in the extreme upper part of my audible range (my hearing goes to ~16kHz these days). So yeah, I'm guessing I was responding to some nearly subliminal HF aliasing distortion as extra excitement or "realism." I slightly modified the steepness parameter to move the aliasing beyond (my) audibility, and have been happy with the sound, so at least I am not missing the degree of distortion I was hearing before.

 

Regarding "learn in advance how they operate," that's definitely something I hope this thread will help with.

[Superdad]

Wow. I woke up this morning to so many interesting posts in this thread. I don't know where to begin. First, I guess I could say that I am like Jud in a number of ways: Curious, and with a good system and a lot of time fine tuning iZotope in Audirvana. (And my decades in audio hopefully keep me from fooling myself with "euphonic" enhancement.) A big difference between Jud and I is that he has spent time with both XXHightEnd and HQPlayer, whereas I have yet to conquer either (though I continue to make preparations--especially for HQPlayer--since I will soon have a chance to listen to a DSD DAC prototype similar to the architecture of Miska's DSC1, but a bit beyond it in some areas).

 

I am glad that the discussion has moved beyond the boring topic of the cascaded oversampling filters in common DAC chips. It takes only a few minutes to produce a better sounding x8 filter in iZotope or SoX--and it is fun to make cheap DACs sound so much better (you know that DirectPath output stage built into the TI PCM5102/5142 is not terrible, and since it runs off a single-ended supply, it is great for tiny DACs--but you have to ditch its filters!).

 

To clarify a couple of things to Peter: Yes, for a long time in years past I listened to PCM1704K NOS with straight Redbook--aliases and all. But it was mostly because I did not like the sound of other DACs and filters (this is mostly pre-computer audio and SRC s/w age), and the output stage in my DAC is quite special. But once I was able to apply a decent filter in s/w (thank you A+/iZotope and WaveIO USB>I2S), there was no going back. NOS 16/44.1 sounds "dirty" in comparison.

And with the extensive amount of time I have put into tuning iZotope, I do know what each parameter sounds like and how to balance even very small changes.

 

Peter, you started to address--or deflect--my questions about the differences between the various SRC s/w. I know my question was asking too much (I just did not want to leave out any major categories of s/w or h/w methods--well it is all s/w code anyway isn't it, just a matter of total available resources), and yes there are 100+ offline SRCs listed at SRC Comparisons. Looking at the graphs and impulse responses at that site does not tell the story about how they will sound (and of course the site only shows it for some fixed set of filter parameters, whereas I would customize).

 

So let's just focus on the few used around here: yours and Jussi's (in XXHighEnd and HQPlayer respectively), iZotope (in Audirvana), and SoX (as a plug-in for many players). You and Miska clearly have some opinions on those (but your comments so far were vague and confusing).

What I wish to learn more about is:

a) How the 4 SRC programs are alike and different in their methods of getting from 16/44 to 24/352.8;

 

b) What parameters are you focusing on to produce your "best" filters.

 

c) Are there special methods you use to produce a "not-too-leaky" filter with near-perfect impulse response? I have seen some of your graphs on the Phasure forum (and maybe some from Miska) and scratch my head as to how you two get such beautiful impulse responses. What is "Arc Prediction" really--and what role does it play in getting a great sounding filter?

 

d) What do you see as the strengths and shortcomings of both iZotope and SoX? You made some mention that "SoX does more." What did you mean by that?

 

e) Since computers allow for far more computation than the short filters in DAC chips, how many taps are enough? How many are too many? They have an effect on duration of ringing if I recall correctly.

 

f) And back to the often misunderstood (on my part) term of "apodizing"; is it really anything more than just starting the cut-off a bit earlier?

 

 

Sorry to have so many questions. I am just trying to stick with the spirit and topic that Jud started this thread on: "What Makes Good Filtering?"

 

Thanks and regards,

 

ALEX C.

[Jud]

e) Since computers allow for far more computation than the short filters in DAC chips, how many taps are enough? How many are too many? They have an effect on duration of ringing if I recall correctly.

 

ALEX C.

 

Hi Alex. Don't know if you saw these posts, but if you didn't, do they help?

 

http://www.computeraudiophile.com/f8-general-forum/can-you-hear-difference-between-16bit-and-24bit-audio-files-20921/index6.html#post338952

 

http://www.computeraudiophile.com/f8-general-forum/can-you-hear-difference-between-16bit-and-24bit-audio-files-20921/index6.html#post338956

 

http://www.computeraudiophile.com/f8-general-forum/can-you-hear-difference-between-16bit-and-24bit-audio-files-20921/index6.html#post338957

 

http://www.computeraudiophile.com/f8-general-forum/can-you-hear-difference-between-16bit-and-24bit-audio-files-20921/index6.html#post338983

[sandyk]

The maths is way beyond my tired old brain these days, but I find the frequent disagreements between Peter and Miska in several areas to be very confusing. Perhaps we need more input from other suitably qualified members, or links to peer reviewed sources ? I am not saying that these guys don't both deliver fantastic results, but they both appear to go about it in very different ways, as well as being poles apart in the area of hi res, especially DSD vs. RB CD.

[Superdad]

Hi Alex. Don't know if you saw these posts, but if you didn't, do they help?

 

Thanks Jud. I did, and I somewhat internalized that stuff back when. But of course those posts don't answer my questions. I'd elaborate, but a) I don't think my questions need further elaboration; b) I have to go pack myself and our two sons for a cross country plane trip to visit my dad in North Carolina. We have to leave the house at about 4:00 a.m.!

So I might not be on the forum much again until early next week.

Ciao all!

--Alex

[Jud]

The maths is way beyond my tired old brain these days, but I find the frequent disagreements between Peter and Miska in several areas to be very confusing. Perhaps we need more input from other suitably qualified members, or links to peer reviewed sources ? I am not saying that these guys don't both deliver fantastic results, but they both appear to go about it in very different ways, as well as being poles apart in the area of hi res, especially DSD vs. RB CD.

 

Some of the confusion about "different ways" came from Peter thinking Miska was describing his own methods when Miska was actually describing what happens in typical DACs. But yes, there are differences on the matter of filters.

 

- Miska offers sigma delta modulators, Peter doesn't like them around (essentially DSD pro and con).

 

- Peter makes his compromise between time and frequency domain performance further to the time domain side than Miska, and Miska makes his further to the time domain side than some others.

 

- Miska offers a selection of filters, Peter offers pretty much one.

[Jud]

I'm wondering if I'm thinking about this correctly. If the highest PCM rate we can expect to filter is 384kHz (except with PeterSt's DAC) then a filter length of 384k will be a second. I'm supposing the signal output will be cut substantially quicker than that, won't it? Or have I got this all wrong?

[Miska]

I'm wondering if I'm thinking about this correctly. If the highest PCM rate we can expect to filter is 384kHz (except with PeterSt's DAC) then a filter length of 384k will be a second. I'm supposing the signal output will be cut substantially quicker than that, won't it? Or have I got this all wrong?

 

Can you elaborate a bit more?

 

If we look at the NPC's filter lengths:

169 / 88200 = 1.9 ms

27 / 176400 = 153 µs

17 / 352800 = 48 µs

 

The first filter almost always dominates the output.