Restoring hi-end in pitched-down tracks - click
____
What does changing batch_size from 1 to 2
(it wasn’t used in Rofo beta UVR for 9 Jan 2025, but maybe it got changed)
“if your input is batch time sequence, it looks like this:
[ batch1->[time->[sequence],time2->[sequence]..], batch2->[time->[sequence],time2->[sequence]..] ]
As you increase batch_size you increase the amount of data the model gets to churn through.
So higher batch_size allows the model to see more data before you do a thing called backward prop which calculates another thing called gradients,
which are used to improve the model by tuning loads of little values inside the neurons so that the next pass through is more accurate” frazer
Q: They told me that increasing batch size to 2 makes it process faster
A: “So when that user says you can increase the batch_size what they mean is you can use more than one song to process - i.e. instead of running a single song at batch_size = 1 you can run 2 at the same time (batch_size = 2)
Q: Ah so batch_size param is used for the amount of chunks of the input, so if I set [batch_size] to 4 my audio is chunked into 4”
A: “No, the chunks are split based on defined chunk_size in config (which is more related to STFT settings), and then the script is stacking 'batch_size' number of chunks in same tensor to process them at same time (for inference).” jarredou
A: “Increasing the batch size increases the number of chunks that can be processed at one time, which may speed up processing, but also increases memory usage.
It will probably not affect quality.” - unwa
Inference Colab by jarredou forces batch_size=1. Iirc the clicking issue with such value was fixed in MSST repo later, and you can stick to it. Probably in UVR too, since latest patches where newer inference code from MSST was implemented.
Someone was once saying that a value not bigger than 2 takes no more than 4GB of VRAM, but it will rather differ from AMD/Intel when the VRAM usage is higher due to lack of garbage collector present in CUDA.