Closed Macusercom closed 1 year ago
Hello @Macusercom , what is the duration of the wav file you are trying to compress ? We are not trying to be too smart about long files, and a lot of intermediate state will be held in memory so this could just be OOM.
Hello @Macusercom , what is the duration of the wav file you are trying to compress ? We are not trying to be too smart about long files, and a lot of intermediate state will be held in memory so this could just be OOM.
It is about 15 minutes long. Ubuntu is showing 7 GB of RAM and 40 GB storage space left but shorting the file to about 5 minutes worked. So probably OOM as you've said. I'm happy I got it working now, thanks!
I'll be closing the issue, I've added a FAQ section in the readme to mention that specific point.
🐛 Bug Report
Using the casual model at 24 kHz results in the process being killed after ~10 seconds. It doesn't matter if the language model
--lm
is used or not. The 48 kHz mode works as expected.To Reproduce
I've used the following command and got these results:
python3 -m encodec -r -b 1.5 --lm '/home/user/Downloads/Audiofile.wav' '/home/user/Downloads/Audiofile_EnCodec.wav';
Downloading: "https://dl.fbaipublicfiles.com/encodec/v0/encodec_24khz-d7cc33bc.th" to /home/user/checkpoints/encodec_24khz-d7cc33bc.th 100.0%
Downloading: "https://dl.fbaipublicfiles.com/encodec/v0/encodec_lm_24khz-1608e3c0.th" to /home/user/checkpoints/encodec_lm_24khz-1608e3c0.th 100.0%
Killed
user@user:~$
I even deleted the checkpoints folder to make sure that this isn't an issue. I've tested with a 16 and 24 bit PCM WAV with mono channel. Using
--hq
and--lm
together works as expected so I believe the 24 kHz is the culprit.Expected behavior
It should not kill the process and result in a properly encoded and decoded file.
Actual Behavior
It kills the process.
Your Environment