• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Test report MBP built-in audio device
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Test report MBP built-in audio device


  • Subject: Re: Test report MBP built-in audio device
  • From: "Mikael Hakman" <email@hidden>
  • Date: Thu, 28 Aug 2008 18:38:31 +0200
  • Organization: Datakonsulten AB

On Thursday, August 28, 2008 5:07 PM, Stephan M. Bernsee wrote:

There is one case where this scenario doesn't apply and where windowing is actually harmful and this is when the period of your measuring signal is exactly an integer multiple of the DFT transform size. In this special case I would have to agree with Mikael that windowing will pollute the measurement and you will lose resolution.

There are many cases where you don't want windowing. In general it depends on the purpose of you taking the DFT. Then as you say there are additional cases when the period of the signal is an exact integer _divisor_ of the DFT transform size.


So it all depends on how the DFT is being used if windowing is actually desired, or not. In my opinion it is necessary to include information on how these measurements were obtained. IOW: if you're not using a window you should mention this so people could interpret your graph in the right context.

I have given the information that I'm using 4800 points DFT and an SR of 48000 samples/sec. Then how difficult can it be to infer that at 1000 Hz (one of the charts in my report) there are exactly 100 periods in signal segment submitted to DFT? And that at 10000 Hz (the other test frequency) there are 10 periods? At least for someone pretending to know the subject and having opinions what should or shouldn't be done? Do I have to write every trivial and obvious detail on such person's nose?


Also, to go back to the original application, taking these measurements to judge the quality of an audio algorithm may be misleading depending on the nature of the algorithm. A time stretching algorithm may have a perfect frequency response but may still sound horrible to human ears due to transient smearing and other factors that will not show up in a DFT graph.

It may be misleading but I don't think it is, and you have no information pointing in another direction. A time stretching algorithm produces horrible distortion, which is detected both by traditional steady-state and my new method THD+N computations. This distortion will show up in a DFT graph if you do measurement and analysis in a correct way.


Regards/Mikael

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >Re: Test report MBP built-in audio device (From: "Stephan M. Bernsee" <email@hidden>)

  • Prev by Date: Re: Test report MBP built-in audio device
  • Next by Date: Re: Test report MBP built-in audio device
  • Previous by thread: Re: Test report MBP built-in audio device
  • Next by thread: how to fill audio queues with data from a TCP stream, not a file
  • Index(es):
    • Date
    • Thread