Optimization suggestions

[Mrw33554432]

New feature required

Great work so far! With the following simple optimization, the inference speed of demucs-gui can be improved significantly, and save storage space as well.

• [x] #31
• [x] #25
• [x] #53 Save as mp3 (we can do that with ffmpeg anyway, however doing it from source may use less IO operations).

[Mrw33554432]

Perhaps we can just modify the code a little (but I failed to run from source code - the release package works fine)

        save_callback(file, out, self.save_callback)
        self.updateStatus(f"Successfully separated audio {file.name}")
        finishCallback(shared.FileStatus.Finished, item)
        self.separating = False

to

        self.separating = False
        save_callback(file, out, self.save_callback)
        self.updateStatus(f"Successfully separated audio {file.name}")
        finishCallback(shared.FileStatus.Finished, item)

I guess self.separating is controlling when the next process will be started. And if this doesn't work we can just assign a new thread with a copy of parameter.

[CarlGao4]

I've moved the first suggestion into a new issue. Though your modification will not achieve what you want. I'll add it to 1.0

[Mrw33554432]

I've moved the first suggestion into a new issue. Though your modification will not achieve what you want. I'll add it to 1.0

I find this, which might make 2nd task much easier

# If you only want to separate vocals out of an audio, use `--two-stems=vocals` (You can also set to drums or bass)
demucs --two-stems=vocals myfile.mp3

[CarlGao4]

You will find that it was me who developed this function :smile: In fact, I'm planning to add a mixer, allowing the users to mix stems and change their volumes, so operations like making vocals louder would be easier. But I won't add it before 1.1

[Mrw33554432]

You will find that it was me who developed this function 😄 In fact, I'm planning to add a mixer, allowing the users to mix stems and change their volumes, so operations like making vocals louder would be easier. But I won't add it before 1.1

The new thread based save seems working well. Now the audio loading is taking lot of time between each file, so I guess it also deserve a separate thread (maybe pre-load 10 files in a queue and directly send them when the model is ready).

[Mrw33554432]

You will find that it was me who developed this function 😄 In fact, I'm planning to add a mixer, allowing the users to mix stems and change their volumes, so operations like making vocals louder would be easier. But I won't add it before 1.1

The new thread based save seems working well. Now the audio loading is taking lot of time between each file, so I guess it also deserve a separate thread (maybe pre-load 10 files in a queue and directly send them when the model is ready).

On a 3090, the audio loading can take 1/3 of the inference time, and on a 4090 it may take about 2/3 of inference time. So I guess it is a big issue. I tried to write that function by myself, but it seems like the backend (audio processing) is deeply correlated with the front end (queue control).

[CarlGao4]

In fact, I'm worrying about the memory issue. With parallel reading and writing, more than one uncompressed audio files are stored in memory, which will increase the possibility of encountering OOM

[Mrw33554432]

In fact, I'm worrying about the memory issue. With parallel reading and writing, more than one uncompressed audio files are stored in memory, which will increase the possibility of encountering OOM

I don't actually think that will be a problem, as each loaded sound file will only take a little mem (as long as the file itself is not too large - but 200M+ audios are rare cases). In my other projects even loading 100 audios in a queue/list won't really take much ram, and the extra ram usage (<200M I guess) comparing to the current mem usage (2G) would be minor. Reducing the amount of pre-loaded audio would also help, you can try 2/3/4 preloaded files and ideally that should be quite enough.

[CarlGao4]

All done in 1.2