This may seem strange coming from a TBB advocate, Jason, but what does TBB add to the mix in your application? If all you are interested in is tbb::task, which is an escape for TBB applications that need some means for some portion of their operation to run a blocking or asynchronous task, not the primary feature of TBB, perhaps you should just stick with Qt.
A more fundamental question I have, though, regards the idea of multi-threading the suggested libraries, VORBIS and FLAC (I don't know either--I've spent a few minutes looking at each of their FAQs). In my quick scan, I found no suggestion whether these libraries are capable of operating in a threaded environment. They might, or they might not be thread safe. If they rely on global variables or have other side effects that preclude rentrancy, then it would make more sense to build your application as a multi-processing code rather than a multi-threading code (ie, spawn separate processes for separate clips). You would have to deal with aforementioned load balance issues, which may be a problem if your clips are varied in length and few in number, but if there's a lot of them, you can schedule clips to keep HW threads busy. There is the progress resporting issue, which would be compounded by using multiple processes and requiring multi-process shared memory or MPI protocol to solve the communications issues.
I second AJ's comments about progress update frequency. The question I would ask is: how much resolution do you need in your progress bar? Is four segments enough? Or does your application need 100? Progress reporting is a balance of forces between observability and freedom from interruption: the more frequently your codereports, the more disruption occurs in the task being tracked. I've seen several server applications whose principal bottleneck was their log reporting data flow. If you're able to do this on a multi-threaded span, the issue will be one of cache line thrashing. You'd like to write progress reports as soon as they're available and not have to wait to get back to the task. If your thread owns the cache line, it can repeatedly and quickly overwrite it as needed (particularly important if the quanta upon which you're reporting progress vary in size). However, at some point your master thread is going to want to know status and its issue of a read request will cause a snoop that will force the task HW thread to flush the modified cache line to memory, which will eat into its memory bandwidth. So infrequent reads and private cache line writes by each worker thread could be a workable scheme.