[Bravotv]

Hello Head-Fi,

I'm a 3rd year engineering student, one of my classes is a lab course, where we have to design an experiment, and write a report. I'm trying to see if there is anything that i can do related to audio/headphones. I'm posting this here, trying to see if anyone would have any suggestions. I'm mainly trying to see what sorts of things I can measure in respect to frequency response. Some ideas i have are:

• Burn in effect on frequency response (somewhat already done)
• Changes to frequency response based on temperature, moisture, etc.
• Frequency response changes based on different AMP/DAC's powering the same headphones.
• Try to quantify changes in audio quality from measurements.

Any ideas or anything you think is worth studying? This is fairly open ended, but i would like to have something concrete since I'll have to pitch an idea to my team next week.
P.S.:How are frequency response graphs made? What equipment and procedures does one need?

 

[castleofargh]

Data on burn in, if by it you mean the driver itself changing over time and nothing else, that's something we certainly would love to see done properly.
The obvious problem is that measurement on one product will at no point define the behavior of the vast range of products on the market. So you'd have to approach this a one off anecdote, or manage to experiment on a number of headphones.
Having done pretty much the same experiment on all my new IEMs, I'd bet that the changes measured in your link are from a very atypical IEM, or that the experiment itself was badly done. I've never seen anything coming remotely close to that much change. Usually to get something like this you have to break it, or maybe change the size of the vent(block it?).

Changes from temperature and humidity are fairly well known by actual engineers working with measurement rigs. and pretty much totally ignored by amateurs like myself who don't have the rigor and accuracy justifying to control those variables.

FR changes from amps are also well known and easily predictable. If you just take the impedance over frequency of the headphone and amplifier's output, you will be able to calculate the FR variation almost perfectly from voltage at each frequency. DAC variations should remain consistent with measuring the DAC's FR unloaded. and for the vast majority of DACs, we would expect dead flat within +/-0.5dB in the audible range. FR for DACs is a non story.

Quantify audio quality is a complicated and ultimately subjective game. In respect to frequency response and subjective preferences on headphones, there is a goldmine of information to be found in various papers published by Harman in the last decade. If you can't have access to the papers, you can find some summary here http://seanolive.blogspot.com/

P.S.:How are frequency response graphs made? What equipment and procedures does one need?

The most basic would be to send noise into the headphone and look at the spectrum at the output with a microphone. You can find cellphone or computer apps to do that, or any RTA app.
For more stable results, we usually have a loop where the app that measures the FR is also the one sending the test signal. Then the most commonly used signal is a sine sweep because it does the job well and fast.
And to really go all nerd, you'd do a step sine measurement with a single tone at a time being played and measured before moving on to the next frequency.
Room Eq Wizard is a free software that allows to do it all on a computer for free. In fact it does so many things that you might wish for a simpler tool at some point ^_^.

For headphone measurements if you only care about variations(and leave the nightmare that is calibration, alone), then pretty much any cheap microphone stuck into a cardboard box will do. Even the worst mics tend to measures FR pretty consistently. I guess if the mic is new, then you'll have to burn it in before using it for measurements .

 

[Bravotv]

Is there any experiments you would like to see? Doesn't have to be frequency response only. Thanks for the detailed response.

 

[SoundAndMotion]

I'm a 3rd year engineering student, one of my classes is a lab course, where we have to design an experiment, and write a report.

This tells us a little, but actually raises more questions than it answers.
Have you had courses on system theory? Do you know what Laplace, Fourier and Bode analyses are? Stability, transfer functions, system identification (black box analysis)?
Is this your first lab course? Does it have a central theme (EE, programming, systems)?
If you are asked to design an experiment, I assume you've already done other experiments that were explicitly spelled out. Is that true?
This tells a lot:

P.S.:How are frequency response graphs made? What equipment and procedures does one need?

Are these things the professor would expect you already know, but you want some refresher tips here? I (and others) can help. Or is this really new info for you? Is this relevant to the specific course you are taking?

Most people here will want you to do something that is not already known. They'll want answers to as-yet unanswered questions. But what does your prof want? If you attempt a really interesting, novel experiment*, but do it poorly and don't really understand the engineering principles behind it, you'll get a bad grade. If you repeat an experiment that has been done dozens or thousands (hundreds of thousands?) of times before, and you do it well, and use and learn important engineering concepts, you'll get a good grade and learn useful stuff.

Some clichés come to mind: "don't bite off more than you can chew" and "learn to walk before you try to run".

Do some engineering! And understand what you are doing. And realize this: I could spend a half-hour explaining to an art history or economics student how to use ready-made apps to test a dozen headphones under a dozen conditions, and produce a hundred pages of really pretty graphs... but you'll have to do better.

Let us know if you need more help.

*Of course, if you do a really interesting, novel experiment really well and understand all the underlying principles, you'll probably win an award or a scholarship.

 

[Bravotv]

This tells us a little, but actually raises more questions than it answers.

I'm in Mechanical Engineering. To specifically answer your questions. I do have knowledge of Laplace, and Fourrier, the other subjects mentioned are not traditionally in the realm of mechanical engineering. I do realize that an experiment like this would fall more into the electrical engineering field, however we are not given a specific theme. The course is more about learning how to design and carry out experiments as opposed to a specific theme. For the experiment we are expected to generate our own methods, testing equipment, and analysis. For timeline, we have two months and a team of 5 people, so a fair bit of time. We are encouraged to pursue an experiment in fields that interest us.

Some experiments/labs that were spelled out in the past (for example): experimentally determine a coefficient of thermal expansion for a soda can based on changes in internal pressure and temperature. Analysis of a natural gas engine with different loads, compression ratios ans spark timing. Sharpness of a saw based on the frequencies recorded.
An example past experiment done by students is: measuring the change in guitar tune, based on the humidity of the room. Or the effectiveness of a friction knot on a fishing line.

I've been an audiophile for years, but the nitty gritty technical details are all new to me and I'll have some catch-up to do.

 

[SoundAndMotion]

Okay, we need not discuss whether systems theory applies to all systems (including mechanical systems, as I've seen), but out of curiosity, in what context did you learn the Laplace transform? It is typically... often... (sometimes?) used to go back and forth between time-domain system differential equations and transfer functions (frequency-domain). Transfer function methods are easier to conceptualize (at least the way I teach them), and easier mathematically (algebra vs. calculus). The normal assumption for using frequency-domain methods is that the system is LTIC (linear, time-invariant, causal).

The course is more about learning how to design and carry out experiments as opposed to a specific theme. For the experiment we are expected to generate our own methods, testing equipment, and analysis. For timeline, we have two months and a team of 5 people, so a fair bit of time. We are encouraged to pursue an experiment in fields that interest us.

Excellent! Very cool. So, you don't need to become expert in systems theory, but you should have a look at system identification methods. For all the ideas that interest you, you'll treat the HP/IEMs as a black box (well, gray, since you know more than zero about them), and you'll seek to identify the system characteristics. The most basic basics: you provide a/(some) well-chosen stimulus/input signal(s) and record the response/output signal(s). Even though I teach "nothing is linear*", you'll start by assuming the system (e.g. IEM) is LTIC. If you have enough time (2 months is short in my mind), you'll want to test this assumption. If the assumption is good, you won't need to create transfer functions or diff. eqs., you'll present Bode plots, which always include gain and phase.

You can then vary some parameter: time (burn-in), temp, humidity, etc. I hope a red flag popped up: all these violate LTIC! Why would you use LTIC methods to show non-LTIC-ity? You'll need to explain in your report (easy - we can discuss), or use time-domain methods: some form of ARMA (ARIMA, ARMAX, etc.) or Monte Carlo (e.g. MCMC), or others. Unless one of your team has experience with these, I'd recommend against that.

A few tips (more, if this interaction continues): 1- @castleofargh gives some very useful ideas to consider, but I would strongly recommend against using any closed-source software. That is its own black-box. And in your case, the software requirements are pretty straightforward, and if anyone on your team is a competent programmer, easy enough to do yourselves. A reasonable second choice is open-source that someone on your team has gone over and explained. But the reference material from REW, that @castleofargh mentioned (here) is good.
2- Put a considerable effort into proving whatever hypotheses you have false. If your hypothesis is true, it will easily withstand the effort. But if you avoid this, your conclusions will be easy to pick apart.
3- IMO, avoid, for now, the perception (audio quality) issue. Two months really is too short to properly deal with this for an engineering course. In the future, if your interest continues, we can discuss further, since that is my field.

* nothing is always and completely LTIC