Here's a simplified .blend that still crashes. It has a single image (used as a 360-frame image strip) and 2 sound files.
I don't know how to bundle the image into the .blend file, but the 2 sound files seem to be there.
I'll add the image file here, and you can re-add the image strip.

Cant reproduce, renders fine here.

@Cerbyo (Kite)
https://docs.blender.org/manual/en/dev/data_system/scenes/properties.html?highlight=scene%20audio#audio

In T54418#495968, @Joerg Mueller (nexyon) wrote:

4. You can set the scene audio channels under properties -> scene -> audio -> format -> audio channels.

3. You have to know what you want to do... If you can do the audio editing in Blender, do it there, if not use some other program.

@Cerbyo (Kite) I'll post on the BSE.

So this is what I'm getting from all this:

1. The 32 channels of the blender vse are called channels but they aren't the same as audio channels (aka mono being 1, stereo 2 channel).

Maybe it does make sure that these settings are controlled and saved in the file. At least this will keep things consistent if a studio is having multiple people us one file. Between 1 & 3, I think I like 3 best.

Looking at T54115 it sounds like system settings and not workspace settings are where the current user settings should go to, since these settings are hardware specific.

In T49241#491006, @Joerg Mueller (nexyon) wrote:

Your distinction between the three types of settings is pretty clear. Regarding the user preferences there is no discussion, they are stored system wide and not blend file wide. Playback will always have to happen within the bounds of the user settings. For example, if your user settings are stereo, you simply can't playback 7.1, it will be mixed down to stereo, as in @Christopher Anderssarian (Christopher_Anderssarian)'s laptop example.

Now for scene and encoding (stored in the blend file) there are three options that I see right now in terms of format (=channels) and rate (=sample rate):

1. Keep the settings where they are and use them for encoding and playback (an option here would be to duplicate the input elements in the encoding panel, but I wouldn't remove them from the scene settings).
2. Move the values to encoding and for playback always use the user settings.
3. Duplicate the values and have different encoding and playback settings.

If your source audio file isn't using the full dynamic range of the amplitude, it is basically wasting quality. Most audio files have a dynamic range of 16 bit. If you have to double the amplitude (volume in blender = 2), you are already wasting one of these bits. At 10, you are already wasting more than 3 bits. So for any recording engineer the goal is to utilize the whole dynamic range to not lose any quality during recording. When you have a file that doesn't use the full dynamic range, then increasing the volume in audacity instead of blender doesn't make any difference in terms of outcome, so you could just do it in blender directly. The problem is of course that you don't by how much, so using audacity makes sense after all. As soon as you normalized the volume in audacity, you are using the full dynamic range, going higher in blender then leads to clipping.

I don't understand why you said

Ok, then I'll close this. There is no difference in processing of the strips between mixdown and rendering. Not even to playback, the only difference there is that the user settings are used in terms of channels and sample rate.

In T54418#492826, @Joerg Mueller (nexyon) wrote:

...This approach is volume preserving and is also what OpenAL does, though Blender doesn't use OpenAL to do this in the sequencer.

Ok, changing the number of channels is another story. Blender supports surround sound (=more than two channels) in contrast to Audacity.

Thanks @Joerg Mueller (nexyon) for the clarification.

Ok, there is a lot going on here and a lot of the information written here is just plainly wrong. Let me try to summarize: you're setting the volume of an audio strip to 10 and get an output that is clipped. Well, that's expected. I tried this and whatever I do, it always sounds the same - whether I play back in Blender (SDL or OpenAL), mix down (wav or flac) or render to a video (matroska, PCM). In that sense, I cannot reproduce the bug report.

In T54418#491941, @stephen paschke (paskperfect) wrote:

I did my first serious non-linear editing with other linux-based editors, that required rendering of audio and video separately, and then muxing them together for the final file. Computers have gotten better and faster, so sometimes it is easy to forget that there are ways to put less stress on the way data flows in computer hardware.

I like your idea, Cerbyo (Kite).
Starting with the best sound possible, and adjusting volumes downward (by ear, or numbers) seems reasonable, if you are trusting of your hearing. But I have been working with blender for many years, and would caution you to stay vigilant, with visual ques (from the Audacity graphical images), as well. Projects (in Blender) that have many small clips moved around, and key-frame adjustments to volume levels, can be taxing on some computer processors.

Edit: I recorded the vse playback in audacity of a 1.0 volume strip (one I had doctored up in audacity all nicely that was imported into the vse as a single strip). And lined it up with the mixdowned version of that strip back in audacity. Playback in audacity: The recorded playback sounded clearer and better, the mixdowned version had a waveform that was clipping in some spots. EVen if i was recording the vse playback at a lower volume, thus not getting clipping, who cares! there is no way to change the volume/amplitude of the mixdowned version to get it to sound as good, cause it clipped. I would have to manually do the scene method to change the volume.....and that has countless problems to begin with including the ending audio getting cutout (so u have to put an extra strip in). I'm just gonna record the playback for now on in the vse and use that. I might try my method below still, but seriously I can see so many things going wrong....why bother. And here's what I don't get: the 1.0 volume strip was from a mixed down audacity file I have open right now....and there is noooooo clipping, and the waveform is much lower than the mixdowned waveform!?!?? THAT makes no sense based on my previous tests and the test below that say a 1.0 imported waveform will export as the same volume/waveform level. Contradictions abound. Again this was .flac 1 accuracy.
My only thoughts to leave on is the OpenAL vse SDL might have something to do with all this. As I stated earlier, OpenAL sound so much clearer on vse playback than SDL. Perhaps OpenAL is not making it into the rendering process though, thus I'm hearing some kind of jumbled SDL output? Perhaps OpenAL is applying some unknown amazing effect in the VSE playback and its making it all amazing sounding?!? But I haven't been able to recreate by recording SDL vs OpenAL via audacity capture. Regardless, I don't know anymore, I'll stick with what is working over what is supposed to be working.

@Joerg Mueller (nexyon)
Your humble wizdom?

I chimed in, just to let you know that I didn't think it was a good idea to use a volume level of '10', and expect that there wouldn't be a problem with an audio strip in the VSE.

After having done some testing;
there is a peculiarity to the way Blender downmixes (and whatever the name is for doing the opposite).

Responding to Cerbyo (Kite):

I don't fully understand the process or how the community works as of yet. Forgive me on that front. Question: Is this case still open, do I need to give it more time, or is it a case of people can't recreate what I said and its dismissed? I feel like I'm making a big deal out of something that has been that way for a very long time and is deemed a nonissue. And in my quest for answers I am asking questions and creating a massive wall of text that normally would only serve to hinder my original issue (of which it is still a big deal for me). The more I learn, and I'm learning alot here, the more I come to the conclusion that this is a 'purposely' built limitation of the VSE, but I'm the only one who thinks its a clear decisive limitation and a huge deal!

Your distinction between the three types of settings is pretty clear. Regarding the user preferences there is no discussion, they are stored system wide and not blend file wide. Playback will always have to happen within the bounds of the user settings. For example, if your user settings are stereo, you simply can't playback 7.1, it will be mixed down to stereo, as in @Christopher Anderssarian (Christopher_Anderssarian)'s laptop example.

Sorry, Cerbyo (Kite) , I'll try to say it a different way.

In T54418#490677, @stephen paschke (paskperfect) wrote:

1.) Volume levels greater than 1.0 raise volume of input strip, in Decibels (dB), by 'value-1' dB.

I would first check to see if you have Loudness Equalization on (Link), as that would mitigate some clipping in the realtime preview.

Documentation here ( https://docs.blender.org/manual/en/dev/editors/vse/sequencer/strips/sound.html ) is missing information that was available in previous sources:

Thanks for checking that out.

In T54418#490299, @Stephen Swaney (stiv) wrote:

In your User Prefs, you have System->Sound set to OpenAL (recommended for game engine usage).
Do you still have the same issue with Sound set to SDL (recommended for sequencer use) ?

Hi, while we love to hear these ideas, this is not the right place for them. This website is mainly used to track bug reports and not feature requests. But luckly, there are some other nice solutions you can take, so please use one of the other forms of communication listed below:

please do NOT triage tickets your self.

In your User Prefs, you have System->Sound set to OpenAL (recommended for game engine usage).
Do you still have the same issue with Sound set to SDL (recommended for sequencer use) ?

Responding to T49241#389445 T49241#389480 (Removal of the volume slider in the encoding settings)

Hi, thanks for the report.

Hi, thanks for the report. This is a known problem - audaspace doesn't work with negative timings. The reason for this is that blender itself wasn't really designed to work with audio - to overcome some of these problems, I had to make some design decisions that ended in not supporting negative timings. The alternative would have been to not support animation (of volume, pitch, etc.), which is definitely the worse alternative. We could at least document somewhere that negative timings don't work with audio?

@Joerg Mueller (nexyon): could you have a look?

@Joerg Mueller (nexyon): could you have a look?

Hi, original purpose of Blender was to produce images from 3D scene.
Historically, there was an audio sequencer decoupled from video sequencer. They were merged by 2.5 re-design.
If you take attention to Edit Strip panel in Metastrip properties, you can see that they are based on Scene, Movie, Image strips properties with a blend mode dedicated to image blending.