Audio désynchronisé après récupération — Comment le corriger

Vous avez récupéré un fichier corrompu. La vidéo est lue. L'audio est lu. Mais ils ne sont tout simplement pas synchronisés. Soit l'audio est décalé par rapport à l'image d'une durée fixe (souvent d'environ une demi-seconde), soit il démarre de manière synchronisée et dérive au cours de l'enregistrement.

Cette page explique les deux cas et comment les corriger.

Cas 1 : décalage audio fixe (~0,5 s)

Il s'agit du problème de synchronisation audio le plus courant dans les fichiers MP4/MOV récupérés. L'audio commence environ une demi-seconde avant ou après l'image et reste ainsi pendant tout l'enregistrement.

La cause est presque toujours le positionnement des segments audio lors de la reconstruction. Dans l'entrelacement MOV/MP4, les segments audio sont placés à côté des segments vidéo à l'intérieur de « mdat ». L'emplacement du bloc audio par rapport au bloc vidéo dans chaque groupe est important : placé après le bloc vidéo dans son groupe, l'audio dérive d'environ 0,5 seconde ; placé au début du groupe, la synchronisation est correcte.

Cela concerne en particulier les fichiers Atomos / Ninja / Shogun : ces unités écrivent un modèle spécifique de placement des segments que certains outils de récupération gèrent mal. Nous l'avons appris sur un micrologiciel Ninja V, nous avons effectué un test de régression et nous plaçons désormais les segments audio au début de leur groupe vidéo par défaut.

Solution rapide dans votre éditeur : décalez la piste audio de 0,5 s en avant (ou en arrière, selon le sens du décalage) et la synchronisation se fait généralement automatiquement. Premiere : sélectionnez la piste audio, alt-glisser. Resolve : décalage de la timeline. Le décalage est constant sur l'ensemble du fichier, donc un seul ajustement suffit à le corriger.

Meilleure solution : régénérez la récupération avec un placement corrigé des blocs. Si vous avez utilisé notre service, faites remonter le cas et demandez : il s'agit d'un paramètre unique et la réexécution est gratuite.

Schéma 2 : l'audio dérive au fil du temps

L'audio démarre de manière synchronisée et dérive progressivement. À la 10e minute d'une prise de 30 minutes, il y a un décalage de quelques secondes ; à la 30e minute, le décalage est évident.

Il s'agit d'une inadéquation de la fréquence d'échantillonnage. La fréquence d'échantillonnage réelle de l'audio (par exemple 48 000 Hz) ne correspond pas à la fréquence déclarée dans le conteneur reconstruit (par exemple 44 100 Hz). Le lecteur décode l'audio à la mauvaise vitesse, de sorte que chaque seconde d'audio prend un peu moins ou un peu plus de temps qu'elle ne le devrait, et le décalage augmente.

Cause : lors de la récupération, l'en-tête audio était manquant ou endommagé. L'outil de récupération a deviné une fréquence et s'est trompé.

Solution : réimportez le fichier en spécifiant la fréquence d'échantillonnage correcte. Dans FFmpeg :

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

(Remplacez 48 000 par la fréquence réelle. Vérifiez le menu audio de votre caméra pour confirmer : la plupart des caméras modernes sont réglées par défaut sur 48 kHz ; certaines plus anciennes utilisent 44,1 kHz.)

Si vous avez utilisé notre service, faites remonter le cas et indiquez la fréquence d'échantillonnage correcte ; nous régénérerons le fichier.

Schéma 3 : l'audio est synchronisé aux points de coupe, mais pas entre les deux

Moins courant mais reconnaissable : l'audio est synchronisé au début, synchronisé à la fin, synchronisé à chaque coupure visible, mais dérive dans chaque plan. Cela signifie généralement que l'enregistrement était à fréquence d'images variable (VFR) — la caméra a filmé à une fréquence d'images théorique, mais a en fait écrit les images à des intervalles légèrement variables — et que la récupération a été convertie en fréquence d'images constante (CFR) sans resynchronisation de l'audio.

La plupart des séquences de caméra sont en CFR. Les séquences de téléphone sont l'exception courante : les iPhones et les téléphones Android enregistrent souvent en VFR. Si vous récupérez des séquences de téléphone et que vous constatez ce décalage, c'est pour cette raison.

Solution : réexportez le fichier récupéré en conservant le VFR :

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

Si le problème persiste, les horodatages sous-jacents dans le flux de codec ont été endommagés et la seule solution fiable est de resynchroniser chaque plan dans votre éditeur.

Modèle 4 : l'audio ressemble à du bruit statique

Différent de la synchronisation : l'audio est lu au bon moment, mais ressemble à du bruit blanc. Il s'agit généralement d'un problème d'endianness — le plus souvent avec Atomos et d'autres enregistreurs externes qui écrivent du PCM 24 bits en little-endian. Les outils de récupération génériques qui échangent des octets de manière inconditionnelle produisent du bruit statique ; une récupération correcte détecte l'ordre des octets à partir des données.

Voir '/fix/atomos-ninja-recording-stopped' pour la version spécifique à Atomos.

Comment déterminer le schéma auquel vous êtes confronté

Lisez le fichier et regardez les lèvres :

Comment notre récupération gère ces problèmes

Le passage de la sonde audio détecte :

• Endianness en échantillonnant les données et en vérifiant quelle interprétation a une distribution plausible. Nous n'effectuons pas d'échange, sauf si les données nous le demandent.
• Fréquence d'échantillonnage à partir de la dominance de la taille des blocs — la plupart des blocs ont une taille déterminée par la fréquence réelle ; les valeurs aberrantes sont filtrées.
• La disposition des canaux à partir de l'analyse de corrélation (mono/stéréo/5.1).
• Le positionnement des blocs en fonction du modèle d'écriture de la caméra.

Dans les cas où nous nous trompons sur l'un de ces éléments lors du premier passage, le flux d'escalade vous permet de nous indiquer le symptôme et nous relançons l'analyse avec le bon paramètre. Les réexécutions sont gratuites.

Ce que vous faites

Si votre récupération est effectuée par nos soins :

1. Faites remonter le cas depuis votre page de travail. Dites-nous quel modèle vous voyez.
2. Nous réexécutons avec des paramètres corrigés. Sans frais.

Si votre récupération provient d'ailleurs :

1. Téléchargez le fichier original endommagé. Nous refaisons la récupération avec un traitement audio correct. Aperçu gratuit avant tout paiement.

FAQ

Pourquoi la récupération initiale n'a-t-elle pas correctement synchronisé l'audio ? Pour un fichier propre, la synchronisation audio est sans ambiguïté. Pour un fichier récupéré, les métadonnées qui indiquent au lecteur comment interpréter l'audio sont en partie manquantes : la récupération doit les déduire. Une inférence plus intelligente fait la différence entre les outils.

Mon audio est correct dans certains lecteurs et désynchronisé dans d'autres. Il s'agit très probablement d'un indicateur de métadonnées qu'un lecteur strict (Premiere) interprète, mais qu'un lecteur permissif (VLC) ignore. Remultiplexez avec FFmpeg pour nettoyer les métadonnées.

Pouvez-vous réexporter uniquement l'audio, pas la vidéo ? Oui — faites remonter le cas et demandez. Nous pouvons renvoyer l'audio seul au format WAV / AAC si cela vous est plus utile.

Mes séquences sont-elles en sécurité ? Serveur en France, suppression automatique après 48 heures, jamais utilisées pour entraîner un système ou partagées. Politique de confidentialité.

Connexes

• Enregistrement Atomos Ninja arrêté
• La vidéo est lue, mais il n'y a pas de son
• Comment fonctionne notre moteur de récupération

Téléchargez votre fichier →