You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Python and PyTorch version: Python 3.11.0, PyTorch: 1.13.0
Operating system and version (desktop or mobile): Ubuntu 24.04.01 LTS
Hardware (gpu or cpu, amount of RAM etc.): Virtual machine (AMD 5900X, RTX 3080, 16 GB RAM assigned to the VM)
The text was updated successfully, but these errors were encountered:
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!
馃悰 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
The text was updated successfully, but these errors were encountered: