Closed ThreeDeeJay closed 12 months ago
If it doesn't support 24-bit samples, then that would mean it doesn't support the latest mhr version. That would be an issue since makemhr only supports outputting the latest version, so it would need an option to output older versions.
As for MIN_RATE, the general idea is that HRTF isn't very useful below 32khz. The typical next sample rates below 32khz are 24khz and 22050hz, which only carry sounds up to 12 and 11khz respectively, which severely harms localization capabilities.
Using low sample rates isn't really to match the device's format but rather the sfx so for example, if a game plays a sound that's 8000 Hz and there's no HRTF-8000.mhr (which by the way is already included so this is just hypothetical), it will not spatialize the sound and maybe even play it really loud, because there's no resampling on the fly. Some games have tools to resample all files to get around this, but other than that, we gotta just play and check the log for missing sample rates to generate them. Super tedious, I know š
So if the newer version is a lot more complex than just higher bitrate, I guess I'll go ahead and close this issue š
It wouldn't be out of the realm of possibility to add an option to output an older mhr format if there's apps that need it.
The "isn't really to match the device's format but rather the sfx" is looking at the problem wrong, though. Sounds should be resampled to a canonical rate so they can be mixed together, and it's after that resampling to the target rate that HRTF would be applied for mixing. Particularly with 3D audio there may be a pitch change for a sound, which is accomplished with resampling, and you don't want to apply HRTF before altering the pitch since that will mess up the HRTF (the peaks and valleys in the frequency response, and inter-channel delays, that are supposed to be constant for a given direction will be stretched or shrunk). Applying HRTF before resampling also means the quality of the resampler will influence the quality of the HRTF-filtered sound. Doing resampling after HRTF also means, for mono/3D sounds, the resampler needs to be applied to both HRTF output channels to mix it with the other sounds, instead of the one source that goes into the HRTF. You also don't want effects like reverb to apply after HRTF, but need it needs to be done after the sounds are resampled and mixed for the effect bus.
Yeah, I completely agree that that's how it should be done.
However, since X3DAudio HRTF never got proper SFX resampling like that and development is stalled, we're stuck having to use a tool to resample all SFX files or use an MHR for every single SFX frequency used by the game, otherwise sounds will play loudly and non-spatialized.
Even the developer himself had to edit makehrtf.exe to generate more MHRs for some games.
But yeah, the main reason for this request was so that I can convert SOFAs to X3DAudio HRTF MHR format for the HRTF database, since the only other alternative is to get the WAVs and reverse-engineer a .DEF file by hand (tedious IME) so that I can use makehrtf.exe (the old version, which lacks SOFA support) š
Hopefully the developer or someone else continues their work and overhauls the resampling/mixing system so we don't need hacky workarounds like this š
X3DAudio HRTF is like OpenAL Soft, but for XAudio2 + X3DAudio (usually Unreal Engine 4 games) and it uses MHRs for HRTF. However, it hasn't been updated in a long time and the original author made the repo private. I got in touch with him and apparently it was done following some Russian software protest and said it may get an update in the future but to be honest, given the situation, it doesn't seem likely anytime soon. š
Anyhow, the reason why it needs an update is because it doesn't support newer MHRs that use 24-bit or <32000 Hz sample rates and other changes after https://github.com/kcat/openal-soft/commit/0349bcc500fdb9b1245a5ddce01b2896bcf9bbb9 like SOFA support and more importantly, realtime resampling, which means it needs an MHR for every single sample rate, including ones currently restricted by MIN_RATE.
I was able to build makehrtf by using the previously working commit as base and following the author's suggestion to lower MIN_RATE which works, but it would be nice if we could make the latest makemhr generate X3DAudio HRTF-compatible MHRs by using 16-bits (optional, of course; as a command argument like
--bits 16
) and any specified sample rate. I'm not 100% sure this is all that's needed to make it work, though, but it might be worth a shot, and hopefully #783 would help make testing easier.