Note this is doing exactly the same as what Extension:Score does. We just print whatever stderr gives us. These types of errors are only going to happen due to sysadmin negligence. In that sense, it doesn't seem necessary to show it to the user, but it did help us debug multiple issues when we deployed to the beta cluster! So I kind of wonder if it's okay to leave it as-is? Once things are stable, it's unlikely anyone will ever see these messages, and meanwhile it's kind of helpful to sysadmins of 3rd party wikis who are setting up Phonos for the first time.

Otherwise, not printing the stderr is a trivial change to the code. Instead of Failed to convert audio to MP3: /bin/bash /usr/bin/lame: No such file or directory, it would just say Failed to convert audio to MP3. The relevant messages are here: https://github.com/wikimedia/mediawiki-extensions-Phonos/blob/a9473a9b7fc0cf185cc57d0e046ec48acfb85121/i18n/en.json#L9-L12

Further to what @MusikAnimal mentions above, I definitely agree that it has been incredibly helpful in quickly diagnosing T317128 and T317195 — if these messages didn't include stderr then we'd have to go trawling through logs (admittedly, on the beta cluster/production stderr is fairly easy to check, but you need to know what you're looking for...)

So I kind of wonder if it's okay to leave it as-is? Once things are stable, it's unlikely anyone will ever see these messages, and meanwhile it's kind of helpful to sysadmins of 3rd party wikis who are setting up Phonos for the first time.

Sounds like it's ok to leave as is for now! Going to move this to P2 and we can revisit this one once we have stabilized more! Hope that sounds like a good plan, going to be bold and move it out of backlog

It should not try to convert a free audio file format into an unfree one: T346508.

That is offtopic for this task (and it is not "unfree").