enzo1982
--threads option seemingly not working with AppImage
Describe the bug Note: I wasn't sure whether I should submit this issue here or on the BoCA repository, but since the issue occurs with the freaccmd CLI I posted it here.
The --threads option seems to be ignored when running in superfast mode.
To Reproduce Steps to reproduce the behavior:
- Download a large input file (I uploaded the specific file I'm testing with, but it occurs with other large files as well)
- Using the latest release (or continuous build) appimage, run
./freac-continuous-linux-x86_64.AppImage freaccmd --superfast --threads=8 --ignore-chapters --ignore-coverart -o out.opus -e opus audio_stream.aac - Observe CPU usage.
- Run same command but with
--threads=1 - Observe CPU usage being the same as step 3.
- Change
--threadsto any other value and observe CPU usage still staying the same.
This issue occurs at minimum when converting aac -> mp3 and aac -> opus. I have not tested other combinations yet.
Expected behavior
I expected CPU usage to go up since more threads were being used. However, it still stays the same even when removing the --threads arg completely. This means that conversion is also pretty slow with large files.
System (please complete the following information)
- OS: Linux Ubuntu 20.04.03 LTS
- CPU: AMD Ryzen 3600x
- RAM: 64 GB
- Build: AppImage latest
Thank you for reporting this!
The value 1 for the --threads argument actually has a special meaning internally, that the number of threads to use should be determined automatically. This is not handled correctly by freaccmd.
The default number of encoding threads used on your CPU would be 9 (all physical cores + half of the logical ones), which is very close to the 8 threads you were passing in your example. So due to this bug, you will see no real difference between --threads=8 and --threads=1. Other values like --threads=2 should work correctly, though.
I'll change it so that passing --threads=1 will disable multi-threading in freaccmd.
Note another caveat when converting to Opus: As Opus uses a 48 kHz sample rate internally, fre:ac resamples any non 48 kHz input to that rate. The resampler is not multi-threaded, though, so when using --superfast, fre:ac is unlikely to use all threads due to being limited by the resampling speed.
Thank you for the quick fix!
Do I understand correctly that all resampling operations are single-threaded? Converting opus -> mp3 and setting the bitrate to 48kbps seems to be single-threaded as well.
fre:ac's resampling component is single-threaded, yes. That is relevant when converting anything that is not sampled at 48 kHz to Opus as resampling will then be employed.
What you see when converting Opus to 48 kbps MP3 is a different effect. The LAME encoder itself resamples to a lower rate when encoding at such low bitrates in order to achieve better overall quality. This means the sample rate of the resulting MP3 is lower than what fre:ac has initially fed to the encoder and that in turn disables fre:ac's SuperFast algorithm for multi-threaded MP3 encoding. The SuperFast algorithm only works as long as the encoder does not change the sample rate.
Note that I discovered a minor flaw while verifying this. When the "Disable all filtering" option is checked in the LAME encoder configuration (fre:ac GUI only), no resampling occurs, so multi-threading could stay enabled. fre:ac currently still disables multi-threaded encoding in this case. This will be fixed in the next update. It's absolutely not recommended to use the "Disable all filtering" option, though, as it can severely impact sound quality.