Eu tenho medo que o James P esteja enganado, pelo menos tão recentemente quanto o ffmpeg 3.4.2, mas isso é um mal-entendido comum. Infelizmente, este é um erro de longa data na forma como o ffmpeg usa o libmp3lame. Ele define o cabeçalho como Joint Stereo, mas na verdade não codifica em Joint Stereo. Os tocadores de MP3 que exigem o Joint Stereo vão se engasgar com esses arquivos. A opção -joint_stereo 1 NÃO funciona como um parâmetro no ffmpeg. Veja o relatório de erros em aberto: link
Eu uso coxo ou sox para definir arquivos MP3 para estéreo conjunto depois de fazer outras alterações com ffmpeg. Eu gostaria que isso não fosse necessário, especialmente quando se trabalha com arquivos MP3 com perdas, onde cada ação nos arquivos os reduz um pouco, mas não é tão ruim.
No Windows (isso funciona a partir do CMD não PS), por exemplo, aqui está um comando que eu uso freqüentemente para converter em lote e normalizar arquivos WAV para MP3 via ffmpeg e então usar o SoX para definir o Stereo comum (sua saída padrão). Uma das verificações mais fáceis no Windows para estéreo comum ou estéreo é o Mp3tag e certifique-se de exibir a coluna "Modo", que simplesmente diz "estéreo mono", "estéreo" ou "estéreo comum". Esta é também a maneira mais fácil de confirmar que o ffmpeg não é capaz de gerar corretamente o Stereo.
para% x em ("* .wav") do (ffmpeg -i "% x" -ab 320k -f mp3 -af dynaudnorm -id3v2_versão 3 "int_% x.mp3" & sox --norm = - 2,75 "int_% x.mp3" -c2-192 "pronto-% x.mp3")
Eu uso uma taxa de bits mais alta para o arquivo intermediário do que a saída final (320 x 192 neste caso), para minimizar a degradação da qualidade de áudio.
Observe que isso deixará os arquivos intermediários (int *) no mesmo diretório dos arquivos original e final (ready *).