Áudio dessincronizado após a recuperação — Como corrigir

Recuperou um ficheiro corrompido. O vídeo é reproduzido. O áudio é reproduzido. Mas não estão alinhados. Ou o áudio está desfasado da imagem por um valor fixo (muitas vezes cerca de meio segundo), ou começa sincronizado e vai-se desviando ao longo da gravação.

Esta página explica ambos os padrões e como corrigi-los.

Padrão 1: desfasamento fixo do áudio (~0,5 s)

Este é o problema de sincronização de áudio mais comum em ficheiros MP4/MOV recuperados. O áudio começa cerca de meio segundo antes ou depois da imagem e permanece assim durante toda a gravação.

A causa é quase sempre o posicionamento do bloco de áudio durante a reconstrução. Na intercalação MOV/MP4, os blocos de áudio ficam ao lado dos blocos de vídeo dentro de "mdat". Onde o bloco de áudio fica em relação ao bloco de vídeo em cada grupo é importante: colocado depois do bloco de vídeo no seu grupo, o áudio fica ~0,5 segundos atrasado; colocado no início do grupo, a sincronização está correta.

Isto afeta os ficheiros Atomos / Ninja / Shogun em particular — essas unidades escrevem um padrão específico de colocação de blocos que algumas ferramentas de recuperação tratam incorretamente. Aprendemos isso num firmware Ninja V, executámos um teste de regressão e agora colocamos os blocos de áudio no início do seu grupo de vídeo por predefinição.

Correção rápida no seu editor: desloque a faixa de áudio 0,5 s para mais cedo (ou mais tarde, dependendo da direção do desvio) e a sincronização geralmente encaixa. Premiere: selecione a faixa de áudio, alt-arrastar. Resolve: deslocamento da linha do tempo. O desvio é constante em todo o ficheiro, pelo que um único ajuste corrige-o.

Melhor correção: gere novamente a recuperação com o posicionamento corrigido dos blocos. Se utilizou o nosso serviço, encaminhe o caso e peça — é um único parâmetro e a nova execução é gratuita.

Padrão 2: o áudio desvia-se ao longo do tempo

O áudio começa sincronizado e desvia-se progressivamente. Ao minuto 10 de uma tomada de 30 minutos, está alguns segundos desfasado; ao minuto 30, é uma discrepância óbvia.

Isto é uma incompatibilidade da taxa de amostragem. A taxa de amostragem real do áudio (por exemplo, 48 000 Hz) não corresponde à taxa declarada no contentor reconstruído (por exemplo, 44 100 Hz). O reprodutor descodifica o áudio à velocidade errada, pelo que cada segundo de áudio demora um pouco menos ou mais tempo do que deveria, e o desvio aumenta.

Causa: durante a recuperação, o cabeçalho de áudio estava em falta ou danificado. A ferramenta de recuperação adivinhou uma taxa e errou.

Correção: reimporte o ficheiro especificando a taxa de amostragem correta. No FFmpeg:

ffmpeg -i recovered.mp4 -c:v copy -c:a pcm_s24le -ar 48000 corrected.mov

(Substitua 48000 pela taxa real. Verifique o menu de áudio da sua câmara para confirmar — a maioria das câmaras modernas tem 48 kHz como predefinição; algumas mais antigas usam 44,1 kHz.)

Se utilizou o nosso serviço, encaminhe o caso e forneça a taxa de amostragem correta; nós regeneraremos.

Padrão 3: o áudio está sincronizado nos pontos de corte, mas não entre eles

Menos comum, mas reconhecível: o áudio está sincronizado no início, sincronizado no final, sincronizado em cada corte visível, mas desvia dentro de cada plano. Normalmente, significa que a gravação foi feita com taxa de fotogramas variável (VFR) – a câmara filmou a uma taxa de fotogramas nominal, mas na verdade gravou os fotogramas em intervalos ligeiramente variáveis – e a recuperação converteu para taxa de fotogramas constante (CFR) sem ressincronizar o áudio.

A maioria das filmagens de câmara é CFR. As filmagens de telemóvel são a exceção comum: iPhones e telemóveis Android costumam gravar em VFR. Se estiver a recuperar imagens de um telemóvel e a ver este desvio, é por isso.

Solução: reexporte o ficheiro recuperado com o VFR preservado:

ffmpeg -i recovered.mov -c copy -vsync passthrough corrected.mov

Se ainda assim estiver errado, os carimbos de data/hora subjacentes no fluxo do codec foram danificados e a única correção fiável é a ressincronização de cada plano no seu editor.

Padrão 4: o áudio soa como estática

Diferente da sincronização: o áudio é reproduzido no momento certo, mas soa como ruído branco. Isto geralmente é endianness — mais comum com Atomos e outros gravadores externos que gravam PCM de 24 bits em little-endian. As ferramentas de recuperação genéricas que trocam bytes incondicionalmente produzem estática; a recuperação correta deteta a ordem dos bytes a partir dos dados.

Consulte '/fix/atomos-ninja-recording-stopped' para a versão específica da Atomos.

Como descobrir qual o padrão que tem

Reproduza o ficheiro e observe os lábios:

Como a nossa recuperação lida com isto

A passagem da sonda de áudio deteta:

• Endianness por amostragem dos dados e verificação de qual interpretação tem uma distribuição plausível. Não trocamos, a menos que os dados nos digam para o fazer.
• Taxa de amostragem a partir da dominância do tamanho do bloco — a maioria dos blocos tem um tamanho determinado pela taxa real; os valores atípicos são filtrados.
• Disposição dos canais a partir da análise de correlação (mono/estéreo/5.1).
• Posicionamento de blocos com base no padrão de escrita da câmara.

Para os casos em que erramos um destes na primeira passagem, o fluxo de escalonamento permite-lhe indicar-nos o sintoma e nós executamos novamente com o parâmetro correto. Sem custos para as reexecuções.

O que faz

Se a sua recuperação for feita por nós:

1. Encaminhe o caso a partir da sua página de trabalho. Diga-nos qual o padrão que está a ver.
2. Executamos novamente com os parâmetros corrigidos. Sem custos.

Se a sua recuperação for de outro lugar:

1. Carregue o ficheiro original danificado. Vamos refazer a recuperação com o tratamento correto do áudio. Pré-visualização gratuita antes de qualquer pagamento.

FAQ

Porque é que a recuperação original não acertou na sincronização de áudio? Para um ficheiro limpo, a sincronização de áudio é inequívoca. Num ficheiro recuperado, os metadados que dizem ao reprodutor como interpretar o áudio estão parcialmente em falta — a recuperação tem de os inferir. Uma inferência mais inteligente é a diferença entre as ferramentas.

O meu áudio está bom em alguns leitores e dessincronizado noutros. Muito provavelmente, um sinalizador de metadados que um leitor rigoroso (Premiere) interpreta, mas um leitor permissivo (VLC) ignora. Faça um re-mux com o FFmpeg para limpar os metadados.

Podem reexportar apenas o áudio, e não o vídeo? Sim — encaminhe o caso e pergunte. Podemos devolver apenas o áudio em WAV/AAC, se isso for mais útil para si.

As minhas imagens estão seguras? Servidor em França, eliminadas automaticamente após 48 horas, nunca usadas para treinar nada ou partilhadas. Política de privacidade.

Relacionado

• Gravação do Atomos Ninja interrompida
• O vídeo é reproduzido, mas sem áudio
• Como funciona o nosso motor de recuperação

Carregue o seu ficheiro →