Fix Incorrect Time Estimates when Exporting 5.1 Channel Multitrack Mixdowns
Currently, when exporting a multitrack mixdown of a 5.1 file (let's say a 5.1 main track flagged as "Music" and ducked against a stereo file panned to cover mostly center channel exported to 32-bit float PCM, since this is what I'm mainly doing)... For a ~2 hour file, the "Time remaining" estimate starts off low... maybe 3 minutes. Then, up until the 50% progress mark, the estimate just continuously increases. The actual mixdown may take 10-15 minutes but it's impossible to know without setting a timer. It's also a single-threaded process, which is pretty terrible since we're talking about uncompressed PCM here (not some weird compression scheme that requires a bunch of lookahead and deltas from previous frames) and audition is already aware of all points where ducking is happening.
My computer in 1999 had two physical CPUs, and consumer-grade CPUs have been multi-core for a very long time now. Practically all other high end software has been threaded wherever possible since the 90s (I didn't buy two processors to play Quake), and even game developers, who are notoriously and monumentally terrible when it comes to keeping up with hardware (and programming in general, these days) have started writing multithreaded games. I know audio has many situations where it's hard or impossible to parallelize an algorithm, but I'm not talking about any of those.
Anyway, after 50% is hit, it apparently enters the "write to disk phase" and the huge time estimate that's built up over the first 50% rapidly disappears as the file is written to an NVMe in 20 seconds or so.
Finally, the progress hangs at 99% for around 30 seconds. Audition will go into whited out "not responding" mode if interacted with during that phase. The file is already written to disk at this point and usable by anything that only opens for reading, so I'm not sure what it's doing here.
Nothing else can really be done in Audition during the whole export process since the "parallelize disk access" setting does nothing, apparently, as the decoders and encoders seem to share one thread that will pause to complete the newest item. If a mixdown is going on, it'll just pause the mixdown while audition continues using a single CPU core.
Anyway, I can deal with the slowness of export, but it would be wonderful if, since Audition knows exactly how much audio it has to process, and can figure out how long it's going to take per second very quickly, it would spit out something resembling the correct number on the interface so I can leave the room and come back in X minutes instead of having to check up on it randomly... which is mainly an issue because after the PCM file is exported I have to use FFMPEG to convert it to an AAC or AC3 file manually since audition decided not to support any useful compressed multi-channel file formats after dropping Dolby licenses.