오디오 스트림 이 ffprobe.pcm_u8, 8000 Hz, mono, u8
현대적인 것으로 트랜스코딩하고 싶습니다.
FFmpeg 기본값을 사용한 트랜스코딩이 실패합니다.
libfaac은 이 출력 형식을 지원하지 않습니다!
따라서 아마도 libfaac은 작동하기 때문에 8kHz를 지원하지 않을 것입니다 -c:a copy.
8kHz 샘플링 속도를 지원하는 인코더는 무엇입니까? 그만큼여기에서 찾은 목록샘플링 속도는 거의 언급하지 않습니다.
설치된 모든 코덱을 시도하는 스크립트를 작성할 수 있습니까?
ffmpeg -codecs | grep EA`
...어떤 것이 작동하는지 직접 확인하려면?
답변1
기본 FFmpeg AAC 인코더( -c:a aac)는 8000Hz 샘플링 속도를 지원합니다.
ffmpeg -h encoder=aac
...
Supported sample rates: 96000 88200 64000 48000 44100 32000 24000 22050 16000 12000 11025 8000 7350
입력과 가장 일치하는 샘플링 속도를 자동으로 선택하므로 다음을 선언할 필요가 없습니다 -ar.
ffmpeg -i input.mov -c:a aac output.m4a
FFmpeg의 어떤 오디오 인코더가 8kHz를 지원합니까?
aac, aptx, aptx_hd, dca, flac, g723_1, libfdk_aac, libmp3lame, libopus, libspeex, libvorbis, real_144, wavpack, 많은 pcm 변형.
아마도 다른 것들도 있을 것입니다. 그러나 보고는 supported_samplerates일관성이 없습니다.
현대적인 것으로 트랜스코딩하고 싶습니다.
libfaac은 수년간 FFmpeg에서 제거되었으며 최신 AAC 인코더로 간주되지 않습니다. 당신은 ffmpeg고대인임에 틀림없습니다. 기본 FFmpeg AAC 인코더를 업데이트하여 사용하거나 libfdk_aac.
가장 현대적인 사용을 원한다면 libopus.
그런데 [aac]를 시도해보니 원본에 비해 파일 크기가 늘어나고 일부 고주파수가 감쇠되는 현상이 나타났습니다.
귀하의 제품이 매우 오래된 것으로 의심되므로 ffmpeg인코더에 대한 주요 품질 업데이트가 누락되었을 가능성이 높습니다 aac. 업그레이드와 품질이 향상될 가능성이 높습니다.
답변2
샘플링 속도와 코덱은 서로 다른 매개변수입니다. 아마도 당신은 다음과 같은 것을 원할 것입니다.
-ar 48000 -c:a aac
8KHz에서 48KHz로 업샘플링하고 AAC로 압축하려면
답변3
8KHz는 '협대역'으로 알려진 음성 표준입니다. 이것이 음성이라면 많은 옵션이 있어야 하지만 기본적으로 FFmpeg에서 지원되는 옵션은 많지 않습니다. 아마도 가장 좋은 옵션은 다음과 같습니다.
- AMR- 넌 할 수 있어libopencode-amrnb를 FFmpeg로 컴파일지원을 위해
- Vorbis CELT 음성 코덱을 사용하는 Opus
그러나 8KHz 8비트 PCM은 처음부터 그다지 좋은 소스는 아닙니다. 대부분의 인코더는 더 나은 입력을 기대/희망합니다. 예를 들어 8비트로 인코딩된 12비트 데이터인 8비트 G.711 mu-law와 같습니다. 부동 소수점. 순수 8비트 PCM 입력은 모델링된 음성 패턴과 맞지 않을 수 있으므로 제대로 작동하지 않을 수 있습니다.
또한 이미 매우 작은 파일이므로 비디오 컨테이너가 더 복잡한 코덱을 지원하지 않을 수도 있습니다. 그래서 나는 이것이 가치 있는 것보다 더 큰 문제라고 생각하고 오디오를 그대로 두겠습니다.
답변4
작일반적으로 사용 가능한 최고의 낮은 비트 전송률 코덱으로 간주됩니다.문제가 없어8kHz 입력 샘플링 속도를 사용합니다. 결과 opus 스트림은 디코더에 편리한 샘플링 속도로 계속 디코딩될 수 있습니다. (다른 손실 코덱과 마찬가지로 FFT를 수행한 후 주파수 대역을 기준으로 압축합니다. 그러나 일부 다른 코덱은 분명히 입력과 동일한 샘플링 속도로만 디코딩하기를 원합니다. 다른 답변에서 알 수 있듯이~할 수 있다입력을 코덱에 제공하기 전에 FFmpeg를 사용하여 입력을 리샘플링해야 하지만 Opus에는 필요하지 않습니다.
노력하다ffmpeg -c:a libopus -b:a 24k -frame_duration 12024kbit/s Opus용.
아마도 시도해 볼 가치가 있을 것입니다. -application voip기본 프로필 대신 "향상된 음성 명료도"를 조정하는 것입니다 audio.
가장 높은 값으로 설정하면 -frame_duration오버헤드가 줄어드는 것 같습니다. 실시간 양방향 음성 채팅이 아닌 파일만 있기 때문에 인코더/디코더 지연 시간은 신경 쓰지 않습니다. 따라서 120ms의 오디오를 버퍼링하고 여러 CELT 또는 SILK 프레임을 함께 묶어 프레임 헤더의 중복성을 줄일 수 있습니다.
사용 가능한 최고의 Opus 인코더는 무료 오픈 소스 libopus(https://opus-codec.org) 최고의 인코더가 비공개 소스인 AAC와 달리 FFmpeg는 이를 사용할 수 있습니다.
Opus에는 매우 낮은 비트 전송률(예: 16kb/s)을 위한 특수 모드가 있어 음성을 감지하고 낮은 비트 전송률에서 SILK(음성별 인코더)로 전환할 수도 있습니다.
Opus의 낮은 비트 전송률 코딩 도구는 HE-AACv2가 수행할 수 있는 것과 유사합니다.위키피디아 기사.
그런데 막상 해보니 원본에 비해 파일 크기가 커졌네요...
손실 압축의 핵심 중 하나는 다음과 같습니다.선택하다출력 비트 전송률, 품질과의 균형. -b:a 32k예를 들어 대부분의 코덱은 32kbit/s의 오디오 비트 전송률을 선택하는 데 사용할 수 있습니다 .
(비디오의 경우 인코딩에 소요된 CPU 시간을 절충할 수도 있습니다(예: -preset Veryslow 및 -preset Medium). 하지만 오디오 압축은 충분히 저렴하므로 대부분의 코덱에는 비트 전송률을 향상시키기 위해 더 많은 CPU 시간을 소비할 수 있는 옵션이 많지 않습니다. 대 품질 절충.)
모노 8비트 8kHz PCM의 비트 전송률은 64kbit/s = 8 * 8000이므로 그보다 낮은 것을 목표로 삼고 그렇지 않으면 원본 파일을 유지하는 것이 좋습니다. PCM은 원시 샘플일 뿐이므로 비트 전송률은 샘플 속도와 샘플 폭의 곱일 뿐입니다. 비트맵 이미지 에 해당하는 오디오와 같습니다 .bmp. 이는 매우 비효율적이며 더 나은 코덱이 발명된 이유입니다. (그리고 청취를 통해 알 수 있듯이 PCM의 비트 전송률을 절약하면 품질과 주파수에 막대한 비용이 발생합니다.범위비트 전송률은 샘플링 속도와 1:1로 묶여 있기 때문입니다. 손실 코덱을 사용하여 주파수 영역에서 양자화하는 경우에는 그렇지 않습니다.)
일부 고주파수는 감쇠되었습니다. 그러니까 그보다 더 나쁜 건
-c:a copy
FFmpeg의 기본 AAC 인코더는 -c:a aac꽤 나빴고 오래된 FFmpeg를 사용하고 있었습니다. https://trac.ffmpeg.org/wiki/Encode/HighQualityAudio2017년 현재 AAC-LC(낮은 복잡도 높은 비트 전송률) aac보다 더 나은 경우가 있다고 합니다. libfdk_aac그러나 HE-AAC는 언급되지 않았으며 이것이 바로 낮은 비트 전송률 AAC에 필요한 것입니다.
libfdk_aac 사용 가능한 최고의 오픈 소스 AAC 인코더였으며 아마도 여전히 HE-AAC용일 것입니다. AFAIK, 둘 다 최고의 무료 AAC 인코더만큼 좋지는 않습니다.
낮은 비트 전송률 AAC의 경우 더 많은 코딩 도구를 추가하는 HE-AAC가 필요합니다.https://en.wikipedia.org/wiki/High-Efficiency_Advanced_Audio_Coding. -c:a aac그렇게 할 수 있는지 잘 모르겠습니다 .
https://trac.ffmpeg.org/wiki/Encode/HighQualityAudio다양한 인코더에 대한 몇 가지 권장 설정과 유용한 비트 전송률 범위를 나열합니다.
하지만 아마도 Opus나 4kbit/s와 같은 비트 전송률을 위한 AMR-NB(협대역)를 원할 것입니다. 몇 살인지 모르겠어요Opus 위키 기사의 품질 대 비트 전송률 도표하지만 8kb/s 미만에서는 Opus보다 더 높은 품질로 AMR-NB를 보여줍니다.
그 적은 비트로 말을 이해할 수는 있지만 소리는 나지 않습니다.멋진. 단지 어떤 코덱이 가장 덜 끔찍한지에 대한 문제일 뿐입니다.