I have been interested for a long time in how human hearing works.
We do not hear a room, a loudspeaker or a direction from one isolated measurement. Our hearing combines information from both ears, small differences in timing and level, the first arriving sound, later reflections, movement and many other clues. The brain somehow turns all of this into a useful impression of space.
That led me to a simple question: how much of the same kind of information could a computer measure and combine?
I started exploring that question through a number of smaller programs and experiments. Over time, those separate tools began to grow into a larger project called Binaural Geometry Mapper, or BGM.
BGM is currently an experimental collection of measurement and analysis methods. It can play test signals, record them through a binaural microphone setup and examine different clues in the captured sound. The broader goal is to learn what can be inferred about loudspeakers, their relative directions and distances, the room, reflections and the audio system itself—while avoiding assumptions about what the answer is supposed to look like.
The project has grown in many directions. Some experiments have become useful parts of the main program, while others have exposed limitations, failed or remained unresolved. I consider those negative and uncertain results important too. If the available measurements do not contain enough information for a reliable answer, the software should say so instead of quietly inventing one.
BGM has a long development history already. Some earlier versions and measurement projects can be seen in videos I have shared on YouTube. Those show different stages of the work, so they should not necessarily be taken as a description of the current version. The software and my understanding of the problem have both changed considerably along the way.
At the moment, BGM is not a finished commercial product, and there is no decided commercial plan behind it. I do not yet know whether there ever will be one. The development will probably continue for as long as I find the questions interesting and the experiments meaningful.
I am also interested in the possibility of open-source development. Additional developers and testers could help explore more hardware, rooms and measurement conditions, and could potentially move the project forward much faster. On the other hand, maintaining a fully open project, answering questions and supporting users could become a large project of its own. For that reason, I have not made a decision about the development model yet.
For now, I plan to use this thread as a development diary: sharing the general direction, interesting experiments, things that work, things that do not work and questions that remain open. I will try to keep the main posts readable without requiring a deep technical background. More detailed explanations can follow if people are interested or have specific questions.
This is a resource-intensive project, and there is a limit to how quickly one person can develop, measure, test and document everything—even with extensive AI-assisted coding. Still, the subject continues to be fascinating, and there are many directions left to explore.
— HaK77
AI assistance disclosure: This post was drafted with OpenAI Codex from HaK77’s notes and BGM project documentation, and is published after review by HaK77. The project concepts, measurement methods, physical testing, evaluation and development decisions are HaK77’s.
We do not hear a room, a loudspeaker or a direction from one isolated measurement. Our hearing combines information from both ears, small differences in timing and level, the first arriving sound, later reflections, movement and many other clues. The brain somehow turns all of this into a useful impression of space.
That led me to a simple question: how much of the same kind of information could a computer measure and combine?
I started exploring that question through a number of smaller programs and experiments. Over time, those separate tools began to grow into a larger project called Binaural Geometry Mapper, or BGM.
BGM is currently an experimental collection of measurement and analysis methods. It can play test signals, record them through a binaural microphone setup and examine different clues in the captured sound. The broader goal is to learn what can be inferred about loudspeakers, their relative directions and distances, the room, reflections and the audio system itself—while avoiding assumptions about what the answer is supposed to look like.
The project has grown in many directions. Some experiments have become useful parts of the main program, while others have exposed limitations, failed or remained unresolved. I consider those negative and uncertain results important too. If the available measurements do not contain enough information for a reliable answer, the software should say so instead of quietly inventing one.
BGM has a long development history already. Some earlier versions and measurement projects can be seen in videos I have shared on YouTube. Those show different stages of the work, so they should not necessarily be taken as a description of the current version. The software and my understanding of the problem have both changed considerably along the way.
At the moment, BGM is not a finished commercial product, and there is no decided commercial plan behind it. I do not yet know whether there ever will be one. The development will probably continue for as long as I find the questions interesting and the experiments meaningful.
I am also interested in the possibility of open-source development. Additional developers and testers could help explore more hardware, rooms and measurement conditions, and could potentially move the project forward much faster. On the other hand, maintaining a fully open project, answering questions and supporting users could become a large project of its own. For that reason, I have not made a decision about the development model yet.
For now, I plan to use this thread as a development diary: sharing the general direction, interesting experiments, things that work, things that do not work and questions that remain open. I will try to keep the main posts readable without requiring a deep technical background. More detailed explanations can follow if people are interested or have specific questions.
This is a resource-intensive project, and there is a limit to how quickly one person can develop, measure, test and document everything—even with extensive AI-assisted coding. Still, the subject continues to be fascinating, and there are many directions left to explore.
— HaK77
AI assistance disclosure: This post was drafted with OpenAI Codex from HaK77’s notes and BGM project documentation, and is published after review by HaK77. The project concepts, measurement methods, physical testing, evaluation and development decisions are HaK77’s.
Last edited: