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

@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)

@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

Follow

@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_ 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

Sign in to participate in the conversation
📟🐱 GlitchCat

A small, community‐oriented Mastodon‐compatible Fediverse (GlitchSoc) instance managed as a joint venture between the cat and KIBI families.