From 1d91e282c80949d30edfdbca96f1a833719ad5c6 Mon Sep 17 00:00:00 2001 From: Chris Robinson Date: Tue, 11 Feb 2020 00:37:21 -0800 Subject: Update the MHR format This update removes the 16/24-bit sample type enum, now always being 24-bit (other than a very small size saving, there's no practical benefit to storing 16-bit samples). This also reverses the field storage, so no on-load fixup is needed, and stores the IR delays with 2 bits of sub-sample precision, allowing for slightly better timing (after resampling, blending, etc). --- docs/hrtf.txt | 51 +++++++++++++++++++++++++-------------------------- 1 file changed, 25 insertions(+), 26 deletions(-) (limited to 'docs/hrtf.txt') diff --git a/docs/hrtf.txt b/docs/hrtf.txt index ba8cd8fa..7a1a500f 100644 --- a/docs/hrtf.txt +++ b/docs/hrtf.txt @@ -13,25 +13,22 @@ including above and below the listener, instead of just to the front, back, and sides. The default data set is based on the KEMAR HRTF data provided by MIT, which can -be found at . It's only -available when using 44100hz or 48000hz playback. +be found at . Custom HRTF Data Sets ===================== OpenAL Soft also provides an option to use user-specified data sets, in -addition to or in place of the default set. This allows users to provide their -own data sets, which could be better suited for their heads, or to work with -stereo speakers instead of headphones, or to support more playback sample -rates, for example. +addition to or in place of the default set. This allows users to provide data +sets that could be better suited for their heads, or to work with stereo +speakers instead of headphones, for example. The file format is specified below. It uses little-endian byte order. == -ALchar magic[8] = "MinPHR02"; +ALchar magic[8] = "MinPHR03"; ALuint sampleRate; -ALubyte sampleType; /* Can be 0 (16-bit) or 1 (24-bit). */ ALubyte channelType; /* Can be 0 (mono) or 1 (stereo). */ ALubyte hrirSize; /* Can be 8 to 128 in steps of 8. */ ALubyte fdCount; /* Can be 1 to 16. */ @@ -42,28 +39,30 @@ struct { ALubyte azCount[evCount]; /* Each can be 1 to 128. */ } fields[fdCount]; -/* NOTE: ALtype can be ALshort (16-bit) or ALbyte[3] (24-bit) depending on - * sampleType, +/* NOTE: ALbyte3 is a packed 24-bit sample type, * hrirCount is the sum of all azCounts. * channels can be 1 (mono) or 2 (stereo) depending on channelType. */ -ALtype coefficients[hrirCount][hrirSize][channels]; +ALbyte3 coefficients[hrirCount][hrirSize][channels]; ALubyte delays[hrirCount][channels]; /* Each can be 0 to 63. */ == -The data is described as thus: +The data layout is as follows: -The file first starts with the 8-byte marker, "MinPHR02", to identify it as an +The file first starts with the 8-byte marker, "MinPHR03", to identify it as an HRTF data set. This is followed by an unsigned 32-bit integer, specifying the -sample rate the data set is designed for (OpenAL Soft will not use it if the -output device's playback rate doesn't match). +sample rate the data set is designed for (OpenAL Soft will resample the HRIRs +if the output device's playback rate doesn't match). -Afterward, an unsigned 8-bit integer specifies how many sample points (or -finite impulse response filter coefficients) make up each HRIR. +Afterward, an unsigned 8-bit integer specifies the channel type, which can be 0 +(mono, single-channel) or 1 (stereo, dual-channel). After this is another 8-bit +integer which specifies how many sample points (or finite impulse response +filter coefficients) make up each HRIR. The following unsigned 8-bit integer specifies the number of fields used by the -data set. Then for each field an unsigned 16-bit short specifies the distance -for that field (in millimeters), followed by an 8-bit integer for the number of +data set, which must be in descending order (farthest first, closest last). +Then for each field an unsigned 16-bit short specifies the distance for that +field in millimeters, followed by an 8-bit integer for the number of elevations. These elevations start at the bottom (-90 degrees), and increment upwards. Following this is an array of unsigned 8-bit integers, one for each elevation which specifies the number of azimuths (and thus HRIRs) that make up @@ -71,14 +70,14 @@ each elevation. Azimuths start clockwise from the front, constructing a full circle. Mono HRTFs use the same HRIRs for both ears by reversing the azimuth calculation (ie. left = angle, right = 360-angle). -The actual coefficients follow. Each coefficient is a signed 16-bit or 24-bit -sample. Stereo HRTFs interleave left/right ear coefficients. The HRIRs must -be minimum-phase. This allows the use of a smaller filter length, reducing +The actual coefficients follow. Each coefficient is a signed 24-bit sample. +Stereo HRTFs interleave left/right ear coefficients. The HRIRs must be +minimum-phase. This allows the use of a smaller filter length, reducing computation. For reference, the default data set uses a 32-point filter while even the smallest data set provided by MIT used a 128-sample filter (a 4x reduction by applying minimum-phase reconstruction). -After the coefficients is an array of unsigned 8-bit delay values, one for -each HRIR (with stereo HRTFs interleaving left/right ear delays). This is the -propagation delay (in samples) a signal must wait before being convolved with -the corresponding minimum-phase HRIR filter. +After the coefficients is an array of unsigned 8-bit delay values as 6.2 fixed- +point integers, one for each HRIR (with stereo HRTFs interleaving left/right +ear delays). This is the propagation delay in samples a signal must wait before +being convolved with the corresponding minimum-phase HRIR filter. -- cgit v1.2.3