☰

오디오 파일 비트 전송률을 빠르게 테스트하세요

tag-icon • tag-icon shell-script audio ffmpeg
오디오 파일 비트 전송률을 빠르게 테스트하세요

오디오 컬렉션에서 비트 전송률이 높거나 낮은 파일을 식별하기 위해 쉘 스크립트를 사용하려고 합니다. 매우 빠르게 수행할 수 있습니다 file test.mp3.

$time file test.mp3 
test.mp3: Audio file with ID3 version 2.3.0, contains: MPEG ADTS, layer III, v1, 128 kbps, 44.1 kHz, Stereo

real    0m0.027s

그러나 file.m4a 파일의 비트 전송률은 표시되지 않습니다.

$time file test.m4a 
test.m4a: ISO Media, Apple iTunes ALAC/AAC-LC (.M4A) Audio

real    0m0.056s

사용해 보았는데 exiftool적어도 ffprobe10배는 느린 것 같습니다.

$time exiftool test.m4a 
Avg Bitrate                     : 131 kbps

real    0m0.532s

$time ffprobe test.m4a 
  Stream #0:0[0x1](und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 130 kb/s (default)

real    0m0.621s

이는 분당 약 100개 파일에 불과하며 상당히 느립니다. m4a 파일의 비트 전송률을 찾는 더 빠른 방법이 있습니까? 내가 아는 바로는 ffprobe태그 대신 스트림 데이터를 확인하므로 file비트 전송률 값이 빠르면 덜 정확해도 괜찮습니다.

답변1

이 태그에 대한 내 경험으로는 그렇지 않습니다.근사치를 내다, 그들은잘못된, 특히 오래된 VBR로 인코딩된 MP3 파일의 경우 차이가 최대 8배나 될 수 있습니다. 일반적으로 MP4는 그다지 좋지 않습니다(거의 가변 비트 전송률을 사용하지만 "MP4"에는큰가족동일한 속도로 품질이 다른 매우 다양한 오디오 코덱! )

이는 다음 두 가지와 관련이 있습니다.

  1. 압축되어 저장된 오디오(디지털 라디오 방송국, 전화 또는 온라인 비디오의 오디오 트랙으로 전송되지 않음)는필요일정한 비트 전송률로 압축하는 것은 의미가 없습니다. "침묵"을 표현하려면 다중 악기 노래에서 복잡한 순간을 표현하는 것보다 더 적은 비트가 필요합니다. 따라서 오디오의 모든 덩어리에 대해 하나의 비트 전송률을 선택하고 이를 고수하면 평균 비트 전송률보다 더 많은 비트 전송률이 필요할 때 많은 공간을 낭비하거나 사운드가 더 나빠질 것이며 . 따라서 "합리적인" 일정한 비트 전송률을 갖는 것은 좋지 않은 것 같습니다. 우리는 2000년경에 매우 높은 고정 비트 전송률을 사용했는데 여전히 소리가 형편없었습니다. 단지 많은 인코더가 그다지 좋지 않았기 때문입니다. 맹세컨대 2002년경에는 CD를 리핑하는 데 사용했던 다양한 MP3 인코더의 소리를 통해 160kbps로 알 수 있었습니다. 좋지 않습니다. 이들은 오프로드 짐승입니다.
  2. 인코더가 고정 비트 전송률이 아닌 고정 품질로 설정된 경우 헤더에 어떤 비트 전송률을 입력합니까? 가장 낮은? 노래에 1000분의 1초의 침묵이 있다면 그것은 아무 의미가 없습니다. 최대값? 그것은 말이 되지 않습니다. 단지 드러머가 심벌즈를 치는 순간일 수도 있습니다. 평균? 일부 노래는 다른 노래보다 인코딩하기가 더 쉽기 때문에 조금 더 이해가 되지만 노래의 볼륨, 장르, 템포, 제작 품질, 공간 분리가 상대적으로 일정하다고 가정할 때, 즉 모든 음악이 동일하게 들리는 경우 대략적으로 다음과 같은 결과를 얻을 수 있습니다. 파일 크기(비트 단위)를 노래 길이로 나누어도 동일한 결과가 나옵니다. 빨리 해야 합니다!

이것을 제외하십시오. 주요 시간 ffprobe은 일반적으로 로딩 및 내부 설정에 소비됩니다. @OleTange의 GNU를 사용하여 멋지게 숨길 수 있습니다 parallel.

# for bash, whose recursive globbing is off by default
# omit if on zsh
shopt -s globstar nullglob dotglob

# run all ffprobe in parallel.
# GNU parallel takes care of keeping output in correct order
parallel --eta \
  ffprobe \
    -loglevel fatal \
    -output_format json \
    -show_entries format=bit_rate:format=filename \
  ::: **/*.mp4 **/*.mp3 **/*.mpeg **/*.mpc **/*.wma **/*.opus **/*.ogg \
| jq  \
  '.[] | {(.filename): (.bit_rate|tonumber)} ' \
| jq --slurp \
  'reduce .[] as $i ({}; . * $i)' 
> allfiles.json

나는 그것을 시도했고 나에게 그것은 약 400%의 속도 향상을 의미했습니다.

( jq마지막 체인은 완전히 선택 사항이지만 파일 이름을 비트 전송률로 매핑하는 효율적이고 사용하기 쉬운 문서를 제공합니다)

관련 정보