Hey guys, I got another filter for you.

This is a linear-phase DC offset filter that can be used as an alternative to [hip~] when needed. It has a much faster response than [hip~], but at the expense of some delay. The amount of delay in samples can be provided as an argument. Smaller delays result in a faster response, but frequencies in the audible range may become attenuated. Larger delays improve the frequency response but slow the transient response.

So, the main advantages of this are the response time and linear-phase response. If you're dealing with a signal that has some wild DC fluctuations, [hip~] might not be fast enough. Increasing the cutoff for [hip~] will improve its response time, but can also introduce phase issues, so if phase is also important than [dcblock.mmb~] might be a better choice.

http://www.pdpatchrepo.info/hurleur/dcblock.mmb~.pd

Hey guys, I got another filter for you.

This is a linear-phase DC offset filter that can be used as an alternative to [hip~] when needed. It has a much faster response than [hip~], but at the expense of some delay. The amount of delay in samples can be provided as an argument. Smaller delays result in a faster response, but frequencies in the audible range may become attenuated. Larger delays improve the frequency response but slow the transient response.

So, the main advantages of this are the response time and linear-phase response. If you're dealing with a signal that has some wild DC fluctuations, [hip~] might not be fast enough. Increasing the cutoff for [hip~] will improve its response time, but can also introduce phase issues, so if phase is also important than [dcblock.mmb~] might be a better choice.

http://www.pdpatchrepo.info/hurleur/dcblock.mmb~.pd

@bassik said:

In this case I don't really get the point why you are researching the exact sample value of the peak value. In my experience, analysis of simple IR don't give substantial different results if the time zero of the IR is not exactly on the peak

Some more experimenting has learned me that it depends on the system under test. For an IR of the MacBook internal soundcard loopback, the problem is manifest. For an IR of my room, that is not the case. The difference is probably this: the soundcard's spectrum is near to perfect and there is only a direct response. The room test response missed a lot of the low spectrum end (also due to lousy 'test equipment'), and the direct response is buried in reflections because of the small room size. It's funny that the room response is much easier to trim than the loopback response.

Searching the internet I found the name for the phenomenon: fractional delay. And of course implementations for fractional delay, which can also be used to get rid of fractional delay. As far as I can see now, we'll only need it for cases where the direct response has a prominent role. For example, when we want to produce inverse filters for correction of spectral deficiencies in test equipment. We're not at that point yet.

Anyway, I did a patch with a model of fractional delay, which clearly illustrates the problem. (See attachment). And if you do a loopback test with [IRrecorder], you'll see what I mean as well.

edit: bah, again impossible to attach file. (Did I exceed my upload quotum?). It's here:

http://www.katjaas.nl/temp/fractional-delay.pd.zip

Katja

Status: Waiting to retry...
Status: Resolving IP-Address for www.fuzzy-math.com
Status: Connecting to "your IP add"
Status: Connection established, waiting for welcome message...
Response: 220---------- Welcome to Pure-FTPd [TLS] ----------
Response: 220-You are user number 1 of 50 allowed.
Response: 220-Local time is now 19:58. Server port: 21.
Response: 220-This is a private system - No anonymous login
Response: 220-IPv6 connections are also welcome on this server.
Response: 220 You will be disconnected after 15 minutes of inactivity.
Command: USER anonymous
Error: Could not connect to server

both Filezilla and FireFTP did not work