Teste rápido para taxa de bits de arquivo de áudio

Minha experiência com essas tags é que elas não são aproximadas , estão erradas , especialmente para arquivos MP3 codificados em VBR mais antigos, às vezes, por um fator de 8. Em geral, as coisas não são melhores para o MP4 (que usa praticamente uma taxa de bits variável; mas o "MP4" contém uma grande família de codecs de áudio muito diferentes, com qualidades diferentes na mesma taxa !)

Isso tem a ver com duas coisas:

1. O áudio compactado para armazenamento (não para envio, por exemplo, por uma estação de rádio digital, um telefone ou como faixa de áudio em um vídeo on-line) não precisaser compactado a uma taxa de bits constante – isso simplesmente não faz sentido. Representar o “silêncio” simplesmente precisa de menos bits do que representar um momento complexo em uma música multiinstrumental. Portanto, selecionar uma taxa de bits e segui-la para cada pedaço de áudio simplesmente desperdiçará muito espaço ou soará pior quando você precisar de mais bits do que a média, e será bom em passagens onde você não percebe. Portanto, ter uma taxa de bits constante "sensata" vai parecer ruim. Usar uma taxa de bits constante muito alta é algo que fazíamos muito por volta de 2000, mas ainda parecia ruim – simplesmente porque muitos dos codificadores simplesmente não eram muito bons. Juro que, por volta de 2002, eu sabia distinguir os diferentes codificadores de MP3 que usava para rasgar meus CDs pelos artefatos audíveis – a 160 kbps. Não é bom; estes eram animais cheios de erros.
2. Se, em vez de taxa de bits constante, o codificador foi configurado para qualidade constante, qual taxa de bits você colocará em um cabeçalho? O mínimo ? Não faz sentido se houver alguns milissegundos de silêncio na música. O máximo? Não faz sentido, pode ser apenas o momento em que o baterista bateu no prato de impacto. A média? Faz apenas um pouco mais de sentido, já que algumas músicas são melhores para codificar do que outras, mas supondo que você tenha músicas com volume, gênero, velocidade, qualidade de produção e separação espacial relativamente constantes, em outras palavras, se todas as suas músicas soam iguais: Você poderia obter aproximadamente o mesmo dividindo o tamanho do arquivo em bits pela duração da música. Isso deve ser rápido!

Com isso resolvido: o principal tempo ffprobegasto normalmente é o carregamento e a configuração interna; você pode esconder isso bem usando o GNU do @OleTange 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

Eu tentei, e para mim isso significou uma aceleração de cerca de 400%.

(a jqcadeia no final é puramente opcional, mas fornecerá um documento válido e agradável de trabalhar, mapeando nomes de arquivos para taxas de bits)