FR3001325A3 - Codeur et decodeur audio avec des metadonnees d'etat de traitement d'intensite sonore - Google Patents

Abstract

L'invention concerne des appareils et procédés pour générer un train de bits audio codé, y compris en incluant des métadonnées d'état de traitement d'intensité sonore (LPSM) en au moins un segment d'une trame du train de bits et des données audio dans au moins un autre segment de la trame, et pour décoder un tel train de bits y compris en extrayant la LPSM et en réalisant typiquement également au moins l'un d'un traitement d'intensité sonore adaptatif des données audio, ou d'une authentification et/ou validation de la LPSM et/ou de données audio à l'aide de la LPSM. Un autre aspect est une unité de traitement audio configurée pour réaliser tout mode de réalisation de la présente invention ou qui comprend une mémoire tampon qui stocke au moins une trame d'un train de bits audio.

Description

CODEUR ET DECODEUR AUDIO AVEC DES METADONNEES D'ETAT DE TRAITEMENT D'INTENSITE SONORE Domaine technique L'invention concerne le traitement de signaux audio, et plus particulièrement le codage et le décodage de trains de bits de données audio avec des métadonnées indiquant l'état de traitement d'intensité sonore du contenu audio. Certains modes de réalisation de l'invention génèrent ou décodent des données audio dans l'un des formats connus sous les noms de Dolby Digital (AC-3), Dolby Digital Plus (AC-3 amélioré ou E- AC-3), ou Dolby E. Contexte de l'invention Dolby, Dolby Digital, Dolby Digital Plus, et Dolby E sont des marques déposées de la Société Dolby Laboratories Licensing Corporation. Dolby Laboratories fournit des mises en oeuvre propriétaires d'AC-3 et EAC-3 connues sous les noms de Dolby Digital et Dolby Digital Plus, respectivement. Les unités de traitement de données audio fonctionnent typiquement à l'aveugle et ne prêtent pas attention aux antécédents de traitement de données audio qui se produisent avant la réception des données. Cela peut fonctionner dans une structure de traitement dans laquelle une entité unique effectue la totalité du traitement et du codage de données audio pour une variété de dispositifs de rendu multimédia cibles tandis qu'un dispositif de rendu multimédia cible effectue tout le décodage et le rendu des données audio codées. Cependant, ce traitement aveugle ne fonctionne pas bien (ou pas du tout) dans des situations où une pluralité d'unités de traitement audio sont éparpillées à travers un réseau différent ou sont placées en tandem (c'est-à-dire en chaîne) et sont supposées effectuer de manière optimale leurs types respectifs de traitement audio. Par exemple, certaines données audio peuvent être encodées pour des systèmes multimédias haute performance et peuvent devoir être converties en une forme réduite appropriée pour un dispositif mobile le long d'une chaîne de traitement multimédia. En conséquence, une unité de traitement audio peut inutilement réaliser un type de traitement sur les données audio qui a déjà été réalisé. Par exemple, une unité de nivellement de volume peut effectuer un traitement sur un clip audio d'entrée, sans se soucier de savoir si le même nivellement de volume ou un nivellement similaire a été réalisé au préalable sur le clip audio d'entrée. En conséquence, l'unité de nivellement de volume peut réaliser un nivellement même lorsqu'il n'est pas nécessaire. Ce traitement inutile peut alors provoquer une dégradation et/ou la suppression de particularités spécifiques pendant le rendu du contenu des données audio.

Un flux typique de données audio inclut à la fois un contenu audio (par exemple, un ou plusieurs canaux de contenu audio) et des métadonnées indiquant au moins une caractéristique du contenu audio. Par exemple, dans un train de bits AC-3 il existe plusieurs paramètres de métadonnées audio qui sont spécifiquement destinés à être utilisés pour changer le son du programme diffusé à un environnement d'écoute. Un des paramètres de métadonnées est le paramètre DIALNORM, qui est destiné à indiquer le niveau moyen de dialogue qui se produit dans un programme audio, et est utilisé pour déterminer le niveau de signaux de reproduction audio. Pendant la reproduction d'un train de bits comprenant une séquence de différents segments de programme audio (ayant chacun un paramètre DIALNORM différent), un décodeur AC-3 utilise le paramètre DIALNORM de chaque segment pour réaliser un type de traitement d'intensité sonore dans lequel il modifie le niveau ou l'intensité sonore de reproduction de telle sorte que l'intensité sonore perçue du dialogue de la séquence de segments est à un niveau constant. Chaque segment audio codé (élément) dans une séquence d'éléments audio codés aurait (en général) un paramètre DIALNORM différent, et le décodeur mettrait à l'échelle le niveau de chacun des éléments de telle sorte que le niveau ou l'intensité sonore de reproduction du dialogue pour chaque élément est identique ou très similaire, bien que ceci pourrait nécessiter l'application de différentes quantités de gains à certains éléments différents des éléments pendant la reproduction.

DIALNORM est typiquement établi par un utilisateur, et n'est pas généré automatiquement, bien qu'il y ait une valeur DIALNORM par défaut si aucune valeur n'est établie par l'utilisateur. Par exemple, un créateur de contenu peut réaliser des mesures d'intensité sonore avec un dispositif externe à un codeur AC-3 puis transférer le résultat (indiquant l'intensité sonore du dialogue parlé d'un programme audio) au codeur pour établir la valeur DIALNORM. Ainsi, il existe une dépendance sur le créateur de contenu pour établir le paramètre DIALNORM correctement.

Il existe plusieurs raisons différentes pour lesquelles le paramètre DIALNORM dans un train de bits AC-3 peut être incorrect. En premier lieu, chaque codeur AC-3 a une valeur DIALNORM par défaut qui est utilisée pendant la génération du train de bits si une valeur DIALNORM n'est pas établie par le créateur de contenu. Cette valeur par défaut peut être sensiblement différente du niveau d'intensité sonore du dialogue réel de l'audio. En deuxième lieu, même si un créateur de contenu mesure l'intensité sonore et établit la valeur DIALNORM en conséquence, un algorithme de mesure d'intensité sonore ou un sonomètre qui n'est pas conforme au procédé de mesure d'intensité sonore AC-3 recommandé peut être utilisé, conduisant à une valeur DIALNORM incorrecte. En troisième lieu, même si un train de bits AC-3 a été créé avec la valeur DIALNORM mesurée et établi correctement par le créateur de contenu, il peut avoir été changé en une valeur incorrecte pendant la transmission et/ou le stockage du train de bits. Par exemple, il n'est pas inhabituel dans des applications de télédiffusion que des trains de bits AC-3 soient décodés, modifiés puis recodés à l'aide d'informations de métadonnées DIALNORM incorrectes. Ainsi, une valeur DIALNORM incluse dans un train de bits AC-3 peut être incorrecte ou imprécise et peut par conséquent avoir un impact négatif sur la qualité de l'expérience d'écoute.

En outre, le paramètre DIALNORM n'indique pas l'état de traitement d'intensité sonore de données audio correspondantes (par exemple quel(s) type(s) de traitement d'intensité sonore a ou ont été réalisé(s) sur les données audio). Jusqu'à la présente invention, un train de bits audio n'incluait pas de métadonnées, indiquant l'état de traitement d'intensité sonore (par exemple, le ou les type(s) de traitement d'intensité sonore appliqué(s) au) le contenu du train de bits audio ou l'état de traitement d'intensité sonore et l'intensité sonore du contenu audio du train de bits, dans un format d'un type décrit dans la présente divulgation. Les métadonnées d'état de traitement d'intensité sonore dans un tel format sont utiles pour faciliter le traitement d'intensité sonore adaptif d'un train de bits audio et/ou la vérification de validité de l'état de traitement d'intensité sonore et l'intensité sonore du contenu audio, de manière particulièrement efficace.

La demande de publication internationale PCT numéro WO 2012/075246 A2, ayant une date de dépôt international au premier décembre 2011 et cédée au cessionnaire de la présente demande, divulgue des procédés et des systèmes pour générer, décoder et traiter des trains de bits audio incluant des métadonnées indiquant l'état de traitement (par exemple, l'état de traitement d'intensité sonore) et des caractéristiques (par exemple l'intensité sonore) de contenu audio. Cette référence décrit également un traitement adaptif du contenu audio des trains de bits à l'aide des métadonnées, et la vérification de validité de l'état de traitement d'intensité sonore et l'intensité sonore de contenu audio des trains de bits à l'aide des métadonnées. Cependant, la référence ne décrit pas l'inclusion dans un train de bits audio de métadonnées (LPSM) indiquant l'état de traitement d'intensité sonore et l'intensité sonore de contenu audio dans un format d'un type décrit dans la présente description. Comme noté, la LPSM dans un tel format est utile pour faciliter le traitement d'intensité sonore adaptif du flux et/ou la vérification de validité de l'état de traitement d'intensité sonore et l'intensité sonore du contenu audio, de manière particulièrement efficace. Bien que la présente invention ne soit pas limitée à une utilisation avec un train de bits AC-3, un train de bits E-AC-3, ou un train de bits Dolby E, pour des raisons pratiques elle sera décrite dans des modes de réalisation dans lesquels elle génère, décode ou sinon traite un train de bits qui inclut des métadonnées d'état de traitement d'intensité sonore. Un train de bits codé AC-3 comprend des métadonnées et un à six canaux de contenu audio. Le contenu audio est une donnée audio qui a été compressée à l'aide d'un codage audio perceptuel. Les métadonnées comprennent plusieurs paramètres de métadonnées audio qui sont destinés à être utilisés pour changer le son d'un programme diffusé à un environnement d'écoute. Des détails d'un codage AC-3 (également connu sous le nom de Dolby Digital) sont bien connus et sont 30 présentés dans de nombreuses références publiées incluant les suivantes : « ATSC Standard A52/A : Digital Audio Compression Standard (AC-3), Révision A », Comité pour l'avancement des systèmes télévisés, 20 août 2001 ; et les brevets US 5 583 962 ; 5 632 005 ; 5 633 981 ; 5 727 119 et 6 021 386. Des détails du codage Dolby Digital Plus (E-AC-3) sont présentés dans « Introduction to Dolby Digital Plus, an Enhancement to the Dolby Digital Coding System », texte de Convention AES 6196, 117e Convention AES, 28 octobre 2004. Des détails du codage Dolby E sont présentés dans « Efficient Bit Allocation, Quantization, and Coding in an Audio Distribution System », prépublication AES 5068, 107e conférence AES, août 1999 et « Professional Audio Coder Optimized for Use with Video », prépublication AES 5033, 107e conférence AES, août 1999. Chaque trame d'un train de bits audio codé AC-3 contient un contenu audio et des métadonnées pour 1 536 échantillons d'audionumérique. Pour une vitesse d'échantillonnage de 48 kHz, ceci représente 32 millisecondes d'audionumérique ou une vitesse de 31,25 trames par seconde d'audio. Chaque trame d'un train de bits audio codé E-AC-3 contient un contenu audio et des métadonnées pour 256, 512, 768 ou 1536 échantillons d'audionumérique, selon que la trame contient un, deux, trois ou six blocs de données audio respectivement. Pour une vitesse d'échantillonnage de 48 kHz, ceci représente 5,333, 10,667, 16 ou 32 millisecondes d'audionumérique respectivement ou une vitesse de 189,9, 93,75, 62,5 ou 31,25 trames par seconde d'audio respectivement.

Comme indiqué sur la figure 4, chaque trame AC-3 est divisée en sections (segments), incluant : une section d'information de synchronisation (SI) qui contient (comme le montre la figure 5) un mot de synchronisation (SW) et le premier de deux mots de correction d'erreur (CRC1) ; une section d'information de train de bits (BSI) qui contient la plupart des métadonnées ; six blocs audio (ABO à AB5) qui contiennent un contenu audio compressé de données (et peuvent également comprendre des métadonnées) ; des bits déchets (W) qui contiennent tous les bits inutilisés restant après compression du contenu audio ; une section d'information auxiliaire (AUX) qui peut contenir plus de métadonnées ; et le second des deux mots de correction d'erreur (CRC2). Comme indiqué sur la figure 7, chaque trame E-AC-3 est divisée en sections (segments), incluant : une section d'information de synchronisation (SI) qui contient (comme le montre la figure 5) un mot de synchronisation (SW) ; une section d'information de train de bits (BSI) qui contient la plupart des métadonnées ; entre un et six blocs audio (ABO à AB5) qui contiennent un contenu audio compressé de données (et qui peuvent également comprendre des métadonnées) ; des bits déchets (W) qui contiennent tous les bits inutilisés restant après compression du contenu audio ; une section d'information auxiliaire (AUX) qui peut contenir plus de métadonnées ; et un mot de correction d'erreur (CRC).

Dans un train de bits AC-3 (ou E-AC-3), il existe plusieurs paramètres de métadonnées audio qui sont spécifiquement destinés à être utilisés pour changer le son du programme diffusé à un environnement d'écoute. Un des paramètres de métadonnées est le paramètre DIALNORM qui est inclus dans le segment BSI.

Comme le montre la figure 6, le segment BSI d'une trame AC-3 inclut un paramètre à cinq bits (« DIALNORM ») indiquant la valeur DIALNORM pour le programme. Un paramètre à cinq bits (« DIALNORM2 ») indiquant la valeur DIALNORM pour un second programme 10 audio porté dans la même trame AC-3 est inclus si le mode de codage audio (« acmod ») de la trame AC-3 est « 0 », indiquant qu'une configuration de double-mono canal ou « 1 + 1 » est utilisée. Le segment BSI comprend également un 15 drapeau (« addbsie ») indiquant la présence (ou l'absence) d'information de train de bits supplémentaire suivant le bit « addbsie », d'un paramètre (« addbsil ») indiquant la longueur de toute information de train de bits supplémentaire suivant la 20 valeur « addbsil », et jusqu'à 64 bits d'information de train de bits supplémentaire (« addbsi ») suivant la valeur « addbsil ». Le segment BSI comprend d'autres valeurs de métadonnées qui ne sont pas spécifiquement montrées sur 25 la figure 6. Brève description de l'invention Dans une classe de modes de réalisation, l'invention est un procédé incluant les étapes de 30 codage de données audio afin de générer un train de bits audio codé, y compris en incluant des métadonnées d'état de traitement d'intensité sonore (LPSM) dans au moins un segment d'au moins une trame du train de bits et des données audio dans au moins un autre segment de la trame. Dans des modes de réalisation typiques, le procédé comprend une étape de multiplexage des données audio avec la LPSM dans chaque trame du train de bits. Dans un décodage typique, le décodeur extrait la LPSM du train de bits (y compris en analysant et démultiplexant la LPSM et les données audio), et traite les données audio afin de générer un flux de données audio décodées (et dans certains cas, réalise également au moins l'un d'un traitement d'intensité sonore adaptatif des données audio, ou d'une authentification et/ou validation de LPSM et/ou de données audio à l'aide de la LPSM). Dans certains cas, les données audio décodées et la LPSM sont acheminées du décodeur à un post-processeur configuré pour réaliser un traitement d'intensité sonore adaptif sur les données audio décodées à l'aide de la LPSM. Le traitement d'intensité sonore adaptatif peut comprendre ou consister en une plage dynamique et/ou une commande d'intensité sonore (par exemple, un nivellement d'intensité sonore de dialogue ou autre nivellement de volume). En réponse à la LPSM, une unité de traitement audio peut désactiver le traitement d'intensité sonore qui a déjà été réalisé (comme indiqué par la LPSM) sur un contenu audio correspondant. Des métadonnées d'état de traitement d'intensité sonore incorporées dans un train de bits audio en 30 conformité avec des modes de réalisation typiques de l'invention peuvent être authentifiées et validées, par exemple, pour permettre à des entités de réglementation d'intensité sonore de vérifier si l'intensité sonore d'un programme particulier se situe déjà dans une plage spécifiée et que les données audio correspondantes elles-mêmes n'ont pas été modifiées (garantissant ainsi une conformité aux réglementations applicables). Une valeur d'intensité sonore incluse dans un bloc de données comprenant les métadonnées d'état de traitement d'intensité sonore peut être lue afin de vérifier ceci, au lieu de calculer à nouveau l'intensité sonore. En réponse à la LPSM, un organisme de réglementation peut déterminer qu'un contenu audio correspondant est en conformité (tel qu'indiqué par la LPSM) avec des exigences réglementaires et/ou statutaires d'intensité sonore (par exemple, les réglementations promulguées sous la loi d'atténuation d'intensité sonore de message publicitaire (Commercial Advertisement Loudness Mitigation Act) également connue sous le nom de loi « CALM ») sans qu'il ne soit nécessaire de calculer 20 l'intensité sonore du contenu audio. Un autre aspect de l'invention est une unité de traitement audio (APU) configurée pour réaliser tout mode de réalisation du procédé de l'invention. Dans une autre classe de modes de réalisation, l'invention est 25 une APU comprenant une mémoire tampon (tampon) qui stocke (par exemple, de manière non transitoire) au moins une trame d'un train de bits audio codé qui a été généré par tout mode de réalisation du procédé de l'invention. Des exemples d'APU comprennent, mais sans 30 s'y limiter, des codeurs (par exemple des transcodeurs), des décodeurs, des codecs, des systèmes de pré- traitement (pré-processeurs), des systèmes de post- traitement (post-processeurs), des systèmes de traitement de train de bits audio, et des combinaisons de ces éléments.

Dans une autre classe de modes de réalisation, l'invention est une unité de traitement audio (APU) configurée pour générer un train de bits audio codé comprenant des segments de données audio et des segments de métadonnées, où les segments de données audio sont indicatifs de données audio, et chacun d'au moins certains des segments de métadonnées inclut des métadonnées d'état de traitement d'intensité sonore (LPSM). Typiquement, au moins un de ces segments de métadonnées dans une trame du train de bits inclut au moins un segment de LPSM indiquant si un premier type de traitement d'intensité sonore a été réalisé sur les données audio de la trame (à savoir, des données audio dans au moins un segment de données audio de la trame), et au moins un autre segment de LPSM indiquant l'intensité sonore d'au moins certaines des données audio de la trame (par exemple, l'intensité sonore de dialogue d'au moins certaines des données audio de la trame qui indiquent un dialogue). Dans un mode de réalisation de cette classe, l'APU est un codeur configure pour coder des données audio afin de générer de l'audio codé, et les segments de données audio incluent l'audio codé. Dans des modes de réalisation typiques de cette classe, chacun des segments de métadonnées a un format préféré à décrire ici.

Dans un format préféré, le train de bits codé est un train de bits AC-3 ou un train de bits E-AC-3, et chacun des segments de métadonnées qui inclut une LPSM est inclus en tant qu'information de train de bits supplémentaire dans le champ « addbsi » du segment d'information de train de bits (« BSI ») d'une trame du train de bits. Chaque segment de métadonnées incluant une LPSM a le format spécifié ici en référence aux tableaux 1 et 2 ci-dessous (à savoir, il inclut les éléments de coeur spécifiés dans le tableau 1 ou une variation de ceux-ci, suivis d'un identifiant de charge utile (identifiant les métadonnées en tant que LPSM) et des valeurs de taille de charge utile, suivies de la charge utile (données LPSM qui ont un format comme indiqué dans le tableau 2, ou un format comme indiqué dans une variation du tableau 2 décrit ici).

Dans un autre format préféré, le train de bits codé est un train de bits AC-3 ou un train de bits EAC-3, et chacun des segments de métadonnées qui inclut une LPSM est inclus dans un champ « addbsi » du segment d'information de train de bits (« BSI ») d'une trame de train de bits, ou dans un champ de données auxiliaires (par exemple, le segment AUX montré sur la figure 4) à la fin d'une trame du train de bits. Une trame peut inclure un ou deux segments de métadonnées, chacun desquels inclut une LPSM, et si la trame inclut deux segments de métadonnées, l'un est présent dans le champ addbsi de la trame et l'autre dans le champ AUX de la trame. Chaque segment de métadonnées incluant une LPSM a le format spécifié ici en référence aux tableaux 1 et 2 ci-dessous (à savoir, il inclut les éléments de coeur spécifiés dans le tableau 1 ou une variation de ceux-ci, suivis d'un identifiant de charge utile (identifiant les métadonnées en tant que LPSM) et des valeurs de taille de charge utile, suivies par la charge utile (données de LPSM qui ont un format tel qu'indiqué dans le tableau 2, ou un format tel qu'indiqué dans une variation du tableau 2 décrit ici). Dans un autre format préféré, le train de bits codé est un train de bits qui n'est ni un train de bits AC-3, ni un train de bits E-AC-3, et chacun des segments de métadonnées qui inclut une LPSM est inclus dans un segment (ou champ ou fente) du train de bits réservé pour le stockage de données supplémentaires. Chaque segment de métadonnées incluant une LPSM peut avoir un format similaire ou identique à celui spécifié ici en référence aux tableaux 1 et 2 ci-dessous (à savoir, il inclut des éléments de coeur similaires ou identiques à ceux spécifiés dans le tableau 1, suivis d'un identifiant de charge utile (identifiant les métadonnées en tant que LPSM) et des valeurs de taille de charge utile, suivies de la charge utile (données LPSM qui ont un format similaire ou identique au format indiqué dans le tableau 2 ou une variation du tableau 2 décrit ici). Dans certains modes de réalisation, le train de bits codé comprend une séquence de trames, chacune des trames inclut un segment d'information de train de bits (« BSI ») incluant un champ « addbsi » (parfois désigné par segment ou fente), et un champ ou une fente de données auxiliaires (par exemple, le train de bits codé est un train de bits AC-3 ou un train de bits E- AC-3), et comprend des segments de données audio (par exemple, les segments ABO à AB5 de la trame montrée sur la figure 4) et des segments de métadonnées, où les segments de données audio sont indicatifs de données audio, et chacun d'au moins certains des segments de métadonnées inclut des métadonnées d'état de traitement d'intensité sonore (LPSM). Les LPSM sont présentes dans le train de bits dans le format suivant. Chacun des segments de métadonnées qui inclut une LPSM est inclus dans un champ « addbsi » du segment BSI d'une trame du train de bits, ou dans un champ de données auxiliaires d'une trame du train de bits. Une trame du train de bits peut inclure un ou deux segments de métadonnées, dont chacun inclut une LPSM, et si la trame inclut deux segments de métadonnées, l'un est présent dans le champ addbsi de la trame et l'autre dans le champ AUX de la trame. Chaque segment de métadonnées incluant une LPSM inclut un segment de charge utile (ou contenant) de LPSM ayant le format suivant : un en-tête (incluant typiquement au moins une valeur d'identification, par exemple, la version de format LPSM, la longueur, la période, le décompte et des valeurs d'association de sous-flux indiquées dans le tableau 2 ci-dessous) ; et après l'en-tête, au moins une valeur d'indication de dialogue (par 25 exemple, un paramètre « canal ou canaux de dialogue » du tableau 2) indiquant si les données audio correspondantes indiquent un dialogue ou n'indiquent pas de dialogue (par exemple, quels canaux de données audio correspondantes indiquent un dialogue). La ou les 30 valeurs d'indication de dialogue peuvent indiquer si un dialogue est présent dans toute combinaison, ou dans la totalité des canaux des données audio correspondantes ; au moins une valeur de conformité de réglementation d'intensité sonore (par exemple, un 5 paramètre « type de réglementation d'intensité sonore » du tableau 2) indiquant si les données audio correspondantes sont conformes à un ensemble indiqué de réglementations d'intensité sonore ; au moins une valeur de traitement d'intensité 10 sonore (par exemple, un ou plusieurs des paramètres « drapeau de correction d'intensité sonore à déclenchement de dialogue », « type de correction d'intensité sonore » du tableau 2 indiquant au moins un type de traitement d'intensité sonore qui a été réalisé 15 sur les données audio correspondantes ; et au moins une valeur d'intensité sonore (par exemple, un ou plusieurs des paramètres « Intensité sonore à déclenchement relatif de l'UIT », « Intensité sonore déclenchement de parole de l'UIT », 20 « Intensité sonore 3s à court terme de l'UIT (EBU 3341) », et « crête véritable » du tableau 2) indiquant au moins une intensité sonore (par exemple, une crête d'intensité sonore ou une intensité sonore moyenne) caractéristique des données audio 25 correspondantes. Dans tout mode de réalisation de l'invention qui considère, utilise ou génère au moins une valeur d'intensité sonore indicative de données audio correspondantes, la ou les valeurs d'intensité sonore 30 peuvent indiquer au moins une mesure d'intensité sonore caractéristique utilisée pour traiter l'intensité sonore et/ou la plage dynamique des données audio. Dans certaines mises en oeuvre, chacun des segments de métadonnées dans un champ « addbsi » ou un champ de 5 données auxiliaires d'une trame du train de bits a le format suivant : en-tête de coeur (incluant typiquement un mot de synchronisation identifiant le début du segment de métadonnées, suivi de valeurs d'identification, par 10 exemple, la version d'élément de coeur, la longueur et la période, le décompte d'élément étendu, et des valeurs d'association de sous-flux indiquées dans le tableau 1 ci-dessous) ; et après l'en-tête de coeur, au moins une valeur de 15 protection (par exemple, un condensé HMAC et des valeurs d'empreintes digitales audio, où le condensé HMAC peut être un condensé HMAC à 256 bits (utilisant un algorithme SHA-2) calculé sur les données audio, l'élément de coeur, et tous les éléments étendus, d'une 20 trame entière, tel qu'indiqué dans le tableau 1) utile pour au moins l'un d'un déchiffrement, d'une authentification ou d'une validation d'au moins l'une de métadonnées d'état de traitement d'intensité sonore ou des données audio correspondantes) ; et 25 également après l'en-tête de coeur, si le segment de métadonnées inclut une LPSM, des valeurs d'identification (« ID ») de charge utile LPSM et de taille de charge utile LPSM qui identifient des métadonnées suivantes en tant que charge utile LPSM et 30 indiquent la taille de la charge utile LPSM, le segment de charge utile LPSM (ayant de préférence le format spécifié ci-dessus) suit les valeurs d'identification de charge utile LPSM et de taille de charge utile LPSM. Dans certains modes de réalisation du type décrit dans le paragraphe précédent, chacun des segments de 5 métadonnées dans le champ de données auxiliaires (ou champ « addbsi ») de la trame a trois niveaux de structure : une structure de niveau élevé, incluant un drapeau indiquant si le champ de données auxiliaires (ou addbsi) 10 inclut des métadonnées, au moins une valeur d'identification indiquant quel(s) type(s) de métadonnées sont présents, et typiquement également une valeur indiquant combien de bits de métadonnées (par exemple, de chaque type) sont présents (si des 15 métadonnées sont présentes). Un type de métadonnées qui pourrait être présent est la LSPM, et un autre type de métadonnées qui pourrait être présent est les métadonnées de recherche multimédia (par exemple, métadonnées de recherche multimédia de Nielsen) ; 20 une structure de niveau intermédiaire, comprenant un élément de coeur pour chaque type identifié de métadonnées (par exemple, en-tête de coeur, valeurs de protection, et valeurs d'identification de charge utile et de taille de charge utile, par exemple, du type 25 mentionné ci-dessus, pour chaque type identifié de métadonnées) ; et une structure de niveau bas, comprenant chaque charge utile pour un élément de coeur (par exemple, une charge utile LPSM, si l'élément de coeur en identifie 30 une comme étant présente, et/ou une charge utile de métadonnées d'un autre type, si l'élément de coeur en identifie une comme étant présente). Les valeurs de données dans une telle structure à trois niveaux peuvent être emboîtées. Par exemple, la ou les valeur(s) de protection pour une charge utile LPSM et/ou une autre charge utile de métadonnées identifiée par un élément de coeur peuvent être incluses après chaque charge utile identifiée par l'élément de coeur (et ainsi après l'en-tête de coeur de l'élément de coeur). Dans un exemple, un en-tête de coeur pourrait identifier une charge utile de LPSM et une autre charge utile de métadonnées, des valeurs d'identification de charge utile et de taille de charge utile pour la première charge utile (par exemple, la charge utile LPSM) pourraient suivre l'en-tête de coeur, la première charge utile elle-même pourrait suivre les valeurs d'identification et de taille, la valeur d'identification de charge utile et de taille de charge utile pour la seconde charge utile pourrait suivre la première charge utile, la seconde charge utile elle-même pourrait suivre ces valeurs d'identification et de taille, et une ou des valeur(s) de protection pour l'une ou l'autre des charges utiles ou les deux (ou pour des valeurs d'élément de coeur et l'une ou l'autre des charges utiles ou les deux) pourraient suivre la dernière charge utile. Dans certains modes de réalisation, l'élément de coeur d'un segment de métadonnées dans un champ de données auxiliaires (ou champ « addbsi ») d'une trame comprend un en-tête de coeur (incluant typiquement des valeurs d'identification, par exemple, une version d'élément de coeur), et après l'en-tête de coeur : des valeurs indiquant si les données d'empreintes digitales sont incluses pour les métadonnées du segment de métadonnées, des valeurs indiquant si les données externes (liées aux données audio correspondant aux métadonnées du segment de métadonnées) existent, des valeurs d'identification de charge utile et de taille de charge utile pour chaque type de métadonnées (par exemple, LPSM, et/ou métadonnées d'un type autre que la LPSM) identifiées par l'élément de coeur, et des valeurs de protection pour au moins un type de métadonnées identifiées par l'élément de coeur. La ou les charge(s) utile(s) de métadonnées du segment de métadonnées suivent l'en-tête de coeur, et sont (dans certains cas) emboîtées à l'intérieur des valeurs de l'élément de coeur. Dans un autre format préféré, le train de bits codé est un train de bits Dolby E, et chacun des segments de métadonnées qui inclut une LPSM est inclus dans les N premiers emplacements d'échantillon de l'intervalle de bande de garde Dolby E. Dans une autre classe de modes de réalisation, l'invention est une APU (par exemple, un décodeur) couplée et configurée pour recevoir un train de bits audio codé comprenant des segments de données audio et des segments de métadonnées, où les segments de données audio sont indicatifs de données audio, et chacun d'au moins certains des segments de métadonnées inclut des métadonnées d'état de traitement d'intensité sonore (LPSM), et pour extraire la LPSM du train de 30 bits, pour générer des données audio décodées en réponse aux données audio et pour réaliser au moins une opération de traitement d'intensité sonore adaptatif sur les données audio à l'aide de la LPSM. Certains modes de réalisation de cette classe incluent également un post-processeur couplé à l'APU, où le post- processeur est couplé et configuré pour réaliser au moins une opération de traitement d'intensité sonore adaptatif sur les données audio à l'aide de la LPSM. Dans une autre classe de modes de réalisation, l'invention est une unité de traitement audio (APU) incluant une mémoire tampon (tampon) et un sous-système de traitement couplé au tampon, où l'APU est couplée pour recevoir un train de bits audio codé comprenant des segments de données audio et des segments de métadonnées, où les segments de données audio sont indicatifs de données audio, et chacun d'au moins certains des segments de métadonnées inclut des métadonnées d'état de traitement d'intensité sonore (LPSM), le tampon stocke (par exemple, de manière non transitoire) au moins une trame du train de bits audio codé, et le sous-système de traitement est configuré pour extraire la LPSM du train de bits et pour réaliser au moins une opération de traitement d'intensité sonore adaptatif sur les données audio à l'aide de la LPSM. Dans des modes de réalisation typiques de cette classe, l'APU est l'un d'un codeur, d'un décodeur, et d'un post-processeur. Dans certaines mises en oeuvre du procédé de l'invention, le train de bits audio généré est l'un d'un train de bits codé AC-3, d'un train de bits E-AC-3 ou d'un train de bits Dolby E, incluant des métadonnées d'état de traitement d'intensité sonore, ainsi que d'autres métadonnées (par exemple, un paramètre de métadonnées DIALNORM, des paramètres de métadonnées de commande de plage dynamique, et d'autres paramètres de métadonnées). Dans certaines autres mises en oeuvre du procédé, le train de bits audio généré est un train de bits codé d'un autre type. Des aspects de l'invention incluent un système ou dispositif configuré (par exemple, programmé) pour réaliser tout mode de réalisation du procédé de l'invention, et un support lisible par ordinateur (par exemple, un disque) qui stocke un code (par exemple, dans un mode non transitoire) pour mettre en oeuvre tout mode de réalisation du procédé de l'invention ou des étapes de celui-ci. Par exemple, le système de l'invention peut être ou inclut un processeur universel programmable, un processeur de signaux numériques, ou un microprocesseur, programmé avec un logiciel ou un micrologiciel et/ou sinon configuré pour réaliser l'une quelconque d'une variété d'opérations sur des données, incluant un mode de réalisation du procédé de l'invention ou des étapes de celui-ci. Un tel processeur universel peut être ou inclut un système d'informatique incluant un dispositif d'entrée, une mémoire et une circuiterie de traitement programmée (et/ou sinon configurée) pour réaliser un mode de réalisation du procédé de l'invention (ou des étapes de celui-ci) en réponse à des données qui y sont affirmées. L'invention concerne un appareil de traitement 30 audio, caractérisé en ce qu'il comprend : une mémoire tampon d'entrée pour stocker au moins une trame d'un train de bits audio codé comprenant une LPSM et des données audio ; un analyseur couplé à la mémoire tampon d'entrée 5 pour extraire le train de bits audio codé et/ou la LPSM ; un décodeur AC-3 ou E-AC-3 couplé à l'analyseur pour générer un flux de données audio décodées ; et une mémoire tampon de sortie couplée au décodeur 10 pour stocker les données audio décodées. Avantageusement, l'appareil de traitement audio comprend en outre un processeur d'intensité sonore couplé au décodeur AC-3 ou E-AC-3 pour réaliser un traitement d'intensité sonore adaptatif du flux de 15 données audio décodées à l'aide de la LPSM. Avantageusement, l'appareil de traitement audio comprend en outre un validateur d'état audio couplé au décodeur AC-3 ou E-AC-3 pour authentifier et/ou valider la LPSM et/ou le flux de données audio décodées à 20 l'aide de la LPSM, dans lequel le validateur d'état audio est en outre couplé au processeur d'intensité sonore pour commander le traitement d'intensité sonore adaptatif du processeur d'intensité sonore. 25 Avantageusement, l'appareil de traitement audio comprend en outre un post-processeur couplé au décodeur AC-3 ou E-AC-3 pour réaliser un traitement d'intensité sonore adaptif sur le flux de données audio décodées à l'aide de la LPSM. 30 Avantageusement l'appareil de traitement audio comprend en outre un validateur d'état audio couplé au décodeur AC-3 ou E-AC-3, pour authentifier et/ou valider la LPSM et/ou le flux de données audio décodées à l'aide de la LPSM, dans lequel le validateur d'état audio est en 5 outre couplé au processeur d'intensité sonore et au post-processeur pour commander le traitement d'intensité sonore adaptatif du processeur d'intensité sonore et du post-processeur. Avantageusement, la LPSM est un contenant d'une ou 10 plusieurs métadonnées d'état de traitement d'intensité sonore situé après un en-tête dans l'au moins une trame. Avantageusement, la LPSM comprend une fente de type régulation d'intensité sonore. Avantageusement, la LPSM comprend une fente de 15 type correction d'intensité sonore. Brève description des dessins La figure 1 est un schéma de principe d'un mode de réalisation d'un système qui peut être configuré pour 20 réaliser un mode de réalisation du procédé de l'invention ; la figure 2 est un schéma de principe d'un codeur qui est un mode de réalisation de l'unité de traitement audio de l'invention ; 25 la figure 3 est un schéma de principe d'un décodeur qui est un mode de réalisation de l'unité de traitement audio de l'invention, et d'un post-processeur couplé à celle-ci qui est un autre mode de réalisation de l'unité de traitement audio de 30 l'invention ; la figure 4 est un diagramme d'une trame AC-3, incluant les segments dans lesquels elle est divisée ; la figure 5 est un diagramme du segment d'information de synchronisation (SI) d'une trame AC-3, 5 incluant des segments dans lesquels elle est divisée ; la figure 6 est un diagramme d'un segment d'information de train de bits (BSI) d'une trame AC-3, incluant des segments dans lesquels elle est divisée ; la figure 7 est un diagramme d'une trame E-AC-3, 10 incluant des segments dans lesquels elle est divisée. Notation et Nomenclature Tout au long de cette divulgation, y compris dans les revendications, l'expression réaliser une opération 15 « sur » un signal ou des données (par exemple, filtrage, mise à l'échelle, transformation, ou application d'un gain au signal ou aux données) est utilisée dans un sens large pour indiquer la réalisation de l'opération directement sur le signal ou les données, ou sur une 20 version traitée du signal ou des données (par exemple, sur une version du signal qui a subi un filtrage ou pré-traitement préliminaire préalablement à la réalisation de l'opération sur celui-ci). Tout au long de cette divulgation, y compris dans 25 les revendications, l'expression « système » est utilisée dans un sens large pour indiquer un dispositif, système ou sous-système. Par exemple, un sous-système qui met en oeuvre un décodeur peut être désigné comme système de décodeur, et un système incluant un tel 30 sous-système (par exemple, un système qui génère X signaux de sortie en réponse à de multiples entrées, dans lequel le sous-système génère M des entrées et les autres entrées X à M sont reçus depuis une source externe) peut également être désigné en tant que système de décodeur.

Tout au long de cette divulgation, y compris dans les revendications, le terme « processeur » est utilisé dans un sens large pour indiquer un système ou dispositif programmable ou sinon configurable (par exemple, avec un logiciel ou un micrologiciel) pour réaliser les opérations sur des données (par exemple, des données audio, ou vidéo ou d'autres données d'images). Les exemples de processeurs incluent un réseau pré-diffusé programmable par l'utilisateur (ou un autre circuit intégré configurable ou jeu de puce), un processeur de signaux numériques programmé et/ou sinon configuré pour réaliser un traitement pipeline sur des données audio ou autres données sonores, un processeur ou ordinateur universel programmable, et une puce ou un jeu de puce de microprocesseur programmable.

Tout au long de cette divulgation y compris dans les revendications, les expressions « processeur audio » et « unité de traitement audio » sont utilisées de manière interchangeable, et dans un sens large, pour signifier un système configuré pour traiter des données audio. Des exemples d'unités de traitement audio incluent, mais sans s'y limiter des codeurs (par exemple, les transcodeurs), des décodeurs, des codecs, des systèmes de pré-traitement, des systèmes de post-traitement, et des systèmes de traitement de train de bits (parfois désignés par outils de traitement de train de bits).

Tout au long de cette divulgation, y compris dans les revendications, l'expression « métadonnées d'état de traitement » (par exemple, comme dans l'expression « métadonnées d'état de traitement d'intensité sonore ») se réfère à des données séparées et différentes de données audio correspondantes (le contenu audio d'un flux de données audio qui inclut également des métadonnées d'état de traitement). Les métadonnées d'état de traitement sont associées à des données audio, indiquent l'état de traitement d'intensité sonore des données audio correspondantes (par exemple, quel(s) type(s) de traitement ont déjà été réalisés sur les données audio), et indiquent également typiquement au moins une particularité ou caractéristique des données audio. L'association des métadonnées d'état de traitement avec les données audio est synchrone dans le temps. Ainsi, les métadonnées d'état de traitement (reçues ou mises à jour le plus récemment) indiquent que les données audio correspondantes comprennent de façon simultanée les résultats du ou des type(s) indiqué(s) de traitement de données audio. Dans certains cas, les métadonnées d'état de traitement peuvent comprendre des antécédents de traitement et/ou certains ou la totalité des paramètres qui sont utilisés dans et/ou dérivés des types indiqués de traitement. De plus, les métadonnées d'état de traitement peuvent comprendre au moins une particularité ou caractéristique des données audio correspondantes, qui a été calculée ou extraite des données audio. Les métadonnées d'état de traitement peuvent également inclure d'autres métadonnées qui ne sont pas liées à ou dérivées de tout traitement des données audio correspondantes. Par exemple, des données tierces, des informations de suivi, des identifiants, des informations propriétaires ou type, des informations d'annotation utilisateur, des données de préférence utilisateur, etc. peuvent être ajoutés par une unité de traitement audio particulière afin d'être acheminées à d'autres unités de traitement audio. Tout au long de cette divulgation, y compris dans 10 les revendications, l'expression « métadonnées d'état de traitement d'intensité sonore » (ou « LPSM ») signifie des métadonnées d'état de traitement indicatives de l'état de traitement d'intensité sonore des données audio correspondantes (par exemple quel(s) 15 type(s) de traitements d'intensité sonore ont été réalisés sur les données audio) et typiquement également au moins une particularité ou caractéristique (par exemple, l'intensité sonore) des données audio correspondantes. Les métadonnées d'état 20 de traitement d'intensité sonore peuvent inclure des données (par exemple, d'autres métadonnées) qui ne sont pas (c'est-à-dire, lorsqu'elles sont considérées seules) des métadonnées d'état de traitement d'intensité sonore. Tout au long de cette divulgation, y compris dans 25 les revendications, les termes « couple » ou « couplé » sont utilisés pour indiquer une connexion directe ou indirecte. Ainsi, si un premier dispositif se couple à un second dispositif, cette connexion peut se faire par l'intermédiaire d'une connexion directe, ou par 30 l'intermédiaire d'une connexion indirecte via d'autres dispositifs et connexions.

Description détaillée des modes de réalisation de l'invention En conformité avec des modes de réalisation typiques de l'invention, des métadonnées d'état de traitement d'intensité sonore (LPSM) sont incorporées dans un ou plusieurs champs réservés (ou fentes) de segments de métadonnées d'un train de bits audio qui inclut également des données audio dans d'autres segments (segments de données audio). Typiquement, au moins un segment de chaque trame du train de bits inclut une LPSM, et au moins un autre segment de la trame inclut des données audio correspondantes (c'est-à-dire, les données audio dont l'état de traitement d'intensité sonore et l'intensité sonore sont indiqués par la LPSM). Dans certains modes de réalisation, le volume de données de la LPSM peut être suffisamment petit pour être transporté sans affecter le débit binaire alloué pour transporter les données audio.

La communication de métadonnées d'état de traitement d'intensité sonore dans une chaîne de traitement de données audio est particulièrement utile lorsque deux unités de traitement audio ou plus doivent travailler en tandem l'une avec l'autre à travers la chaîne de traitement (ou le cycle de vie du contenu). Sans l'inclusion de métadonnées d'état de traitement d'intensité sonore dans un train de bits audio, de graves problèmes de traitement multimédia tels que des dégradations spatiales, de niveau et de qualité peuvent se produire, par exemple, lorsque deux codecs audio ou plus sont utilisés dans la chaîne et qu'un nivellement de volume asymétrique est appliqué plus d'une fois pendant le trajet d'un train de bits dans un dispositif de consommation multimédia (ou un point de rendu du contenu audio du train de bits).

La figure 1 est un schéma de principe d'un exemple de chaîne de traitement audio (un système de traitement de données audio) dans laquelle un ou plusieurs des éléments du système peuvent être configurés en conformité avec un mode de réalisation de la présente invention. Le système inclut les éléments suivants, couplés ensemble comme montré : une unité de pré-traitement, un codeur, une unité de correction de métadonnées et d'analyse de signaux, un transcodeur, un décodeur, et une unité de pré-traitement. Dans des variations du système montré, un ou plusieurs des éléments sont omis, ou des unités de traitement de données supplémentaires sont incluses. Dans certaines mises en oeuvre, l'unité de pré-traitement de la figure 1 est configurée pour accepter des échantillons PCM (domaine temporel) comprenant un contenu audio en tant qu'entrée, et pour produire en sortie les échantillons PCM traités. Le codeur peut être configuré pour accepter les échantillons PCM en tant qu'entrée et pour produire en sortie un train de bits audio codé (par exemple, compressé) indicatif du contenu audio. Les données du train de bits qui sont indicatives du contenu audio sont parfois désignées ici par « données audio ». Si le codeur est configuré en conformité avec un mode de réalisation typique de la présente invention, la sortie de train de bits audio du codeur inclut des métadonnées d'état de traitement d'intensité sonore (et typiquement également d'autres métadonnées) ainsi que des données audio. L'unité de correction de métadonnées et d'analyse de signaux de la figure 1 peut accepter un ou plusieurs trains de bits audio codés en tant qu'entrée et déterminer (par exemple, valider) si les métadonnées d'état de traitement dans chaque train de bits audio codé sont correctes, en réalisant une analyse de signaux. Si l'unité de correction de métadonnées et d'analyse de signaux trouve que des métadonnées incluses sont invalides, elle remplace typiquement la ou les valeur(s) incorrecte(s) par la ou les valeur(s) correcte(s) obtenue(s) à partir de l'analyse de signaux. Ainsi, chaque train de bits audio codé produit en sortie par l'unité de correction de métadonnées et d'analyse de signaux peut inclure des métadonnées d'état de traitement corrigées (ou non corrigées) ainsi que des données audio encodées. Le transcodeur de la figure 1 peut accepter des trains de bits audio codés comme entrée, et des trains de bits audio modifiés en sortie (par exemple, codés différemment) en réponse (par exemple en décodant un flux d'entrée et en recodant le flux décodé dans un format de codage différent). Si le transcodeur est configuré en conformité avec un mode de réalisation type de la présente invention, le train de bits audio produit en sortie par le transcodeur inclut des métadonnées d'état de traitement d'intensité sonore (et typiquement également d'autres métadonnées) ainsi que des données audio codées. Les métadonnées peuvent avoir été incluses dans le train de bits.

Le décodeur de la figure 1 peut accepter des trains de bits audio codés (par exemple, compressés) en tant qu'entrée, et des flux de sortie (en réponse) d'échantillons audio PCM décodés. Si le décodeur est configuré en conformité avec un mode de réalisation typique de la présente invention, la sortie du décodeur en fonctionnement typique est ou comprend l'un quelconque des éléments suivants : un flux d'échantillons audio, et un flux correspondant de métadonnées d'état de traitement d'intensité sonore (et typiquement également d'autres métadonnées) extraites d'un train de bits codé d'entrée ; ou un flux d'échantillons audio, et un flux correspondant de bits de commande déterminé à partir des métadonnées d'état de traitement d'intensité sonore (et typiquement également d'autres métadonnées) extraites d'un train de bits codé d'entrée ; ou un flux d'échantillons audio, sans flux correspondant de métadonnées d'état de traitement ou de bits de commande déterminé à partir de métadonnées d'état de traitement. Dans ce dernier cas, le décodeur peut extraire des métadonnées d'état de traitement d'intensité sonore (et/ou d'autres métadonnées) à partir du train de bits codé d'entrée et réaliser au moins une opération sur les métadonnées extraites (par exemple, une validation), même s'il ne produit pas en sortie les métadonnées extraites ou des bits de commande déterminés à partir de celles-ci.

En configurant l'unité de post-traitement de la figure 1 en conformité avec un mode de réalisation typique de la présente invention, l'unité de post-traitement est configurée pour accepter un flux d'échantillons audio PCM décodés, et pour réaliser un post-traitement dessus (par exemple, un nivellement de volume du contenu audio) à l'aide de métadonnées d'état de traitement d'intensité sonore (et typiquement également d'autres métadonnées) reçues avec les échantillons, ou des bits de commande (déterminés par le décodeur à partir de métadonnées d'état de traitement d'intensité sonore et typiquement également d'autres métadonnées) reçues avec les échantillons. L'unité de post-traitement est également typiquement configurée pour rendre le contenu audio post-traité pour une reproduction par un ou plusieurs haut-parleurs.

Des modes de réalisation typiques de la présente invention proposent une chaîne de traitement audio améliorée dans laquelle des unités de traitement audio (par exemple, des codeurs, des décodeurs, des transcodeurs, et des unités de pré- et post-traitement) adaptent leur traitement respectif à appliquer à des données audio selon un état simultané des données multimédia comme indiqué par des métadonnées d'état de traitement d'intensité sonore reçues respectivement par les unités de traitement audio.

Les données audio entrées dans une quelconque unité de traitement audio du système de la figure 1 (par exemple, le codeur ou le transcodeur de la figure 1) peuvent inclure des métadonnées d'état de traitement d'intensité sonore (et facultativement également d'autres métadonnées) ainsi que des données audio (par exemple, des données audio codées). Ces métadonnées peuvent avoir été incluses dans l'entrée audio par un autre élément du système de la figure 1 (ou une autre source, non montrée sur la figure 1) en conformité avec un mode de réalisation de la présente invention. L'unité de traitement qui reçoit l'audio d'entrée (avec des métadonnées) peut être configurée pour réaliser au moins une opération sur les métadonnées (par exemple, une validation) ou en réponse aux métadonnées (par exemple, un traitement adaptif de l'audio d'entrée), et également typiquement pour inclure dans son audio de sortie les métadonnées, une version traitée des métadonnées, ou des bits de commande déterminés à partir des métadonnées. Un mode de réalisation typique de l'unité de traitement audio de l'invention (ou processeur audio) est configure pour réaliser un traitement adaptif de données audio basé sur l'état des données audio tel qu'indiqué par les métadonnées d'état de traitement d'intensité sonore correspondant aux données audio.

Dans certains modes de réalisation, le traitement adaptatif est (ou inclut) un traitement d'intensité sonore (si les métadonnées indiquent que le traitement d'intensité sonore, ou un traitement similaire à celui-ci, n'a pas déjà été réalisé sur les données audio, mais n'est pas (et n'inclut pas) de traitement d'intensité sonore (si les métadonnées indiquent qu'un tel traitement d'intensité sonore, ou un traitement similaire à celui-ci, a déjà été réalisé sur les données audio). Dans certains modes de réalisation, le traitement adaptatif est ou inclus une validation de métadonnées (par exemple, réalisé dans une sous-unité de validation de métadonnées) pour garantir que l'unité de traitement audio réalise un autre traitement adaptatif des données audio basé sur l'état des données audio tel qu'indiqué par les métadonnées d'état de traitement d'intensité sonore. Dans certains modes de réalisation, la validation détermine la fiabilité des métadonnées d'état de traitement d'intensité sonore associées aux données audio (par exemple, incluses dans un train de bits avec les données audio). Par exemple, si les métadonnées sont validées comme étant fiables, alors les résultats d'un type de traitement audio réalisé précédemment peuvent être réutilisés et une nouvelle performance du même type de traitement audio peut être évitée. D'un autre côté, si l'on découvre que les métadonnées ont été altérées (ou qu'elles sont sinon non fiables) alors le type de traitement multimédia supposément réalisé précédemment (tel qu'indiqué par les métadonnées non fiables) peut être répété par l'unité de traitement audio, et/ou un autre traitement peut être réalisé par l'unité de traitement audio sur les métadonnées et/ou les données audio. L'unité de traitement audio peut également être configurée pour signaler à d'autres unités de traitement audio en aval dans une chaîne de traitement multimédia améliorée que les métadonnées d'état de traitement d'intensité sonore (par exemple, présentes un train de bits multimédia) sont valides, si l'unité détermine que les métadonnées d'état de traitement sont valides (par exemple, basées sur une correspondance d'une valeur cryptographique extraite et d'une valeur cryptographique de référence).

La figure 2 est un schéma de principe d'un codeur 100 qui est un mode de réalisation de l'unité de traitement audio de l'invention. L'un quelconque des composants ou éléments du codeur 100 peut être mis en oeuvre en tant qu'un ou plusieurs procédés et/ou un ou plusieurs circuits (par exemple, ASIC, FPGA, ou autres circuits intégrés), dans un matériel, logiciel, ou une combinaison de matériel et de logiciel. Le codeur 100 comprend un tampon de trame 110, un analyseur 111, un décodeur 101, un validateur d'état audio 102, un étage de traitement d'intensité sonore 103, un étage de sélection de flux audio 104, un codeur 105, un étage de dispositif de bourrage/formatage 107, un étage de génération de métadonnées 106, un sous-système de mesure d'intensité sonore de dialogue 108, et un tampon de trame 109, connectés comme montré. Typiquement également, un codeur 100 inclut d'autres éléments de traitement (non montrés). Le codeur 100 (qui est un transcodeur) est configuré pour convertir un train de bits audio d'entrée (qui par exemple, peut être l'un d'un train de bits AC-3, d'un train de bits E-AC-3, ou d'un train de bits Dolby E) en un train de bits audio de sortie codé (qui par exemple peut être un autre d'un train de bits AC-3, d'un train de bits E-AC-3, ou d'un train de bits Dolby E) y compris en réalisant un traitement d'intensité sonore automatisé et adaptatif à l'aide de métadonnées d'état de traitement d'intensité sonore incluses dans le train de bits d'entrée. Par exemple, le codeur 100 peut être configuré pour convertir un train de bits Dolby E d'entrée (un format typiquement utilisé dans des installations de radiodiffusion et de production mais pas dans les dispositifs consommateurs qui reçoivent des programmes audio qui leur ont été diffusés) en un train de bits audio de sortie codé (approprié pour une radiodiffusion à des dispositifs consommateurs) en format AC-3 ou E-AC-3. Le système de la figure 2 inclut également un sous-système de diffusion audio codé 150 (qui stocke et/ou diffuse les trains de bits codés produits en sortie par le codeur 100) et un décodeur 152. Un train de bits audio codé produit en sortie par le codeur 100 peut être stocké par le sous-système 150 (par exemple sous forme d'un DVD ou d'un disque Blu-ray), ou transmis par un sous-système 150 (qui peut mettre en oeuvre un chaînon ou un réseau de transmission), ou qui peut être à la fois stocké et transmis par le sous-système 150. Le décodeur 152 est configuré pour décoder un train de bits audio codé (généré par le codeur 100) qu'il reçoit via le sous-système 150, y compris en extrayant des métadonnées d'état de traitement d'intensité sonore (LPSM) de chaque trame du train de bits, et en générant des données audio décodées. Typiquement, le décodeur 152 est configuré pour réaliser un traitement d'intensité sonore adaptatif sur les données audio décodées à l'aide de la LPSM, et/ou pour acheminer les données audio décodées et la LPSM à un post-processeur configuré pour réaliser un traitement d'intensité sonore adaptatif sur les données audio décodées à l'aide de la LPSM. Typiquement, le décodeur 152 inclut un tampon qui stocke (par exemple, de manière non transitoire) le train de bits audio codé reçu du sous-système 150. Diverses mises en oeuvre du codeur 100 et du décodeur 152 sont configurées pour réaliser différents 5 modes de réalisation du procédé de l'invention. Un tampon de trame 110 est une mémoire tampon couplée pour recevoir un train de bits audio d'entrée codé. En fonctionnement, la mémoire tampon 110 stocke (par exemple de manière non transitoire) au 10 moins une trame du train de bits audio codé, et une séquence des trames du train de bits audio codé est affirmée du tampon 110 à l'analyseur 111. L'analyseur 111 est couplé et configuré pour extraire des métadonnées d'état de traitement 15 d'intensité sonore (LPSM) et d'autres métadonnées de chaque trame de l'audio d'entrée codé, pour affirmer au moins la LPSM au validateur d'état audio 102, à l'étage de traitement d'intensité sonore 103, à l'étage 106 et au sous-système 108, afin d'extraire des données audio 20 de l'audio d'entrée codé, et pour affirmer les données audio du décodeur 101. Le décodeur 101 du codeur 100 est configuré pour décoder les données audio afin de générer des données audio décodées, et pour affirmer des données audio décodées à l'étage de traitement 25 d'intensité sonore 103, à l'étage de sélection de flux audio 104, au sous-système 108, et typiquement également au validateur d'état 102. Le validateur d'état 102 est configuré pour authentifier et valider la LPSM (et facultativement 30 d'autres métadonnées) affirmée à celle-ci. Dans certains modes de réalisation, la LPSM est (ou est incluse dans) un bloc de données qui a été inclus dans le train de bits d'entrée (par exemple en conformité avec un mode de réalisation de la présente invention). Le bloc peut comprendre un hachage cryptographique (un code d'identification de message à base de hachage ou « HMAC ») pour traiter la LPSM (et facultativement également d'autres métadonnées) et/ou les données sous-jacentes (fournies du décodeur 101 validateur 102). Le bloc de données peut être numériquement dans ces modes de réalisation, de que l'unité de traitement audio en aval authentifier et valider relativement facilement audio au signé sorte peut les métadonnées d'état de traitement. Par exemple, le HMAC est utilisé pour générer un condensé, et la ou les valeurs de protection incluses dans le train de bits de l'invention peuvent inclure le condensé. Le condensé peut être généré comme suit pour une trame AC-3 : 1. après codage des données AC-3 et de la LPSM, les octets de données de trame (données #1 trame concaténée et donnée #2 trame) et les octets de données LPSM sont utilisés en tant qu'entrée pour la fonction de hachage HMAC. D'autres données, qui peuvent être présentes à l'intérieur d'un champ de données auxiliaires, ne sont pas prises en considération pour calculer le condensé. Ces autres données peuvent être des octets n'appartenant ni aux données AC-3 ni aux données LPSM. Des bits de protection inclus dans la LPSM peuvent ne pas être considérés pour calculer le condensé HMAC. 2. Après que le condensé a été calculé, il est écrit dans le train de bits dans un champ réservé aux bits de protection. 3. La dernière étape de la génération de la trame AC-3 complète est le calcul de la vérification CRC. Celle-ci est écrite à la toute fin de la trame et toutes les données appartenant à cette trame sont prises en considération, y compris les bits LPSM. D'autres procédés cryptographiques incluant mais sans s'y limiter l'un quelconque d'un ou plusieurs procédés cryptographiques non-HMAC peuvent être utilisés pour la validation de LPSM (par exemple dans le validateur 102) afin de garantir une transmission et une réception sécurisées de la LPSM et/ou des données audio sous-jacentes. Par exemple, la validation (à l'aide d'un tel procédé cryptographique) peut être réalisée dans chaque unité de traitement audio qui reçoit un mode de réalisation du train de bits audio de l'invention afin de déterminer si les métadonnées d'état de traitement d'intensité sonore et les données audio correspondantes incluses dans le train de bits ont subi (et/ou sont le résultat d') un traitement d'intensité sonore spécifique (comme indiqué par les métadonnées) et n'ont pas été modifiées après la réalisation d'un tel traitement d'intensité sonore spécifique. Le validateur d'état 102 affirme des données de commande à l'étage de sélection de flux audio 104, au générateur de métadonnées 106, et au sous-système de mesure d'intensité sonore de dialogue 108, afin d'indiquer les résultats de l'opération de validation.

En réponse aux données de commande, l'étage 104 peut sélectionner (et faire passer à travers le codeur 105) : soit la sortie traitée de façon adaptative de l'étage de traitement d'intensité sonore 103 (par 5 exemple, lorsque les LPSM indiquent que les données audio produites en sortie par le décodeur 101 n'ont pas subi un type spécifique de traitement d'intensité sonore, et les bits de commande du validateur 102 indiquent que les LPSM sont valides) ; 10 soit les données audio produites en sortie par le décodeur 101 (par exemple, lorsque les LPSM indiquent que les données audio produites en sortie par le décodeur 101 ont déjà subi le type spécifique de traitement d'intensité sonore qui serait réalisé par 15 l'étage 103, et les bits de commande du validateur 102 indiquent que les LPSM sont valides). L'étage 103 du codeur 100 est configuré pour réaliser un traitement d'intensité sonore adaptatif sur les données audio décodées produites en sortie par le 20 décodeur 101, en se basant sur une ou plusieurs caractéristiques de données audio indiquées par les LPSM extraites par le décodeur 101. L'étage 103 peut être un processeur de commande de plage dynamique et d'intensité sonore en temps réel en domaine de 25 transformée adaptatif. L'étage 103 peut recevoir une entrée utilisateur (par exemple, des valeurs de plage dynamique/d'intensité sonore cibles ou des valeurs dialnormes d'utilisateur), ou une autre entrée de métadonnées (par exemple, un ou plusieurs types de 30 données de tierce partie, des informations de suivi, des identifiants, des informations propriétaire ou type, des données d'annotation utilisateur, des données de préférence utilisateur, etc.) et/ou une autre entrée (par exemple, d'un procédé d'empreintes digitales), et utiliser cette entrée pour traiter les 5 données audio décodées produites en sortie par le décodeur 101. Le sous-système de mesure d'intensité sonore de dialogue 108 peut fonctionner pour déterminer l'intensité sonore de segments de l'audio décodé (par 10 le décodeur 101) qui sont indicatifs de dialogue (ou d'autres paroles), par exemple, à l'aide des LPSM (et/ou d'autres métadonnées) extraites par le décodeur 101, lorsque les bits de commande du validateur 102 indiquent que les LPSM sont invalides. 15 Le fonctionnement du sous-système de mesure d'intensité sonore de dialogue 108 peut être désactivé lorsque les LPSM indiquent une intensité sonore déterminée précédemment de segments de dialogue (ou d'autres paroles) de l'audio décodé (du décodeur 101) lorsque 20 les bits de commande du validateur 102 indiquent que les LPSM sont valides. Il existe des outils utiles (par exemple, le sonomètre Dolby LM100) permettant de mesurer le niveau de dialogue dans un contenu audio de façon pratique et 25 aisée. Certains modes de réalisation de l'APU de l'invention (par exemple, l'étage 108 du codeur 100) sont mis en oeuvre pour inclure (ou pour réaliser les fonctions de) cet outil afin de mesurer l'intensité sonore moyenne de dialogue du contenu audio d'un train 30 de bits audio (par exemple, un train de bits AC-3 décodé affirmé à l'étage 108 par le décodeur 101 du codeur 100). Si l'étage 108 est mis en oeuvre pour mesurer l'intensité sonore moyenne véridique de dialogue de données audio, la mesure peut inclure une étape d'isolement de segments du contenu audio qui contiennent des paroles de façon prédominante. Les segments audio qui sont de façon prédominante des paroles sont alors traités en conformité avec un algorithme de mesure d'intensité sonore. Pour des données audio décodées à partir d'un train de bits AC-3, cet algorithme peut être une mesure type d'intensité sonore pondérée K (en conformité avec la norme internationale ITU-R BS.1770). En variante, d'autres mesures d'intensité sonore peuvent être utilisées (par exemple, celles basées sur des modèles psycho-acoustiques d'intensité sonore). L'isolement de segments de parole n'est pas essentiel pour mesurer l'intensité sonore moyenne de dialogue de données audio. Cependant, il améliore la précision de la mesure et fournit typiquement des résultats plus satisfaisants du point de vue d'un auditeur. Tous les contenus audio ne contenant pas de dialogue (parole), la mesure d'intensité sonore de la totalité du contenu audio peut fournir une approximation suffisante du niveau de dialogue de l'audio, si de la parole avait été présente. Un générateur de métadonnées 106 génère des métadonnées à inclure par l'étage 107 dans le train de 30 bits codé à produire en sortie par le codeur 100. Le générateur de métadonnées 106 peut acheminer à l'étage 107 les LPSM (et/ou d'autres métadonnées) extraites par le codeur 101 (par exemple, lorsque des bits de commande du validateur 102 indiquent que les LPSM et/ou d'autres métadonnées sont valides), ou générer de nouvelles LPSM (et/ou d'autres métadonnées) et affirmer les nouvelles métadonnées à l'étage 107 (par exemple, lorsque des bits de commande du validateur 102 indiquent que les LPSM et/ou d'autres métadonnées extraites par le décodeur 101 sont invalides), ou il peut affirmer à l'étage 107 une combinaison de métadonnées extraites par le décodeur 101 et de métadonnées nouvellement générées. Le générateur de métadonnées 106 peut inclure des données d'intensité sonore générées par le sous-système 108, et au moins une valeur indiquant le type de traitement d'intensité sonore réalisé par le sous-système 108, dans les LPSM qu'il affirme à l'étage 107 pour inclusion dans le train de bits codé à produire en sortie du codeur 100. Le générateur de métadonnées 106 peut générer des bits de protection (qui peuvent consister en ou inclure un code d'authentification de message à base de hachage ou « HMAC ») utile pour au moins l'un d'un décryptage, d'une authentification, ou d'une validation des LPSM (et facultativement également d'autres métadonnées) à inclure dans le train de bits codé et/ou les données audio sous-jacentes à inclure dans le train de bits codé. Le générateur de métadonnées 106 peut fournir ces bits de protection à l'étage 107 pour inclusion dans le train de bits codé.

En fonctionnement typique, le sous-système de mesure d'intensité sonore de dialogue 108 traite les données audio produites en sortie par le décodeur 101 afin de générer en réponse à celles-ci des valeurs d'intensité sonore (par exemple, des valeurs d'intensité sonore de dialogue déclenchées et non déclenchées) et des valeurs de plage dynamique. En réponse à ces valeurs, le générateur de métadonnées 106 peut générer des métadonnées d'état de traitement d'intensité sonore (LPSM) pour inclusion (par dispositif de bourrage/formatage 107) dans le train de 10 bits codé à produire en sortie par le codeur 100. En outre, en variante ou facultativement, des sous-systèmes de 106 et/ou 108 du codeur 100 peuvent réaliser une analyse supplémentaire des données audio afin de générer des métadonnées indiquant au moins une 15 caractéristique des données audio pour inclusion dans le train de bits codé à produire en sortie par l'étage 107. Le codeur 105 code (par exemple en réalisant une compression dessus) les données audio produites en 20 sortie par l'étage de sélection 104, et affirme les données codées à l'étage 107 pour inclusion dans le train de bits codé à produire en sortie par l'étage 107. L'étage 107 multiplexe l'audio codé par le codeur 105 et les métadonnées (incluant les LPSM) du 25 générateur 106 afin de générer le train de bits codé à produire en sortie par l'étage 107, de préférence de telle sorte que le train de bits codé a un format tel que spécifié par un mode de réalisation préféré de la présente invention. 30 Le tampon de trame 109 est une mémoire tampon qui stocke (par exemple, de manière non transitoire) au moins une trame du train de bits audio codé produit en sortie par l'étage 107, et une séquence des trames du train de bits audio codé est alors affirmée du tampon 109 en tant que sortie du codeur 100 au système de diffusion 150. Les LPSM générées par le générateur de métadonnées 106 et incluses dans le train de bits codé par l'étage 107 indiquent l'état de traitement d'intensité sonore de données audio correspondantes (par exemple, quel(s) type(s) de traitement d'intensité sonore ont été réalisés sur les données audio) et l'intensité sonore (par exemple l'intensité sonore du dialogue mesurée, et/ou l'intensité sonore déclenchée et/ou non déclenchée, et/ou la plage dynamique) des données audio correspondantes. Ici, le « déclenchement » de mesures d'intensité sonore et/ou de niveau réalisées sur les données audio se réfère à un niveau spécifique ou seuil d'intensité sonore où une ou des valeurs calculées qui dépassent le seuil sont incluses dans la mesure finale (par exemple, en ignorant les valeurs d'intensité sonore à court terme en dessous de -60 dBFS dans les valeurs mesurées finales). Un déclenchement sur une valeur absolue se réfère à un niveau ou une intensité sonore fixe, tandis qu'un déclenchement sur une valeur relative se réfère à une valeur qui dépend d'une valeur de mesure « non déclenchée » courante. Dans certaines mises en oeuvre du codeur 100, le 30 train de bits codé mis en mémoire tampon dans la mémoire 109 (et produit en sortie au système de diffuseur 150) est un train de bits AC-3 ou un train de bits E-AC-3, et comprend des segments de données audio (par exemple, les segments ABO à AB5 de la trame montrée sur la figure 4) et des segments de métadonnées, 5 où les segments de données audio indiquent des données audio, et chacun d'au moins certains des segments de métadonnées inclut des métadonnées d'état de traitement d'intensité sonore (LPSM). L'étage 107 insère des LPSM dans le train de bits dans le format suivant. Chacun 10 des segments de métadonnées qui inclut des LPSM est inclus dans un champ « addbsi » du segment d'information de train de bits (« BSI ») d'une trame du train de bits, ou dans un champ de données auxiliaires (par exemple le segment AUX montré sur la 15 figure 4) à la fin d'une trame du train de bits. Une trame du train de bits peut inclure un ou deux segments de métadonnées, chacun desquels inclut des LPSM, et si la trame inclut deux segments de métadonnées, l'un est présent dans le champ addbsi de la trame et l'autre 20 dans le champ AUX de la trame. Chaque segment de métadonnées incluant des LPSM inclut un segment de charge utile (ou contenant) LPSM ayant le format suivant : un en-tête (incluant typiquement un mot de 25 synchronisation identifiant le début de la charge utile LPSM, suivi d'au moins une valeur d'identification, par exemple la version de format LPSM, la longueur, la période, le décompte, et des valeurs d'association de sous-flux indiquées dans le tableau 2 ci-dessous) ; et 30 après l'en-tête, au moins une valeur d'indication de dialogue (par exemple, un paramètre « canal ou canaux de dialogue » du tableau 2) indiquant si des données audio correspondantes indiquent un dialogue ou n'indiquent pas de dialogue (par exemple, quels canaux de données audio correspondantes indiquent un dialogue) ; au moins une valeur de conformité de règlementation d'intensité sonore (par exemple, un paramètre « type de règlementation d'intensité sonore » du tableau 2) indiquant si les données audio correspondantes sont conformes à un ensemble indiqué de réglementations d'intensité sonore ; au moins une valeur de traitement d'intensité sonore (par exemple, un ou plusieurs des paramètres « drapeau de correction d'intensité sonore déclenchée de dialogue », « type de correction d'intensité sonore », du tableau 2) indiquant au moins un type de traitement d'intensité sonore qui a été réalisé sur les données audio correspondantes ; et au moins une valeur d'intensité sonore (par exemple, un ou plusieurs des paramètres « Intensité sonore à déclenchement relatif de l'UIT », « Intensité sonore déclenchement de parole de l'UIT », « Intensité sonore 3s à court terme de l'UIT (EBU 3341) » et « crête véritable » du tableau 2) indiquant au moins une intensité sonore (par exemple, une crête d'intensité sonore ou une intensité sonore moyenne) caractéristique des données audio correspondantes. Dans certaines mises en oeuvre, chacun des segments 30 de métadonnées insérés par l'étage 107 dans un champ « addbsi » ou un champ de données auxiliaires d'une trame du train de bits a le format suivant : un en-tête de coeur (incluant typiquement un mot de synchronisation identifiant le début du segment de 5 métadonnées, suivi de valeurs d'identification, par exemple, la version, la longueur et la période de l'élément de coeur, le décompte d'élément étendu, et des valeurs d'association de sous-flux indiquées dans le tableau 1 ci-dessous) ; et 10 après l'en-tête de coeur, au moins une valeur de protection (par exemple le condensé HMAC et des valeurs d'empreintes digitales audio du tableau 1) utiles pour au moins l'un d'un décryptage, d'une authentification ou d'une validation d'au moins l'une des métadonnées 15 d'état de traitement d'intensité sonore ou des données audio correspondantes) ; et également après l'en-tête de coeur, si le segment de métadonnées inclut des LPSM, des valeurs d'identification (« ID ») de charge utile LPSM et de 20 taille de charge utile LPSM qui identifient des métadonnées suivantes en tant que charge utile LPSM et indiquent la taille de la charge utile LPSM. Le segment de charge utile (ou contenant) LPSM (ayant de préférence le format spécifié ci-dessus) 25 suit les valeurs d'identification de charge utile LPSM et de taille de charge utile LPSM. Dans certains modes de réalisation, chacun des segments de métadonnées dans le champ de données auxiliaires (ou champ « addbsi ») d'une trame a trois 30 niveaux de structure : un niveau de structure élevé, incluant un drapeau indiquant si le champ de données auxiliaires (ou addbsi) inclut des métadonnées, au moins une valeur d'indentification indiquant quel(s) type(s) de métadonnées sont présents, et typiquement également une valeur indiquant combien de bits de métadonnées (par exemple, de chaque type) sont présents (si des métadonnées sont présentes). Un type de métadonnées qui pourrait être présent est la LSPM, et un autre type de 10 métadonnées qui pourrait être présent est des métadonnées de recherche multimédia (par exemple, des métadonnées de recherche multimédia Nielsen) ; une structure de niveau intermédiaire, comprenant un élément de coeur pour chaque type identifié de 15 métadonnées (par exemple, un en-tête de coeur, des valeurs de protection, et des valeurs d'identification de charge utile LPSM et de taille de charge utile LPSM, telles que mentionnées ci-dessus, pour chaque type identifié de métadonnées) ; et 20 une structure de niveau bas, comprenant chaque charge utile pour un élément de coeur (par exemple, une charge utile LPSM, si l'élément de coeur en identifie une comme étant présente, et/ou une charge utile de métadonnées d'un autre type, si l'élément de coeur en 25 identifie une comme étant présente). Les valeurs de données dans une telle structure à trois niveaux peuvent être emboîtées. Par exemple, la ou les valeurs de protection pour une charge utile LPSM et/ou une autre charge utile de métadonnées identifiée 30 par un élément de coeur peuvent être incluses après chaque charge utile identifiée par l'élément de coeur (et ainsi après l'en-tête de coeur de l'élément de coeur). Dans un exemple, un en-tête de coeur pourrait identifier une charge utile LPSM et une autre charge utile de métadonnées, des valeurs d'identification de charge utile et de taille de charge utile pour la première charge utile (par exemple, la charge utile LPSM) pourraient suivre l'en-tête de coeur, la première charge utile elle-même pourrait suivre les valeurs d'identification et de taille, la valeur d'identification de charge utile et de taille de charge utile pour la seconde charge utile pourrait suivre la première charge utile, la seconde charge utile elle-même pourrait suivre ces valeurs d'identification et de taille, et des bits de protection pour les deux charges utiles (ou pour des valeurs d'élément de coeur et les deux charges utiles) pourraient suivre la dernière charge utile. Dans certains modes de réalisation, si le décodeur 101 reçoit un train de bits audio généré en conformité avec un mode de réalisation de l'invention avec un hachage cryptographique, le décodeur est configuré pour analyser et récupérer le hachage cryptographique à partir d'un bloc de données déterminé à partir du train de bits, ledit bloc comprenant des métadonnées d'état de traitement d'intensité sonore (LPSM). Le validateur 102 peut utiliser le hachage cryptographique pour valider le train de bits reçu et/ou des métadonnées associées. Par exemple, le validateur 102 constate que les LPSM sont valides en se basant sur la correspondance entre un hachage cryptographique de référence et le hachage cryptographique récupéré à partir du bloc de données, puis il peut désactiver le fonctionnement du processeur 103 sur les données audio correspondantes et amener un stage de sélection 104 à acheminer les données audio (non modifiées). En outre, en variante ou facultativement, d'autres types de techniques cryptographiques peuvent être utilisées à la place d'un procédé basé sur un hachage cryptographique. Le codeur 100 de la figure 2 peut déterminer (en réponse aux LPSM extraites par le décodeur 101) que l'unité de post/pré-traitement a réalisé un type de traitement d'intensité sonore sur les données audio à coder (dans les éléments 105, 106 et 107) et peut donc créer (dans le générateur 106) des métadonnées d'état de traitement d'intensité sonore qui incluent les paramètres spécifiques utilisés dans et/ou dérivés du traitement d'intensité sonore réalisé précédemment. Dans certaines mises en oeuvre, le codeur 100 peut créer (et inclure dans le train de bits codé produit en sortie à partir de celui-ci) des métadonnées d'état de traitement indiquant les antécédents de traitement sur le contenu audio tant que le codeur est informé des types de traitement qui ont été réalisés sur le contenu audio.

La figure 3 est un schéma de principe d'un décodeur (200) qui est un mode de réalisation de l'unité de traitement audio de l'invention, et d'un post-processeur (300) couplé à celle-ci. Le post-processeur (300) est également un mode de réalisation de l'unité de traitement audio de l'invention. L'un quelconque des composants ou éléments du décodeur 200 et du post-processeur 300 peut être mis en oeuvre en tant qu'un ou plusieurs procédés et/ou un ou plusieurs circuits (par exemple, ASIC, FPGA, ou d'autres circuits intégrés), dans un matériel, un logiciel, ou une 5 combinaison de matériel et de logiciel. Le décodeur 200 comprend un tampon de trame 201, un analyseur 205, un décodeur audio 202, un étage de validation d'état audio (validateur) 203, et un étage de génération de bit de commande 204, connectés comme montré. 10 Typiquement également, le décodeur 200 inclut d'autres éléments de traitement (non montrés). Le tampon de trame 201 (une mémoire tampon) stocke (par exemple, de manière non transitoire) au moins une trame du train de bits audio codé reçu par le 15 décodeur 200. Une séquence des trames du train de bits audio codé est affirmée du tampon 201 à l'analyseur 205. L'analyseur 205 est couplé et configuré pour extraire des métadonnées d'état de traitement d'intensité sonore (LPSM) et d'autres métadonnées de 20 chaque trame de l'audio d'entrée codé, afin d'affirmer au moins les LPSM au validateur d'état audio 203 et à l'étage 204, afin d'affirmer les LPSM comme sortie (par exemple, au post-processeur 300), afin d'extraire des données audio de l'audio d'entrée codé, et afin 25 d'affirmer les données audio extraites au décodeur 202. Le train de bits audio codé fourni en entrée au décodeur 200 peut être l'un d'un train de bits AC-3, d'un train de bits E-AC-3, ou d'un train de bits Dolby E. 30 Le système de la figure 3 inclut également un post-processeur 300. Le post-processeur 300 comprend un tampon de trame 301 et d'autres éléments de traitement (non montrés) incluant au moins un élément de traitement couplé au tampon 301. Le tampon de trame 301 stocke (par exemple, de manière non transitoire) au moins une trame du train de bits audio décodé reçu par le post-processeur 300 du décodeur 200. Des éléments de traitement du post-processeur 300 sont couplés et configurés pour recevoir et traiter de façon adaptive une séquence des trames du train de bits audio décodé produit en sortie par le tampon 301, à l'aide de métadonnées (incluant des valeurs de LPSM) produites en sortie par le décodeur 202 et/ou des bits de commande produits en sortie par l'étage 204 du décodeur 200. Typiquement, le post-processeur 300 est configuré pour réaliser un traitement d'intensité sonore adaptatif sur les données audio décodées à l'aide des valeurs de LPSM (par exemple, basées sur un état du traitement d'intensité sonore, et/ou une ou plusieurs caractéristiques de données audio indiquées par les 20 LPSM). Diverses mises en oeuvre du décodeur 200 et du post-processeur 300 sont configurées pour réaliser divers modes de réalisation du procédé de l'invention. Le décodeur audio 202 du décodeur 200 est 25 configuré pour décoder les données audio extraites par l'analyseur 205 afin de générer des données audio décodées, et pour affirmer les données audio décodées en tant que sortie (par exemple, au post- processeur 300). 30 Le validateur d'état 203 est configuré pour authentifier et valider les LPSM (et facultativement d'autres métadonnées) affirmées à celui-ci. Dans certains modes de réalisation, les LPSM sont (ou sont incluses dans) un bloc de données qui a été inclus dans le train de bits d'entrée (par exemple, en conformité avec un mode de réalisation de la présente invention). Le bloc peut comprendre un hachage cryptographique (un code d'authentification de message à base de hachage ou « HMAC ») pour traiter les LPSM (et facultativement également d'autres métadonnées) et/ou les données audio sous-jacentes (fournies par l'analyseur 205 et/ou le décodeur 202 au validateur 203). Le bloc de données peut être signé numériquement dans ces modes de réalisation, de sorte qu'une unité de traitement audio en aval puisse authentifier et valider relativement facilement les métadonnées d'état de traitement. D'autres procédés cryptographiques incluant mais sans s'y limiter l'un quelconque d'un ou plusieurs procédés cryptographiques non HMAC peuvent être utilisés pour validation des LPSM (par exemple, dans le validateur 203) afin de garantir une transmission et une réception sécurisées des LPSM et/ou des données audio sous-jacentes. Par exemple, une validation (utilisant un tel procédé cryptographique) peut être réalisée dans chaque unité de traitement audio qui reçoit un mode de réalisation du train de bits audio de l'invention afin de déterminer si les métadonnées d'état de traitement d'intensité sonore et des données audio correspondantes incluses dans le train de bits ont subi (et/ou résultent d') un traitement d'intensité sonore spécifique (comme indiqué par les métadonnées) et n'ont pas été modifiées après réalisation d'un tel traitement d'intensité sonore spécifique. Le validateur d'état 203 affirme des données de commande au générateur de bit de commande 204, et/ou 5 affirme les données de commande en tant que sortie (par exemple, au post-processeur 300), afin d'indiquer les résultats de l'opération de validation. En réponse aux données de commande (et facultativement également aux autres métadonnées extraites du train de bits d'entrée), 10 l'étage 204 peut générer (et affirmer au post-processeur 300) : soit des bits de commande indiquant que des données audio décodées produites en sortie par le décodeur 202 ont subi un type spécifique de traitement 15 d'intensité sonore (lorsque les LPSM indiquent que les données audio produites en sortie par le décodeur 202 ont subi le type spécifique de traitement d'intensité sonore, et les bits de commande du validateur 203 indiquent que les LPSM sont valides) ; 20 soit des bits de commande indiquant que les données audio décodées produites en sortie par le décodeur 202 devraient subir un type spécifique de traitement d'intensité sonore (par exemple, lorsque les LPSM indiquent que les données audio produites par le 25 décodeur 202 n'ont pas subi le type spécifique de traitement d'intensité sonore, ou lorsque les LPSM indiquent que les données audio produites en sortie par le décodeur 202 ont subi le type spécifique de traitement d'intensité sonore mais que les bits de 30 commande du validateur 203 indiquent que les LPSM ne sont pas valides.

En variante, le décodeur 200 affirme les LPSM (et toutes autres métadonnées) extraites par le décodeur 202 du train de bits d'entrée au post-processeur 300, et le post-processeur 300 réalise un traitement d'intensité sonore sur les données audio décodées à l'aide des LPSM, ou réalise une validation des LPSM puis réalise un traitement d'intensité sonore sur les données audio décodées à l'aide des LPSM si la validation indique que les LPSM sont valides.

Dans certains modes de réalisation, si le décodeur 201 reçoit un train de bits audio généré en conformité avec un mode de réalisation de l'invention avec hachage cryptographique, le décodeur est configuré pour analyser et récupérer le hachage cryptographique à partir d'un bloc de données déterminé à partir du train de bits, ledit bloc comprenant des métadonnées d'état de traitement d'intensité sonore (LPSM). Le validateur 203 peut utiliser le hachage cryptographique afin de valider le train de bits reçu et/ou des métadonnées associées. Par exemple, si le validateur 203 constate que les LPSM sont valides en se basant sur une correspondance entre un hachage cryptographique de référence et le hachage cryptographique récupéré à partir du bloc de données, alors il peut signaler à une unité de traitement audio en aval (par exemple, le post-processeur 300, qui peut être ou inclut une unité de nivellement de volume) d'acheminer les données audio (non modifiées) du train de bits. En outre, en variante ou facultativement, d'autres types de techniques cryptographiques peuvent être utilisés à la place d'un procédé basé sur un hachage cryptographique.

Dans certaines mises en oeuvre du décodeur 100, le train de bits codé reçu (et mis en mémoire tampon dans la mémoire 201) est un train de bits AC-3 ou un train de bits E-AC-3, et comprend des segments de données audio (par exemple, les segments ABO à AB5 de la trame montrée sur la figure 4) et des segments de métadonnées, où les segments de données audio indiquent des données audio, et chacun d'au moins certains des segments de métadonnées inclut des métadonnées d'état de traitement d'intensité sonore (LPSM). L'étage de décodeur 202 est configuré pour extraire du train de bits des LPSM ayant le format suivant. Chacun des segments de métadonnées qui inclut des LPSM est inclus dans un champ « addbsi » du segment d'information de train de bits (« BSI ») d'une trame du train de bits, ou dans un champ de données auxiliaires (par exemple, le segment AUX montré sur la figure 4) à la fin d'une trame du train de bits. Une trame du train de bits peut inclure un ou deux segments de métadonnées, chacun desquels inclut des LPSM, et si la trame inclut deux segments de métadonnées, l'un est présent dans le champ addbsi de la trame et l'autre dans le champ AUX de la trame. Chaque segment de métadonnées incluant des LPSM inclut un segment de charge utile (ou contenant) du LPSM ayant le format suivant : un en-tête (incluant typiquement un mot de synchronisation identifiant le début de la charge utile LPSM, suivi par des valeurs d'identification, par exemple, la version de format LPSM, la longueur, la période, le décompte et des valeurs d'association de sous-flux indiquées dans le tableau 2 ci-dessous) ; et après l'en-tête, au moins une valeur d'indication de dialogue (par exemple, un paramètre « canal ou canaux de dialogue » du tableau 2) indiquant si les données audio correspondantes indiquent un dialogue ou n'indiquent pas de dialogue (par exemple, quels canaux des données audio correspondantes indiquent un dialogue) ; au moins une valeur de conformité de réglementation d'intensité sonore (par exemple, un paramètre « type de réglementation d'intensité sonore » du tableau 2) indiquant si les données audio correspondantes sont conformes à un ensemble indiqué de réglementations d'intensité sonore ; au moins une valeur de traitement d'intensité 15 sonore (par exemple, un ou plusieurs des paramètres « drapeau de correction d'intensité sonore à déclenchement de dialogue », « type de correction d'intensité sonore », du tableau 2) indiquant au moins un type de traitement d'intensité sonore qui a été 20 réalisé sur les données audio correspondantes ; et au moins une valeur d'intensité sonore (par exemple, un ou plusieurs des paramètres « Intensité sonore à déclenchement relatif à l'UIT », « Intensité sonore déclenchement de parole de l'UIT », 25 « Intensité sonore 3s à court terme de l'UIT (EBU 3341) » et « crête véritable » du tableau 2) indiquant au moins une intensité sonore (par exemple, crête d'intensité sonore ou intensité sonore moyenne) caractéristique des données audio correspondantes. 30 Dans certaines mises en oeuvre, l'étage de décodeur 202 est configuré pour extraire, du champ « addbsi » ou d'un champ de données auxiliaires d'une trame de train de bits, chaque segment de métadonnées ayant le format suivant : un en-tête de coeur (incluant typiquement un mot de 5 synchronisation identifiant le début du segment de métadonnées, suivi d'au moins une valeur d'identification, par exemple, la version, la longueur et la période d'élément de coeur, le décompte d'élément étendu, et des valeurs d'association de sous-flux 10 indiquées dans le tableau 1 ci-dessous) ; et après l'en-tête de coeur, au moins une valeur de protection (par exemple, le condensé HMAC et des valeurs d'empreintes digitales audio du tableau 1) utile pour au moins l'un d'un décryptage, d'une 15 authentification, ou d'une validation d'au moins l'une de métadonnées d'état de traitement d'intensité sonore ou de données audio correspondantes) ; et également après l'en-tête de coeur, si le segment de métadonnées inclut des LPSM, des valeurs 20 d'identification (« ID ») de charge utile LPSM et de taille de charge utile LPSM qui identifient des métadonnées suivantes en tant que charge utile LPSM et indiquent la taille de la charge utile LPSM. Le segment de charge utile (ou contenant) de 25 LPSM (ayant de préférence le format spécifié ci-dessus) suit les valeurs d'identification de charge utile LPSM et de taille de charge utile LPSM. De façon plus générale, le train de bits audio codé généré par des modes de réalisation préférés de 30 l'invention a une structure qui fournit un mécanisme pour marquer des éléments et sous-éléments de métadonnées en tant que coeur (obligatoire) ou étendu (éléments facultatifs). Ceci permet au débit de données du train de bits (y compris ses métadonnées) de se mettre à l'échelle à travers de nombreuses applications. Les éléments de coeur (obligatoire) de la syntaxe de train de bits préférée devraient également être capables de signaler que les éléments étendus (facultatifs) associés au contenu audio sont présents (intra-bande) et/ou dans un emplacement éloigné (hors de la bande). Un ou des éléments de coeur sont nécessairement présents dans chaque trame du train de bits. Certains sous-éléments d'éléments de coeur sont facultatifs et peuvent être présents en toute combinaison. Des éléments étendus ne sont pas nécessairement présents dans chaque trame (afin de limiter le sur-débit binaire). Ainsi, des éléments étendus peuvent être présents dans certaines trames et pas d'autres. Certains sous-éléments d'un élément étendu sont facultatifs et peuvent être présents en toute combinaison, tandis que certains sous-éléments d'un élément étendu peuvent être obligatoires (c'est-à-dire, si l'élément étendu est présent dans une trame du train de bits).

Dans une classe de modes de réalisation, un train de bits audio codé comprenant une séquence de segments de données audio et des segments de métadonnées est généré (par exemple, par une unité de traitement audio qui représente l'invention). Les segments de données audio sont indicatifs de données audio, chacun d'au moins certains des segments de métadonnées inclut des métadonnées d'état de traitement d'intensité sonore (LPSM), et les segments de données audio sont multiplexés par répartition dans le temps avec les segments de métadonnées. Dans des modes de réalisation préférés de cette classe, chacun des segments de métadonnées a un format préféré qui est décrit ici. Dans un format préféré, le train de bits codé est un train de bits AC-3 ou un train de bits E-AC-3, et chacun des segments de métadonnées qui inclut des LPSM est inclus (par exemple, par l'étage 107 d'une mise en oeuvre préférée du codeur 100) en tant qu'information de train de bits supplémentaire dans le champ « addbsi » (montré sur la figure 6) du segment d'information de train de bits (« BSI ») d'une trame du train de bits, ou dans un champ de données auxiliaires d'une trame de train de bits. Dans le format préféré, chacune des trames inclut un élément de coeur ayant le format montré dans le tableau 1 ci-dessous, dans le champ addbsi de la trame :20 Tableau 1 Paramètre Description Obligatoire /facultatif SYNC [ID] 0 Version 0 d'élément de coeur Longueur d'élément de coeur 0 Période 0 d'élément de coeur (xxx) Décompte d'élément étendu Indique le nombre 0 d'éléments de métadonnées étendus associés à l'élément de coeur. Cette valeur est incrémentée/décrémentée lorsque le train de bits passe de la production à la distribution et émission finale. Association de sous-flux Décrit le ou les sous-flux auxquels l'élément de coeur est associé. 0 Signature (condensé HMAC) Condensé HMAC de 0 256 bits (à l'aide un algorithme SHA-2) calculé sur les données audio, l'élément de coeur, et tous les éléments étendus, de la totalité de la trame.

Paramètre Description Obligatoire /facultatif Compte à Le champ n'apparaît que pour un certain nombre de trames au niveau de la tête ou queue d'un fichier/flux de programme F rebours limite PGM audio. Ainsi, un changement de version d'élément de coeur pourrait être utilisé pour signaler l'inclusion de ce paramètre. Empreinte Empreinte digitale audio prise sur un certain nombre d'échantillons audio PCM représentée par le champ de période d'élément de coeur. F digitale audio Empreinte Empreinte digitale vidéo prise sur un certain nombre d'échantillons F digitale vidéo vidéo compressés (le cas échéant) représentée par le champ de période d'élément de coeur. URL/UUID Ce champ est défini pour porter une URL et/ou un F UUDI (il peut être redondant à l'empreinte digitale) qui référence un emplacement externe de contenu de programme supplémentaire (essence) et/ou des métadonnées associées au train de bits. Dans le format préféré, chacun des champs addbsi (ou de données auxiliaires) qui contient les LPSM contient une en-tête de coeur (et facultativement également des éléments de coeur supplémentaires), et après l'en-tête de coeur (ou l'en-tête de coeur et d'autres éléments de coeur), les valeurs LPSM suivantes (paramètres) : un identifiant de charge utile (identifiant les métadonnées en tant que LPSM) suivant les valeurs 5 d'élément de coeur (par exemple, comme spécifié dans le tableau 1) ; une taille de charge utile indiquant la taille de la charge utile LPSM) suivant l'identifiant de charge utile ; et 10 des données LPSM (suivant la valeur d'identifiant de charge utile et de taille de charge utile) ayant un format tel qu'indiqué dans le tableau suivant (tableau 2) : 15 Tableau 2 Paramètre LPSM Description Nombre Obligatoire/ Vitesse [Intensité d'états Facultatif d'insertion sonore uniques (période de intelligente] mise à jour du paramètre) Version LPSM 0 Période Applicable à xxx champs seulement 0 LPSM (xxx) Décompte LPSM 0 Association de sous-flux LPSM 0 Canal ou canaux de dialogue Indique quelles combinaisons de 8 0 -0,5 seconde (typique) canaux audio L, C & R contiennent de la parole sur les 0,5 seconde précédentes. Lorsqu'aucune parole n'est présente dans une quelconque combinaison L, C ou R, alors ce paramètre indiquera « aucun dialogue » Paramètre LPSM Description Nombre Obligatoire/ Vitesse [Intensité d'états Facultatif d'insertion sonore uniques (période de intelligente] mise à jour du paramètre) Type de régulation d'intensité sonore Indique que le flux de données audio associé est en conformité avec un ensemble spécifique de réglementations (par exemple, ATSC A/85 ou EBU R128) 8 0 Trame Drapeau de correction d'intensité sonore à déclenchement de dialogue Indique si le flux audio associé a été corrigé sur la base d'un déclenchement de dialogue 2 F (seulement Trame présent si le type de réglementation d'intensité sonore indique que l'audio correspondant est NON CORRIGE) Type de correction d'intensité sonore Indique si le flux audio associé a été corrigé avec un contrôleur d'intensité sonore et de plage dynamique par anticipation 2 F (seulement Trame infinie (à base de présent si le fichier) ou en type de temps réel (RT) réglementation d'intensité sonore indique que l'audio correspondant est NON CORRIGE) Intensité sonore à déclenchement relatif à Indique 128 F 1 s l'UIT (INF) l'intensité sonore intégrée UIT-R BS.1770-2 du flux audio associé sans métadonnée appliquée (par exemple, 7 bits : -58 -> +5,5 LKFS 0,5 étape LKFS Intensité sonore à déclenchement de parole de Indique 128 F 1 s l'UIT (INF) l'intensité sonore intégrée UIT-R BS.1770-2 du flux audio associé sans métadonnée appliquée (par exemple, 7 bits : -58 -> +5,5 LKFS 0,5 étape LKFS Paramètre LPSM Description Nombre Obligatoire/ Vitesse [Intensité d'états Facultatif d'insertion sonore uniques (période de intelligente] mise à jour du paramètre) Intensité sonore 3s à court terme de Indique 256 F 0,1 s l'UIT (EBU l'intensité sonore UIT non déclenchée de 3 secondes du flux audio associé sans métadonnée 3341) appliquée (fenêtre glissante) @ - taux d'insertion 10 Hz (par exemple 8 bits : 116 -> +11,5 LKFS 0,5 étape LKFS) Valeur de crête réelle Indique la valeur de crête réelle UIT-R BS.1770 256 F 0,5 s annexe 2 (dB TP) du flux audio associé sans métadonnée appliquée. (c'est- à-dire, valeur la plus grande sur une période de trame signalée dans le champ de période d'élément) 116 -> +11,5 LKFS 0,5 étape LKFS Dans un autre format préféré d'un train de bits codé généré en conformité avec l'invention, le train de bits est un train de bits AC-3 ou un train de bits E5 AC-3, et chacun des segments de métadonnées qui inclut des LPSM est inclus (par exemple, par l'étage 107 d'une mise en oeuvre préférée du codeur 100) soit dans : un champ « addbsi » (montré sur la figure 6) du segment d'information de train de bits (« BSI ») d'une trame du 10 train de bits ; soit dans un champ de données auxiliaires (par exemple, le segment AUX montré sur la figure 4) à la fin d'une trame de train de bits. Une trame peut inclure un ou deux segments de métadonnées, chacun desquels inclut des LPSM, et si la trame inclut deux segments de métadonnées, l'un est présent dans le champ addbsi de la trame et l'autre dans le champ AUX de la trame. Chaque segment de métadonnées incluant des LPSM a le format spécifié ci-dessus en référence aux tableaux 1 et 2 ci-dessus (c'est-à-dire, il inclut les éléments de coeur spécifiés dans le tableau 1, suivis des valeurs d'identifiant de charge utile (identifiant les métadonnées en tant que LPSM) et de taille de charge utile spécifiée ci-dessus, suivie de la charge utile (les données LPSM qui ont un format tel qu'indiqué dans le tableau 2). Dans un autre format préféré, le train de bits codé est un train de bits Dolby E, et chacun des segments de métadonnées qui inclut des LPSM est les N premiers emplacements d'échantillons de l'intervalle de bande de garde Dolby E. Un train de bits Dolby E incluant un tel segment de métadonnées qui inclut des LPSM inclut de préférence une valeur indicative d'une longueur de charge utile LPSM signalée dans le mot Pd du préambule SMPTE 337M (le taux de répétition de mot Pa SMPTE 337M reste de préférence identique au taux de trame vidéo associé). Dans un format préféré, dans lequel le train de bits codé est un train de bits E-AC-3, chacun des segments de métadonnées qui inclut des LPSM est inclus (par exemple, par l'étage 107 d'une mise en oeuvre préférée du codeur 100) en tant qu'information de train de bits supplémentaire dans le champ « addbsi » du segment d'information de train de bits (« BSI ») d'une trame du train de bits. Nous décrivons ensuite des aspects supplémentaires du codage d'un train de bits E-AC-3 avec des LPSM dans ce format préféré : 1. pendant la génération d'un train de bits E-AC-3, tandis que le codeur E-AC-3 (qui insère les valeurs 5 LPSM dans le train de bits) est « actif », pour chaque trame générée (trame sync), le train de bits devrait inclure un bloc de métadonnées (incluant des LPSM) porté dans le champ addbsi de la trame. Les bits nécessaires pour porter le bloc de métadonnées ne 10 devraient pas augmenter le débit binaire du codeur (longueur de trame) ; 2. chaque bloc de métadonnées (contenant des LPSM) devrait contenir les informations suivantes : - 1. drapeau de type de correction d'intensité sonore : 15 où « 1 » indique que l'intensité sonore des données audio correspondantes a été corrigée en amont du codeur, et « 0 » indique que l'intensité sonore a été corrigée par un correcteur d'intensité sonore intégré dans le codeur (par exemple, processeur d'intensité sonore 103 20 du codeur 100 de la figure 2) ; - 2. canal de parole : indique quel(s) canal (canaux) de source contiennent de la parole (sur les 0,5 s précédentes). Si aucune parole n'est détectée, ceci doit être indiqué comme tel ; 25 - 3. intensité sonore de parole : indique l'intensité sonore de parole intégrée de chaque canal audio correspondant qui contient de la parole (sur les 0,5 s précédentes) ; - 4. intensité sonore UIT : indique l'intensité 30 sonore UIT BS.1770-2 de chaque canal audio correspondant ; - 5. gain : gain(s) composite(s) d'intensité sonore pour inversion dans un décodeur (afin de démontrer la réversibilité) ; 3. pendant que le codeur E-AC-3 (qui insère les 5 valeurs LPSM dans le train de bits) est « actif » et reçoit une trame AC-3 avec un drapeau « sécurisé », le contrôleur d'intensité sonore dans le codeur (par exemple, le processeur d'intensité sonore 103 du codeur 100 de la figure 2) devrait être contourné. Les valeurs 10 DRC et dialnorm de source « sécurisé » devraient être acheminées (par exemple, par le générateur 106 du codeur 100) jusqu'à la composante du codeur E-AC-3 (par exemple, l'étage 107 du codeur 100). La génération de bloc LPSM se poursuit et le 15 drapeau de type de correction d'intensité sonore est établi sur « 1 ». La séquence de contournement de contrôleur d'intensité sonore doit être synchronisée avec le début de la trame AC-3 décodée là où le drapeau « sécurisé » apparaît. La séquence de contournement de 20 contrôleur d'intensité sonore devrait être mise en oeuvre comme suit : le contrôle de quantité de nivelleur est décrémenté d'une valeur de 9 à une valeur de 0 sur 10 périodes de bloc audio (c'est-à-dire 53,3 ms) et le contrôle du compteur dorsal de nivelleur est placé en 25 mode contournement (cette opération devrait produire une transition continue). Le terme contournement « sécurisé » du nivelleur implique que la valeur dialnorm du train de bits de source est également réutilisée au niveau de la sortie du codeur (par 30 exemple si le train de bits de source « sécurisé » a une valeur dialnorm de -30 alors la sortie du codeur devrait utiliser -30 pour la valeur dialnorm sortante ; 4. lorsque le codeur E-AC-3 (qui insère les valeurs LPSM dans le train de bits) est « actif » et 5 reçoit une trame AC-3 sans le drapeau « sécurisé », le contrôleur d'intensité sonore incorporé dans le codeur (par exemple, le processeur d'intensité sonore 103 du codeur 100 de la figure 2) devrait être actif. La génération de bloc LPSM se poursuit et le 10 drapeau de type de correction d'intensité sonore est établi à « 0 ». La séquence d'activation de contrôleur d'intensité sonore devrait être synchronisée au début de la trame AC-3 décodée où le drapeau « sécurisé » disparaît. La séquence d'activation de contrôleur 15 d'intensité sonore devrait être mise en oeuvre comme suit : le contrôle de quantité de nivelleur est incrémenté d'une valeur de 0 à une valeur de 9 sur 1 période de bloc audio (c'est-à-dire 5,3 ms) et le contrôle du compteur dorsal de nivelleur est placé en 20 mode « actif » (cette opération devrait produire une transition continue et inclure une réinitialisation d'intégration de compteur dorsal) ; et 5. pendant le codage, une interface utilisateur graphique (GUI) devrait indiquer à un utilisateur les 25 paramètres suivants : « programme audio d'entrée : [sécurisé/non sécurisé] » - l'état de ce paramètre est basé sur la présence du drapeau « sécurisé » dans le signal d'entrée ; et « correction d'intensité sonore en temps réel : [activé/désactivé] » - l'état de ce 30 paramètre est basé sur le fait de savoir si ce contrôleur d'intensité sonore intégré dans le codeur est actif. Lors du décodage d'un train de bits AC-3 ou E-AC-3 qui comporte des LPSM (dans le format préféré) incluses 5 dans le champ « addbsi » du segment d'information de train de bits (« BSI ») de chaque trame du train de bits, le décodeur devrait analyser les données de bloc LPSM (dans le champ addbsi) et acheminer toutes les valeurs LPSM extraites à une interface utilisateur 10 graphique (GUI). L'ensemble des valeurs LPSM extraites est rafraîchi à chaque trame. Dans un autre format préféré d'un train de bits codé généré en conformité avec l'invention, le train de bits codé est un train de bits AC-3 ou un train de bits 15 E-AC-3, et chacun des segments de métadonnées qui inclut des LPSM est inclus (par exemple, par l'étage 107 d'une mise en oeuvre préférée du codeur 100) en tant qu'information de train de bits supplémentaire dans le champ « addbsi » (montré sur la figure 6) du 20 segment d'information de train de bits (« BSI ») (ou dans le segment Aux) d'une trame de train de bits. Dans ce format (qui est une variation du format décrit ci-dessus en référence aux tableaux 1 et 2), chacun des champs addbsi (ou Aux) qui contient des LPSM contient 25 les valeurs LPSM suivantes : les éléments de coeur spécifiés dans le tableau 1, suivis des valeurs d'identifiant de charge utile (identifiant les métadonnées en tant que LPSM) et de taille de charge utile, suivies de la charge 30 utile (données LPSM) qui a le format suivant (similaire aux éléments obligatoires indiqués dans le tableau 2 ci-dessus) : version de charge utile LPSM : un champ de 2 bits qui indique la version de la charge utile LPSM ; dialchan : un champ de 3 bits qui indique si les canaux gauches, droits et/ou centraux de données audio correspondantes contiennent un dialogue parlé. L'allocation de bit du champ dialchan peut être comme suit : bit 0, qui indique la présence de dialogue dans le canal gauche, est stocké dans le bit le plus significatif du champ dialchan ; et bit 2, qui indique la présence de dialogue dans le canal central, est stocké dans le bit le moins significatif du champ dialchan. Chaque bit du champ dialchan est établi à « 1 » si le canal correspondant contient du dialogue parlé pendant les 0,5 seconde précédentes du programme ; loudregtyp : un champ de 3 bits qui indique à quelle norme de réglementation d'intensité sonore est conforme l'intensité sonore du programme. Le réglage du champ « loudregtyp » à « 000 » indique que la LPSM n'indique pas de conformité une réglementation d'intensité sonore. Par exemple, une valeur de ce champ (par exemple 000) peut indiquer qu'une conformité avec une norme de réglementation d'intensité sonore n'est pas indiquée, une autre valeur de ce champ (par exemple 001) peut indiquer que les données audio du programme sont conformes à la norme ATSC A/85, et une autre valeur de ce champ (par exemple 010) peut indiquer que les données audio du programme sont conformes à la norme EBU R128. Dans l'exemple, si le champ est réglé à toute valeur autre que « 000 », les champs loudcorrdialgat et loudcorrtyp devraient suivre dans la charge utile ; loudcorrdialgat : un champ d'un bit qui indique si une correction d'intensité sonore à déclenchement par dialogue a été appliquée. Si l'intensité sonore du programme a été corrigée à l'aide du déclenchement de dialogue, la valeur du champ loudcorrdialgat est établie à « 1 ». Sinon, elle est établie à « 0 » ; loudcorrtyp : un champ d'un bit qui indique le type de correction d'intensité sonore appliqué au programme. Si l'intensité sonore du programme a été corrigée avec un processus de correction d'intensité sonore par anticipation infinie (à base de fichier) la valeur du champ loudcorrtyp est établie à « 0 ». Si l'intensité sonore du programme a été corrigée à l'aide d'une combinaison de mesure d'intensité sonore en temps réel et de contrôle de plage dynamique, la valeur de ce champ est établie à « 1 » ; loudrelgate : un champ d'un bit qui indique si les données d'intensité sonore à déclenchement relatif (UIT) existent. Si le champ loudrelgate est établi à « 1 », un champ loudrelgat de 7 bits devrait suivre dans la charge utile ; loudrelgat : un champ de 7 bits qui indique une intensité sonore de programme à déclenchement relatif (UIT). Ce champ indique l'intensité sonore intégrée du programme audio, mesurée selon la norme UIT-R BS.1770-2 sans application d'ajustement de gain dû à dialnorm et à la compression de plage dynamique.

Les valeurs de 0 à 127 sont interprétées comme -58 LKFS à +5,5 LKFS, dans des étapes de 0,5 LKFS ; loudspchgate : un champ d'un bit qui indique si les données d'intensité sonore à déclenchement de parole (UIT) existent. Si le champ loudspchgate est établi à « 1 », un champ loudspchgat de 7 bits devrait suivre dans la charge utile ; loudspchgat : un champ de 7 bits qui indique l'intensité sonore du programme de déclenchement de parole. Ce champ indique l'intensité sonore intégrée de la totalité du programme audio correspondant, mesurée selon la formule (2) de UIT-R BS.1770-3 et sans ajustement de gain dû à dialnorm et une compression de plage dynamique qui est appliquée. Les valeurs de 0 à 127 sont interprétées comme -58 à +5,5 LKFS, dans des étapes de 0,5 LKFS ; loudstrm3se : un champ d'un bit qui indique si des données d'intensité sonore à court terme (3 secondes) existent. Si le champ est établi à « 1 », un champ loudstrm3s de 7 bits devrait suivre dans la charge utile ; loudstrm3s : un champ de 7 bits qui indique l'intensité sonore sans déclenchement des 3 secondes précédentes du programme audio correspondant, mesurée selon UIT-R BS.1771-1 et sans application d'un ajustement de gain dû à dialnorm et à une compression de plage dynamique. Les valeurs de 0 à 256 sont interprétées comme -116 LKFS à +11,5 LKFS dans des étapes de 0,5 LKFS ; truepke : un champ d'un bit qui indique si les données d'intensité sonore de crête réelle existent. Si 30 le champ truepke est établi à « 1 », un champ truepk de 8 bits devrait suivre dans la charge utile ; et truepk : un champ de 8 bits qui indique la valeur d'échantillon de crête réelle du programme, mesurée selon l'annexe 2 de UIT-R BS.1770-3 et sans application d'un ajustement de gain dû dialnorm et à une compression de plage dynamique. Les valeurs de 0 à 256 sont interprétées en tant que -116 LKFS à +11,5 LKFS dans des étapes à 0,5 LKFS. Dans certains modes de réalisation, l'élément de coeur d'un segment de métadonnées dans un champ de données auxiliaires (ou champ « addbsi ») d'une trame d'un train de bits AC-3 ou d'un train de bits E-AC-3 comprend un en-tête de coeur (incluant typiquement des valeurs d'identification, par exemple, la version de l'élément de coeur), et après l'en-tête de coeur : des valeurs indiquant si les données d'empreinte digitale sont (ou d'autres valeurs de protection) incluses pour les métadonnées du segment de métadonnées, les valeurs indiquant si des données externes (relatives à des données audio correspondant aux métadonnées du segment de métadonnées) existent, les valeurs d'identifiant de charge utile et de taille de charge utile pour chaque type de métadonnées (par exemple, LPSM, et/ou métadonnées d'un type autre que la LPSM) identifié par l'élément de coeur, et des valeurs de protection pour au moins un type de métadonnées identifié par l'élément de coeur. La ou les charges utiles de métadonnées du segment de métadonnées suivent l'en-tête de coeur, et sont (dans certains cas) emboîtées dans des valeurs de l'élément de coeur.

Les modes de réalisation de la présente invention peuvent être mis en oeuvre dans un matériel, un micrologiciel, ou un logiciel ou une combinaison des deux (par exemple, en tant que réseau logique programmable). Sauf indication contraire, les algorithmes ou processus inclus en tant que partie de l'invention ne sont pas liés de manière inhérente à un ordinateur particulier ou autre appareil. En particulier, diverses machines universelles peuvent être utilisées avec des programmes écrits en conformité avec les enseignements indiqués ici, ou il peut être plus pratique de construire un appareil plus spécialisé (par exemple, des circuits intégrés) pour réaliser les étapes du procédé nécessaires. Ainsi, l'invention peut être mise en oeuvre dans un ou plusieurs programmes informatiques s'exécutant sur un ou plusieurs systèmes informatiques programmables (par exemple, une mise en oeuvre de l'un quelconque des éléments de la figure 1, ou du codeur 100 de la figure 2 (ou un élément de celui-ci), ou du décodeur 200 de la figure 3 (ou d'un élément de celui-ci), ou du post-processeur 300 de la figure 3 (ou d'un élément de celui-ci)) comprenant chacun au moins un processeur, au moins un système de stockage de données (incluant une mémoire volatile et non volatile et/ou des éléments de stockage), au moins un dispositif ou port d'entrée, et au moins un dispositif ou port de sortie. Un code de programme est appliqué pour entrer des données afin de réaliser les fonctions décrites ici et générer des informations de sortie. Les informations de sortie sont appliquées à un ou plusieurs dispositifs de sortie, de manière connue.

Chacun de ces programmes peut être mis en oeuvre dans tout langage informatique souhaité (incluant des langages machine, d'assemblage, ou procédural de haut niveau, logique ou de programmation orientée objet) afin de communiquer avec un système informatique. Dans tous les cas, le langage peut être un langage de compilation ou d'interprétation. Par exemple, lorsqu'elles sont mises en oeuvre par des séquences d'instruction de logiciel informatique, diverses fonctions et étapes de modes de réalisation de l'invention peuvent être mises en oeuvre par des séquences d'instruction de logiciel multi-filière exécutées dans un matériel de traitement de signaux numériques approprié, auquel cas, les divers dispositifs, étapes et fonctions des modes de réalisation peuvent correspondre à des portions des instructions de logiciel. Chacun de ces programmes informatiques est de préférence stocké ou téléchargé sur un support ou dispositif de stockage (par exemple, mémoire ou support à semi-conducteur, ou support magnétique ou optique) lisible par un ordinateur programmable universel ou spécialisé, permettant de configurer et d'exploiter l'ordinateur lorsque le support ou dispositif de stockage est lu par le système informatique pour réaliser les procédures décrites ici. Le système de l'invention peut également être mis en oeuvre en tant que support de stockage lisible par ordinateur, configuré avec (c'est-à-dire, stockant) un programme informatique, où le support de stockage ainsi configuré amène un système informatique à fonctionner de manière spécifique et prédéfinie afin de réaliser les fonctions décrites ici. Un certain nombre de modes de réalisation de l'invention ont été décrits. Néanmoins, on comprendra 5 que diverses modifications peuvent être réalisées sans s'éloigner de l'esprit et de la portée de l'invention. De nombreuses modifications et variations de la présente invention sont possibles à la lumière des enseignements ci-dessus. Il convient de comprendre que 10 dans la portée des revendications annexées, l'invention peut être utilisée en pratique d'une façon différente de celle décrite spécifiquement ici.

Claims (8)

1. REVENDICATIONS1. Appareil de traitement audio, caractérisé en ce qu'il comprend : une mémoire tampon d'entrée pour stocker au moins 5 une trame d'un train de bits audio codé comprenant une LPSM et des données audio ; un analyseur couplé à la mémoire tampon d'entrée pour extraire le train de bits audio codé et/ou la LPSM ; 10 un décodeur AC-3 ou E-AC-3 couplé à l'analyseur pour générer un flux de données audio décodées ; et une mémoire tampon de sortie couplée au décodeur pour stocker les données audio décodées. 15
2. 2. Appareil de traitement audio selon la revendication 1, comprenant en outre un processeur d'intensité sonore couplé au décodeur AC-3 ou E-AC-3 pour réaliser un traitement d'intensité sonore adaptatif du flux de données audio décodées à l'aide de 20 la LPSM.
3. 3. Appareil de traitement audio selon la revendication 2, comprenant en outre un validateur d'état audio couplé au décodeur AC-3 ou E-AC-3 pour 25 authentifier et/ou valider la LPSM et/ou le flux de données audio décodées à l'aide de la LPSM, dans lequel le validateur d'état audio est en outre couplé au processeur d'intensité sonore pour commander le traitement d'intensité sonore adaptatif du 30 processeur d'intensité sonore.
4. 4. Appareil de traitement audio selon la revendication 2, comprenant en outre un post-processeur couplé au décodeur AC-3 ou E-AC-3 pour réaliser un traitement d'intensité sonore adaptif sur le flux de données audio décodées à l'aide de la LPSM.
5. 5. Appareil de traitement audio selon la revendication 4, comprenant en outre un validateur 10 d'état audio couplé au décodeur AC-3 ou E-AC-3, pour authentifier et/ou valider la LPSM et/ou le flux de données audio décodées à l'aide de la LPSM, dans lequel le validateur d'état audio est en outre couplé au processeur d'intensité sonore et au 15 post-processeur pour commander le traitement d'intensité sonore adaptatif du processeur d'intensité sonore et du post-processeur.
6. 6. Appareil de traitement audio selon la 20 revendication 1, dans lequel la LPSM est un contenant d'une ou plusieurs métadonnées d'état de traitement d'intensité sonore situé après un en-tête dans l'au moins une trame. 25
7. 7. Appareil de traitement audio selon la revendication 1, dans lequel la LPSM comprend une fente de type régulation d'intensité sonore.
8. 8. Appareil de traitement audio selon la 30 revendication 1, dans lequel la LPSM comprend une fente de type correction d'intensité sonore.