Le MP3 ne se lit pas

Un MP3 n'est pas un bloc unique — c'est une séquence de petites trames audio MPEG, chacune d'environ 26 ms de son. Chaque trame commence par un en-tête de 4 octets : l'octet 0 est 0xFF, et les trois bits de poids fort de l'octet 1 complètent la synchronisation de trame de 11 bits (0xFFE…). Le reste de l'en-tête empaquette la version MPEG (MPEG-1, MPEG-2 ou MPEG-2.5), la couche (presque toujours la Couche III), un indice de débit binaire, un indice de fréquence d'échantillonnage et un bit de remplissage. À partir du débit et de la fréquence d'échantillonnage, le décodeur calcule la longueur en octets de la trame — pour la Couche III c'est floor(144 × bitrate ÷ sample_rate) + padding — et l'utilise pour sauter directement à la synchronisation suivante. Certaines combinaisons de bits sont illégales selon la norme : une version réservée, une couche réservée, un indice de débit de 0 (libre) ou 15 (invalide), ou un indice de fréquence d'échantillonnage de 3. Si l'en-tête sur lequel le décodeur atterrit décode vers l'une de ces valeurs, ce n'est pas une véritable limite de trame et le flux se bloque.

Deux choses font le plus souvent dérailler ce saut. La première est une étiquette ID3v2 défectueuse tout au début. Une étiquette ID3v2 commence par les octets ASCII ID3 (0x49 0x44 0x33), un en-tête de 10 octets et une taille syncsafe de 28 bits répartie sur quatre octets (chacun n'apportant que ses 7 bits de poids faible). Si cette taille est incorrecte — souvent parce qu'une pochette d'album intégrée surdimensionnée ou tronquée a corrompu l'étiquette — le lecteur soit se positionne au-delà du début de l'audio réel, soit tente de décoder l'étiquette comme du son. La seconde est le déchet initial : un téléchargement partiel, une page d'erreur HTTP enregistrée par accident sous un nom .mp3, ou un défaut d'ordre des octets qui ajoute des octets avant la première synchronisation. Les fichiers dépourvus de toute étiquette ID3 ne sont qu'une « synchronisation de trame audio MPEG nue » — un signal faible que certains lecteurs ne reconnaissent même pas comme un MP3.

C'est pourquoi les symptômes sont si variés. ffmpeg signale Failed to find two consecutive MPEG audio frames ou Header missing ; mpg123 affiche Illegal Audio-MPEG-Header 0x00000000 et avertit d'un Frankenstein stream lorsque les paramètres de trame changent en cours de fichier ; un élément <audio> du navigateur lève DEMUXER_ERROR_COULD_NOT_OPEN. Tous décrivent la même chose : la chaîne de trames est rompue, pas que la musique a disparu.

La réparation est une resynchronisation structurelle, et elle s'exécute en TypeScript pur dans votre onglet. Elle mesure d'abord toute étiquette ID3v2 initiale à partir de cette taille syncsafe (plus un pied de page de 10 octets lorsque le drapeau de pied de page est activé) et la franchit. Ensuite, elle parcourt le fichier vers l'avant à la recherche d'un motif d'octets qui s'analyse comme un véritable en-tête — 0xFF, les bits de synchronisation 0xE0, une version et une couche non réservées, et un indice de débit et de fréquence d'échantillonnage tous deux dans les limites. Point crucial, un 0xFF 0xEx isolé peut apparaître par hasard au sein des données audio ; un candidat n'est donc accepté que lorsque la longueur de trame qu'il calcule place le lecteur exactement sur une autre synchronisation valide (ou sur la fin du fichier). Cette confirmation à deux trames est ce qui rejette les faux positifs au lieu d'écrire du bruit dans la sortie.

À partir de là, elle avance de trame en trame, en copiant chaque trame confirmée telle quelle dans la sortie. Les octets antérieurs à la première bonne trame sont comptés comme déchet initial et écartés ; un tronçon qui ne s'analyse pas au milieu est traité comme une région de trames corrompues et sauté, afin que le lecteur puisse reprendre la chaîne à la synchronisation propre suivante. Comme chaque trame conservée est copiée octet par octet, il n'y a ni réencodage ni perte de qualité — l'audio survivant est exactement ce que vous avez enregistré. L'outil indique ce qu'il a fait : trames trouvées par rapport aux trames conservées, combien d'octets de déchet initial il a supprimés, et une classe de dégât de clean (une réussite nette) ou resynced (un résultat partiel, où des déchets ou des trames corrompues ont été écartés).

Deux détails méritent d'être connus. Beaucoup de MP3 portent un en-tête Xing/Info (ou VBRI) à l'intérieur de la première trame ; il stocke le nombre total de trames et une table de recherche pour les fichiers à débit variable. Cet en-tête est lui-même une trame MPEG valide, donc la resynchronisation le conserve lorsqu'il survit — et quand ce n'est pas le cas, les lecteurs se rabattent sur l'estimation de la durée à partir du débit (ffmpeg avertit littéralement Estimating duration from bitrate, this may be inaccurate). Une étiquette ID3v1 en fin de fichier — les 128 octets fixes commençant par TAG à la fin du fichier — n'est pas une trame, elle est donc simplement retirée de la queue plutôt que de perturber le décodeur. Rien de tout cela ne touche au réseau : vous pouvez ouvrir l'onglet Réseau et confirmer qu'aucun octet du fichier n'est envoyé.

La resynchronisation n'aide que lorsque de vraies trames MPEG survivent quelque part dans le fichier. Si le balayage ne trouve aucune trame décodable, l'outil s'arrête et le dit honnêtement (un résultat no-frames) au lieu de vous remettre un fichier vide qui fait semblant de fonctionner. Cette issue signifie généralement que les octets ne sont pas du tout de l'audio MPEG : un fichier AAC/.m4a, WMA ou Opus renommé en .mp3, ou une page web enregistrée ou un fragment de téléchargement portant une extension audio. Il n'y a aucun en-tête de trame 0xFFE auquel s'accrocher, et aucune resynchronisation ne peut les inventer.

Elle ne peut pas non plus récupérer un audio qui a été physiquement écrasé ou renvoyé sous forme de zéros par un disque défaillant ou une carte défectueuse — ces trames ne sont pas sur le disque, alors récupérez d'abord les octets bruts au niveau du stockage, puis réparez le fichier. Les pistes protégées par DRM (l'ancien .m4p d'Apple ou l'AAC protégé) ne sont pas des MP3 et ont besoin de leurs clés pour être décodées ; cet outil n'y touchera pas. Et là où une région corrompue a dû être écartée, un bref silence ou clic peut subsister à cet endroit — la réparation copie les bonnes trames sans perte, mais ne synthétise pas les millisecondes manquantes. Ce que vous récupérez de façon fiable, c'est chaque trame qui était intacte, dans l'ordre, dans un conteneur qu'un lecteur ouvrira vraiment.