hey @vaporeon_ is there a good way to parallelize the following bash script I'm using to convert FLACs to MP3s?
#!/usr/bin/env bash
find "./${1}" | while read -r file; do
case $(file -b "${file}") in
'FLAC '*)
echo "${file}"
ffmpeg -nostdin -i "${file}" -ab 320k -map_metadata 0 -id3v2_version 3 "${file%flac}mp3" -v 16
;;
*)
;;
esac
done
@vaporeon_ a little searching tells me that audio encoding is typically handled with a single thread
☭
@wallhackio Hm, assuming the audio files are mostly of similar length, does something like this work? I didn't test it, but you get the idea, right?
case $(file -b "${file}") in
'FLAC '*)
echo "${file}"
ffmpeg -nostdin -i "${file}" -ab 320k -map_metadata 0 -id3v2_version 3 "${file%flac}mp3" -v 16 &
i=$(($i+1))
if [ $i -eq `nproc` ] ; then
wait # Wait for all `nproc` jobs to finish
i=0
fi
;;
@wallhackio Initialize i to 0 before starting that entire pipeline, of course
@vaporeon_ for some reason this will quit before finishing all of the files...
@wallhackio Is it the "tail", the last up to nproc-1 files, which are not waited for because the counter never reaches nproc? And you can put another wait at the end of the script to await them. Or is there an error?
@vaporeon_ I'm not getting any errors. I am very conbfused
@wallhackio Screenshot of whatever output you're getting?
@vaporeon_ It was some weird issue with WSL.
If you run bash from a windows terminal, it briefly opens a WSL instance to execute the command. For some reason this closed early
I used a WSL terminal directly instead of running bash from a windows terminal and it works just fine now
@wallhackio Reported for using Microsoft Windows 
@wallhackio this motherfucker typed esac
@wallhackio if you are doing `${file%flac}mp3"´ anyway can¦t you just switch on file extension rather than making a call to `file´?
if it were me i would parallelize this by using GNU Make which has a parallelization option
probably, to get all the functionality you want, creating some default rules to generate a %.mp3 from a %.flac and a fallback match-anything rule that treats its target as a directory (using FORCE) with secondary expansion to set the child files as dependencies from the target name dynamically (i think that works…)
but i¦m sure there is a more sane way
@Lady @wallhackio i think file is fur a recursive directory search? otherwise yeah he overengineered it (and unreliably so at that)
@aescling @wallhackio file is for a recursive directory search but there is no reason why you can¦t call file in a makefile
@aescling @wallhackio *find. find is for that.
file is just for getting the type of the file
@Lady @wallhackio i don't think you can do it in a Makefile in a way that is reliable since files can have newlines in them but 99% of the time it would be fine so whatever
@aescling @wallhackio files cannot have newlines in them that is absurd
they can have spaces in them however,,
@wallhackio @vaporeon_ i would write a makefile that knew how to make mp3s from flacs using this ffmpeg invocation and then tell make to target a particular system load rather than start a fixed number of parallel jobs
@alas @wallhackio Sounds good! My suggestion is extremely flawed if Clodsire e.g. has 50 FLACs that take 1 minute to convert, but 1 FLAC that takes 1 hour to convert, all the other CPU cores will be idling while waiting for the long FLAC...
Very stupid question: How do I tell the Makefile to recursively convert every FLAC to MP3, including any FLACs nested in subdirectories?
@vaporeon_ @wallhackio i don't know particularly complex make patterns off the top of my head lol i would also probably be consulting the manual for this unless i knew where i had something relevant lying around
@wallhackio @vaporeon_ either of my recommendations here would be cursed, either using a Makefile or doing heinous a find(1) invocation like find -name '*.flac' -exec sh -c [...] {} + lol
@wallhackio Does FFmpeg not already use all available CPU cores for converting a file in parallel? I thought FFmpeg did that, at least for videos.
(If not, I can type up something, but first want to confirm that it isn't already being parallel inside FFMPEG)