Боюсь, что Джеймс П ошибается, по крайней мере, недавно, как ffmpeg 3.4.2, но это распространенное недоразумение. К сожалению, это давняя ошибка в том, что ffmpeg использует libmp3lame. Он устанавливает заголовок в Joint Stereo, но фактически не кодирует в Joint Stereo. MP3-плееры, которым требуется Joint Stereo, будут задыхаться от этих файлов. Опция -joint_stereo 1 НЕ работает в качестве параметра в ffmpeg. См. Открытый отчет об ошибке: https://trac.ffmpeg.org/ticket/4954.
Я использую lame или sox, чтобы установить MP3-файлы для совместного стерео после внесения других изменений с помощью ffmpeg. Хотелось бы, чтобы в этом не было необходимости, особенно при работе с MP3-файлами с потерями, где каждое действие над файлами немного понижает их, но это не так уж плохо.
Например, в Windows (это работает с CMD, а не с PS), вот команда, которую я часто использую для пакетного преобразования и нормализации из файлов WAV в MP3 через ffmpeg, а затем с помощью SoX задайте для Joint Stereo (вывод по умолчанию). Одна из самых простых проверок в Windows для Joint Stereo или Stereo - это Mp3tag, и обязательно покажите столбец "Mode", который будет просто обозначать Mono, Stereo или Joint Stereo. Это также самый простой способ подтвердить, что ffmpeg не способен правильно выводить данные в Joint Stereo.
для% x in ("* .wav") do (ffmpeg -i "% x" -ab 320k -f mp3 -af dynaudnorm -id3v2_version 3 "int_% x.mp3" & sox --norm = -2.75 "int_% x.mp3 "-c 2 -C 192" готов-% x.mp3 ")
Я использую более высокую скорость передачи битов для промежуточного файла, чем конечный вывод (320 против 192 в данном случае), чтобы минимизировать ухудшение качества звука.
Обратите внимание, что при этом промежуточные файлы (int *) останутся в той же директории, что и исходный и конечный (ready *) файлы.