Monday, June 8, 2020

Switched to Markdown

After writing about 50 posts I decided to do something about how I typeset them. Previously I was using Blogger post editor in "Compose" (WYSIWYG) mode. It allows to get job done, however there was no complete control over the details of formatting. For example, I like to use non-breaking spaces between values and their units, as in "1 kHz", so they don't end up on different lines. However, Blogger editor doesn't show "special" characters. They can only be viewed in HTML mode, however the text looks overwhelming with all the extra tags and attributes that Blogger's WYSIWYG editor throws in.

Another huge missing feature of the Blogger editor is "find and replace". There is "find" function built into the browser but no "replace". Again, you can work around by copying the HTML source into a capable editor, doing all the work there, then pasting back. Hopefully you haven't screwed up the HTML tags.

I realized that I would like to use my favorite editor for writing posts and then convert them into HTML (just once!), paste the result into Blogger and be happy. These days Markdown is the standard way for typesetting moderately complex pages, and its minimalist nature makes the page source look very readable even without syntax highlighting.

So Markdown it be. Where is it convenient to store Markdown sources? GitHub pages is a good place since GitHub offers a built-in renderer for them. The renderer also adds some nice "extensions" to basic Markdown. Decided—I will use GitHub pages for storing the Markdown originals and continue posting them on Blogger, because people actually do read the posts there.

Converting old pages

As an experiment in feasibility of this approach I decided to convert my existing blog pages to Markdown and "distill" them back into HTML. This would help to establish the process and iron out all the possible issues. This also ensures that the blog "mirror" on GitHub doesn't have dangling links to old posts.

I downloaded the archive of this blog via Blogger's "Back up content" function. It provides a huge XML file containing all the posts in HTML format, so it's easy to cut out their content for further processing.

For conversion I used Pandoc tool which among numerous formats supports both HTML and GitHub "flavor" of Markdown. So, for the old pages the process was as follows:

  1. Save the post as HTML file, convert it into GitHub markdown using Pandoc:

    pandoc input.html -f html-native_divs-native_spans \
    --shift-heading-level-by=-1 --atx-headers -t markdown_github \
    -o output.md

    By trial and error I figured out that I like the results of the deprecated markdown_github converter better than its gfm replacement. For some pages I used --shift-heading-level-by because I was using <h3> HTML headers and needed to have them "level up"-ed.

  2. Clean up the converted Markdown: remove trailing whitespace, extra line breaks, make sure all non-breaking spaces are in place, etc.

  3. Preview the Markdown file using excellent grip tool. This saves from unnecessary uploads to GitHub.

  4. Convert the Markdown back to HTML for Blogger:

    pandoc output.md -f markdown_github -t html -o distilled.html
  5. Paste the "distilled" HTML back to Blogger.

  6. Upload the Markdown to GitHub.

  7. Compare the looks and make necessary adjustments to Blogger styling.

The last step also helped me to resolve long standing annoyances with the default CSS styles used by "Awesome Inc" Blogger theme. I put my CSS overrides into "Advanced > Add CSS" section in the theme editor.

BTW, I'm not exaggerating about the converted back HTML being "distilled". Blogger puts so much superfluous formatting that the size of a file containing a post from Blogger typically reduces by 25–50% after converting back and forth via Markdown!

Of course, the conversion isn't without flaws, and Markdown does in fact offer less formatting capabilities than Blogger. Let's consider the differences in detail.

Post links

I decided to use the same file structure for Markdown posts, this makes converting links easier. The conversion is needed because GitHub uses names of the Markdown files—md extension, while Blogger uses html. I made all the post links to be "site relative" (starting from /) so it doesn't matter where the page is actually hosted.

This way, a link to a previous post in Markdown looks like this:

[as shown in the previous post](/2019/06/previous-post.md)

and when "distilling" Markdown source to HTML I replace md with html.

Update Mar 28, 2021 I've noticed that Github now only replaces .md to .html extension in the links of the top-level README.md. So I have changed all other cross-references in posts to use .html:

[as recently shown in the previous post](/2019/06/previous-post.html)

This is even better as now there is no need to do the aforementioned replacement.

Pictures

There are a lot of pictures in this blog, I decided to leave them hosted on Blogger. The reason is that Blogger server can resize the picture to a smaller size from the parameters specified in the image URL. These smaller images are used for previews in the article. After clicking on the preview a full size picture is served. This is more efficient than serving a full picture only and sizing it down in the browser.

This approach also works when links to images host on Blogger are used in Markdown arcticle on GitHub. As I've figured out, GitHub in addition makes a copy of any externally hosted image for serving from its own CDN, so it really doesn't make sense to pull out images to GitHub manually.

One notable loss is that Markdown doesn't allow specifying alignment and interaction with text for pictures, so they are always aligned to the left and can't have text fills on the size.

Code

Up to the redesign Blogger wasn't offering dedicated code formatting. I used monospace font with non-breaking spaces for sequences of multiple spaces. While converting, I changed all those code fragments to use Markdown fenced code blocks.

Tables

Similar thing for tables. I used tabulated monospaced formatting. This wasn't super convenient. I converted these ersatz tables into Markdown tables which translate into actual HTML tables for Blogger. This looks better. The only inconvenience is that GitHub Markdown doesn't allow "headerless" tables.

Colors

Markdown doesn't have means for colorizing text. It's actually good for accessibility (think screen readers, color blind people), but I used to highlight text with colors when discussing graph. Now I will have to provide more annotations on the graph itself.

Miscellaneous

  1. In Markdown the header of the post is specified on the first line using # style (heading level 1). In Blogger the header stored separately.
  2. Special characters like "non-breaking space", "em dash" need to be written using corresponding Unicode characters in Markdown. Note that the sequence of three dashes --- is used in Markdown for horizontal breaks.

Writing a new post

I'm writing this post in Markdown and the life feels good. The only culprit is adding pictures. I still want them to be stored on Blogger. For example, I want to post an image of the same post in Blogger and on GitHub. Here is what I have to do. After preparing the image, I upload it to Blogger and insert into the post draft. Then I copy the link and transform it into Markdown link format. This is the result:

The GitHub mirror of this blog is now located here: https://mnaganov.github.io

Testimonials

Both Pandoc and grip are awesome tools that helped me a lot with converting my posts into Markdown and back into HTML. I highly recommend them for any document conversion work and Markdown authoring.

Saturday, May 2, 2020

Sennheiser Ambeo Headset Applications

As I have mentioned in the previous posts about optimizing audio in our Mercedes GLK, I used Sennheiser Ambeo Headset as a measurement device in the car. In this challenging acoustical environment it allowed to achieve better channel matching than a conventional measurement microphone. I decided to make a dedicated post about this headset because I've found some interesting applications for it.

Overview

I discovered this headset at the AES Headphones conference where it was used in conjunction with Magic Leap's One AR glasses. By the time when I decided to buy it for my experiments, Sennheiser had already abandoned its production. Nevertheless, it's still possible to buy leftovers from the stock and used gear.

This is how this device looks:

By comparing it with the image on the packing box it's easy to spot a marketing trick. On the box the controlling unit is pictured from the side, making an impression that it's thin and long. However, in reality this unit is pretty thick and looks a bit ugly:

The headphones themselves are designed to be worn around ears, sports-style. They don't however feel sturdy enough like a real sport-style headphone should—yet another perceptual mismatch. Overall, the look of these headphones isn't too exciting, certainly not as appealing as "iconic" Apple earbuds.

Speaking of the technical side, the only connection option offered is Apple Lightning connector. There is also a companion iOS app, however so far I was only using this headset with Android devices and laptops. This becomes possible using Anker's Lightning-to-USB-C adapter which is a must have device if you happen to own any good Lightning headsets and plan to connect them to other devices besides your iPhone. Anker's connector tech specs explicitly lists the Ambeo headset as a compatible device. As a side note, the adaptor also works great with Lightning cables by Audeze.

The controlling unit has a lot of buttons. Besides three usual media controls, there is also a rocking switch toggling between active noise cancelling, "normal" mode, and "transparent hearing"—when the device uses its built-in microphones to allow any external sounds in. This mode is useful because the headphones are designed for in-ear insertion and actually provide a good noise isolation even without active noise cancelling.

Another switch on the controlling unit activates "padding" for the stereo microphones. The designers intended it for use at concerts to avoid clipping during recording.

Speaking of the microphones, since this device was conceived for "3D" recording, besides the usual headset style mono microphone on the right earphone wire, it also has a microphone housed inside left and right earphone:

Before I bought this device I was thinking that the microphones are behind the grilles on the sides of the earphones, but actually the microphone is placed on the inner side of the earphone and faces the reflecting cavity of the pinna:

Overall, from a regular consumer's point of view, the appealing features of this headset are its noise cancelling function and the ability to create entertaining 3D "dummy head"-style recordings. However, the build of the earphones and bulkiness of the controlling unit (and probably relatively high price) most likely worked against its wide adoption.

Earphones

I didn't plan to actively use this headphone for listening to music, but it's still interesting to check what it is capable of. For comparison I'm using very well known and widespread Shure SE215 in-ear phones.

What you will immediately notice with the Ambeo headset is that it's very bright, up to the point when listening to vocal recordings with a bit of extra sibilance becomes unpleasant. My usual tracks for checking this are "Little Wing" performed by Valerie Joyce on "New York Blue" album, and Madonna's "Hang Up" from "Confessions on a Dance Floor".

On the other hand, this brightness also provides a very strong sense of spatiality that can be heard on Hol Baumann's "Endless Park" theme from "Human" album which sounds much duller and more two-dimensional on SE215.

I don't have a rig for measuring headphones, however I was able to capture reliably the high-frequency part of the transfer function of both Ambeo and SE215 by moving them in a free air close to a measurement microphone (a variant of MMA averaging)—the measurements are only valid starting from about 2 kHz. Then I simply divided these transfer functions and found this huge bump around 9 kHz on Ambeo:

To validate my finding, I used an equalizer first to add more high-end to SE215 and then to reduce the harshness of Ambeo, and it worked. The setting of the high-end equalization on Ambeo is extreme. The right setting seems to be somewhere in the middle between Ambeo and SE215—to add a wide peak of +6 dB Q 0.7 centered at 9 kHz to playback via SE215, and to apply a good dip when playing via Ambeo.

The difference in 1–5 kHz region can also be seen and it results in a more "distanced" perception of vocals. I tried adding a -2.5 dB Q 0.7 filter centered at 2 kHz and this helped adding some "depth" to the sounding of SE215 trading for some loss of clarity. Looks like these two settings result in a more "ambient" perception of an audio program. I suppose the reason for this equalization on the Ambeo headset is due to intention to use it primarily for immersive audio playback—playing back the "3D" sound captured with its microphones.

As a side note, I also liked that I found this equalization curve for Shure SE215, which by default sounds more "closer" and two-dimensional. It works even better if crossfeed is added. This experiment has rekindled my interest in SE215.

One problem that I've found at least with my particular Ambeo headset is the mismatch of the earphones transfer function at high frequencies. First I thought that this was due to my bad measurements—I used a DIY coupler to simulate an ear canal, so positioning of the earphone wasn't super precise. But then I also tried the averaging measurement method mentioned above. With both methods, I was always able to match left and right speakers on other in-ear headphones, except for Ambeo which always yielding rather different curves for the left and right earphones (below is the MMA measurement):

So I came to a conclusion that it must be the headset's fault. However, I can't say that I can hear this mismatch clearly, (especially the one in high frequencies). Still, for a headset of this price which has built-in DSP processing leaving this fairly obvious (via measurements) mismatch between left and right channels seems strange to me.

Microphones

Since my primary intended use of this headset was for "dummy head"-style measurements, I was curious to see how well the left and right microphones are matched and how they are tuned. Note that when this headset is connected to a PC (or Mac), it offers both "mono" and "stereo" recording modes. My expectation was that the "mono" mode uses the headset microphone (located on the right earphone wire) which is intended for communications. However, it turned out that the "mono" mode simply uses the left earphone microphone only. So I'm not sure how to activate the headset mic—perhaps when this headset is connected to an iOS device directly, it uses some special mode not available via the Anker adapter. Not a big loss though.

After seeing the mismatch between the outputs of the left and right earphones I was worried whether left and right "3D" mics are suffering from the same issue. I validated them by placing as close as possible to each other in a fixture (not on my head) and measuring the same sound source. Turned out that the mics are actually matched quite well, and we can see very close measurements when coherence is good. On the picture below the measurements are blanked out when coherence is less than 85%:

The tuning of the mics seems to be for "diffuse field"—with a prominent bump at high frequencies. This is important to know as would I try to tune a sound system to a "flat" curve using these mics, this will result in an excessively bright sound. Here is the comparison of measuring the same sound source in the same conditions using a Beyerdynamic MM-1 microphone with "free field" (0 degrees) calibration:

We can see that microphones of Ambeo start sloping up after 2 kHz at approximately 2 dB/octave rate. I wouldn't be paying much attention to other differences as they are likely due to differences in the microphones placement.

The next validation was to see how the transfer function of the microphones differs when they are inserted into ears. Due to the microphone placement, the incoming sound is now transformed by reflections from the pinna and torso. Below is the graph comparing freestanding vs. in ear microphone placements for the same sound source:

As we can see, the main difference is the prominent dip at approximately 4.8 kHz. I'm not a big specialist on anatomy of human hearing, so I can't say what it is caused by exactly. I tried putting a sound absorbing material on my shoulder and this changed nothing, so I suppose this dip is caused by some interference within the pinna. The wavelength corresponding to 4.8 kHz is approx. 7 cm, so half and quarter wavelength fit ear size.

There is a 2–3 dB boost in the speech range (300 Hz to 4 kHz)—I suppose this is thanks to the design of the pinna. And also noticeable a significant loss in high frequencies starting from approximately 14 kHz. This can actually explain why I'm not hearing well the mismatch between the left and the right earphones.

The differences in low frequencies are most likely due to variations of placement of the freestanding vs. in-ear and need to be ignored.

While writing this post I've looked up other reviews of Ambeo headset and found that on iOS it's possible to record at 24/96. Unfortunately the Anker adapter only supports 24/48. However, that's enough for my applications.

Applications

Now let's consider a couple of applications for this headset.

Sound System "offline" Evaluation

It can be useful to capture the produced sound field of a sound system for evaluating it later, perhaps in a more comfortable setting. This is similar to the original function of this headset—capturing 3D sound fields for realistic playback recreating the original environment.

There are great notes by S. Linkwitz of how much our perceptual system can ignore the room and focus on the direct sound of the speakers. However, if we reproduce a binaural recording of the system in a room back using the same system, we immediately start noticing all the room contributions (see the paper "Room Reflections Misunderstood?", Section 5). This is a really interesting experiment to try with this headset.

Note that since Ambeo is a binaural headset, not a spherical stereo microphone, the pinnaes of the person making the recording inevitably color the sound. As we have seen in the section above, the filtering by the pinna is non-negligible. I found that it's best to play back these recordings either on Ambeo itself (no surprise here), or on IEMs with close to direct field equalization. Playing on over-ear headphones or via speakers will "apply" the pinnae filter once again.

"Dummy Head" or "Spherical Microphone" Measurements

This is what I was doing when tuning audio in the car. Since the "room" is very small, and the presence of a human body introduces a significant change in the acoustic environment, using in-ear microphones for left and right speakers alignment produced better results than use of a measurement microphone.

To reiterate, I was using Ambeo only for matching the sound arriving into the left ear from the left speaker to the sound arriving into the right ear from the right speaker by equalizing the speakers. The final tonal adjustment was done using MMA averaging and double-checking with known music tracks. As we saw from the measurement of Ambeo's stereo microphones are well matched and are equalized for diffuse field. The dip around 4.8 kHz that occurs when they are inserted into ears (at least, my ears) must be ignored during sound sources matching.

A note of caution here. Ambeo headset is a digital device, not an analog microphone, and unlike pro audio interfaces it lacks external clock input. Since the audio output from Ambeo only goes into its earphones, one will need to use another digital audio interface for audio output. This is where the problem comes in—with two digital devices not synchronized via "world clock" feed there inevitably will be clock drift between them. To illustrate how bad the resulting measurements can be affected check the graph below:

The red trace is the original EQ filter (BTW, it's the SE215 "improvement" filter I was discussing in the Earphones section, with a bit of bass added), the magenta trace is the same filter as measured by Ambeo headset from a playback done via a separate audio interface. As we can see, there is a very serious spectral shift.

What to do about it? In REW the solution is to use the shortest test impulse (128k):

Using a shorter impulse has worse signal-to-noise ratio (there is more visible noise on the green trace) but at least there is almost no spectral shift. In fact, it's a well known problem with REW when it's used with USB microphones like miniDSP UMIK-1. I've seen several threads on forums where people were wondering why the results of their measurements using different log sweep lengths but otherwise the same setup didn't match. I'm really curious why REW allows for multi-device measurements by default.

The clock drift problem is the reason why Acourate only allows using a single device for input and output. With Acourate it's recommended to use even longer sweeps than REW uses, so attempts to "work around" single device limitation by using drivers like ASIO4All will inevitably lead to a severe spectral shift.

SMAART has a very useful feature for tracking the impulse response delay changes automatically. This is in fact the technique I used when aligning car speakers via Ambeo. I had to experiment with averaging settings to find the one that allowed for more reactive compensation of clock drift. Usually, the shorter the averaging is, the better.

Over-ear Headphones Equalization

Here is the full story of how I obtained the graphs above. I put on the Ambeo headset and then put Audeze EL-8 closed back over-ear headphones on top of it. Then I was playing test sweeps via EL-8 and measuring their output using Ambeo. Crazy, right? I don't think anyone at Sennheiser were considering this application of the Ambeo headset. However, as the last graph demonstrates, this setup can actually be used for measuring acoustically the effects of headphone equalization.

Does it mean this $200–$300 headset plus your own head can replace a head simulator for over-ear headphone measurements? Not quite. The trick with the measurement above was that I didn't move or replace the headphones while doing it, I simply was toggling equalization on and off. This allowed for quite reliable comparison of the measurements before and after equalization. What happens if I remove the headphones from the head, put them back again, and make another measurement? The measurement will be different. As people in the headphone industry know, in order to obtain a reliable measurement of headphones one needs to re-mount them several times and then average all the measurements taken.

This is how the derived EQ looks like when I actually re-installed EL-8 several times and used averaged measurements:

The results at high frequencies are not that reliable anymore, the tolerance is only within 2 dB, which is a lot for headphone measurements. This is what will happen if one will try to compare equalization of different over-ear headphones. So, Ambeo isn't a very precise tool for this task, at least for the whole operating frequency range.

However, Ambeo still provides a good reliable output for low frequencies. And in fact, it's the low frequencies where use of a head simulator is required because headphone drivers can only deliver their full bass output when there is a closed chamber between the driver and the ear drum. That brings an idea—we can use a combined measurement of MMA for high frequencies plus Ambeo for low frequencies.

As I've mentioned in the Earphones section, this is a variation of MMA where we slowly move the headphones near a microphone and wait for the RTA measurement with infinite averaging to stabilize. To demonstrate that the produced measurement can be reliable used, here is the EQ derived from this technique, I was holding EL-8 close to MM-1 and moving it slowly, waiting for 100 sampled measurements to accumulate:

As we can see, there is much better tolerance at high frequencies, but below 1 kHz the data is unreliable. And here is where Ambeo comes to the rescue. By merging together low frequency measurement done by Ambeo on a head with the rest of measurement obtained via MMA we can measure over-ear headphones output reliably.

A note of caution—this method is only good for comparing headphones. We measure one headset, then another, then derive the differences in their equalization. There is no way for measuring absolute frequency response of headphones using this method.

For a practical demonstration I measured filtering applied by Audeze Cipher cable for EL-8. Everyone heard the debates whether or not headphone cables make the sound different. Well, in the case of the Cipher cable vs. analog cable the difference is real because Cipher cable is digital and contains a DSP in it. I noticed that even when the EQ in Audeze app is set to 0 dB at all bands, the sound via Cipher still differs from the sound via analog cable. And I was able to measure this using the technique described above:

For the analog cable measurements I used SPL Phonitor Mini, which has very low output impedance and thus provides adequate bass output. The section of the graph below 1 kHz was obtained from comparing measurements done by the Ambeo headset on my head. There is noise because I turned off FTW gating in SMAART to get a full bass extension. However, we can clearly see that the Cipher cable boosts the bass by almost 3 dB (remember, this is with a "flat" EQ setting in the controlling app!). The section of the graph after 1 kHz was obtained with MMA technique. A "scoop" at middle frequencies can be seen clearly.

I found electrical measurements of the Cipher cable done by user KaiSc on Head-Fi.org. It confirms the 3 dB boost, but not the middle section scoop. Although KaiSc also mentions compression effects from the Cipher DSP at high volume. Since I was testing EL-8 at high volume to obtain adequate free-field output, it's possible that the DSP has thrown in some compression at this point. UPDATE: the "scoop" is a measurement error, see my post.

Sunday, April 5, 2020

Improving audio in Mercedes GLK350 (X204), Part 2

In Part 1 of this post I explained how I replaced the "basic" speakers with the ones from Harman-Kardon Logic 7 configuration and studied their behavior with AudioFrog GSC610C passive crossover. Now it's time to install the crossover into the car and tune the system.

Installing the Crossover

Initially I was planning to fit the crossover somewhere inside the door—affix it to the middle steel panel. However, the panel has turned out to be quite uneven, to improve its rigidity, I guess—so the crossover unit couldn't really fit anywhere on it. Then I went with the plan B—installed the crossover into the door pocket at the bottom of the door panel (also known as "map pocket"). It took about half of the space, still leaving room for a water bottle. Learning from the hardware designers of Mercedes, I used aluminium rivets to mount it.

Obviously, I had to tap into the wire harness that goes from the cockpit into the door to insert the crossover. And since I had installed the crossover into a removable part of the door, I had to enable the possibility to detach the connecting wires of the crossover. I ended up with the following arrangement:

There is a hatch in the door panel which is used to get access to the electrical wiring of the door without actually removing the former. There was still some room there so I put a screw terminals block that joins elongated wires from the door harness with the wires of the crossover unit. Would anyone need to remove the door panel, they will need to unscrew the crossover wires first.

Checking Tweeter Polarity

Now the most interesting part—squeezing the best possible sound from this configuration. First I decided to check the sound of the door speaker as a unit. The main problem with car door speakers is that the drivers are placed very far from each other. Ideally, one would need to listen to such a speaker from a good distance in order to achieve "blending" between the tweeter and the woofer. Unfortunately, this isn't an option in the car. The other problem is that the speaker components are not equidistant from the listeners' ears. In sophisticated car audio systems this problem is partially solved by installing a lot of speakers and tuning the delay of each speaker driver individually. In my case this wasn't an option though.

One thing I wanted to decide on is the polarity of the tweeter. Initially I just followed the color codes of the wires, attaching brown wires to "-" terminals of the crossover. However, this didn't exclude an option that the tweeter could be wired in reverse polarity at the factory to achieve better integration of the drivers. In order to check which polarity works the best, I opened the door and set up a microphone to be equidistant from the drivers (about 55 cm).

Then I captured the impulse response with the tweeter connected in the initial wiring and inverted. The frequency response didn't differ much:

The response shown is FDW-windowed at 7 cycles to get rid of surrounding reflections. Note that in both cases there is a huge notch between 500–600 Hz. Perhaps, it's caused by some reflection inside the door—the quarter-length wavelengths involved here are 17.2–14.3 cm, and the door isn't fully stuffed with absorbing material, so this seems to be a natural explanation.

However, the frequency response doesn't tell the full story. Here are the impulse responses:

As we can see, they look very much like mirror images of each other, and the inverted one (black) looks more correct to me as it's main peak goes in the positive direction. So I ended up inverting the tweeter polarity. I think it's actually the "natural" polarity for the tweeter, thus it seems that in the "basic" configuration the tweeter polarity was inverted, and I just restored it back.

Taming the Rear Door Speakers

As I mentioned in Part 1 of this post, I didn't replace the rear door speakers due to their peculiar mounting. However, I wanted to find a way to minimize their negative influence on the sound of the front speakers.

Fortunately, Audio 20 unit has an engineering menu (accessible by pressing "Hang Up", "1", and "#" buttons on the keypad simultaneously) that gives access to the equalizer and low- and high-pass filters for each door driver individually. I decided to leave to the rear door drivers the role of low frequency extensions, so I set up for them a low pass filter to 100 Hz with a 12 dB / octave roll-off:

Besides eliminating incoherent sound, this also leaves more current for the front speaker channels in the power amplifier.

Aligning Front Door Speakers

While verifying the polarity of the tweeter, I also checked how similar the resulting door speakers are. They were pretty close, which was good. However, in the car the speaker setup is highly asymmetric due to the presence of the steering wheel and the driver's body.

I was thinking for some time how to approach the alignment. I've found the paper by M. Ziemba "Test Signals for the Objective and Subjective Evaluation of Automotive Audio Systems" which suggested the use of a stereo spherical microphone which simulates human head better than a regular measurement mic or mic array. What I realized is that a real human head with in-ear microphones constitute an even better measurement device. Another advantage of using a real human is that we also perform exact measurement of the actual acoustic crossover formed by non-coincident door speaker drivers and the driver's body.

Recalling my visit to the AES Conference on Headphones I decided to buy Sennheiser Ambeo headset. I learned that Sennheiser has sunset this product, but I've managed to find it through 3rd party sellers. Yet another technical obstacle was that the Ambeo headset was only available for iPhones and thus has a Lightning connector. Thankfully, Anker has developed a Lightning-to-USB adapter which explicitly lists the Ambeo headset as one of the supported products. This allows using this headset with laptops. The Ambeo headset has turned out to be a very useful audio measurement instrument, although not free from issues. I plan to do a separate post about it.

Now my strategy was to align the frequency response of the left door speaker as measured by the left ear microphone with the frequency response of the right door speaker as measured by the right ear microphone. I used Rational Acoustics Smaart v8 in dual-channel FFT mode to be able to look at the correlation graphs for the measured transfer functions. Yet another useful feature of Smaart is the ability to apply gating in the dual-channel mode. Since the car cabin is full of reflections, it's important to ensure that we are equalizing the direct sound within the integration period (the first 10 ms of arrival). I was using an 8 ms window in my tuning process.

The tuning was done by manual real-time tweaking of the Audio 20 parametric equalizer. I didn't use REW because it isn't aware of the correlation between the test signal and the captured audio output and thus it might attempt to correct areas that are simply not correctable because the dips are caused by destructive acoustic interference or other acoustic interaction. Also, by tweaking PEQs manually in real time I was able to see the changes instantly on the analyzer.

This is what I've got for the left speaker as measured by the microphone in the left ear vs. the right speaker as measured by the microphone in the right ear. The levels are matched for the purposes of comparison. In reality the left channel is about 2 dB louder due to proximity.

This looks a bit scary, however this really demonstrates how challenging the car cabins are for accurate sound reproduction. I couldn't make the region of the left channel from 600 Hz to 2 kHz to match the right channel—it seems that the dip is caused by acoustic interference. Also note the 5 kHz dip which is an artifact of measurements with the Ambeo headset.

I've also made a moving microphone average measurement with both left and right channels playing, in the area where the driver's head is (w/o the driver being there, of course) using Beyerdynamic MM-1 microphone with diffuse field calibration profile. Here it is compared to the target curve recommended by AudioFrog:

I've got slightly more bass, but this is easily adjustable using the tone controls. Also, the bass in the car anyway needs a bit of boost while on the road due to engine and wheels noise. As we can see, there is no dip at 5 kHz we've seen on the measurement acquired via the Ambeo headset. However, there is a wide dip at 500–700 Hz likely the same one we've seen on the door measurement, and also a narrower dip at 2 kHz. It can also be seen on the door measurement, and it could be a result of an imperfect crossover overlap. If we recall the measurement showing the effect of the crossover on the HKL7 drivers:

I've set GSC610C to "-3 dB" setting to tame the high frequencies (yellow graph) and we can see that it has the fastest decay at the crossover point, however it's still a bit higher than w/o the crossover (green graph, the topmost in the right part).

Listening Impressions

I checked my usual "spatial" test tracks:

  • track 28 "Natural stereo imaging" from "Chesky Records Jazz Sampler & Audiophile Test Compact Disc, Vol. 3";
  • track 11 "LEDR" from "Chesky Records Jazz Sampler & Audiophile Test Compact Disc, Vol. 1"

For sure, the localization is much worse in the car cabin environment with lots of reflections and asymmetric seating. On the first track, there was no difference between "left" and "extreme left" (and right) drum positions, however, the drum running around the listener still could be imagined well. On the second track, the "going up" sound wasn't actually moving, but the one making an arc from the left to right speaker was perceived realistically—to my surprise.

I also checked some musical tracks and compared them to the sound in Shure SRH1540 headphones matched by volume. The car sound was more "relaxed" and even had spaciousness, it sounded more "enjoyable" than in headphones, which sounded more "forward" and a bit brighter.

Costs

Here is what this upgrade cost me (excluding tools):

  • HKL7 tweeters A2128201002, pair (from a disassembled car): $30
  • HKL7 woofers A2048202102, pair (new): $318
  • Door trim retainer clip A0009917940, pair: $5
  • AudioFrog GSC610C crossover, pair: $194

Total: $547

Conclusions

This has turned out to be an interesting and challenging project, requiring a lot of research (at a hobbyist level). I'm glad that I started it, and like the result. It's a pity that basic car audio packages do not sound well. Next time I will be buying a car, I will definitely look into "premium audio" options.