Recording Impulse Responses for Speaker Virtualization

[Lion3]

It was my mistake. I’m sorry

 

[Kosorm]

Hello everyone. I have been working on a beginner friendly guide/article based on what I've learned about this process as I went and I am excited to show you all, but for the time being I just wanted to drop in and comment on this discussion about the HeSuVi/Equalizer APO mix code. @Lion3 sent me the modified mix file as well as a modified version of my BRIR to work with it and I have tested it out. I do not have the proper technical knowledge to comment on the argument about which file is correct, but I will say that listening to this new file opens the sound stage and panning on each side much further than without. It sounds much more true to life in my opinion than the original and I was not expecting much of a difference at all going into it. I am not always super discerning to small changes with different audio settings, but this was immediately noticeable and felt like a great improvement. I would recommend people try this out at the very least and see how they feel before writing it off completely, I am certainly glad I did anyways

 

[Lion3]

It was my mistake. I’m sorry

 

[Kosorm]

As a quick update to my previous post, I have done more tests with the mix files provided by @Lion3 specifically in regards to 7ch games and it produced some surprising results. Although using my 7ch brir file for the game Hunt: Showdown was already a big improvement as far as positional audio goes, with the new mix i feel like I can accurately pinpoint the position of enemies as they walk around offscreen in a way that was only somewhat vague and general previously. I also generally feel the distance of the speakers actively without needing to stare at my actual speakers in order to maintain the effect whereas before this was not the case.

 

[musicreo]

I'm now totally confused.
The sequence of channels after the command. "Channel: " has no meaning at all. --> I'm really surprised by this.
However in my code the channels still seem to be assigned to the correct channels. If I increase the volume in the wav file on the second channel ( FL-r channel) the virtual channel that is effected is R1. But this actually what I want?

 

[Lion3]

It was my mistake. I’m sorry

 

[Lion3]

It was my mistake. I’m sorry

 

[Alamar5]

I'm now totally confused.
The sequence of channels after the command. "Channel: " has no meaning at all. --> I'm really surprised by this.
However in my code the channels still seem to be assigned to the correct channels. If I increase the volume in the wav file on the second channel ( FL-r channel) the virtual channel that is effected is R1. But this actually what I want?

Seems like even some developers of audio software are misinformed about how Channel: command works. This command is for channels selection only and, as you have discovered it, Channels: do not impact channels order at all for convolution processing.
The most "dangerous" command here is Copy:
You have to be very careful with this Copy command, because it creates that channels order to which convolution processing will be applied. Just test it, it's very simple

 

[Lion3]

It was my mistake. I’m sorry

 

[Alamar5]

You stated that it determines the order in which the convolution processing will occur.

Exactly and that only. So, when you are creating multi-channels Copy line, do care about the channels sequence for convolution processing. Or else you configuration for APO will be messed up.

 

[musicreo]

Seems like even some developers of audio software are misinformed about how Channel: command works. This command is for channels selection only and, as you have discovered it, Channels: do not impact channels order at all for convolution processing.
The most "dangerous" command here is Copy:
You have to be very careful with this Copy command, because it creates that channels order to which convolution processing will be applied. Just test it, it's very simple

Probably I knew it when I used the code the first time but this was even before Hesuvi existed.

 

[Alamar5]

According to the original Hesuvi text and the original track order:

• FLL, FRR are Dirac pulses.
• FLR has a peaking filter applied negatively.
• FRL has a peaking filter applied positively.

If the Hesuvi text and track order truly work correctly, the result should be identical when input and output are correctly assigned in that order.

Can you tell, please, where did you find info about peaking filter applied negatively and positively in the HeSuVi HRIRs? I don't see such filters application on the graphs when open some default HeSuVi HRIR in Audacity. All peaks are mostly positive in the all 14 channels for example, in the default dht.wav. At the moment, I can't insert images from my PC on this forum for some reason.

 

[Kosorm]

At the moment, I can't insert images from my PC on this forum for some reason.

From my understanding new users cant post pictures but I think you can upload the images to imgur or something and link them here

 

[Lion3]

It was my mistake. I’m sorry

 

[Alamar5]

I created it myself. We can make it directly using tools like REW or Audacity.
While it’s possible to use actual BRIRs or HRIRs, the current discussion is focused on input/output matching. And Hesuvi means just
Therefore, I applied Dirac impulses, as well as positive and negative filters, to each channel for intuitive visualization.

All right, I will look at your loopback measurement further.