This is respectfully submitted to the forum as a bug report at the suggestion of a BMS team member.
For the past years, I’ve been dabbling with the Falcon BMS sound files used in Falcon BMS and governed by F4SndTbl.textproto master list. This list contains 428 (Index# 0 - 427) defined sound parameter ‘packets’. Of those, 13 packets represent unused and reserved Index#s, and so are not represented by any actual sound file. This leaves 415 sound parameter packets that do represent actual sound files that are used by Falcon BMS and exist in various sound folders.
Each ‘packet’ of information is identified with a unique Index#, and contains a lot of data that define what the sound is and how the flight sim uses it. Each data packet includes:
filename: (The name of the sound file)
max_dist:
min_3d_dist: (to characterize attenuation behavior)
max_vol:
min_vol:
primary_flag: (One of several possible designations)
secondary_flags: (One OR MORE of several possible designations)
sound_group: (One of several possible designations)
cone_inside_angle_deg: (to define the nature of a directional sound)
cone_outside_angle_deg: (to define the nature of a directional sound)
cone_outside_volume: (an attenuation value associated with cone values)
index: (The unique Index number of this sound packet definition)
Not all of the data packets contain all of the above statements. Omni-directional sounds, for instance, do not (or at least should not) have cone angle statements.
Some of the data packets do not have a max_vol statement (the code apparently assumes a max_vol value of 0 in that case, but as a 30+ year professional coder, I personally think that it’s far more professional to have an explicit “max_vol: 0” statement for clarity and consistency).
Some packets do not include a min_3d_dist statement because the nature of the sound is such that this value is not relevant (attenuation is not an issue for internal cockpit sounds, for instance, which are all right next to you in a close relatively unchanging distance).
When I fly Falcon BMS, I always use high-quality enclosed headphones. They insulate you from real-world distractions, and add significant “fullness” to the quality of the Falcon sounds. You can almost feel the heavier bass sounds, or faintly hear the solid thump of the landing gear locking into place, and even the quiet subtle bump of air/ground ordinance releasing from your wings.
But I also hear the imbalance of certain sounds, or the inappropriate volume (or silence) of some sounds. The biggest issue for me was something that might be a non-issue for many players who stay mostly in their cockpit: outside view external sounds. Many of these sounds, particularly external engine sounds, just weren’t expressing themselves in a realistic way. I’m one of those players who love to open the canopy before takeoff and after landing and listen to the cacophony of sounds in a busy airbase. So I wanted to examine and possibly improve those external sounds.
So over the years, I would spend a few days now and then trying to study the sound tables. The frustration of making significant headway are two-fold: First, the explanatory remarks at the top of the master file are almost as confusing as they are helpful. Second, the packets are all listed in Index# sequence, from 0 to 437, but similar sound packets are often not conveniently contiguous. In fact, many are scattered all over the master list, making comparative examination and comprehensive group analysis of various ‘categories’ of sounds very difficult.
This past week, however, spurred and encouraged by recent private chats and suggestions from a BMS team member, I took a fresh look at this:
First, I imported the entire F4SndTbl.textproto data into an Excel-based worksheet, which was a challenging task, but I managed to figure it out. Then, irrespective of Index#s, I rearranged all of the data packet definitions into similar groupings by rows: Common, Engines, F-16, F-18, kc10, M2k, kc135, AV8, JA37, Heli, TWI (Threat Warning Indicator sounds), cockpit sounds, missiles, and unused reserved data packets.
Then, I arranged column categories as follows:
Index# & filename
Comments
max_dist
min_3d_dist
max_vol
min_vol
Flags
Sound group
Linked Sound IDs
Inside Cone value
Outside Cone value
Cone attenuation value
I then color-coded related columns for visual clarity, border-shaded associated group rows, and looked at the entire Falcon BMS sound data info in a whole new way that was immediately and obviously a magnitude easier to examine and evaluate, particularly for group analysis and spotting inconsistencies within similar categories.
First the good news: of the 415 sound packets defined, 397 of them did not appear to have any obvious issues. Of the 18 sound packets that did have obvious issues, nearly all of them were external engine sounds that can only be heard from an outside view, or a canopy-open view. Some of these issues were inarguably errors-- a typo, maybe, or an inadvertent reversal of min/max values, or an unintended inclusion or exclusion of data. Some issues might be debatably a matter of opinion or preference.
As a result of the analysis, I made a few changes to my own F4SndTbl.textproto file. Most were error corrections, and some were definitely a matter of personal preference. As someone who enjoys spending a lot of time listening to external sounds, the results, for me, are like playing a whole new game.
Bottom line is that this represents an “issue” rate of only 4% of the sound packets, and that 4% would only be of concern to those users who want to enjoy more realistic external view sounds. Keep in mind that the original sound data values were largely inherited by the BMS team, and they did a lot of needed work on them to improve things; I’m just trying to correct or improve those small number of issues that I found in this study.
I’ve made the above-mentioned spreadsheet available for anyone to review via the below link:
https://docs.google.com/spreadsheets/d/1CCOyttwTPZO5BUNTqkVwJbHWAsxic3Ql/edit?usp=sharing&ouid=103587896249403193829&rtpof=true&sd=true
Obvious errors are in a red background. ‘Preference values’ are in a yellow background with an attached comment/explanation. I would especially suggest that the new approach that I recommend for listening to rain, both inside the cockpit (with canopy open and closed) and outside the plane in an external view, be considered. It think it’s much more realistic and enjoyable.
Despite my best efforts, I still don’t feel that I have a good grasp on the nuance of assigning cone values to directional sounds, so for the most part I just accepted them, sometimes with questions, sometimes with suggestions. But I do think they need some work, particularly transitional attenuation effects from the inside cone volume to the outside cone volume and beyond.
If I could just get a good explanation of how the BMS code interprets and implements the cone value data, that would be the only remaining area of the F4SndTbl.textproto file that I would like to study, exhaustively test, and suggest possible improvements.
Respectfully submitted.