In 3.1.1, you can change the Volume Db of the AudioStreamPlayer. However, you cannot change the volume of individual audio sound files.
Would it be feasible to add a Volume Db to the import settings? It has a normalize option wich does change the volume so I assume that manually changing the volume could be an option as well.
You can call play() with a custom DB value. Wherever you are loading your files, associate them with a volume. Problem solved.
I actually agree this could be useful. Tracking down the base volume at which sounds play all over the place in code isn't great from a sound designer perspective. Writing yourself a framework to do this is too much of a hassle when there are already an engine with options going into that direction.
Alternative is to go edit all sounds in an audio editor (which makes normalizing pointless). That's what I do because I export sounds from a DAW with all of them lined up.
This sounds good to me. Would it be possible to warn the user if the newly-imported sound has clipping at a specific volume though? (If the imported audio resource isn't actually edited, but just has its volume modified in software like with play(), I don't know if this is needed.)
Unless the sound is in float format, it might make sense to just have a multiplier value, then multiply by this whenever the sound is played, rather than to change the actual sample data (which nearly always results in degradation).
I personally do this myself in a sound wrapper (much as Duriel suggested).
Rather than doing it only at import time, there might also be an argument for being able to set this at runtime too allowing easier changes. Maybe an extra float value stored on the AudioStream (perhaps copied over from the import settings if this was preferable)?
If you did all this by multiplier, you could also potentially get rid of the need to normalize the sound data, just have this as a multiplier too. Unless that was relied on for some other feature like the trimming.
Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.
The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.
If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!
Most helpful comment
Unless the sound is in float format, it might make sense to just have a multiplier value, then multiply by this whenever the sound is played, rather than to change the actual sample data (which nearly always results in degradation).
I personally do this myself in a sound wrapper (much as Duriel suggested).
Rather than doing it only at import time, there might also be an argument for being able to set this at runtime too allowing easier changes. Maybe an extra float value stored on the AudioStream (perhaps copied over from the import settings if this was preferable)?
If you did all this by multiplier, you could also potentially get rid of the need to normalize the sound data, just have this as a multiplier too. Unless that was relied on for some other feature like the trimming.