Audio quality option (especially for billion-notes nuclear BMs)

[Kerbinator-Fras]

there should be some options to prevent deadly broken converted audio as the quality of 16int is far from enough to hold, especially for truly nuclear black midis (for example bad apple 5357 million notes.)
In theory, as they contain close-to-65536 tracks, as it is known that calculation of track merging is integer, so 65536x65536 will not exceed 2147483647 anyway. Adding the values of all audio at the same sampling point should result in a value not exceeding 2147483647.
so there should be track and file volume.
if better (assuming OC math only support int for sake of preventing precision loss when a big number add a small number in float), 32 int for tracks, 64 int (if format could hold) for output file.
as nuclear black midis often have spikes at more than +40~60db even for ~50 million (converted in coolsoft using 32float), also I want to prevent loudmax during conversion as it cause the audio to be incorrectly converted.

[Kerbinator-Fras]

Warning: To be assessed.
This was happening in a debate in one of my friend trying to convert BA5357M with old (16-int) OmniConverter version.
I'll try today with a soundfont of lower release time, and seems like new OmniConverter run on 32f instead of 16i.
if so, then override soundfont release time, and LPF soft limiter can be taken into account.
after test results are produced this issue may be deleted, due to being a debate-based issue, just wait.

[KaleidonKep99]

there should be some options to prevent deadly broken converted audio as the quality of 16int is far from enough to hold, especially for truly nuclear black midis (for example bad apple 5357 million notes.) In theory, as they contain close-to-65536 tracks, as it is known that calculation of track merging is integer, so 65536x65536 will not exceed 2147483647 anyway. Adding the values of all audio at the same sampling point should result in a value not exceeding 2147483647. so there should be track and file volume. if better (assuming OC math only support int for sake of preventing precision loss when a big number add a small number in float), 32 int for tracks, 64 int (if format could hold) for output file. as nuclear black midis often have spikes at more than +40~60db even for ~50 million (converted in coolsoft using 32float), also I want to prevent loudmax during conversion as it cause the audio to be incorrectly converted.

Warning: To be assessed. This was happening in a debate in one of my friend trying to convert BA5357M with old (16-int) OmniConverter version. I'll try today with a soundfont of lower release time, and seems like new OmniConverter run on 32f instead of 16i. if so, then override soundfont release time, and LPF soft limiter can be taken into account. after test results are produced this issue may be deleted, due to being a debate-based issue, just wait.

Actually, OmniConverter only recently got support for 16-bit integer audio, which is still processed as 32-bit float internally, before being limited to 16-bit integer with its built-in audio limiter, so I don't really know what you're trying to say with this issue?