hi,
I have a signal sampled at 16 kHz and i have a corresponding
timing file which contains
the time values of certain discrete events occurring in this
signal.
Now I want to down sample this signal to 8 kHz and then mark
those events occuring
in the signal using the timing file.
This looks straight forward but there is problem with it coz
when i am downsampling the
16 kHz signal to 8 kHz i need to pass the 16 kHz signal through
a low pass filter which
introduces a phase shift into the signal. coz of this phase
shift I am not able to mark the
events correctly in the downsampled 8 KHz signal.
I tried reversing the signal and passing it through the lowpass
filter again before down
sampling. But is this the correct way of doing it.
What is the best way to deal with this problem?
how to avoid phase shift introduced due to low pass filtering.
Started by ●April 30, 2008
Reply by ●April 30, 20082008-04-30
rajesh wrote:> hi, > > I have a signal sampled at 16 kHz and i have a corresponding > timing file which contains > the time values of certain discrete events occurring in this > signal. > > Now I want to down sample this signal to 8 kHz and then mark > those events occuring > in the signal using the timing file. > > This looks straight forward but there is problem with it coz > when i am downsampling the > 16 kHz signal to 8 kHz i need to pass the 16 kHz signal through > a low pass filter which > introduces a phase shift into the signal. coz of this phase > shift I am not able to mark the > events correctly in the downsampled 8 KHz signal. > > I tried reversing the signal and passing it through the lowpass > filter again before down > sampling. But is this the correct way of doing it. > What is the best way to deal with this problem?You _can_ remove the phase shift by running the file backwards, as you suggest. Be aware that the amplitude response of the filter is squared. That increases attenuation in the stopband, but also ripple in the passband. A symmetric FIR produces no phase shift; why not use one? Note also that any filter corrupts both ends of the file. The transients are as long as the filter's impulse response, so with any one filter, the more passes, the more of the file is currupted. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●April 30, 20082008-04-30
On Wed, 30 Apr 2008 10:18:07 -0400, Jerry Avins wrote:> rajesh wrote: >> hi, >> >> I have a signal sampled at 16 kHz and i have a corresponding >> timing file which contains >> the time values of certain discrete events occurring in this >> signal. >> >> Now I want to down sample this signal to 8 kHz and then mark >> those events occuring >> in the signal using the timing file. >> >> This looks straight forward but there is problem with it coz >> when i am downsampling the >> 16 kHz signal to 8 kHz i need to pass the 16 kHz signal through >> a low pass filter which >> introduces a phase shift into the signal. coz of this phase >> shift I am not able to mark the >> events correctly in the downsampled 8 KHz signal. >> >> I tried reversing the signal and passing it through the lowpass >> filter again before down >> sampling. But is this the correct way of doing it. What is the >> best way to deal with this problem? > > You _can_ remove the phase shift by running the file backwards, as you > suggest. Be aware that the amplitude response of the filter is squared. > That increases attenuation in the stopband, but also ripple in the > passband. A symmetric FIR produces no phase shift; why not use one? > > Note also that any filter corrupts both ends of the file. The transients > are as long as the filter's impulse response, so with any one filter, > the more passes, the more of the file is currupted. > > JerryMore correctly (and yes, I'm picking nits), a symmetric FIR has an _easily predictable_ phase shift -- it's just a pure delay that doesn't change with frequency. If you're doing this all as a post-processing operation then this delay is no problem at all; if you're trying to do this in real time, with your events getting detected and labeled within some finite amount of time, then it may be a big deal. -- Tim Wescott Control systems and communications consulting http://www.wescottdesign.com Need to learn how to apply control theory in your embedded system? "Applied Control Theory for Embedded Systems" by Tim Wescott Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html
Reply by ●April 30, 20082008-04-30
Tim Wescott wrote:> On Wed, 30 Apr 2008 10:18:07 -0400, Jerry Avins wrote: > >> rajesh wrote: >>> hi, >>> >>> I have a signal sampled at 16 kHz and i have a corresponding >>> timing file which contains >>> the time values of certain discrete events occurring in this >>> signal. >>> >>> Now I want to down sample this signal to 8 kHz and then mark >>> those events occuring >>> in the signal using the timing file. >>> >>> This looks straight forward but there is problem with it coz >>> when i am downsampling the >>> 16 kHz signal to 8 kHz i need to pass the 16 kHz signal through >>> a low pass filter which >>> introduces a phase shift into the signal. coz of this phase >>> shift I am not able to mark the >>> events correctly in the downsampled 8 KHz signal. >>> >>> I tried reversing the signal and passing it through the lowpass >>> filter again before down >>> sampling. But is this the correct way of doing it. What is the >>> best way to deal with this problem? >> You _can_ remove the phase shift by running the file backwards, as you >> suggest. Be aware that the amplitude response of the filter is squared. >> That increases attenuation in the stopband, but also ripple in the >> passband. A symmetric FIR produces no phase shift; why not use one? >> >> Note also that any filter corrupts both ends of the file. The transients >> are as long as the filter's impulse response, so with any one filter, >> the more passes, the more of the file is currupted. >> >> Jerry > > More correctly (and yes, I'm picking nits), a symmetric FIR has an > _easily predictable_ phase shift -- it's just a pure delay that doesn't > change with frequency. If you're doing this all as a post-processing > operation then this delay is no problem at all; if you're trying to do > this in real time, with your events getting detected and labeled within > some finite amount of time, then it may be a big deal.For real-time signals, easily predictable is appropriate. For files, it has the same delay as a recording. Since playback can begin at an arbitrary time, such delay is rarely considered. Now who's picking nits? Jerry -- Engineering is the art of making what you want from things you can get. ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Reply by ●April 30, 20082008-04-30
On Apr 30, 8:31�am, Tim Wescott <t...@seemywebsite.com> wrote:> On Wed, 30 Apr 2008 10:18:07 -0400, Jerry Avins wrote: > > rajesh wrote: > >> � � hi, > > >> � � � � I have a signal sampled at 16 kHz and i have a corresponding > >> timing file which contains > >> � � � �the time values of certain discrete events occurring in this > >> signal. > > >> � � � �Now I want to down sample this signal to 8 kHz and then mark > >> those events occuring > >> � � � �in the signal using the timing file. > > >> � � � This looks straight forward but there is problem with it coz > >> when i am downsampling �the > >> � � � 16 kHz signal to 8 kHz i need to pass the 16 kHz signal through > >> a low pass filter which > >> � � � introduces a phase shift into the signal. coz of this phase > >> shift I am not able to mark the > >> � � � events correctly in the downsampled 8 KHz signal. > > >> � � � I tried reversing the signal and passing it through the lowpass > >> filter again before down > >> � � � sampling. But is this the correct way of doing it. What is the > >> � � � best way to deal with this problem? > > > You _can_ remove the phase shift by running the file backwards, as you > > suggest. Be aware that the amplitude response of the filter is squared. > > That increases attenuation in the stopband, but also ripple in the > > passband. A symmetric FIR produces no phase shift; why not use one? > > > Note also that any filter corrupts both ends of the file. The transients > > are as long as the filter's impulse response, so with any one filter, > > the more passes, the more of the file is currupted. > > > Jerry > > More correctly (and yes, I'm picking nits), a symmetric FIR has an > _easily predictable_ phase shift -- it's just a pure delay that doesn't > change with frequency. �If you're doing this all as a post-processing > operation then this delay is no problem at all; if you're trying to do > this in real time, with your events getting detected and labeled within > some finite amount of time, then it may be a big deal. > > -- > Tim Wescott > Control systems and communications consultinghttp://www.wescottdesign.com > > Need to learn how to apply control theory in your embedded system? > "Applied Control Theory for Embedded Systems" by Tim Wescott > Elsevier/Newnes,http://www.wescottdesign.com/actfes/actfes.html- Hide quoted text - > > - Show quoted text -We have not figured out the best strategy to deal with the phase shift (time delay) in real time. A more complicated situation involves multiple stages of decimation. Each stage will introduce certain fixed delay. The more decimation stages applied, the more delay will get introduced. (Inability of) dealing with the delay becomes the most frustrating issue in the real-time processing. James www.go-ci.com
Reply by ●April 30, 20082008-04-30
Jerry Avins <jya@ieee.org> writes:> For real-time signals, easily predictable is appropriate. For files, > it has the same delay as a recording. Since playback can begin at an > arbitrary time, such delay is rarely considered. Now who's picking > nits?I'd rather nick pits. Ciao, Peter K. -- "And he sees the vision splendid of the sunlit plains extended And at night the wondrous glory of the everlasting stars."
Reply by ●May 1, 20082008-05-01
On 30 Apr, 21:11, Jerry Avins <j...@ieee.org> wrote:> Now who's picking nits?I'd say none of you. Both of you are right. Forward-bakward filtering works in offline applications. Linear-phase FIRs work in online applications. Either way one needs to take care of end transients and do some book-keeping to account for time delays introduced by the algorithm (and to the nit-pickers out there: I said "account for" time delays, not "cancel"...) Rune
Reply by ●May 1, 20082008-05-01
Rune Allnor wrote:> On 30 Apr, 21:11, Jerry Avins <j...@ieee.org> wrote: >> Now who's picking nits? > > I'd say none of you. Both of you are right. Forward-bakward > filtering works in offline applications. Linear-phase FIRs > work in online applications. > > Either way one needs to take care of end transients and > do some book-keeping to account for time delays introduced > by the algorithm (and to the nit-pickers out there: I said > "account for" time delays, not "cancel"...)So tell me: what is the time delay of a .wav file and how can one account for it? Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●May 1, 20082008-05-01
On 1 Mai, 15:48, Jerry Avins <j...@ieee.org> wrote:> Rune Allnor wrote: > > On 30 Apr, 21:11, Jerry Avins <j...@ieee.org> wrote: > >> �Now who's picking nits? > > > I'd say none of you. Both of you are right. Forward-bakward > > filtering works in offline applications. Linear-phase FIRs > > work in online applications. > > > Either way one needs to take care of end transients and > > do some book-keeping to account for time delays introduced > > by the algorithm (and to the nit-pickers out there: I said > > "account for" time delays, not "cancel"...) > > So tell me: what is the time delay of a .wav file and how can one > account for it?I'll answer that once you explain how '.wav file' qualifies as 'algorithm.' Rune
Reply by ●May 1, 20082008-05-01
On May 1, 6:48 am, Jerry Avins <j...@ieee.org> wrote:> > ...> So tell me: what is the time delay of a .wav file and how can one > account for it? > > Jerry > --In the original .wav format time delay was 'accounted for' by including private data chunks with time labels to whatever accuracy was desired/required. These labels could be updated/altered to correspond to processing applied. Sometimes the labels were derived from time codes recorded on the analog tapes being digitized. The Broadcast Wave Format has a published spec that includes extensions specifying time to the sample. Dale B. Dalrymple
