FR3007564A3 - Decodeur audio avec metadonnees d'informations de programme - Google Patents

Abstract

Un dispositif électrique est décrit, lequel inclut une interface destinée à recevoir une trame de contenu audio codé, la trame incluant des métadonnées d'informations de programme situées dans un champ de saut de la trame, et des données audio codées situées en dehors du champ de saut. Une mémoire tampon est couplée à l'interface en vue de stocker temporairement la trame, et un analyseur est couplé à la mémoire tampon afin d'extraire les données audio codées de la trame. Un décodeur audio AC-3 est couplé ou intégré à l'analyseur en vue de générer du contenu audio décodé à partir des données audio codées.

Description

DÉCODEUR AUDIO AVEC MÉTADONNÉES D'INFORMATIONS DE PROGRAMME DESCRIPTION RENVOI AUX APPLICATIONS CONNEXES La présente demande revendique la priorité de la demande de brevet provisoire américaine n° 61/836,865, déposée le 19 juin 2013, intitulée « Audio Encoder and Decoder with Program Information or Substream Structure Metadata » (Codeur et décodeur audio avec métadonnées d'informations de programme ou métadonnées de structure de sous-flux) dont Jeffrey Riedmiller et Michael Ward sont les inventeurs.

DOMAINE TECHNIQUE La présente demande concerne des unités de traitement de signaux audio, et plus particulièrement, des décodeurs de flux binaires de données audio avec des métadonnées indiquant des informations de programme connexes à du contenu audio indiqué par les flux binaires. 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 le nom de « Dolby Digital » (format AC-3), « Dolby Digital Plus » (format « AC-3 » ou « E- AC-3 » optimisé) ou « Dolby E ». CONTEXTE « Dolby », « Dolby Digital », « Dolby Digital Plus » et « Dolby E » sont des marques déposées de 30 Dolby Laboratories Licensing Corporation. Dolby Laboratories fournit des mises en oeuvre propriétaires de AC-3 et E-AC-3 appelées « Dolby Digital » et « Dolby Digital Plus », respectivement. Les unités de traitement de signaux audio fonctionnent généralement de manière aveugle et ne tiennent pas compte de l'historique de traitement de données audio qui est occasionné avant la réception des données. Ceci peut fonctionner dans une infrastructure de traitement dans laquelle une entité unique prend en charge la totalité du traitement et du codage de données audio pour une multitude de dispositifs de rendu multimédia cibles, tandis qu'un dispositif de rendu multimédia cible prend en charge la totalité du décodage et du rendu des données audio codées. Toutefois, ce traitement à l'aveugle offre un fonctionnement médiocre (ou inexistant) dans les situations où une pluralité d'unités de traitement audio sont dispersées à travers un réseau diversifié ou sont placées en tandem (autrement dit, elles forment une chaîne) et doivent mettre en oeuvre de manière optimale leurs types respectifs de traitement audio. Par exemple, certaines données audio peuvent être codées pour les systèmes multimédias en 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 mettre en oeuvre un type de traitement sur les données audio, celui-ci ayant déjà été mis en oeuvre. Par exemple, une unité de nivellement du volume peut mettre en oeuvre un traitement sur un clip audio d'entrée, indépendamment du fait que le même nivellement de volume ou un nivellement similaire ait déjà été mis en oeuvre ou non sur le clip audio d'entrée. En conséquence, l'unité de nivellement du volume peut mettre en oeuvre un nivellement y compris lorsque celui-ci n'est pas nécessaire. Ce traitement inutile peut également occasionner une dégradation et/ou une suppression de fonctionnalités spécifiques lors du rendu du contenu des données audio.

Brève description Un dispositif électrique est décrit lequel inclut une interface destinée à recevoir une trame de contenu audio codé, la trame incluant des métadonnées d'informations de programme situées dans un champ de saut de la trame, et des données audio codées situées en dehors du champ de saut. Une mémoire tampon est couplée à l'interface afin de stocker temporairement la trame, et un analyseur est couplé à la mémoire tampon afin d'extraire les données audio codées de la trame.

Un décodeur audio AC-3 est couplé ou intégré à l'analyseur en vue de générer du contenu audio décodé à partir des données audio codées.

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é afin de mettre en oeuvre un mode de réalisation du procédé 5 inventif. La figure 2 est un schéma de principe d'un codeur qui représente un mode de réalisation de l'unité de traitement audio inventive. La figure 3 est un schéma de principe d'un 10 décodeur qui constitue un mode de réalisation de l'unité de traitement audio inventive, et d'un post-processeur couplé à celle-ci qui constitue un autre mode de réalisation de l'unité de traitement audio inventive. 15 La figure 4 est un schéma d'une trame AC-3, incluant les segments en lesquels elle est divisée. La figure 5 est un schéma du segment d'informations de synchronisation (SI) d'une trame AC3, incluant les segments en lesquels elle est divisée. 20 La figure 6 est un schéma du segment d'informations de flux binaire (BSI) d'une trame AC-3, incluant les segments en lesquels elle est divisée. La figure 7 est un schéma d'une trame E-AC-3, incluant les segments en lesquels elle est divisée. 25 La figure 8 est un schéma d'un segment de métadonnées d'un flux binaire codé généré selon un mode de réalisation de l'invention, incluant un entête de segment de métadonnées comprenant un mot de synchronisation de conteneur (identifié sous le nom de 30 « synchronisation de conteneur » dans la figure 8) et des valeurs d'identifiants de clés et de versions, suivies de plusieurs charges utiles de métadonnées et de bits de protection. Notation et nomenclature Dans la présente description, et notamment dans les revendications annexées, l'expression « métadonnées » (d'un flux binaire audio codé) renvoie à des données individuelles et distinctes des données audio correspondantes du flux binaire.

Dans la présente description, et notamment dans les revendications annexées, l'expression « métadonnées d'informations de programme » (ou « PIM ») désigne les métadonnées d'un flux binaire audio codé indiquant au moins un programme audio, où lesdites métadonnées indiquent au moins une propriété ou caractéristique de contenu audio d'au moins un dit programme (par exemple, les métadonnées indiquant un type ou un paramètre de traitement mis en oeuvre sur des données audio du programme ou les métadonnées indiquant quels canaux du programme sont des canaux actifs). Dans la présente description, et notamment dans les revendications annexées, l'expression « programme audio » désigne un ensemble d'un ou plusieurs canaux audio et facultativement les métadonnées associées (par exemple, les métadonnées qui décrivent une présentation audio spatiale souhaitée et/ou les métadonnées PIM). Dans la présente description, et notamment dans les revendications annexées, le terme « couple(nt) » ou « couplé(es) » est utilisé en vue de désigner une connexion directe ou indirecte. Par conséquent, si un premier dispositif est couplé à un second dispositif, cette connexion peut être mise en oeuvre par une connexion directe, ou par une connexion indirecte impliquant d'autres dispositifs et d'autres connexions.

Description détaillée des modes de réalisation de l'invention Un flux typique de données audio inclut à la fois du 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 flux binaire AC-3, il existe plusieurs paramètres de métadonnées audio qui sont spécifiquement destinés à être utilisés en vue de modifier le son du programme reproduit par un environnement d'écoute. L'un des paramètres de métadonnées est le paramètre « DIALNORM », lequel est destiné à indiquer le niveau moyen de dialogue dans un programme audio, et est utilisé en vue de déterminer le niveau du signal de lecture audio.

Bien que la présente invention ne soit pas limitée à une utilisation impliquant un flux binaire AC-3, un flux binaire E-AC-3, ou un flux binaire Dolby E, elle sera, pour plus de commodité, décrite en référence à des modes de réalisation dans lesquels elle génère, décode, ou encore traite un flux binaire de ce type. Un flux binaire codé AC-3 comprend des métadonnées et inclut de un à six canaux de contenu audio. Le contenu audio correspond à des données audio qui ont été compressées en utilisant un codage audio perceptuel. Les métadonnées incluent plusieurs paramètres de métadonnées audio qui sont destinés à être utilisés en vue de modifier le son d'un programme reproduit sur un environnement d'écoute. Chaque trame d'un flux binaire audio codé AC-3 contient du contenu audio et des métadonnées pour 1 536 échantillons de contenu audio numérique. Pour une fréquence d'échantillonnage de 48 kHz, ceci représente 32 millisecondes de contenu audio numérique, ou un débit de 31,25 trames par seconde de contenu audio. Chaque trame d'un flux binaire audio codé E-AC-3 contient du contenu audio et des métadonnées pour 256, 512, 768 ou 1536 échantillons de contenu audio numérique, selon que la trame contient un, deux, trois ou six blocs de données audio, respectivement. Pour une fréquence d'échantillonnage de 48 kHz, ceci représente 5,333, 10,667, 16 ou 32 millisecondes de contenu audio numérique, respectivement, ou un débit de 189,9, 93,75, 62,5 ou 31,25 trames par seconde de contenu audio, respectivement. Tel qu'indiqué dans la figure 4, chaque trame AC-3 est divisée en sections (ou segments), incluant : une section d'informations 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'informations de flux binaire (BSI), qui contient la plupart des métadonnées ; six blocs audio (ABO à AB5) qui contiennent du contenu audio à données compressées (et peuvent également inclure des métadonnées) ; des segments de bits de mise au rebut (W) (également connus sous le nom de « champs de saut ») qui contiennent des bits non utilisés subsistant suite à la compression du contenu audio ; une section d'informations auxiliaires (AUX) qui peut contenir d'autres métadonnées ; et le second des deux mots de correction d'erreur (CRC2). Tel qu'indiqué dans la figure 7, chaque trame E- AC-3 est divisée en sections (ou segments), incluant : une section d'informations de synchronisation (SI) qui contient (comme le montre la figure 5) un mot de synchronisation (SW) ; une section d'informations de flux binaire (BSI) qui contient la plupart des métadonnées ; entre un et six blocs audio (ABO à AB5) qui contiennent du contenu audio à données compressées (et peuvent également inclure des métadonnées) ; des segments de bits de mise au rebut (W) (également connus sous le nom de « champs de saut ») qui contiennent des bits non utilisés subsistant suite à la compression du contenu audio (bien qu'un seul segment de bits de mise au rebut ne soit montré, un segment de bit de mise au rebut ou segment de champs de saut différent devrait normalement suivre chaque bloc audio) ; une section d'informations auxiliaires (AUX) qui peut contenir d'autres métadonnées ; et un mot de correction d'erreur (CRC). Dans un flux binaire 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 lors de la modification du son du programme reproduit sur un environnement d'écoute. L'un des paramètres de métadonnées est le paramètre « DIALNORM », lequel est inclus dans le segment d'informations BSI.

Comme le montre la figure 6, le segment d'informations BSI d'une trame AC-3 inclut un paramètre de cinq bits (« DIALNORM ») indiquant la valeur « DIALNORM » du programme. Un paramètre de cinq bits (« DIALNORM2 ») indiquant la valeur « DIALNORM » d'un second programme audio transporté dans la même trame AC-3 est inclus si le mode de codage audio (« acmod ») de la trame AC-3 est « 0 », ce qui indique que la configuration de canal double-mono ou « 1+1 » est celle utilisée. Le segment d'informations BSI comprend également 10 un drapeau (« addbsie ») indiquant la présence (ou l'absence) d'informations de flux binaire supplémentaires suivant le bit « addbsie », un paramètre (« addbsil ») indiquant la longueur d'informations de flux binaire supplémentaires suivant 15 la valeur « addbsil », et jusqu'à 64 bits d'informations de flux binaire supplémentaires (« addbsi ») suivant la valeur « addbsil ». Le segment d'informations BSI inclut d'autres valeurs de métadonnées non spécifiquement montrées dans 20 la figure 6. Selon les modes de réalisation typiques de l'invention, les métadonnées PIM (et éventuellement d'autres métadonnées) sont intégrées dans un ou plusieurs champs réservés (ou tranches) de segments de 25 métadonnées d'un flux binaire audio (par exemple, le champ de saut) qui inclut également des données audio dans d'autres segments (les segments de données audio). Généralement, au moins un segment de chaque trame du flux binaire (par exemple, le champ de saut) inclut des 30 métadonnées PIM, et au moins un autre segment de la trame inclut des données audio correspondantes (c'est- à-dire, des données audio présentant au moins une caractéristique ou une propriété indiquée par les métadonnées PIM). Dans une classe de modes de réalisation, chaque segment de métadonnées représente une structure de données (parfois appelée « conteneur » dans la présente description) pouvant contenir une ou plusieurs charges utiles de métadonnées. Chaque charge utile comprend un entête incluant un identifiant de charge utile spécifique (et des données de configuration de charge utile), en vue de fournir une indication non ambigüe du type de métadonnées présentes dans la charge utile. L'ordre des charges utiles dans le conteneur n'est pas défini, de sorte que les charges utiles peuvent être stockées dans n'importe quel ordre, et un analyseur doit être en mesure d'analyser l'ensemble du conteneur en vue d'extraire les charges utiles pertinentes, et d'ignorer les charges utiles qui ne sont pas pertinentes ou ne sont pas prises en charge. La figure 8 (qui sera décrite ultérieurement) illustre la structure d'un tel conteneur et les charges utiles incluses dans le conteneur. La communication des métadonnées (par exemple, des métadonnées PIM) dans une chaîne de traitement de données audio est particulièrement utile lorsque deux unités de traitement audio ou plus doivent opérer mutuellement en tandem tout au long de la chaîne de traitement (ou du cycle de vie du contenu). À défaut de l'inclusion des métadonnées dans un flux binaire audio, de sérieux problèmes de traitement multimédia, par exemple des dégradations de la qualité, des dégradations de niveau et des dégradations spatiales peuvent se produire, par exemple, lorsque deux codecs audio ou plus sont utilisés dans la chaîne et qu'un nivellement de volume unilatéral est appliqué plus d'une fois sur un chemin de flux binaire vers un dispositif de consommation multimédia (ou un point de rendu du contenu audio du flux binaire). La figure 1 est un schéma de principe d'une chaîne de traitement audio exemplaire (un système de traitement de données audio), où un ou plusieurs des éléments du système peuvent être configurés selon un mode de réalisation de la présente invention. Le système comprend les éléments ci-dessous, mutuellement couplés comme suit : 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 variantes du système représenté, un ou plusieurs des éléments sont omis, ou des unités de traitement de données audio supplémentaires sont incluses. Dans certaines mises en oeuvre, l'unité de prétraitement de la figure 1 est configurée de manière à prendre en charge des échantillons de métadonnées PCM (domaine temporel) comprenant du contenu audio en tant qu'entrée, et à générer en sortie des échantillons de métadonnées PCM traités. Le codeur peut être configuré de manière à prendre en charge les échantillons de métadonnées PCM en tant qu'entrée, et à générer en sortie un flux binaire audio codé (par exemple, compressé) indiquant le contenu audio. Les données du flux binaire qui sont représentatives du contenu audio sont parfois appelées « données audio » dans le présent document. Si le codeur est configuré selon un mode de réalisation typique de la présente invention, le flux binaire audio généré en sortie par le décodeur inclut des métadonnées PIM ainsi que des données audio. L'unité de correction de métadonnées et d'analyse de signaux de la figure 1 peut prendre en charge un ou plusieurs flux binaires audio codés en entrée, et déterminer (par exemple, valider) si les métadonnées de chaque flux binaire audio codé sont correctes, en mettant en oeuvre une analyse de signaux. Si l'unité de correction de métadonnées et d'analyse de signaux constate que les métadonnées incluses ne sont pas valides, elle remplace généralement la ou les valeurs incorrectes par la ou les valeurs correctes obtenues à partir de l'analyse de signaux. Ainsi, chaque flux binaire audio codé généré 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 codées. Le décodeur de la figure 1 peut accepter des flux binaires audio codés (par exemple, compressés) en entrée, et (en réponse) générer en sortie des flux d'échantillons audio PCM décodés. Si le décodeur est 25 configuré selon un mode de réalisation typique de la présente invention, la sortie du décodeur, dans le cadre d'un fonctionnement normal, est ou comprend l'un des éléments ci-dessous : un flux d'échantillons audio, et au moins un flux 30 de métadonnées PIM correspondant (et en outre généralement d'autres métadonnées) extraits d'un flux binaire codé d'entrée ; ou un flux d'échantillons audio, et un flux correspondant de bits de commande déterminés à partir des métadonnées PIM (et généralement également d'autres métadonnées) extraites d'un flux binaire codé d'entrée ; ou un flux d'échantillons audio, sans flux correspondant de métadonnées ou de bits de commande déterminés à partir de métadonnées. Dans ce dernier cas, le décodeur peut extraire des métadonnées du flux binaire codé d'entrée et mettre en oeuvre au moins une opération sur les métadonnées extraites (par exemple, une validation), même s'il ne génère pas les métadonnées ou bits de commande extraits déterminés à partir de celles-ci. Lors de la configuration de l'unité de post-traitement de la figure 1 selon un mode de réalisation typique de la présente invention, l'unité de post-traitement est configurée de manière à prendre en charge, ou accepter, un flux d'échantillons audio PCM décodés, et à mettre en oeuvre un post-traitement à partir de cela (par exemple, un nivellement de volume du contenu audio) en utilisant les métadonnées PIM (et généralement d'autres métadonnées également) reçues avec les échantillons, ou les bits de commande déterminés par le décodeur à partir des métadonnées reçues avec les échantillons. L'unité de post-traitement est généralement également configurée de manière à rendre, ou à restituer, le contenu audio résultant du post-traitement, afin qu'il soit lu par un ou plusieurs haut-parleurs.

Des modes de réalisation typiques de la présente invention fournissent une chaîne de traitement audio améliorée, où les unités de traitement audio (par exemple, les codeurs, les décodeurs, les transcodeurs, 5 et les unités de prétraitement / post-traitement) adaptent leur traitement respectif à appliquer aux données audio selon un état simultané des données multimédias, tel qu'indiqué par les métadonnées respectivement reçues par les unités de traitement 10 audio. Les données audio appliquées à 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 PIM (et 15 éventuellement d'autres métadonnées également) ainsi que des données audio (par exemple, des données audio codées). Ces métadonnées ont été incluses dans le contenu audio d'entrée par un autre élément du système de la figure 1 (ou une autre source, non représentée 20 dans la figure 1) selon un mode de réalisation de la présente invention. L'unité de traitement qui reçoit le contenu audio d'entrée (avec des métadonnées) peut être configurée de manière à mettre en oeuvre au moins une opération sur les métadonnées (par exemple, une 25 validation), ou une opération en réponse aux métadonnées (par exemple, un traitement adaptif du contenu audio d'entrée), et généralement également à inclure dans son contenu audio de sortie, les métadonnées, une version traitée des métadonnées, ou 30 les bits de commande déterminés à partir des métadonnées.

La figure 2 est un schéma de principe d'un codeur (100) qui constitue un mode de réalisation de l'unité de traitement audio inventive. L'un quelconque des composants ou éléments du codeur 100 peut être mis en 5 oeuvre sous la forme d'un ou plusieurs processus et/ou d'un ou plusieurs circuits (par exemple, des circuits ASIC, FPGA, ou d'autres circuits intégrés), dans du matériel, des logiciels, ou une combinaison de matériel et de logiciels. Le codeur 100 comprend une mémoire 10 tampon de trames 110, un analyseur 111, un décodeur 101, un module de validation 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 formatage/remplissage 107, un étage de génération de 15 métadonnées 106, un sous-système de mesure d'intensité sonore de dialogue 108 et une mémoire tampon de trames 109, connectés tel qu'indiqué. Généralement, le codeur 100 inclut en outre d'autres éléments de traitement (non représentés). 20 Le codeur 100 (lequel est un transcodeur) est configuré de manière à convertir un flux binaire audio d'entrée (lequel peut, par exemple, être l'un parmi un flux binaire AC-3, un flux binaire E-AC-3, ou un flux binaire Dolby E) en un flux binaire audio de sortie 25 codé (lequel peut, par exemple, être un autre flux parmi un flux binaire AC-3, un flux binaire E-AC-3, ou un flux binaire Dolby E), notamment en mettant en oeuvre un traitement d'intensité sonore adaptatif et automatisé en utilisant les métadonnées d'état de 30 traitement d'intensité sonore, incluses dans le flux binaire d'entrée. Par exemple, le codeur 100 peut être configuré de manière à convertir un flux binaire Dolby E d'entrée (un format généralement utilisé dans les installations de production et de diffusion, mais non pris en charge par les dispositifs de consommation qui 5 reçoivent des programmes audio diffusés vers ces derniers) en un flux binaire audio de sortie codé (adapté à une diffusion sur les dispositifs de consommation) au format AC-3 ou E-AC-3. Le système de la figure 2 inclut également le 10 sous-système de distribution audio codé 150 (lequel stocke et/ou délivre les flux binaires codés générés en sortie par le codeur 100) et le décodeur 152. Un flux binaire audio codé généré en sortie par le codeur 100 peut être stocké par le sous-système 150 (par exemple, 15 sous la forme d'un disque DVD ou d'un disque Blu-Ray), ou peut être transmis par le sous-système 150 (lequel peut mettre en oeuvre une liaison ou un réseau de transmission), ou il peut être à la fois stocké et transmis par le sous-système 150. Le décodeur 152 est 20 configuré de manière à décoder un flux binaire audio codé (généré par le codeur 100) qu'il reçoit par l'intermédiaire du sous-système 150, notamment en extrayant des métadonnées (les métadonnées PIM, et éventuellement des métadonnées d'état de traitement 25 d'intensité sonore et/ou d'autres métadonnées) de chaque trame du flux binaire, et à générer des données audio décodées. Généralement, le décodeur 152 est configuré de manière à mettre en oeuvre un traitement adaptif sur les données audio décodées en utilisant les 30 métadonnées PIM, et/ou à acheminer les données audio décodées et les métadonnées à un post-processeur configuré de manière à mettre en oeuvre un traitement adaptif sur les données audio décodées en utilisant les métadonnées. Généralement, le décodeur 152 inclut une mémoire tampon qui stocke (par exemple, d'une manière non transitoire) le flux binaire audio codé reçu à partir du sous-système 150. Plusieurs mises en oeuvre du codeur 100 et du décodeur 152 sont configurées de manière à mettre en oeuvre divers modes de réalisation du procédé inventif.

La mémoire tampon de trames 110 est une mémoire tampon couplée de manière à recevoir un flux binaire audio d'entrée codé. En fonctionnement, la mémoire tampon 110 stocke (par exemple, d'une manière non transitoire) au moins une trame du flux binaire audio codé et une séquence des trames du flux binaire audio codé est appliquée de la mémoire tampon 110 à l'analyseur 111. L'analyseur 111 est couplé et configuré de manière à extraire les métadonnées PIM de chaque trame du contenu audio d'entrée codé dans laquelle ces métadonnées sont incluses, à extraire les données audio du contenu audio d'entrée codé, et à appliquer les données audio au décodeur 101. Le décodeur 101 du codeur 100 est configuré de manière à décoder les données audio en vue de générer des données audio décodées, et à appliquer les données audio décodées à l'étage de traitement d'intensité sonore 103, à l'étage de sélection de flux audio 104, au sous-système 108, et généralement également au module de validation d'état 102. Le module de validation d'état 102 est configuré de manière à authentifier et à valider les métadonnées qui lui ont été appliquées. Dans certains modes de réalisation, les métadonnées représentent (ou sont incluses dans) un bloc de données qui a été inclus dans le flux binaire d'entrée (par exemple, selon un mode de réalisation de la présente invention). Le bloc peut comporter un hachage cryptographique (un code d'authentification de message à base de hachage ou « HMAC ») destiné à traiter les métadonnées et/ou les données audio sous-jacentes (fournies du décodeur 101 au module de validation 102). 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 peut relativement facilement authentifier et valider les métadonnées d'état de traitement. Le module de validation d'état 102 applique les 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, en vue d'indiquer les résultats de l'opération de validation. En réponse aux données de commande, l'étage 104 peut choisir (et transmettre au codeur 105) la sortie traitée de manière adaptative de l'étage de traitement d'intensité sonore 103 ou les données audio générées en sortie par le décodeur 101. L'étage 103 du codeur 100 est configuré de manière à mettre en oeuvre un traitement d'intensité sonore adaptatif sur les données audio décodées générées en sortie par le décodeur 101, sur la base d'une ou plusieurs caractéristiques de données audio indiquées par les métadonnées 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 de domaine de transformation adaptatif. L'étage 103 peut recevoir une entrée d'utilisateur (par exemple, des valeurs cibles de plage dynamique et d'intensité sonore de l'utilisateur, ou les valeurs « dialnorm »), ou une autre entrée de métadonnées (par exemple, un ou plusieurs types de données tierces, d'informations de suivi, d'identifiants, d'informations propriétaires ou standard, des données d'annotation d'utilisateur, des données de préférence de l'utilisateur, etc.) et/ou une autre entrée (par exemple, d'un processus d'empreintes digitales), et utiliser ladite entrée pour traiter les données audio décodées générées en sortie par le décodeur 101. L'étage 103 peut mettre en oeuvre un traitement d'intensité sonore adaptatif sur les données audio décodées (générées en sortie par le décodeur 101) indiquant un programme audio unique, et peut réinitialiser le traitement d'intensité sonore en réponse à la réception de données audio décodées (générées en sortie par le décodeur 101) indiquant un programme audio différent. Le sous-système de mesure d'intensité sonore de dialogue 108 peut être exploité de manière à déterminer l'intensité sonore de segments du contenu audio décodé (par le décodeur 101) qui sont indicatifs d'un dialogue (ou d'un autre contenu vocal), par exemple, en utilisant les métadonnées extraites par le décodeur 101, lorsque les bits de commande provenant du 30 module de validation 102 indiquent que les métadonnées ne sont pas valides. L'opération du sous-système de mesure d'intensité sonore de dialogue 108 peut être désactivée lorsque les métadonnées indiquent des segments d'intensité sonore de dialogue (ou d'un autre contenu vocal) préalablement déterminés du contenu audio décodé (à partir du décodeur 101) lorsque les bits de commande provenant du module de validation 102 indiquent que les métadonnées sont valides. Le sous-système 108 peut mettre en oeuvre une mesure d'intensité sonore sur les données audio décodées indiquant un programme audio unique, et peut réinitialiser la mesure en réponse à la réception de données audio décodées indiquant un autre programme audio. Des outils utiles (par exemple, l'instrument de mesure d'intensité sonore Dolby LM100) existent, qui 15 permettent de mesurer le niveau de dialogue dans du contenu audio, de manière simple et conviviale. Certains modes de réalisation de l'unité APU inventive (par exemple, l'étage 108 du codeur 100) sont mis en oeuvre de manière à inclure un tel outil, ou à prendre 20 en charge les fonctions dudit outil, en vue de mesurer l'intensité sonore de dialogue moyenne du contenu audio d'un flux binaire audio (par exemple, un flux binaire AC-3 décodé appliqué à l'étage 108 à partir du décodeur 101 du codeur 100). 25 Si l'étage 108 est mis en oeuvre en vue de mesurer l'intensité sonore de dialogue moyenne réelle des données audio, la mesure peut inclure une étape consistant à isoler les segments du contenu audio qui contiennent principalement du contenu vocal. Les 30 segments audio qui représentent principalement du contenu vocal sont ensuite traités selon un algorithme de mesure d'intensité sonore. Pour des données audio décodées à partir d'un flux binaire AC-3, cet algorithme peut être une mesure d'intensité sonore pondérée par k standard (conformément à la norme internationale ITU-R BS.1770). Alternativement, d'autres mesures d'intensité sonore peuvent être utilisées (par exemple celles basées sur des modèles psychoacoustiques d'intensité sonore). Le générateur de métadonnées 106 génère (et/ou transmet à l'étage 107) des métadonnées destinées à être incluses par l'étage 107 dans le flux binaire codé devant être généré en sortie par le codeur 100. Le générateur de métadonnées 106 peut transmettre à l'étage 107 les métadonnées (et éventuellement également des métadonnées PIM) extraites par le codeur 101 et/ou l'analyseur 111 (par exemple, lorsque les bits de commande provenant du module de validation 102 indiquent que les métadonnées sont valides), ou générer de nouvelles métadonnées PIM et/ou d'autres métadonnées et appliquer les nouvelles métadonnées à l'étage 107 (par exemple, lorsque les bits de commande provenant du module de validation 102 indiquent que les métadonnées extraites par le décodeur 101 ne sont pas valides), ou il peut appliquer à l'étage 107 une combinaison de métadonnées extraites par le décodeur 101 et/ou l'analyseur 111 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 indicative du type de traitement d'intensité sonore mis en oeuvre par le sous-système 108.

Le générateur de métadonnées 106 peut générer des bits de protection (qui peuvent inclure ou être constitués d'un code d'authentification de message à base de hachage ou « HMAC ») utile pour au moins l'un des processus parmi le déchiffrement, l'authentification, ou la validation des métadonnées à inclure dans le flux binaire codé et/ou des données audio sous-jacentes à inclure dans le flux binaire codé. Le générateur de métadonnées 106 peut fournir lesdits bits de protection à l'étage 107 afin qu'ils soient inclus dans le flux binaire codé. En fonctionnement normal, le sous-système de mesure d'intensité sonore de dialogue 108 traite les données audio générées en sortie par le décodeur 101 en vue de générer en réponse des valeurs d'intensité sonore (par exemple, des valeurs d'intensité sonore de dialogue dépendantes ou indépendantes) 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 à inclure (par le module de formatage/remplissage 107) dans le flux binaire codé devant être généré en sortie par le codeur 100. Le codeur 105 code (par exemple, en effectuant une compression sur celles-ci), les données audio générées en sortie par l'étage de sélection 104, et applique le contenu audio codé à l'étage 107 en vue d'une inclusion dans le flux binaire codé devant être généré en sortie par l'étage 107.

L'étage 107 multiplexe le contenu audio codé provenant du codeur 105 et les métadonnées (y compris les métadonnées PIM) provenant du générateur 106, en vue de générer le flux binaire codé devant être généré en sortie à partir de l'étage 107, de préférence de sorte que le flux binaire codé présente un format spécifié par un mode de réalisation préféré de la présente invention. La mémoire tampon de trames 109 est une mémoire tampon qui stocke (par exemple, de manière non transitoire) au moins une trame du flux binaire audio codé généré en sortie par l'étage 107, et une séquence des trames du flux binaire audio codé est ensuite appliquée par la mémoire tampon 109 en tant que sortie du codeur 100 vers le système de distribution 150. Dans certaines mises en oeuvre du codeur 100, le flux binaire codé mis en mémoire tampon dans la mémoire 109 (et généré en sortie vers le système de distribution 150) est un flux binaire AC-3 ou un flux binaire E-AC-3, et comprend des segments de données audio (par exemple, les segments ABO - AB5 de la trame montrée dans la figure 4) ainsi que des segments de métadonnées, où les segments de données audio sont représentatifs de données audio, et chacun d'au moins certains des segments de métadonnées comporte des métadonnées PIM (et éventuellement également d'autres métadonnées). L'étage 107 insert les segments de métadonnées (y compris les métadonnées) dans le flux binaire au format suivant. Chacun des segments de métadonnées qui inclut des métadonnées PIM est inclus dans un segment de bits de mise au rebut du flux binaire (également appelé « champ de saut ») (par exemple, un segment de bits de mise au rebut « W » tel que montré dans la figure 4 ou dans la figure 7), ou dans un champ « addbsi » du segment d'informations de flux binaire (« BSI ») d'une trame du flux binaire, ou dans un champ de données auxiliaires « auxdata » (par exemple, le segment « AUX » montré dans la figure 4 ou dans la figure 7) à la fin d'une trame du flux binaire. Une trame du flux binaire peut inclure un ou deux segments de métadonnées, dont chacun comprend des métadonnées, et si la trame comprend deux segments de métadonnées, l'un des segments peut être présent dans le champ « addbsi » de la trame, et l'autre dans le champ « AUX » de la trame. Dans certains modes de réalisation, chaque segment de métadonnées (lesquels sont parfois appelés « conteneur » dans le présent document) inséré par l'étage 107 présente un format qui inclut un entête de segment de métadonnées (et éventuellement d'autres éléments obligatoires ou « de base »), et une ou plusieurs charges utiles de métadonnées qui suivent l'entête de segment de métadonnées. Les métadonnées PIM, le cas échéant, sont incluses dans une première charge utile des charges utiles de métadonnées (identifiée par un entête de charge utile et présentant généralement un format d'un premier type). De même, chaque autre type de métadonnées (le cas échéant) est inclus dans une autre des charges utiles de métadonnées (identifiée par un entête de charge utile et présentant généralement un format spécifique au type de métadonnées). Le format exemplaire permet un accès facile aux métadonnées PIM et à d'autres métadonnées, à d'autres moments que lors du décodage (par exemple, par un post-processeur après décodage, ou par un processeur configuré de manière à reconnaître les métadonnées sans effectuer de décodage complet sur le flux binaire codé), et il permet une détection et correction d'erreur conviviale et efficace (par exemple, de l'identification de sous-flux) lors du décodage du flux binaire. Une charge utile de métadonnées dans un segment de métadonnées peut inclure des métadonnées PIM, une autre charge utile de métadonnées dans le segment de métadonnées peut inclure un second type de métadonnées, et en outre éventuellement au moins une autre charge utile de métadonnées dans le segment de métadonnées peut inclure d'autres métadonnées (par exemple, des métadonnées d'état de traitement d'intensité sonore ou « LPSM »). Dans certains modes de réalisation, une charge utile de métadonnées d'informations de programme (PIM) incluse (par l'étage 107) dans une trame d'un flux binaire codé (par exemple, un flux binaire AC-3 indicatif d'au moins un programme audio) présente le format suivant : un entête de charge utile, comprenant généralement au moins une valeur d'identification (par exemple, une valeur indicative de la version du format des métadonnées PIM, et éventuellement des valeurs de longueur, de période, de comptage, et d'association de sous-flux) ; et après l'entête, les métadonnées PIM au format suivant : des métadonnées de canal actif indicatives de chaque canal silencieux et de chaque canal non silencieux d'un programme audio (autrement dit, qui indiquent quel canal ou quels canaux du programme contiennent des informations audio, et quel canal ou quels canaux (le cas échéant) ne contiennent que du contenu silencieux (généralement pendant toute la durée de la trame)). Dans des modes de réalisation dans lesquels le flux binaire codé est un flux binaire AC-3 ou E-AC-3, les métadonnées de canal actif dans une trame du flux binaire peuvent être utilisées conjointement avec des métadonnées supplémentaires du flux binaire (par exemple, le champ de mode de codage audio (« acmod ») de la trame, et, le cas échéant, le champ « chanmap » dans la trame ou dans une ou des trames de sous-flux dépendants associés, en vue de déterminer quel canal ou quels canaux du programme contiennent des informations audio et quel canal ou quels canaux contiennent du contenu silencieux. Le champ « acmod » d'une trame AC-3 ou E-AC-3 indique le nombre de canaux de plage complète d'un programme audio indiqué par le contenu audio de la trame (par exemple, ce champ indique si le programme est un programme monophonique de canal 1.0, un programme stéréophonique de canal 2.0, ou un programme comprenant des canaux de plage complète L, R, C, Ls, Rs), ou si la trame est indicative de deux programmes monophoniques de canal 1.0 indépendants. Un champ « chanmap » d'un flux binaire E-AC-3 indique une mise en concordance de canaux pour un sous-flux dépendant indiqué par le flux binaire. Les métadonnées de canal actif peuvent être utiles pour la mise en oeuvre d'un mixage ascendant (dans un post-processeur) en aval d'un décodeur, par exemple, pour ajouter du contenu audio à des canaux qui contiennent du contenu silencieux à la sortie du décodeur ; des métadonnées d'état de traitement de mixage descendant indiquant si le programme a été sous-mixé (avant ou lors du codage), et le cas échéant, le type de mixage descendant qui a été appliqué. Les métadonnées d'état de traitement de mixage descendant peuvent être utiles pour la mise en oeuvre d'un mixage ascendant (dans un post-processeur) en aval d'un décodeur, par exemple pour surmixer le contenu audio du programme en utilisant les paramètres qui correspondent le plus étroitement à un type de mixage descendant ayant été appliqué. Dans les modes de réalisation où le flux binaire codé est un flux binaire AC-3 ou E-AC-3, les métadonnées d'état de traitement de mixage descendant peuvent être utilisées conjointement avec le champ de mode de codage audio (« acmod ») de la trame, en vue de déterminer le type de mixage descendant (le cas échéant) appliqué au canal ou aux canaux du programme ; des métadonnées d'état de traitement de mixage ascendant indiquant si le programme a été surmixé (par exemple, à partir d'un nombre inférieur de canaux) avant ou pendant le codage, et le cas échéant, le type 25 de mixage ascendant qui a été appliqué. Les métadonnées d'état de traitement de mixage ascendant peuvent être utiles pour la mise en oeuvre d'un mixage descendant (dans un post-processeur) en aval d'un décodeur, par exemple en vue du mixage descendant du contenu audio du 30 programme d'une manière compatible avec un type de mixage ascendant (par exemple, « Dolby Pro Logic » ou « Dolby Pro Logic II Movie Mode », ou « Dolby Pro Logic II Music Mode » ou « Dolby Professional Upmixer ») qui a été appliqué au programme. Dans les modes de réalisation dans lesquels le flux binaire codé est un flux binaire E-AC-3, les métadonnées d'état de traitement de mixage ascendant peuvent être utilisées conjointement avec d'autres métadonnées (par exemple, la valeur d'un champ « strmtyp » de la trame) en vue de déterminer le type de mixage ascendant (le cas échéant) appliqué au canal ou aux canaux du programme. La valeur du champ « strmtyp » (dans le segment d'informations BSI d'une trame d'un flux binaire E-AC-3) indique si le contenu audio de la trame appartient à un flux indépendant (lequel détermine un programme) ou à un sous-flux indépendant (d'un programme qui inclut ou est associé à de multiples sous-flux) et s'il peut par conséquent être décodé indépendamment de tout autre sous-flux indiqué par le flux binaire E-AC-3, ou si le contenu audio de la trame appartient à un sous-flux dépendant (d'un programme qui inclut ou est associé à de multiples sous-flux) et qui doit par conséquent être décodé conjointement avec un sous-flux indépendant auquel il est associé ; et des métadonnées d'état de prétraitement indiquant si un prétraitement a été mis en oeuvre sur du contenu audio de la trame (avant le codage du contenu audio destiné à générer le flux binaire codé), et le cas échéant, le type de prétraitement mis en oeuvre. Dans certaines mises en oeuvre, les métadonnées 30 d'état de prétraitement indiquent : si une atténuation de pseudo-quadriphonie a été appliquée (par exemple, si les canaux de pseudoquadriphonie du programme audio ont été atténués de 3 dB avant le codage) ; si un déphasage de 90 degrés a été appliqué (par 5 exemple, aux canaux de pseudo-quadriphonie Ls et Rs du programme audio avant le codage) ; si un filtre passe-bas a été appliqué à un canal LFE du programme audio avant le codage ; si le niveau d'un canal LFE du programme a été 10 surveillé au cours de la production et, le cas échéant, le niveau surveillé du canal LFE par rapport au niveau des canaux audio de plage complète du programme ; si une compression de plage dynamique doit être mise en oeuvre (par exemple, dans le décodeur) sur 15 chaque bloc de contenu audio décodé du programme, et le cas échéant, le type (et/ou les paramètres) de compression de plage dynamique à mettre en oeuvre (par exemple, ce type de métadonnées d'état de prétraitement peut indiquer quel type parmi les types de profils de 20 compression ci-après a été pris en charge par le codeur en vue de générer des valeurs de contrôle de compression de plage dynamique qui sont incluses dans le flux binaire codé : « Film Standard », « Film Light », « Music Standard », « Music Light », ou 25 « Speech ». Par ailleurs, ce type de métadonnées d'état de prétraitement peut indiquer qu'une compression de plage dynamique approfondie (compression « compr ») doit être mise en oeuvre sur chaque trame de contenu audio décodé du programme d'une manière déterminée par 30 les valeurs de contrôle de compression de plage dynamique qui sont incluses dans le flux binaire codé), si un codage de traitement d'extension spectrale et/ou un codage de couplage de canaux a/ont été utilisé(s) en vue de coder les plages de fréquences spécifiques du contenu du programme, et le cas échéant, les fréquences minimales et maximales des composantes de fréquence du contenu sur lequel le codage d'extension spectrale a été mis en oeuvre, et les fréquences minimales et maximales des composantes de fréquence du contenu sur lequel le codage de couplage de canaux a été mis en oeuvre. Ce type d'informations de métadonnées d'état de prétraitement peut être utile pour exécuter une égalisation (dans un post-processeur) en aval d'un décodeur. Les informations de couplage de canaux et les informations d'extension spectrale sont également utiles en vue d'optimiser la qualité lors des opérations et applications de transcodage. Par exemple, un codeur peut optimiser son propre comportement (y compris l'adaptation des étapes de prétraitement comme la virtualisation d'écouteurs, le mixage ascendant, etc.) en fonction de l'état de paramètres comme les informations d'extension spectrale et les informations de couplage de canaux. Par ailleurs, le codeur peut adapter dynamiquement ses paramètres d'extension spectrale ou de couplage à des valeurs optimales, ou afin qu'ils correspondent à des valeurs optimales, sur la base de l'état des métadonnées entrantes (et authentifiées) ; et si des données de plage de réglage d'amélioration de dialogue sont incluses dans le flux binaire codé, et 30 le cas échéant, la plage de réglage disponible au cours de l'exécution du traitement d'amélioration de dialogue (par exemple, dans un post-processeur en aval d'un décodeur), en vue d'ajuster le niveau du contenu de dialogue par rapport au niveau du contenu sans dialogue dans le programme audio.

Dans certaines mises en oeuvre, des métadonnées d'état de prétraitement supplémentaires (par exemple, des métadonnées indicatives de paramètres connexes au casque d'écoute ou écouteurs) sont incluses (par l'étage 107) dans une charge utile de métadonnées PIM d'un flux binaire codé devant être généré en sortie par le codeur 100. Chaque charge utile de métadonnées suit les valeurs de configuration de charge utile et d'identifiant de charge utile correspondantes.

Dans certains modes de réalisation, chacun des segments de métadonnées dans le segment de bit de mise au rebut / champs de saut (ou champ « auxdata » ou « addbsi ») d'une trame dispose de trois niveaux de structure : une structure de haut niveau (par exemple, un entête de segment de métadonnées), incluant un drapeau indiquant si le champ de bits de mise au rebut (ou « auxdata » ou « addbsi ») inclut des métadonnées, au moins une valeur d'identifiant indiquant quel(s) type(s) de métadonnées est/sont présent(s), et généralement également une valeur indiquant combien de bits de métadonnées (par exemple, de chaque type) sont présents (dans l'éventualité où des métadonnées seraient présentes). Un type de métadonnées pouvant être présent concerne les métadonnées PIM, un autre type de métadonnées pouvant être présent concerne les métadonnées LSPM ; une structure de niveau intermédiaire, comprenant des données associées à chaque type identifié de métadonnées (par exemple, un entête de charge utile de métadonnées, des valeurs de protection, et des valeurs de configuration de charge utile et identifiant de charge utile pour chaque type de métadonnées identifié) ; et une structure de bas niveau, comprenant une charge utile de métadonnées pour chaque type identifié de métadonnées (par exemple, une séquence de valeurs de métadonnées PIM, s'il est déterminé que des métadonnées PIM sont présentes, et/ou des valeurs de métadonnées d'un autre type (par exemple, LSPM), si cet autre type de métadonnées est identifié comme étant présent). Les valeurs des données dans une telle structure à trois niveaux peuvent être imbriquées. Par exemple, la ou les valeurs de protection pour chaque charge utile (par exemple, chaque charge utile de métadonnées PIM ou chaque autre charge utile de métadonnées) identifiées par les structures de haut niveau et de niveau intermédiaire peuvent être incluses après la charge utile (et par conséquent après l'entête de charge utile de métadonnées de la charge utile), ou la ou les valeurs de protection pour toutes les charges utiles de métadonnées identifiées par les structures de haut niveau et de niveau intermédiaire peuvent être incluses après la charge utile de métadonnées finale dans le segment de métadonnées (et par conséquent après les entêtes de charge utile de métadonnées de toutes les charges utiles du segment de métadonnées).

Dans un exemple (qui sera décrit en référence au segment de métadonnées ou « conteneur » de la figure 8), un entête de segment de métadonnées identifie quatre charges utiles de métadonnées. Comme le montre la figure 8, l'entête de segment de métadonnées comprend un mot de synchronisation de conteneur (appelé ici « synchronisation de conteneur ») et des valeurs d'identifiants de clés et de version. L'entête de segment de métadonnées est suivi des quatre charges utiles de métadonnées et des bits de protection. Les valeurs de configuration de charge utile et d'identifiant de charge utile (par exemple, la taille de la charge utile) de la première charge utile (par exemple, une charge utile de métadonnées PIM) suivent l'entête de segment de métadonnées, la première charge utile elle-même suit les valeurs de configuration et d'identifiant, les valeurs de configuration de charge utile et d'identifiant de charge utile (par exemple, la taille de la charge utile) de la deuxième charge utile (par exemple, une charge utile de métadonnées PIM) suivent la première charge utile, la deuxième charge utile elle-même suit ces valeurs de configuration et d'identifiant, les valeurs de configuration de charge utile et d'identifiant de charge utile (par exemple, la taille de la charge utile) de la troisième charge utile (par exemple, la charge utile des métadonnées d'état de traitement d'intensité sonore) suivent la deuxième charge utile, la troisième charge utile elle-même suit ces valeurs de configuration et d'identifiant, les valeurs de configuration de charge utile et d'identifiant de charge utile (par exemple, la taille de la charge utile) de la quatrième charge utile, suivent la troisième charge utile, la quatrième charge utile elle-même suit ces valeurs de configuration et 5 d'identifiant, et une ou des valeurs de protection (identifiées en tant que « données de protection » dans la figure 8) pour tout ou partie des charges utiles (ou pour la structure de haut niveau et de niveau intermédiaire et tout ou partie des charges utiles) 10 suivent la dernière charge utile. La figure 3 est un schéma de principe d'un décodeur (200) qui constitue un mode de réalisation de l'unité de traitement audio inventive, et d'un post-processeur (300) couplé à celle-ci. Le post-processeur 15 (300) constitue également un mode de réalisation de l'unité de traitement audio inventive. Les composants ou éléments du décodeur 200 et du post-processeur 300 peuvent être mis en oeuvre sous la forme d'un ou plusieurs processus et/ou d'un ou plusieurs circuits 20 (par exemple, des circuits ASIC, FPGA, ou d'autres circuits intégrés), dans du matériel, des logiciels, ou une combinaison de matériel et de logiciels. Le décodeur 200 comporte une mémoire tampon de trames 201, un analyseur 205, un décodeur audio 202, un étage de 25 validation d'état audio (module de validation) 203, et un étage de génération de bits de commande 204, connectés tel qu'indiqué. Généralement, le décodeur 200 comprend également d'autres éléments de traitement (non représentés). 30 La mémoire tampon de trames 201 stocke (par exemple, d'une manière non transitoire) au moins une trame du flux binaire audio codé reçu par le décodeur 200. Une séquence des trames du flux binaire audio codé est appliquée de la mémoire tampon 201 à l'analyseur 205.

L'analyseur 205 est couplé et configuré de manière à extraire des métadonnées PIM (et éventuellement d'autres métadonnées) de chaque trame du contenu audio d'entrée codé, en vue d'appliquer au moins certaines des métadonnées (par exemple, les métadonnées PIM) au module de validation d'état audio 203, et à l'étage 204, en vue d'appliquer les métadonnées extraites en sortie (par exemple, au post-processeur 300), afin d'extraire des données audio du contenu audio d'entrée codé, et d'appliquer les données audio extraites au décodeur 202. Le flux binaire audio codé appliqué au décodeur 200 peut être l'un parmi un flux binaire AC-3, un flux binaire E-AC-3, ou un flux binaire Dolby E. Le système de la figure 3 inclut également le post-processeur 300. Le post-processeur 300 comporte la mémoire tampon de trames 301 et d'autres éléments de traitement (non représentés) incluant au moins un élément de traitement couplé à la mémoire tampon 301. La mémoire tampon de trames 301 stocke (par exemple, d'une manière non transitoire) au moins une trame du flux binaire audio décodé reçu par le post-processeur 300 à partir du décodeur 200. Des éléments de traitement du post-processeur 300 sont couplés et configurés de manière à recevoir et à traiter de façon adaptative une séquence des trames du flux binaire audio décodé généré en sortie par la mémoire tampon 301, en utilisant des métadonnées générées en sortie par le décodeur 200 et/ou des bits de commande générés en sortie par l'étage 204 du décodeur 200. Généralement, le post-processeur 300 est configuré de manière à mettre en oeuvre un traitement adaptif sur les données audio décodées en utilisant des métadonnées provenant du décodeur 200 (par exemple, un traitement d'intensité sonore adaptatif sur les données audio décodées en utilisant des valeurs de métadonnées, où le traitement adaptif peut être basée sur un état de traitement d'intensité sonore, et/ou une ou plusieurs caractéristiques de données audio, indiquées par des métadonnées de données audio indicatives d'un programme audio unique).

Plusieurs mises en oeuvre du décodeur 200 et du post-processeur 300 sont configurées de manière à mettre en oeuvre divers modes de réalisation du procédé inventif. Dans certaines mises en oeuvre du décodeur 200, le flux binaire codé reçu (et mis en mémoire tampon dans la mémoire 201) est un flux binaire AC-3 ou un flux binaire E-AC-3, et comprend des segments de données audio (par exemple, les segments ABO - AB5 de la trame représentée dans 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 comprend des métadonnées PIM (ou d'autres métadonnées). L'étage de décodeur 202 (et/ou d'analyseur 205) est configuré de manière à extraire les métadonnées du flux binaire. Chacun des segments de métadonnées qui comprend des métadonnées PIM (et éventuellement d'autres métadonnées) est inclus dans un segment de bits de mise au rebut d'une trame du flux binaire, ou dans un champ « addbsi » du segment d'informations de flux binaire (« BSI ») d'une trame du flux binaire, ou dans un champ « auxdata » (par exemple, le segment « AUX » représenté dans la figure 4) à la fin d'une trame du flux binaire. Une trame du flux binaire peut inclure un ou deux segments de métadonnées, dont chacun comprend des métadonnées, et si la trame comprend deux segments de métadonnées, l'un des segments peut être présent dans le champ « addbsi » de la trame, et l'autre dans le champ « AUX » de la trame. Les modes de réalisation de la présente invention peuvent être mis en oeuvre dans du matériel, un micrologiciel ou des logiciels, ou une combinaison de cela (par exemple, sous la forme d'un réseau logique programmable). En outre, les unités de traitement audio décrites dans le présent document peuvent faire partie de et/ou être intégrées à différents dispositifs de communication, par exemple des téléviseurs, des téléphones mobiles, des ordinateurs personnels, des ordinateurs-tablettes, des ordinateurs portables, des décodeurs et des récepteurs audio / vidéo. Sauf indication contraire, les algorithmes ou les processus inclus dans le cadre de l'invention ne sont pas intrinsèquement liés à un ordinateur en particulier ou à un autre appareil. En particulier, diverses machines à usage générique peuvent être utilisées avec des programmes écrits selon les enseignements du présent document, ou encore il peut être plus commode de construire des appareils plus spécialisés (par exemple, des circuits intégrés) en vue de mettre en oeuvre les étapes de procédé requises. Ainsi, la présente 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 connexe), ou du décodeur 200 de la figure 3 (ou un élément connexe), ou du post-processeur 300 de la figure 3 (ou un élément connexe)) comprenant chacun au moins un processeur, au moins un système de stockage de données (y compris une mémoire volatile ou non volatile et/ou des éléments de stockage), au moins un dispositif d'entrée ou un port d'entrée, et au moins un dispositif de sortie ou un port de sortie. Le code de programme est appliqué à des données d'entrée en vue de mettre en oeuvre les fonctions décrites dans le présent document et de générer des informations de sortie. Les informations de sortie sont appliquées à un ou plusieurs dispositifs de sortie, d'une manière connue. Chacun de ces programmes peut être mis en oeuvre en utilisant un quelconque langage de programmation désiré (y compris des langages machine, d'assemblage ou des langages de programmation procédurale, logique, ou orientée objet, de haut niveau) en vue de communiquer avec un système informatique. Dans tous les cas, le langage peut être un langage compilé ou interprété.

Par exemple, lorsqu'elles sont mises en oeuvre par des séquences d'instructions de logiciels informatiques, les différentes fonctions et étapes des modes de réalisation de l'invention peuvent être mises en oeuvre par des séquences d'instructions logicielles de programme à plusieurs branches, s'exécutant dans du matériel de traitement de signal numérique approprié, auquel cas, les divers dispositifs, diverses étapes et fonctions des modes de réalisation peuvent correspondre à des parties des instructions logicielles. Chaque dit programme informatique est de préférence stocké ou téléchargé sur un support de stockage ou un dispositif de stockage (par exemple, un support ou une mémoire à semi-conducteur, ou un support magnétique ou optique) lisible par un ordinateur programmable à usage général ou spécifique, en vue de configurer et d'exploiter l'ordinateur lorsque le support ou dispositif de stockage est lu par le système informatique en vue de mettre en oeuvre les procédures décrites dans le présent document. Le système selon l'invention peut également être mis en oeuvre sous la forme d'un support de stockage lisible par ordinateur, configuré avec (autrement dit, stockant) un programme informatique, où le support de stockage ainsi configuré amène un système informatique à fonctionner d'une manière spécifique et prédéfinie en vue d'exécuter les fonctions décrites dans le présent document. Plusieurs modes de réalisation de l'invention ont été décrits. Néanmoins, il est entendu que diverses modifications peuvent être apportées sans s'écarter de l'esprit et de la portée de la présente invention. De nombreuses modifications et variantes de la présente invention sont possibles à la lumière des enseignements susmentionnés. Il doit être compris que dans la portée des revendications annexées, l'invention peut être mise en pratique autrement que de la manière spécifiquement décrite dans la présente description.5

Claims (10)

1. REVENDICATIONS1. Dispositif électrique, comprenant : une interface destinée à recevoir une trame de 5 contenu audio codé, dans lequel la trame comprend des métadonnées d'informations de programme situées dans un champ de saut de la trame et des données audio codées situées en dehors du champ de saut ; une mémoire tampon couplée à l'interface en vue de 10 stocker temporairement la trame ; un analyseur couplé à la mémoire tampon en vue d'extraire les données audio codées de la trame ; et un décodeur audio AC-3 couplé ou intégré à l'analyseur, en vue de générer du contenu audio décodé 15 à partir des données audio codées.
2. 2. Dispositif électrique selon la revendication 1, dans lequel les métadonnées d'informations de programme incluent une charge utile de métadonnées, et la charge 20 utile inclut un entête, et après l'entête, au moins certaines des métadonnées d'informations de programme.
3. 3. Dispositif électrique selon la revendication 1, dans lequel le contenu audio codé est indicatif d'un 25 programme audio, et les métadonnées d'informations de programme sont indicatives d'au moins une propriété ou caractéristique de contenu audio du programme audio.
4. 4. Dispositif électrique selon la revendication 3, 30 dans lequel les métadonnées d'informations de programme incluent des métadonnées de canal actif indicatives dechaque canal non silencieux et de chaque canal silencieux du programme audio.
5. 5. Dispositif électrique selon la revendication 3, dans lequel les métadonnées d'informations de programme incluent des métadonnées d'état de traitement de mixage descendant indiquant si le programme audio a été sous-mixé, et le cas échéant, un type de mixage descendant qui a été appliqué au programme audio.
6. 6. Dispositif électrique selon la revendication 3, dans lequel les métadonnées d'informations de programme incluent des métadonnées d'état de traitement de mixage ascendant indiquant si le programme audio été surmixé, et le cas échéant, un type de mixage ascendant qui a été appliqué au programme audio.
7. 7. Dispositif électrique selon la revendication 3, dans lequel les métadonnées d'informations de programme incluent des métadonnées d'état de prétraitement indiquant si un prétraitement a été mis en oeuvre sur du contenu audio de la trame, et le cas échéant, un type de prétraitement qui a été mis en oeuvre sur le contenu audio.
8. 8. Dispositif électrique selon la revendication 3, dans lequel les métadonnées d'informations de programme incluent des métadonnées de couplage de canaux ou de traitement d'extension spectrale indiquant si un traitement d'extension spectrale ou un couplage de canaux a été appliqué au programme audio, et le caséchéant, une plage de fréquences à laquelle l'extension spectrale ou le couplage de canaux a été appliqué.
9. 9. Dispositif électrique selon la revendication 1, 5 dans lequel le contenu audio codé est un flux binaire AC-3.
10. 10. Dispositif électrique selon la revendication 1, comprenant en outre un post-processeur 10 couplé au décodeur AC-3, dans lequel le post-processeur est configuré de manière à mettre en oeuvre un traitement adaptif sur le contenu audio décodé.