Unsolved Analysis of the 4.37.3 F4SndTbl.textproto file
-
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, only a few appeared to have any obvious errors. However, there were several sound packets did have possible data value issues; nearly all of them were external engine sounds that can only be heard from an outside view, or a canopy-open view. After exhaustive testing, I came up with recommended values that appear to improve the experience, which are highlighted on the worksheet with a yellow background…
As a result of the analysis, I updated my own F4SndTbl.textproto file. Most were error corrections, and some were definitely a matter of personal preference. If you enjoy listening to outside view sounds, I think you would be very happy with the recommended changes.
I’ve made the above-mentioned spreadsheet available for anyone to review via the below link: NOTE: Worksheet updated
2024/04/272024/05/02.Obvious errors are in a red background. ‘Recommended’, ‘preference’, or ‘questionable’ values are in a yellow background with attached comments/explanations. I would especially recommend the changes I made for listening to rain, both inside the cockpit (with canopy open and closed) and outside the plane in an external view. It think it’s much more realistic and enjoyable.
Respectfully submitted.
-
@SoBad said in Analysis of the 4.37.3 F4SndTbl.textproto file:
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.
The code itself and data structure simply don’t allow to have realist and correct rendering both in internal AND external views in all circumstances.
I’ve spend several hundreds of hours playing with those trying all possible compassion … based on my RL experience of flying jets (and other lighter and heavier a/c) I couldn’t find perfect setup.
To make it better we would need and large overhaul of the code+data+sound sample allowing to completely separate the external and internal sound … or … having realistic helmet+canopy sound attenuation and realistic sound propagation in the air (sound attenuation delay relative with distance of sound sources (example: traveling at 420kts, a bomb exploding 500ft from you can’t be hear IRL).
Would also need a different behavior whether or not engine if running and+or canopy is open.Last but not least … you are talking about “faintly hearing the solid thump of the landing gear locking into place” … (and some other example) those should not be heard in cockpit. IRL, it is not possible to hear it. But I had to make some compromises otherwise some ppl are REALLLLY no happy at all. Lot of ppl wants
, not realism (not because they don’t like realism, but because of they wrong/biased expectations of what pilots hear and feel in a fighter jet cockpit).@SoBad said in Analysis of the 4.37.3 F4SndTbl.textproto file:
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).
Yes they are relevant. you just don’t know “where” the compromise had to be made.
Some example: Sonic boom … Chaff/Flare firing sound (which behave erratically because are popping on release, but also when vanishing/disappearing if you pay a careful attention and if you set the volume high enough) … etc … (too bad, I’ve just suppressed from my YT channel few days ago a lot of Dev videos showing some of the sound issue I am talking about).Cockpit\seatup.ogg
Cockpit\seatdown.ogg
Personal preference.
The default volume is annoyingly loud to me.Good example of realims vs preference.
Some values/entries are use for several different sounds and are shared with different “effect”.
IIRC, some bomb explosion sound are also used also when a/c is scraping the ground or hitting the ground (should not but changing this is a nightmare and sometimes must be done in data files, including aircraft.dat files and ParticleSys.ini … and also in the code itself and they must be synced … so you need a coder to make the change in the code and keep it synced with data files all together.)How in hell did somebody come up with a number like ‘-208’??? On a scale from 0 to -10000, that is literally indistinguishable from a normal volume of ‘0’.
-208 … “8” was simply among several values set to “identify” a group of sounds that I need to change together at the same time to keem’em relevant (In excel: Search “-208” to list all the lines that need to be modified the same time) … I was using such tip in Parent data also to identify the weapon Pylons that need a specific Display radius value allowing to use Notepad++ to search all the files and modify all value in one single shot.
…
I could speak about it for hours, but it is long time I didn’t (deeply) worked on that area (so my memory is failing) and it is VERY complex and large (even more that you think).
Last thing I can say: Sound group of Setup is not optimal. We would need to change all of those in order to re-balance a lot of sound category allowing better mix/balance of radio comm’s sounds relative to internal cockpit sound AND relative with engine sounds …
For the moment, it is a “relatively” bad compromise that I had to make in soundtable … because re-doing/re-evaluating all and each entries again, including the .ogg normalization, would require a huge amount of work, time, coordination with coders, AND … lots of discussions/arguing because I am convinced that lots of ppl will not be happy about the final result despite the gained benefits in the customization possibilities and gained realism (was the same problem about UTC/Z time vs local time in game in misson planning and in DED, and also about the True vs Mag heading … we, mainly MavJp and I, had to spend a large amount of energy to explain to arguing ppl why it realistic and why it was REALLY necessary … And it was not a pleasant moment as some people did not want to understand.) -
To be honest I don’t know what a F-16 really sounds from the inside of a cockpit.
But I know what a tank sounds. Haven’t ever complained about sound in a tanksim as even our multimillion simulators with high end sound systems don’t get close.
To get a realistic sound of not only the audible frequencies but in order to feel it physically especially if we are talking about stuff like engine sounds.
As I said training in one of those still feels game-ish in terms of sound
-
@oakdesign
Physiological feedbacks are also taken in account in sound data (this is why we’ve accepted some compromises and added some sound feedbacks that are not heard IRL … I.e. pilot’d breathing sounds under G loads, vibrations when airbrakes and/it landing gear are extended …) -
@Dee-Jay complete with you. Just wanted to underline that there are things that are just not that easy or better to say very difficult to simulate due to individual perception and perspective
-
@Dee-Jay -
Excellent feedback and good points all. Your efforts and results are amazing. I just didn’t know it was you who was doing it.
Your explanation of the “-208” makes perfect sense to me now because I also used such “tricks” to help me associate items in data tables during my programming days (I’ve been retired for over 20 years, which is why I do projects like this for fun now). I should have realized what you were doing when I saw the odd numerical designation.
I’m glad that you compromise to a degree regarding IRL vs. strong user expectations. For example, the speedbrake might not have a faint “beep” when extended IRL, but it’s a far more convenient confirmation than trying to gyrate my TrackIR to see the hidden physical cockpit indicator (I use the modifed “airbrake” ogg file).
And, I might not be able to faintly hear my ground munitions release from my wings IRL, but it helps me to confirm the all-to-briefly blinking FPM. To me, these small concessions (such as selectable HUD colors that aid vision impaired users) are a very practical compromise between IRL and the way these things translate to an old guy like me sitting in front of a computer.
Really, Dee-Jay, my primary purpose was to highlight obvious typos, inadvertent data swaps, and other obvious anomalies, which I did.
But if you (or possibly @Tumbler31) could explain to me (here or via Chat) the way the BMS code interprets and implements the inside_cone_angle_deg and outside_cone_angle_deg values, I would love to spend some time & testing to try to improve the transitional attenuation effects. I just couldn’t glean enough insight from the explanation given at the top of the F4SndTbl.textproto file to understand.
Thanks for your insight, and your dedication.
-
@Dee-Jay said in Analysis of the 4.37.3 F4SndTbl.textproto file:
large overhaul of the code+data+sound sample
working on it