ES2843744T3 - Decodificación de trenes de bits de audio codificados con un contenedor de metadatos situado en un espacio de datos reservado - Google Patents

Decodificación de trenes de bits de audio codificados con un contenedor de metadatos situado en un espacio de datos reservado Download PDF

Info

Publication number
ES2843744T3
ES2843744T3 ES17173020T ES17173020T ES2843744T3 ES 2843744 T3 ES2843744 T3 ES 2843744T3 ES 17173020 T ES17173020 T ES 17173020T ES 17173020 T ES17173020 T ES 17173020T ES 2843744 T3 ES2843744 T3 ES 2843744T3
Authority
ES
Spain
Prior art keywords
audio
metadata
program
loudness
bitstream
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES17173020T
Other languages
English (en)
Inventor
Michael Grant
Scott Gregory Norcross
Jeffrey Riedmiller
Michael Ward
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Dolby Laboratories Licensing Corp
Original Assignee
Dolby Laboratories Licensing Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Dolby Laboratories Licensing Corp filed Critical Dolby Laboratories Licensing Corp
Application granted granted Critical
Publication of ES2843744T3 publication Critical patent/ES2843744T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G10MUSICAL INSTRUMENTS; ACOUSTICS
    • G10LSPEECH ANALYSIS OR SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING; SPEECH OR AUDIO CODING OR DECODING
    • G10L19/00Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis
    • G10L19/04Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis using predictive techniques
    • G10L19/16Vocoder architecture
    • G10L19/167Audio streaming, i.e. formatting and decoding of an encoded audio signal representation into a data stream for transmission or storage purposes
    • GPHYSICS
    • G10MUSICAL INSTRUMENTS; ACOUSTICS
    • G10LSPEECH ANALYSIS OR SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING; SPEECH OR AUDIO CODING OR DECODING
    • G10L19/00Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis
    • G10L19/002Dynamic bit allocation
    • GPHYSICS
    • G10MUSICAL INSTRUMENTS; ACOUSTICS
    • G10LSPEECH ANALYSIS OR SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING; SPEECH OR AUDIO CODING OR DECODING
    • G10L19/00Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis
    • G10L19/008Multichannel audio signal coding or decoding using interchannel correlation to reduce redundancy, e.g. joint-stereo, intensity-coding or matrixing
    • GPHYSICS
    • G10MUSICAL INSTRUMENTS; ACOUSTICS
    • G10LSPEECH ANALYSIS OR SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING; SPEECH OR AUDIO CODING OR DECODING
    • G10L19/00Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis
    • G10L19/04Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis using predictive techniques
    • G10L19/06Determination or coding of the spectral characteristics, e.g. of the short-term prediction coefficients
    • GPHYSICS
    • G10MUSICAL INSTRUMENTS; ACOUSTICS
    • G10LSPEECH ANALYSIS OR SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING; SPEECH OR AUDIO CODING OR DECODING
    • G10L19/00Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis
    • G10L19/04Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis using predictive techniques
    • G10L19/16Vocoder architecture
    • HELECTRICITY
    • H03ELECTRONIC CIRCUITRY
    • H03GCONTROL OF AMPLIFICATION
    • H03G9/00Combinations of two or more types of control, e.g. gain control and tone control
    • H03G9/005Combinations of two or more types of control, e.g. gain control and tone control of digital or coded signals
    • HELECTRICITY
    • H03ELECTRONIC CIRCUITRY
    • H03GCONTROL OF AMPLIFICATION
    • H03G9/00Combinations of two or more types of control, e.g. gain control and tone control
    • H03G9/02Combinations of two or more types of control, e.g. gain control and tone control in untuned amplifiers
    • H03G9/025Combinations of two or more types of control, e.g. gain control and tone control in untuned amplifiers frequency-dependent volume compression or expansion, e.g. multiple-band systems

Abstract

Una unidad de procesamiento de audio (100, 200) que comprende: una memoria intermedia (110, 201) para almacenar al menos una trama de un tren de bits de audio codificado, en donde el tren de bits de audio codificado incluye datos de audio y un segmento de metadatos, en donde el segmento de metadatos son datos separados y diferentes de los datos de audio e incluyen un encabezamiento, una o más cargas útiles de metadatos y datos de protección; un decodificador de audio (101, 202) acoplado a la memoria intermedia (110, 201) para decodificar los datos de audio; y un analizador (111, 205) acoplado o integrado al decodificador de audio (101, 202) para analizar el tren de bits de audio codificado, en donde el encabezamiento incluye una palabra de sincronización que identifica el comienzo del segmento de metadatos, la única o más cargas útiles de metadatos describen un programa de audio asociado a los datos de audio, los datos de protección se ubican después de la única o más cargas útiles de metadatos, y los datos de protección pueden usarse para verificar la integridad del segmento de metadatos y la única o más cargas útiles dentro del segmento de metadatos, y donde la única o más cargas útiles de metadatos incluyen una bandera que es indicativa del número de tramas entre la trama actual y un límite de programa del tren de bits de audio codificado, siendo la trama actual la trama que incluye la bandera.

Description

DESCRIPCIÓN
Decodificación de trenes de bits de audio codificados con un contenedor de metadatos situado en un espacio de datos reservado
Referencia cruzada a solicitudes relacionadas
La presente solicitud reivindica la prioridad de la Solicitud de Patente Provisional de los Estados Unidos No.
61/754,882, presentada el 21 de enero de 2013 y Solicitud de Patente Provisional de los Estados Unidos No.
61/824,010, presentada el 16 de mayo de 2013.
Campo técnico
La invención se refiere al procesamiento de señales de audio y, más concretamente, a la codificación y decodificación de trenes de bits de datos de audio con metadatos indicativos del estado de procesamiento de sonoridad de contenido de audio y la ubicación de los límites del programa de audio indicados por los trenes de bits. Algunas realizaciones de la invención generan o decodifican datos de audio en uno de los formatos conocidos como AC-3, Enhanced AC-3 o E-AC-3, o Dolby E.
Antecedentes de la invención
Dolby, Dolby Digital, Dolby Digital Plus y Dolby E son marcas comerciales de Dolby Laboratories Licensing Corporation. Dolby Laboratories provee implementaciones patentadas de AC-3 y E-AC-3 conocidas como Dolby Digital y Dolby Digital Plus, respectivamente.
Las unidades de procesamiento de datos de audio normalmente funcionan a ciegas y no prestan atención al registro de procesamiento de datos de audio que ocurre antes de recibir los datos. Ello puede funcionar en un marco de procesamiento en el cual una sola entidad hace todo el procesamiento de datos de audio y codificación para una variedad de dispositivos de renderización de medios de destino mientras un dispositivo de renderización de medios de destino lleva a cabo toda la decodificación y renderización de los datos de audio codificados. Sin embargo, dicho procesamiento ciego no funciona bien (o directamente no funciona) en situaciones donde múltiples unidades de procesamiento de audio se dispersan a lo largo de una red diversa o se ubican en serie (a saber, cadena) y se espera que lleven a cabo, de forma óptima, sus respectivos tipos de procesamiento de audio. Por ejemplo, algunos datos de audio pueden codificarse para sistemas de medios de alto rendimiento y pueden tener que convertirse en una forma reducida apropiada para un dispositivo móvil a lo largo de una cadena de procesamiento de medios. Por consiguiente, una unidad de procesamiento de audio puede llevar a cabo, de forma innecesaria, un tipo de procesamiento en los datos de audio que ya se ha llevado a cabo. Por ejemplo, una unidad de nivelación de volumen puede llevar a cabo el procesamiento en un clip de audio de entrada, independientemente de si la misma nivelación o una nivelación de volumen similar se ha llevado a cabo o no previamente en el clip de audio de entrada. Como resultado, la unidad de nivelación de volumen puede llevar a cabo la nivelación incluso cuando no es necesaria. Dicho procesamiento innecesario puede también causar la degradación y/o eliminación de características específicas mientras se reproduce el contenido de los datos de audio.
Un tren típico de datos de audio incluye tanto contenido de audio (p.ej., uno o más canales de contenido de audio) como metadatos indicativos de al menos una característica del contenido de audio. Por ejemplo, en un tren de bits AC-3, existen varios parámetros de metadatos de audio que se prevén específicamente para su uso en el cambio de sonido del programa entregado a un entorno de audición. Uno de los parámetros de metadatos es el parámetro DIALNORM, el cual pretende indicar el nivel medio de diálogo que ocurre en un programa de audio y se usa para determinar el nivel de señal de reproducción de audio.
Durante la reproducción de un tren de bits que comprende una secuencia de diferentes segmentos de programa de audio (cada uno de los cuales tiene un parámetro DIALNORM diferente), un decodificador AC-3 usa el parámetro DIALNORM de cada segmento para llevar a cabo un tipo de procesamiento de sonoridad en el cual modifica el nivel de reproducción o sonoridad de modo que la sonoridad percibida del diálogo de la secuencia de segmentos se encuentra en un nivel coherente. Cada segmento de audio codificado (artículo) en una secuencia de artículos de audio codificados tiene (en general) un parámetro DIALNORM diferente y el decodificador escala el nivel de cada uno de los artículos de modo que el nivel de reproducción o sonoridad del diálogo para cada artículo es igual o muy similar, aunque ello puede requerir la aplicación de diferentes cantidades de ganancia a diferentes artículos durante la reproducción.
DIALNORM se establece, normalmente, por un usuario y no se genera de forma automática, aunque existe un valor DIALNORM por defecto si el usuario no establece ningún valor. Por ejemplo, un creador de contenido puede realizar mediciones de sonoridad con un dispositivo externo a un codificador AC-3 y luego transferir el resultado (indicativo de la sonoridad del diálogo hablado de un programa de audio) al codificador para establecer el valor DIALNORM. Por consiguiente, existe una dependencia del creador de contenido para establecer el parámetro DIALNORM de forma correcta.
Existen varias razones diferentes por las que el parámetro DIALNORM en un tren de bits AC-3 puede ser incorrecto. Primero, cada codificador AC-3 tiene un valor DIALNORM por defecto que se usa durante la generación del tren de bits si un valor DIALNORM no se establece por el creador de contenido. Dicho valor por defecto puede ser sustancialmente diferente del nivel de sonoridad de diálogo real del audio. Segundo, incluso si un creador de contenido mide la sonoridad y establece, por consiguiente, el valor DIALNORM, un medidor o algoritmo de medición de sonoridad puede haberse usado, el cual no se adapta al método de medición de sonoridad AC-3 recomendado, lo cual resulta en un valor DIALNORM incorrecto. Tercero, incluso si un tren de bits AC-3 se ha creado con el valor DIALNORM medido y establecido de forma correcta por el creador de contenido, puede haberse cambiado a un valor incorrecto durante la transmisión y/o almacenamiento del tren de bits. Por ejemplo, es común en aplicaciones de difusión por televisión que los trenes de bits AC-3 se decodifiquen, modifiquen y luego recodifiquen mediante el uso de información de metadatos DIALNORM incorrectos. Por consiguiente, un valor DIALNORM incluido en un tren de bits AC-3 puede ser incorrecto o inexacto y, por lo tanto, puede tener un impacto negativo en la calidad de la experiencia auditiva.
Además, el parámetro DIALNORM no indica el estado de procesamiento de sonoridad de los datos de audio correspondientes (p.ej. qué tipo de procesamiento de sonoridad puede haberse llevado a cabo en los datos de audio). Hasta la presente invención, un tren de bits de audio no incluía metadatos, indicativos del estado de procesamiento de sonoridad del (p.ej., tipo de procesamiento de sonoridad aplicado al) contenido de audio del tren de bits de audio o el estado de procesamiento de sonoridad y sonoridad del contenido de audio del tren de bits, en un formato de un tipo descrito en la presente descripción. Los metadatos de estado de procesamiento de sonoridad en dicho formato son útiles para facilitar el procesamiento de sonoridad adaptativo de un tren de bits de audio y/o verificación de validez del estado de procesamiento de sonoridad y sonoridad del contenido de audio, de una manera particularmente eficaz.
Aunque la presente invención no se encuentra limitada al uso con un tren de bits AC-3, un tren de bits E-AC-3 o un tren de bits Dolby E, en aras de la conveniencia, se describirá en realizaciones en las cuales genera, decodifica o de otra forma procesa dicho tren de bits que incluye metadatos de estado de procesamiento de sonoridad.
Un tren de bits codificado AC-3 comprende metadatos y uno a seis canales de contenido de audio. El contenido de audio consiste en datos de audio que se han comprimido mediante el uso de codificación de audio perceptual. Los metadatos incluyen varios parámetros de metadatos de audio que se prevén para su uso en el cambio de sonido de un programa entregado a un entorno de audición.
Los detalles de la codificación AC-3 (también conocida como Dolby Digital) son conocidos y se establecen en muchas referencias publicadas, incluidas las siguientes:
ATSC Standard A52/a: Digital Audio Compression Standard (AC-3), Revisión A, Advanced Televisión Systems Committee, 20 de agosto de 2001; y
Patentes de Estados Unidos 5,583,962; 5,632,005; 5,633,981; 5,727,119; y 6,021,386 así como la solicitud de patente internacional WO2006/113062, que desvela el formato de tren de bits respectivo implicado.
Los detalles de la codificación Dolby Digital Plus (E-AC-3) se establecen en "Introduction to Dolby Digital Plus, an Enhancement to the Dolby Digital Coding System", AES Convention Paper 6196, 117th AES Convention, 28 de octubre de 2004.
Los detalles de la codificación Dolby E se establecen en "Efficient Bit Allocation, Quantization, and Coding in an Audio Distribution System", AES Preprint 5068, 107th AES Conference, agosto 1999 y "Professional Audio Coder Optimized for Use with Video", AES Preprint 5033, 107th AES Conference, agosto 1999.
Cada trama de un tren de bits de audio codificado AC-3 contiene contenido de audio y metadatos para 1536 muestras de audio digital. Para una velocidad de muestreo de 48 kHz, ello representa 32 milisegundos de audio digital o una velocidad de 31.25 tramas por segundo de audio.
Cada trama de un tren de bits de audio codificado E-AC-3 contiene contenido de audio y metadatos para 256, 512, 768 o 1536 muestras de audio digital, dependiendo de si la trama contiene uno, dos, tres o seis bloques de datos de audio, respectivamente. Para una velocidad de muestreo de 48 kHz, ello representa 5.333, 10.667, 16 o 32 milisegundos de audio digital respectivamente o una velocidad de 189.9, 93.75, 62.5 o 31.25 tramas por segundo de audio, respectivamente.
Como se indica en la Figura 4, cada trama AC-3 se divide en secciones (segmentos), incluidas: una sección de Información de Sincronización (IS) que contiene (como se muestra en la Figura 5) una palabra de sincronización (PS), y la primera de dos palabras de corrección de errores (CRC1); una sección de Información de Tren de Bits (BSI, por sus siglas en inglés) que contiene la mayoría de los metadatos; seis Bloques de Audio (BA0 a BA5) que contienen contenido de audio de datos comprimidos (y pueden incluir también metadatos); segmentos de bits de residuo (W) que contienen bits no usados que quedan después de comprimir el contenido de audio; una sección de información Auxiliar (AUX) que puede contener más metadatos; y la segunda de dos palabras de corrección de errores (CRC2). También puede hacerse referencia al segmento de bits de residuo (W) como un "campo de salto".
Como se indica en la Figura 7, cada trama E-AC-3 se divide en secciones (segmentos), que incluyen: una sección de Información de Sincronización (IS) que contiene (como se muestra en la Figura 5) una palabra de sincronización (PS); una sección de Información de Tren de Bits (BSI) que contiene la mayoría de los metadatos; entre uno y seis Bloques de Audio (BA0 a BA5) que contienen contenido de audio de datos comprimidos (y pueden incluir también metadatos); segmentos de bits de residuo (W) que contienen bits no usados que quedan después de comprimir el contenido de audio (aunque solo se muestra un segmento de bits de residuo, un segmento de bits de residuo diferente seguiría normalmente a cada bloque de audio); una sección de información Auxiliar (AUX) que puede contener más metadatos; y una palabra de corrección de errores (CRC). También puede hacerse referencia al segmento de bits de residuo (W) como un "campo de salto".
En un tren de bits AC-3 (o E-AC-3), existen varios parámetros de metadatos de audio que se prevén específicamente para su uso en el cambio de sonido del programa entregado a un entorno de audición. Uno de los parámetros de metadatos es el parámetro DIALNORM, que se incluye en el segmento BSI.
Como se muestra en la Figura 6, el segmento BSI de una trama AC-3 incluye un parámetro de cinco bits ("DIALNORM") que indica el valor DIALNORM para el programa. Un parámetro de cinco bits ("DIALNORM2") que indica el valor DIALNORM para un segundo programa de audio transportado en la misma trama AC-3 se incluye si el modo de codificación de audio ("acmod") de la trama AC-3 es "0", que indica que una configuración de canal dual mono o "1+1" se encuentra en uso.
El segmento BSI también incluye una bandera ("addbsie") que indica la presencia (o ausencia) de información adicional de tren de bits que sigue al bit "addbsie", un parámetro ("addbsil") que indica la longitud de cualquier información adicional de tren de bits que sigue al valor "addbsil", y hasta 64 bits de información adicional de tren de bits ("addbsi") que sigue al valor "addbsil".
El segmento BSI incluye otros valores de metadatos que no se muestran específicamente en la Figura 6.
Breve descripción de la invención
La presente descripción proporciona unidades de procesamiento de audio, métodos para decodificar un tren de bits de audio codificado y un medio de almacenamiento legible por ordenador que almacena programas de ordenador para llevar a cabo dichos métodos, como se reivindica en las reivindicaciones 1, 14 y 15. En las reivindicaciones dependientes se enumeran características opcionales.
Breve descripción de los dibujos
La Figura 1 es un diagrama de bloques de una realización de un sistema que puede configurarse para llevar a cabo una realización del método inventivo.
La Figura 2 es un diagrama de bloques de un codificador que es una realización de la unidad de procesamiento de audio inventiva.
La Figura 3 es un diagrama de bloques de un decodificador que es una realización de la unidad de procesamiento de audio inventiva, y un postprocesador acoplado a aquella que es otra realización de la unidad de procesamiento de audio inventiva.
La Figura 4 es un diagrama de una trama AC-3, que incluye los segmentos en los cuales se divide.
La Figura 5 es un diagrama del segmento de Información de Sincronización (IS) de una trama AC-3, que incluye los segmentos en los cuales se divide.
La Figura 6 es un diagrama del segmento de Información de Tren de Bits (BSI) de una trama AC-3, que incluye los segmentos en los cuales se divide.
La Figura 7 es un diagrama de una trama E-AC-3, que incluye los segmentos en los cuales se divide.
La Figura 8 es un diagrama de tramas de un tren de bits de audio codificado que incluye metadatos de límite de programa cuyo formato es conforme a una realización de la invención.
La Figura 9 es un diagrama de otras tramas del tren de bits de audio codificado de la Figura 9. Algunas de dichas tramas incluyen metadatos de límite de programa que tienen formato según una realización de la invención.
La Figura 10 es un diagrama de dos trenes de bits de audio codificados: un tren de bits (IEB) en el cual un límite de programa (etiquetado "Límite") se alinea con una transición entre dos tramas del tren de bits, y otro tren de bits (TB) en el cual un límite de programa (etiquetado "Límite Verdadero") se desplaza por 512 muestras de una transición entre dos tramas del tren de bits.
La Figura 11 es un conjunto de diagramas que muestran cuatro trenes de bits de audio codificados. El tren de bits en la parte superior de la Figura 11 (etiquetado "Escenario 1") es indicativo de un primer programa de audio (P1) que incluye metadatos de límite de programa seguidos de un segundo programa de audio (P2) que también incluye metadatos de límite de programa; el segundo tren de bits (etiquetado "Escenario 2") es indicativo de un primer programa de audio (P1) que incluye metadatos de límite de programa seguidos de un segundo programa de audio (P2) que no incluye metadatos de límite de programa; el tercer tren de bits (etiquetado "Escenario 3") es indicativo de un primer programa de audio truncado (P1) que incluye metadatos de límite de programa, y que se ha empalmado con todo un segundo programa de audio (P2) que incluye metadatos de límite de programa; y el cuarto tren de bits (etiquetado "Escenario 4") es indicativo de un primer programa de audio truncado (P1) que incluye metadatos de límite de programa, y un segundo programa de audio truncado (P2) que incluye metadatos de límite de programa y que se ha empalmado con una porción del primer programa de audio.
Notación y Nomenclatura
A lo largo de la presente descripción, incluidas las reivindicaciones, la expresión llevar a cabo una función "en" una señal o dato (p.ej., filtrar, escalar, transformar o aplicar una ganancia a, la señal o dato) se usa en un sentido amplio para denotar llevar a cabo la función directamente en la señal o dato, o en una versión procesada de la señal o dato (p.ej., en una versión de la señal que ha experimentado el filtrado preliminar o preprocesamiento previo a llevar a cabo la función en aquellos).
A lo largo de la presente descripción, incluidas las reivindicaciones, la expresión "sistema" se usa en un sentido amplio para denotar un dispositivo, sistema o subsistema. Por ejemplo, puede hacerse referencia a un subsistema que implementa un decodificador como un sistema de decodificador, y también puede hacerse referencia a un sistema que incluye dicho subsistema (p.ej., un sistema que genera X señales de salida en respuesta a múltiples entradas, en el cual el subsistema genera M de las entradas y las otras X - M entradas se reciben de una fuente externa) como un sistema de decodificador.
A lo largo de la presente descripción, incluidas las reivindicaciones, el término "procesador" se usa en un sentido amplio para denotar un sistema o dispositivo programable o de otra forma configurable (p.ej., con software o firmware) para llevar a cabo funciones en los datos (p.ej., audio o vídeo u otros datos de imagen). Ejemplos de procesadores incluyen una matriz de puertas programables en campo (u otro circuito integrado configurable o conjunto de chips), un procesador de señal digital programado y/o de otra forma configurado para llevar a cabo el procesamiento canalizado en datos de audio y otros datos de sonido, un procesador u ordenador de propósito general programable y un conjunto de chips o un chip de microprocesador programable.
A lo largo de la presente descripción, incluidas las reivindicaciones, las expresiones "procesador de audio" y "unidad de procesamiento de audio" se usan de manera intercambiable y en un sentido amplio para denotar un sistema configurado para procesar datos de audio. Ejemplos de unidades de procesamiento de audio incluyen, pero sin limitación, codificadores (p.ej., transcodificadores), decodificadores, códecs, sistemas de preprocesamiento, sistemas de postprocesamiento y sistemas de procesamiento de tren de bits (a los que algunas veces se hace referencia como herramientas de procesamiento de tren de bits).
A lo largo de la presente descripción, incluidas las reivindicaciones, la expresión "metadatos de estado de procesamiento" (p.ej., como en la expresión "metadatos de estado de procesamiento de sonoridad") se refiere a datos separados y diferentes de los datos de audio correspondientes (el contenido de audio de un tren de datos de audio que también incluye metadatos de estado de procesamiento). Los metadatos de estado de procesamiento se asocian a datos de audio, indican el estado de procesamiento de sonoridad de los datos de audio correspondientes (p.ej., qué tipo de procesamiento ya se ha llevado a cabo en los datos de audio) y, normalmente, también indican al menos una característica de los datos de audio. La asociación de los metadatos de estado de procesamiento a los datos de audio es síncrona en el tiempo. Por consiguiente, los metadatos de estado de procesamiento presentes (más recientemente recibidos o actualizados) indican que los datos de audio correspondientes comprenden, de manera contemporánea, los resultados del tipo indicado de procesamiento de datos de audio. En algunos casos, los metadatos de estado de procesamiento pueden incluir registro de procesamiento y/o algunos o todos los parámetros que se usan en y/o derivan de los tipos de procesamiento indicados. Además, los metadatos de estado de procesamiento pueden incluir al menos una característica de los datos de audio correspondientes, los cuales se han computado o extraído de los datos de audio. Los metadatos de estado de procesamiento también pueden incluir otros metadatos que no se relacionan con o derivan de cualquier procesamiento de los datos de audio correspondientes. Por ejemplo, datos de terceros, información de seguimiento, identificadores, información de propiedad o estándar, datos de anotación de usuario, datos de preferencias de usuario, etc. pueden añadirse por una unidad de procesamiento de audio particular para pasar a las otras unidades de procesamiento de audio.
A lo largo de la presente descripción, incluidas las reivindicaciones, la expresión "metadatos de estado de procesamiento de sonoridad" (o "LPSM") denota metadatos de estado de procesamiento indicativos del estado de procesamiento de sonoridad de datos de audio correspondientes (p.ej., qué tipo de procesamiento de sonoridad se ha llevado a cabo en los datos de audio) y, normalmente, también al menos una característica (p.ej., sonoridad) de los datos de audio correspondientes. Los metadatos de estado de procesamiento de sonoridad pueden incluir datos (p.ej., otros metadatos) que no son los metadatos de estado de procesamiento de sonoridad (a saber, cuando se los considera solos).
A lo largo de la presente descripción, incluidas las reivindicaciones, la expresión "canal" (o "canal de audio") denota una señal de audio monofónica.
A lo largo de la presente descripción, incluidas las reivindicaciones, la expresión "programa de audio" denota un conjunto de uno o más canales de audio y, de forma opcional, también metadatos asociados (p.ej., metadatos que describen una presentación de audio espacial deseada y/o LPSM y/o metadatos de límite de programa).
A lo largo de la presente descripción, incluidas las reivindicaciones, la expresión "metadatos de límite de programa" denota metadatos de un tren de bits de audio codificado, donde el tren de bits de audio codificado es indicativo de al menos un programa de audio (p.ej., dos o más programas de audio), y los metadatos de límite de programa son indicativos de la ubicación en el tren de bits de al menos un límite (comienzo y/o fin) de al menos un programa de audio. Por ejemplo, los metadatos de límite de programa (de un tren de bits de audio codificado indicativo de un programa de audio) pueden incluir metadatos indicativos de la ubicación (p.ej., el comienzo de la "N"ésima trama del tren de bits, o la "M"ésima ubicación de muestra de la "N"ésima trama del tren de bits) del comienzo del programa, y metadatos adicionales indicativos de la ubicación (p.ej., el comienzo de la "J"ésima trama del tren de bits, o la "K"ésima ubicación de muestra de la "J"ésima trama del tren de bits) del fin del programa.
A lo largo de la presente descripción, incluidas las reivindicaciones, el término "se acopla" o "acoplada/o/(s)" se usa para significar una conexión directa o indirecta. Por consiguiente, si un primer dispositivo se acopla a un segundo dispositivo, dicha conexión puede ser a través de una conexión directa, o a través de una conexión indirecta mediante otros dispositivos y conexiones.
Descripción detallada de las realizaciones de la invención
Según realizaciones típicas de la invención, una carga útil de metadatos de sonoridad de programa, a los que se hace referencia como metadatos de estado de procesamiento de sonoridad ("LPSM") y, de forma opcional, también metadatos de límite de programa se incorporan a uno o más campos reservados (o intervalos) de segmentos de metadatos de un tren de bits de audio que también incluyen datos de audio en otros segmentos (segmentos de datos de audio). Normalmente, al menos un segmento de cada trama del tren de bits incluye LPSM, y al menos otro segmento de la trama incluye datos de audio correspondientes (a saber, datos de audio cuyo estado de procesamiento de sonoridad y sonoridad se indican por los LPSM). En algunas realizaciones, el volumen de datos de los LPSM puede ser suficientemente pequeño para transportarse sin afectar la velocidad binaria asignada para transportar los datos de audio.
Comunicar los metadatos de estado de procesamiento de sonoridad en una cadena de procesamiento de datos de audio es particularmente útil cuando dos o más unidades de procesamiento de audio necesitan funcionar en serie entre sí a lo largo de la cadena de procesamiento (o vida útil del contenido). Sin inclusión de metadatos de estado de procesamiento de sonoridad en un tren de bits de audio, problemas serios de procesamiento de medios como, por ejemplo, degradaciones de calidad, nivel y espacial pueden ocurrir, por ejemplo, cuando dos o más códecs de audio se utilizan en la cadena y la nivelación de volumen de extremo único se aplica más de una vez durante el trayecto del tren de bits a un dispositivo de consumo de medios (o un punto de renderización del contenido de audio del tren de bits).
La Figura 1 es un diagrama de bloques de una cadena de procesamiento de audio a modo de ejemplo (un sistema de procesamiento de datos de audio), en el cual uno o más de los elementos del sistema pueden configurarse según una realización de la presente invención. El sistema incluye los siguientes elementos, acoplados, de manera conjunta, como se muestra: una unidad de preprocesamiento, un codificador, una unidad de análisis de señal y corrección de metadatos, un transcodificador, un decodificador y una unidad de preprocesamiento. En variaciones del sistema que se muestra, uno o más de los elementos se omiten o se incluyen unidades de procesamiento de datos de audio adicionales.
En algunas implementaciones, la unidad de preprocesamiento de la Figura 1 se configura para aceptar muestras PCM (dominio temporal) que comprenden contenido de audio como entrada, y para producir muestras PCM procesadas. El codificador puede configurarse para aceptar las muestras PCM como entrada y para producir un tren de bits de audio codificado (p.ej., comprimido) indicativo del contenido de audio. A veces, en la presente memoria, se hace referencia a los datos del tren de bits que son indicativos del contenido de audio como "datos de audio". Si el codificador se configura según una realización típica de la presente invención, el tren de bits de audio producido desde el codificador incluye metadatos de estado de procesamiento de sonoridad (y, normalmente, también otros metadatos, incluidos, de forma opcional, metadatos de límite de programa) así como datos de audio.
La unidad de análisis de señal y corrección de metadatos de la Figura 1 puede aceptar uno o más trenes de bits de audio codificados como entrada y determinar (p.ej., validar) si los metadatos de estado de procesamiento en cada tren de bits de audio codificado son correctos, llevando a cabo el análisis de la señal (p.ej., mediante el uso de metadatos de límite de programa en un tren de bits de audio codificado). Si la unidad de análisis de señal y corrección de metadatos descubre que los metadatos incluidos no son válidos, normalmente reemplaza los valores incorrectos por los valores correctos obtenidos del análisis de la señal. Por consiguiente, cada tren de bits de audio codificado producido desde la unidad de análisis de señal y corrección de metadatos puede incluir metadatos de estado de procesamiento corregidos (o no corregidos) así como datos de audio codificados.
El transcodificador de la Figura 1 puede aceptar trenes de bits de audio codificados como entrada, y producir trenes de bits de audio modificados (p.ej., codificados de manera diferente) en respuesta (p.ej., mediante la decodificación de un tren de entrada y la recodificación del tren decodificado en un formato de codificación diferente). Si el transcodificador se configura según una realización típica de la presente invención, el tren de bits de audio producido desde el transcodificador incluye metadatos de estado de procesamiento de sonoridad (y, normalmente, también otros metadatos) así como datos de audio codificados. Los metadatos pueden haberse incluido en el tren de bits. El decodificador de la Figura 1 puede aceptar trenes de bits de audio codificados (p.ej., comprimidos) como entrada, y producir (en respuesta) trenes de muestras de audio PCM decodificadas. Si el decodificador se configura según una realización típica de la presente invención, la salida del decodificador en una función típica es o incluye cualquiera de los siguientes:
un tren de muestras de audio, y un tren correspondiente de metadatos de estado de procesamiento de sonoridad (y, normalmente, también otros metadatos) extraídos de un tren de bits codificado de entrada; o un tren de muestras de audio, y un tren correspondiente de bits de control determinado a partir de los metadatos de estado de procesamiento de sonoridad (y, normalmente, también otros metadatos) extraídos de un tren de bits codificado de entrada; o
un tren de muestras de audio, sin un tren correspondiente de metadatos de estado de procesamiento o bits de control determinados a partir de los metadatos de estado de procesamiento. En dicho último caso, el decodificador puede extraer metadatos de estado de procesamiento de sonoridad (y/u otros metadatos) del tren de bits codificado de entrada y llevar a cabo al menos una función en los metadatos extraídos (p.ej., validación), aunque no produce los metadatos extraídos o bits de control determinados a partir de aquellos. Mediante la configuración de la unidad de postprocesamiento de la Figura 1 según una realización típica de la presente invención, la unidad de postprocesamiento se configura para aceptar un tren de muestras de audio PCM decodificadas y para llevar a cabo el postprocesamiento en aquellas (p.ej., nivelación de volumen del contenido de audio) mediante el uso de metadatos de estado de procesamiento de sonoridad (y, normalmente, también otros metadatos) recibidos con las muestras, o bits de control (determinados por el decodificador a partir de los metadatos de estado de procesamiento de sonoridad y, normalmente, también otros metadatos) recibidos con las muestras. La unidad de postprocesamiento se configura también, normalmente, para reproducir el contenido de audio postprocesado para la reproducción por uno o más altavoces.
Las realizaciones típicas de la presente invención proveen una cadena de procesamiento de audio mejorada en la cual las unidades de procesamiento de audio (p.ej., codificadores, decodificadores, transcodificadores y unidades de preprocesamiento y postprocesamiento) adaptan su respectivo procesamiento para aplicarlo a datos de audio según un estado contemporáneo de los datos de medios según se indica por los metadatos de estado de procesamiento de sonoridad respectivamente recibidos por las unidades de procesamiento de audio.
Los datos de audio ingresados en cualquier unidad de procesamiento de audio del sistema de la Figura 1 (p.ej., el codificador o transcodificador de la Figura 1) pueden incluir metadatos de estado de procesamiento de sonoridad (y, de manera opcional, también otros metadatos) así como datos de audio (p.ej., datos de audio codificados). Dichos metadatos pueden haberse incluido en el audio de entrada por otro elemento del sistema de la Figura 1 (u otra fuente, no se muestra en la Figura 1) según una realización de la presente invención. La unidad de procesamiento que recibe el audio de entrada (con metadatos) puede configurarse para llevar a cabo al menos una función en los metadatos (p.ej., validación) o en respuesta a los metadatos (p.ej., procesamiento adaptativo del audio de entrada) y, normalmente, también para incluir en su audio de salida los metadatos, una versión procesada de los metadatos, o bits de control determinados a partir de los metadatos.
Una realización típica de la unidad de procesamiento de audio inventiva (o procesador de audio) se configura para llevar a cabo el procesamiento adaptativo de datos de audio según el estado de los datos de audio como se indica por los metadatos de estado de procesamiento de sonoridad correspondientes a los datos de audio. En algunas realizaciones, el procesamiento adaptativo es (o incluye) el procesamiento de sonoridad (si los metadatos indican que el procesamiento de sonoridad, o procesamiento similar a aquel, no se ha llevado a cabo ya en los datos de audio, pero no es (y no incluye) el procesamiento de sonoridad (si los metadatos indican que dicho procesamiento de sonoridad, o procesamiento similar a aquel, ya se ha llevado a cabo en los datos de audio). En algunas realizaciones, el procesamiento adaptativo es o incluye la validación de metadatos (p.ej., llevada a cabo en una subunidad de validación de metadatos) para asegurar que la unidad de procesamiento de audio lleve a cabo otro procesamiento adaptativo de los datos de audio según el estado de los datos de audio según se indica por los metadatos de estado de procesamiento de sonoridad. En algunas realizaciones, la validación determina la fiabilidad de los metadatos de estado de procesamiento de sonoridad asociados a (p.ej., incluidos en un tren de bits con) los datos de audio. Por ejemplo, si los metadatos se validan para ser fiables, entonces los resultados de un tipo de procesamiento de audio llevado a cabo previamente pueden reusarse y puede evitarse llevar a cabo otra vez el mismo tipo de procesamiento de audio. Por otro lado, si se descubre que los metadatos se han alterado (o de otra forma no son fiables), entonces el tipo de procesamiento de medios supuestamente llevado a cabo de forma previa (según se indica por los metadatos no fiables) puede repetirse por la unidad de procesamiento de audio y/u otro procesamiento puede llevarse a cabo por la unidad de procesamiento de audio en los metadatos y/o datos de audio. La unidad de procesamiento de audio puede también configurarse para señalizar a otras unidades de procesamiento de audio corriente abajo en una cadena de procesamiento de medios mejorada que los metadatos de estado de procesamiento de sonoridad (p.ej., presentes en un tren de bits de medios) son válidos, si la unidad determina que los metadatos de estado de procesamiento son válidos (p.ej., según una concordancia de un valor criptográfico extraído y un valor criptográfico de referencia).
La Figura 2 es un diagrama de bloques de un codificador (100) que es una realización de la unidad de procesamiento de audio inventiva. Cualquiera de los componentes o elementos del codificador 100 pueden implementarse como uno o más procesos y/o uno o más circuitos (p.ej., ASIC, FPGA, u otros circuitos integrados), en hardware, software o una combinación de hardware y software. El codificador 100 comprende un búfer de trama 110, analizador 111, decodificador 101, validador de estado de audio 102, etapa de procesamiento de sonoridad 103, etapa de selección de tren de audio 104, codificador 105, etapa de relleno/formateador 107, etapa de generación de metadatos 106, subsistema de medición de sonoridad de diálogo 108 y búfer de trama 109, conectados como se muestra. También normalmente, el codificador 100 incluye otros elementos de procesamiento (no se muestran).
El codificador 100 (que es un transcodificador) se configura para convertir un tren de bits de audio de entrada (que, por ejemplo, puede ser uno de un tren de bits AC-3, un tren de bits E-AC-3, o un tren de bits Dolby E) en un tren de bits de audio de salida codificado (que, por ejemplo, puede ser otro de un tren de bits AC-3, un tren de bits E-AC-3, o un tren de bits Dolby E) incluido llevando a cabo el procesamiento de sonoridad adaptativo y automático mediante el uso de los metadatos de estado de procesamiento de sonoridad incluidos en el tren de bits de entrada. Por ejemplo, el codificador 100 puede configurarse para convertir un tren de bits Dolby E de entrada (un formato normalmente usado en las instalaciones de producción y difusión pero no en dispositivos de consumidor que reciben programas de audio que se han difundido a aquellos) en un tren de bits de audio de salida codificado (apropiado para la difusión a dispositivos de consumidor) en formato AC-3 o E-AC-3.
El sistema de la Figura 2 también incluye un subsistema de entrega de audio codificado 150 (que almacena y/o entrega los trenes de bits codificados producidos desde el codificador 100) y decodificador 152. Un tren de bits de audio codificado producido desde el codificador 100 puede almacenarse por el subsistema 150 (p.ej., en la forma de un DVD o disco Blu-ray) o transmitirse por el subsistema 150 (que puede implementar una red o enlace de transmisión), o puede tanto almacenarse como transmitirse por el subsistema 150. El decodificador 152 se configura para decodificar un tren de bits de audio codificado (generado por el codificador 100) que recibe mediante el subsistema 150, incluido mediante la extracción de metadatos de estado de procesamiento de sonoridad (LPSM) de cada trama del tren de bits (y, de manera opcional, también mediante la extracción de metadatos de límite de programa del tren de bits) y generar datos de audio decodificados. Normalmente, el decodificador 152 se configura para llevar a cabo el procesamiento de sonoridad adaptativo en los datos de audio decodificados mediante el uso de los LPSM (y, de manera opcional, también metadatos de límite de programa) y/o para reenviar los datos de audio decodificados y LPSM a un postprocesador configurado para llevar a cabo el procesamiento de sonoridad adaptativo en los datos de audio decodificados mediante el uso de los LPSM (y, de manera opcional, también metadatos de límite de programa). Normalmente, el decodificador 152 incluye un búfer que almacena (p.ej., de una manera no transitoria) el tren de bits de audio codificado recibido del subsistema 150.
Varias implementaciones del codificador 100 y decodificador 152 se configuran para llevar a cabo diferentes realizaciones del método inventivo.
El búfer de trama 110 es una memoria intermedia acoplada para recibir un tren de bits de audio de entrada codificado. Durante el funcionamiento, el búfer 110 almacena (p.ej., de una manera no transitoria) al menos una trama del tren de bits de audio codificado, y una secuencia de las tramas del tren de bits de audio codificado se afirma del búfer 110 al analizador 111.
El analizador 111 se acopla y configura para extraer metadatos de estado de procesamiento de sonoridad (LPSM) y, de manera opcional, también metadatos de límite de programa (y/u otros metadatos) de cada trama del audio de entrada codificado en el cual se incluyen dichos metadatos, para afirmar al menos los LPSM (y, de manera opcional, también metadatos de límite de programa y/u otros metadatos) al validador de estado de audio 102, etapa de procesamiento de sonoridad 103, etapa 106 y subsistema 108, para extraer datos de audio del audio de entrada codificado, y para afirmar los datos de audio al decodificador 101. El decodificador 101 del codificador 100 se configura para decodificar los datos de audio para generar datos de audio decodificados, y para afirmar los datos de audio decodificados a la etapa de procesamiento de sonoridad 103, etapa de selección de tren de audio 104, subsistema 108 y, normalmente, también al validador de estado 102.
El validador de estado 102 se configura para autenticar y validar los LPSM (y, de manera opcional, otros metadatos) confirmados a aquel. En algunas realizaciones, los LPSM son (o se incluyen en) un bloque de datos que se ha incluido en el tren de bits de entrada (p.ej., según una realización de la presente invención). El bloque puede comprender un hash criptográfico (un código de autenticación de mensaje basado en hash o "HMAC", por sus siglas en inglés) para procesar los LPSM (y, de manera opcional, también otros metadatos) y/o los datos de audio subyacentes (provistos del decodificador 101 al validador 102). El bloque de datos puede firmarse de manera digital en dichas realizaciones, de modo que una unidad de procesamiento de audio corriente abajo puede autenticar y validar, de forma relativamente fácil, los metadatos de estado de procesamiento.
Por ejemplo, el HMAC se usa para generar un digest y los valores de protección incluidos en el tren de bits inventivo pueden incluir el digest. El digest puede generarse de la siguiente manera para una trama AC-3:
1. Después de codificar los datos AC-3 y LPSM, los bytes de datos de trama (trama_datos #1 y trama_datos #2 concatenados) y los bytes de datos LPSM se usan como entrada para e1HMAC de la función de troceado. Otros datos, que pueden estar presentes dentro de un campo auxdata, no se toman en cuenta para calcular el digest. Dichos otros datos pueden ser bytes que no pertenecen a los datos AC-3 ni a los datos LPSM. Los bits de protección incluidos en LPSM pueden no considerarse para calcular el digest HMAC.
2. Después de calcular el digest, se escribe en el tren de bits en un campo reservado para los bits de protección.
3. La última etapa de la generación de la trama AC-3 completa es el cálculo del control CRC. Ello se escribe al final de la trama y todos los datos pertenecientes a dicha trama se toman en cuenta, incluidos los bits LPSM.
Otros métodos criptográficos que incluyen, pero sin limitación, cualquiera de uno o más métodos criptográficos diferentes de HMAC pueden usarse para la validación de LPSM (p.ej., en el validador 102) para garantizar la transmisión y recepción seguras de los LPSM y/o datos de audio subyacentes. Por ejemplo, la validación (mediante el uso de dicho método criptográfico) puede llevarse a cabo en cada unidad de procesamiento de audio que recibe una realización del tren de bits de audio inventivo para determinar si los metadatos de estado de procesamiento de sonoridad y los datos de audio correspondientes incluidos en el tren de bits se han sometido al (y/o han resultado del) procesamiento de sonoridad específico (según se indica por los metadatos) y no se han modificado después de llevar a cabo el procesamiento de sonoridad específico.
El validador de estado 102 afirma los datos de control a la etapa de selección de tren de audio 104, generador de metadatos 106 y subsistema de medición de sonoridad de diálogo 108, para indicar los resultados de la función de validación. En respuesta a los datos de control, la etapa 104 puede seleccionar (y transmitir al codificador 105): la salida adaptativamente procesada de la etapa de procesamiento de sonoridad 103 (p.ej., cuando los LPSM indican que los datos de audio producidos desde el decodificador 101 no se han sometido a un tipo específico de procesamiento de sonoridad, y los bits de control del validador 102 indican que los LPSM son válidos); o
los datos de audio producidos desde el decodificador 101 (p.ej., cuando los LPSM indican que los datos de audio producidos desde el decodificador 101 se han sometido a un tipo específico de procesamiento de sonoridad que se llevaría a cabo por la etapa 103, y los bits de control del validador 102 indican que los LPSM son válidos).
La etapa 103 del codificador 100 se configura para llevar a cabo el procesamiento de sonoridad adaptativo en los datos de audio decodificados producidos desde el decodificador 101, según una o más características de datos de audio indicadas por los LPSM extraídos por el decodificador 101. La etapa 103 puede ser un procesador adaptativo de control de rango dinámico y sonoridad en tiempo real de dominio de transformada. La etapa 103 puede recibir una entrada de usuario (p.ej., valores de rango de sonoridad/dinámico de destino de usuario o valores dialnorm) u otra entrada de metadatos (p.ej., uno o más tipos de datos de terceros, información de seguimiento, identificadores, información de propiedad o estándar, datos de anotación de usuario, datos de preferencias de usuario, etc.) y/u otra entrada (p.ej., de un proceso de huella digital) y usar dicha entrada para procesar los datos de audio decodificados producidos desde el decodificador 101. La etapa 103 puede llevar a cabo el procesamiento de sonoridad adaptativo en datos de audio decodificados (producidos desde el decodificador 101) indicativos de un solo programa de audio (según se indica por los metadatos de límite de programa extraídos por el analizador 111) y puede restablecer el procesamiento de sonoridad en respuesta a la recepción de datos de audio decodificados (producidos desde el decodificador 101) indicativos de un programa de audio diferente según se indica por metadatos de límite de programa extraídos por el analizador 111.
El subsistema de medición de sonoridad de diálogo 108 puede funcionar para determinar la sonoridad de segmentos del audio decodificado (desde el decodificador 101) que son indicativos de diálogo (u otra voz), p.ej., mediante el uso de los LPSM (y/u otros metadatos) extraídos por el decodificador 101, cuando los bits de control del validador 102 indican que los LPSM no son válidos. El funcionamiento del subsistema de medición de sonoridad de diálogo 108 puede inhabilitarse cuando los LPSM indican sonoridad previamente determinada de segmentos de diálogo (u otra voz) del audio decodificado (del decodificador 101) cuando los bits de control del validador 102 indican que los LPSM son válidos. El subsistema 108 puede llevar a cabo una medición de sonoridad en datos de audio decodificados indicativos de un solo programa de audio (según se indica por los metadatos de límite de programa extraídos por el analizador 111) y puede restablecer la medición en respuesta a la recepción de datos de audio decodificados indicativos de un programa de audio diferente según se indica por dichos metadatos de límite de programa.
Existen herramientas útiles (p.ej., el medidor de sonoridad Dolby LM100) para medir el nivel de diálogo en contenido de audio de manera conveniente y fácil. Algunas realizaciones de la APU inventiva (p.ej., la etapa 108 del codificador 100) se implementan para incluir (o para llevar a cabo las funciones de) dicha herramienta para medir la sonoridad de diálogo media de contenido de audio de un tren de bits de audio (p.ej., un tren de bits AC-3 decodificado afirmado a la etapa 108 desde el decodificador 101 del codificador 100).
Si la etapa 108 se implementa para medir la verdadera sonoridad de diálogo media de los datos de audio, la medición puede incluir una etapa de aislamiento de segmentos del contenido de audio que contienen, principalmente, voz. Los segmentos de audio que son, principalmente, voz se procesan entonces según un algoritmo de medición de sonoridad. Para datos de audio decodificados desde un tren de bits AC-3, dicho algoritmo puede ser una medida de sonoridad ponderada K estándar (según el estándar internacional ITU-R BS.1770). De manera alternativa, pueden usarse otras medidas de sonoridad (p.ej., aquellas basadas en modelos psicoacústicos de sonoridad).
El aislamiento de segmentos de voz no es esencial para medir la sonoridad de diálogo media de los datos de audio. Sin embargo, mejora la exactitud de la medida y, normalmente, provee resultados más satisfactorios desde la perspectiva de un oyente. Dado que no todo el contenido de audio contiene diálogo (voz), la medida de sonoridad de todo el contenido de audio puede proveer una aproximación suficiente del nivel de diálogo del audio, si la voz hubiera estado presente.
El generador de metadatos 106 genera (y/o transmite a la etapa 107) metadatos que se incluirán por la etapa 107 en el tren de bits codificado que se producirán desde el codificador 100. El generador de metadatos 106 puede transmitir a la etapa 107 los LPSM (y, de manera opcional, también metadatos de límite de programa y/u otros metadatos) extraídos por el codificador 101 y/o analizador 111 (p.ej., cuando los bits de control del validador 102 indican que los LPSM y/u otros metadatos son válidos), o generar nuevos LPSM (y, de manera opcional, también metadatos de límite de programa y/u otros metadatos) y afirmar los nuevos metadatos a la etapa 107 (p.ej., cuando los bits de control del validador 102 indican que los LPSM y/u otros metadatos extraídos por el decodificador 101 no son válidos), o puede afirmar a la etapa 107 una combinación de metadatos extraídos por el decodificador 101 y/o analizador 111 y metadatos recientemente generados. El generador de metadatos 106 puede incluir datos de sonoridad generados por el subsistema 108, y al menos un valor indicativo del tipo de procesamiento de sonoridad llevado a cabo por el subsistema 108, en los LPSM que afirma a la etapa 107 para su inclusión en el tren de bits codificado que se producirá desde el codificador 100.
El generador de metadatos 106 puede generar bits de protección (que pueden consistir en o incluir un código de autenticación de mensaje basado en hash o "HMAC") útil para al menos una de la descriptación, autenticación o validación de los LPSM (y, de manera opcional, también otros metadatos) que se incluirán en el tren de bits codificado y/o los datos de audio subyacentes que se incluirán en el tren de bits codificado. El generador de metadatos 106 puede proveer dichos bits de protección a la etapa 107 para su inclusión en el tren de bits codificado. En el funcionamiento típico, el subsistema de medición de sonoridad de diálogo 108 procesa los datos de audio producidos desde el decodificador 101 para generar en respuesta a aquellos valores de sonoridad (p.ej., valores de sonoridad de diálogo con puerta y sin puerta) y valores de rango dinámico. En respuesta a dichos valores, el generador de metadatos 106 puede generar metadatos de estado de procesamiento de sonoridad (LPSM) para su inclusión (por el relleno/formateador 107) en el tren de bits codificado que se producirá desde el codificador 100. De manera adicional, opcional o alternativa, los subsistemas de 106 y/o 108 del codificador 100 pueden llevar a cabo un análisis adicional de los datos de audio para generar metadatos indicativos de al menos una característica de los datos de audio para su inclusión en el tren de bits codificado que se producirá desde la etapa 107.
El codificador 105 codifica (p.ej., llevando a cabo la compresión) los datos de audio producidos desde la etapa de selección 104, y afirma el audio codificado a la etapa 107 para su inclusión en el tren de bits codificado que se producirá desde la etapa 107.
La etapa 107 multiplexa el audio codificado del codificador 105 y los metadatos (incluidos los LPSM) del generador 106 para generar el tren de bits codificado que se producirá desde la etapa 107, preferiblemente de modo que el tren de bits codificado tenga un formato según se especifica por una realización preferida de la presente invención. El búfer de trama 109 es una memoria intermedia que almacena (p.ej., de una manera no transitoria) al menos una trama del tren de bits de audio codificado producido desde la etapa 107, y una secuencia de las tramas del tren de bits de audio codificado se afirma entonces desde el búfer 109 como salida del codificador 100 al sistema de entrega 150.
Los LPSM generados por el generador de metadatos 106 e incluidos en el tren de bits codificado por la etapa 107 son indicativos del estado de procesamiento de sonoridad de datos de audio correspondientes (p.ej., qué tipo de procesamiento de sonoridad se ha llevado a cabo en los datos de audio) y sonoridad (p.ej., sonoridad de diálogo medida, sonoridad con puerta y/o sin puerta, y/o rango dinámico) de los datos de audio correspondientes.
En la presente memoria, la "puerta" de sonoridad y/o mediciones de nivel llevadas a cabo en los datos de audio se refiere a un nivel específico o umbral de sonoridad donde los valores computados que superan el umbral se incluyen en la medición final (p.ej., ignorando valores de sonoridad a corto plazo por debajo de -60 dBFS en los valores medidos finales). Las puertas en un valor absoluto se refieren a una sonoridad o nivel fijo, mientras que las puertas en un valor relativo se refieren a un valor que depende de un valor de medición "sin puerta" actual.
En algunas implementaciones del codificador 100, el tren de bits codificado con almacenamiento intermedio en la memoria 109 (y salida al sistema de entrega 150) es un tren de bits AC-3 o un tren de bits E-AC-3, y comprende segmentos de datos de audio (p.ej., los segmentos BA0-BA5 de la trama que se muestra en la Figura 4) y segmentos de metadatos, donde los segmentos de datos de audio son indicativos de datos de audio, y cada uno de al menos algunos de los segmentos de metadatos incluye metadatos de estado de procesamiento de sonoridad (LPSM). La etapa 107 inserta LPSM (y, de manera opcional, también metadatos de límite de programa) en el tren de bits en el siguiente formato. Cada uno de los segmentos de metadatos que incluye LPSM (y, de manera opcional, también metadatos de límite de programa) se incluye en un segmento de bits de residuo del tren de bits (p.ej., un segmento de bits de residuo "W" según se muestra en la Figura 4 o Figura 7), o un campo "addbsi" del segmento de Información de Tren de Bits ("BSI") de una trama del tren de bits, o un campo auxdata (p.ej., el segmento AUX que se muestra en la Figura 4 o Figura 7) al final de una trama del tren de bits. Una trama del tren de bits puede incluir uno o dos segmentos de metadatos, cada uno de los cuales incluye LPSM, y si la trama incluye dos segmentos de metadatos, uno puede estar presente en el campo addbsi de la trama y el otro puede estar presente en el campo AUX de la trama. En algunas realizaciones, cada segmento de metadatos, incluidos los LPSM, incluye un segmento de carga útil LPSM (o contenedor) que tiene el siguiente formato:
un encabezamiento (que normalmente incluye una palabra de sincronización que identifica el comienzo de la carga útil LPSM),
seguido de al menos un valor de identificación, p.ej., versión de formato de LPSM, longitud, período, cómputo y valores de asociación de subtren indicados en la Tabla 2 más abajo); y
después del encabezamiento,
al menos un valor de indicación de diálogo (p.ej., parámetro "Canal(es) de diálogo" de la Tabla 2) que indica si los datos de audio correspondientes indican diálogo o no indican diálogo (p.ej., qué canales de los datos de audio correspondientes indican diálogo);
al menos un valor de cumplimiento de regulación de sonoridad (p.ej., el parámetro "Tipo de Regulación de Sonoridad" de la Tabla 2) que indica si los datos de audio correspondientes cumplen con un conjunto indicado de regulaciones de sonoridad;
al menos un valor de procesamiento de sonoridad (p.ej., uno o más de los parámetros "bandera de Corrección de Sonoridad con puerta de Diálogo", "Tipo de Corrección de Sonoridad", de la Tabla 2) que indica al menos un tipo de procesamiento de sonoridad que se ha llevado a cabo en los datos de audio correspondientes; y
al menos un valor de sonoridad (p.ej., uno o más de los parámetros "Sonoridad con Puerta Relativa a ITU", "Sonoridad con Puerta de Voz ITU", "Sonoridad 3s a Corto Plazo ITU (EBU 3341)", y "Pico Verdadero" de la Tabla 2) que indica al menos una característica de sonoridad (p.ej., sonoridad pico o promedio) de los datos de audio correspondientes.
En algunas realizaciones, cada segmento de metadatos que contiene LPSM y metadatos de límite de programa contiene un encabezamiento principal (y, de forma opcional, también elementos principales adicionales), y después del encabezamiento principal (o el encabezamiento principal y otros elementos principales) un segmento de carga útil LPSM (o contenedor) que tiene el siguiente formato:
un encabezamiento, que normalmente incluye al menos un valor de identificación (p.ej., versión de formato de LPSM, longitud, período, cómputo y valores de asociación de subtren, como se indica en la Tabla 2 establecida en la presente memoria), y
después del encabezamiento, los LPSM y los metadatos de límite de programa. Los metadatos de límite de programa pueden incluir un cómputo de tramas de límite de programa y un valor de código (p.ej., un valor "desplazamiento_existe") indicativo de si la trama incluye solamente un cómputo de tramas de límite de programa o tanto un cómputo de tramas de límite de programa como un valor de desplazamiento), y (en algunos casos) un valor de desplazamiento.
En algunas implementaciones, cada uno de los segmentos de metadatos insertados por la etapa 107 en un segmento de bits de residuo o un campo "addbsi" o un campo auxdata de una trama del tren de bits tiene el siguiente formato:
un encabezamiento principal (que, normalmente, incluye una palabra de sincronización que identifica el comienzo del segmento de metadatos, seguida de valores de identificación, p.ej., la versión del elemento Principal, longitud y período, cómputo de elementos extendidos, y valores de asociación de subtren indicados en la Tabla 1 más abajo); y
después del encabezamiento principal, al menos un valor de protección (p.ej., el digest HMAC y valores de Huella Digital de Audio de la Tabla 1) útil para al menos una de la descriptación, autenticación o validación de al menos uno de los metadatos de estado de procesamiento de sonoridad o los datos de audio correspondientes); y
también después del encabezamiento principal, si el segmento de metadatos incluye LPSM, identificación ("ID") de carga útil LPSM y valores de tamaño de carga útil LPSM que identifican los siguientes metadatos como una carga útil LPSM e indican el tamaño de la carga útil LPSM.
El segmento de carga útil LPSM (o contenedor) (que, preferiblemente, tiene el formato especificado más arriba) sigue a la ID de carga útil LPSM y valores de tamaño de carga útil LPSM.
En algunas realizaciones, cada uno de los segmentos de metadatos en el campo auxdata (o campo "addbsi") de una trama tiene tres niveles de estructura:
una estructura de nivel alto, incluida una bandera que indica si el campo auxdata (o addbsi) incluye metadatos, al menos un valor ID que indica qué tipo(s) de metadatos están presentes y, normalmente, también un valor que indica cuántos bits de metadatos (p.ej., de cada tipo) están presentes (si los metadatos están presentes). Un tipo de metadatos que pueden estar presentes son los LSPM, otro tipo de metadatos que pueden estar presentes son los metadatos de límite de programa, y otro tipo de metadatos que pueden estar presentes son los metadatos de búsqueda de medios (p.ej., metadatos de Búsqueda de Medios de Nielsen);
una estructura de nivel intermedio, que comprende un elemento principal para cada tipo identificado de metadatos (p.ej., encabezamiento principal, valores de protección e ID de carga útil LPSM y valores de tamaño de carga útil LPSM, como se menciona más arriba, para cada tipo identificado de metadatos); y una estructura de nivel bajo, que comprende cada carga útil para un elemento principal (p.ej., una carga útil LPSM, si una se identifica por el elemento principal como presente, y/o una carga útil de metadatos de otro tipo, si una se identifica por el elemento principal como presente).
Los valores de datos en dicha estructura de tres niveles pueden anidarse. Por ejemplo, los valores de protección para una carga útil LPSM y/u otra carga útil de metadatos identificada por un elemento principal pueden incluirse después de cada carga útil identificada por el elemento principal (y, por consiguiente, después del encabezamiento principal del elemento principal). En un ejemplo, un encabezamiento principal podría identificar una carga útil LPSM y otra carga útil de metadatos, ID de carga útil y valores de tamaño de carga útil para la primera carga útil (p.ej., la carga útil LPSM) podrían seguir al encabezamiento principal, la propia primera carga útil podría seguir a la ID y valores de tamaño, la ID de carga útil y valor de tamaño de carga útil para la segunda carga útil podrían seguir a la primera carga útil, la propia segunda carga útil podría seguir a dichos ID y valores de tamaño, y bits de protección para ambas cargas útiles (o para valores de elementos principales y ambas cargas útiles) podrían seguir a la última carga útil.
En algunas realizaciones, si el decodificador 101 recibe un tren de bits de audio generado según una realización de la invención con hash criptográfico, el decodificador se configura para analizar y recuperar el hash criptográfico de un bloque de datos determinado del tren de bits, dicho bloque comprendiendo metadatos de estado de procesamiento de sonoridad (LPSM) y, de manera opcional, también metadatos de límite de programa. El validador 102 puede usar el hash criptográfico para validar el tren de bits recibido y/o metadatos asociados. Por ejemplo, si el validador 102 descubre que los LPSM son válidos según una concordancia entre un hash criptográfico de referencia y el hash criptográfico recuperado del bloque de datos, entonces puede inhabilitar la función del procesador 103 en los datos de audio correspondientes y hacer que la etapa de selección 104 transmita (sin cambios) los datos de audio. De manera adicional, opcional o alternativa, otros tipos de técnicas criptográficas pueden usarse en lugar de un método según un hash criptográfico.
El codificador 100 de la Figura 2 puede determinar (en respuesta a LPSM y, de manera opcional, también metadatos de límite de programa, extraídos por el decodificador 101) que una unidad de post/preprocesamiento ha llevado a cabo un tipo de procesamiento de sonoridad en los datos de audio que se codificarán (en los elementos 105, 106 y 107) y, por lo tanto, puede crear (en el generador 106) metadatos de estado de procesamiento de sonoridad que incluyen los parámetros específicos usados en y/o derivados del procesamiento de sonoridad previamente llevado a cabo. En algunas implementaciones, el codificador 100 puede crear (e incluir en el tren de bits codificado producido desde allí) metadatos de estado de procesamiento indicativos del registro de procesamiento en el contenido de audio siempre y cuando el codificador conozca los tipos de procesamientos que se han llevado a cabo en el contenido de audio.
La Figura 3 es un diagrama de bloques de un decodificador (200) que es una realización de la unidad de procesamiento de audio inventiva, y de un postprocesador (300) acoplado a aquella. El postprocesador (300) también es una realización de la unidad de procesamiento de audio inventiva. Cualquiera de los componentes o elementos del decodificador 200 y postprocesador 300 pueden implementarse como uno o más procesos y/o uno o más circuitos (p.ej., ASIC, FPGA, u otros circuitos integrados), en hardware, software o una combinación de hardware y software. El decodificador 200 comprende un búfer de trama 201, analizador 205, decodificador de audio 202, etapa de validación de estado de audio (validador) 203 y etapa de generación de bits de control 204, conectados como se muestra. También, normalmente, el decodificador 200 incluye otros elementos de procesamiento (no se muestran).
El búfer de trama 201 (una memoria intermedia) almacena (p.ej., de una manera no transitoria) al menos una trama del tren de bits de audio codificado recibido por el decodificador 200. Una secuencia de las tramas del tren de bits de audio codificado se afirma del búfer 201 al analizador 205.
El analizador 205 se acopla y configura para extraer metadatos de estado de procesamiento de sonoridad (LPSM) y, de manera opcional, también metadatos de límite de programa, y otros metadatos de cada trama del audio de entrada codificado, para afirmar al menos los LPSM (y metadatos de límite de programa, si se extraen) al validador de estado de audio 203 y etapa 204, para afirmar los LPSM (y, de manera opcional, también los metadatos de límite de programa) como salida (p.ej., al postprocesador 300), para extraer datos de audio del audio de entrada codificado, y para afirmar los datos de audio extraídos al decodificador 202.
El tren de bits de audio codificado ingresado en el decodificador 200 puede ser uno de un tren de bits AC-3, un tren de bits E-AC-3 o un tren de bits Dolby E.
El sistema de la Figura 3 también incluye el postprocesador 300. El postprocesador 300 comprende un búfer de trama 301 y otros elementos de procesamiento (no se muestran) incluido al menos un elemento de procesamiento acoplado al búfer 301. El búfer de trama 301 almacena (p.ej., de una manera no transitoria) al menos una trama del tren de bits de audio decodificado recibido por el postprocesador 300 del decodificador 200. Los elementos de procesamiento del postprocesador 300 se acoplan y configuran para recibir y procesar, de manera adaptativa, una secuencia de las tramas del tren de bits de audio decodificado producido desde el búfer 301, mediante el uso de metadatos (incluidos los valores LPSM) producidos desde el decodificador 202 y/o bits de control producidos desde la etapa 204 del decodificador 200. Normalmente, el postprocesador 300 se configura para llevar a cabo el procesamiento de sonoridad adaptativo en los datos de audio decodificados mediante el uso de los valores LPSM y, de manera opcional, también metadatos de límite de programa (p.ej., según el estado de procesamiento de sonoridad y/o una o más características de datos de audio, indicados por LPSM para datos de audio indicativos de un solo programa de audio).
Varias implementaciones del decodificador 200 y postprocesador 300 se configuran para llevar a cabo diferentes realizaciones del método inventivo.
El decodificador de audio 202 del decodificador 200 se configura para decodificar los datos de audio extraídos por el analizador 205 para generar datos de audio decodificados y para afirmar los datos de audio decodificados como salida (p.ej., al postprocesador 300).
El validador de estado 203 se configura para autenticar y validar los LPSM (y, de manera opcional, otros metadatos) afirmados a aquel. En algunas realizaciones, los LPSM son (o se incluyen en) un bloque de datos que se ha incluido en el tren de bits de entrada (p.ej., según una realización de la presente invención). El bloque puede comprender un hash criptográfico (un código de autenticación de mensaje basado en hash o "HMAC") para procesar los LPSM (y, de manera opcional, también otros metadatos) y/o los datos de audio subyacentes (provistos del analizador 205 y/o decodificador 202 al validador 203). El bloque de datos puede firmarse de manera digital en dichas realizaciones, de modo que una unidad de procesamiento de audio corriente abajo puede autenticar y validar, de forma relativamente fácil, los metadatos de estado de procesamiento.
Otros métodos criptográficos que incluyen, pero sin limitación, cualquiera de uno o más métodos criptográficos diferentes de HMAC pueden usarse para la validación de LPSM (p.ej., en el validador 203) para garantizar la transmisión y recepción seguras de los LPSM y/o datos de audio subyacentes. Por ejemplo, la validación (mediante el uso de dicho método criptográfico) puede llevarse a cabo en cada unidad de procesamiento de audio que recibe una realización del tren de bits de audio inventivo para determinar si los metadatos de estado de procesamiento de sonoridad y los datos de audio correspondientes incluidos en el tren de bits se han sometido al (y/o han resultado del) procesamiento de sonoridad específico (según se indica por los metadatos) y no se han modificado después de llevar a cabo el procesamiento de sonoridad específico.
El validador de estado 203 afirma datos de control al generador de bits de control 204 y/o afirma los datos de control como salida (p.ej., al postprocesador 300), para indicar los resultados de la función de validación. En respuesta a los datos de control (y, de manera opcional, también otros metadatos extraídos del tren de bits de entrada), la etapa 204 puede generar (y afirmar al postprocesador 300):
bits de control que indican que los datos de audio decodificados producidos desde el decodificador 202 se han sometido a un tipo específico de procesamiento de sonoridad (cuando los LPSM indican que los datos de audio producidos desde el decodificador 202 se han sometido al tipo específico de procesamiento de sonoridad, y los bits de control del validador 203 indican que los LPSM son válidos); o
bits de control que indican que los datos de audio decodificados producidos desde el decodificador 202 deben someterse a un tipo específico de procesamiento de sonoridad (p.ej., cuando los LPSM indican que los datos de audio producidos desde el decodificador 202 no se han sometido al tipo específico de procesamiento de sonoridad, o cuando los LPSM indican que los datos de audio producidos desde el decodificador 202 se han sometido al tipo específico de procesamiento de sonoridad pero los bits de control del validador 203 indican que los LPSM no son válidos).
De manera alternativa, el decodificador 200 afirma los metadatos extraídos por el decodificador 202 desde el tren de bits de entrada, y los LPSM (y, de manera opcional, también metadatos de límite de programa) extraídos por el analizador 205 del tren de bits de entrada al postprocesador 300, y el postprocesador 300 lleva a cabo el procesamiento de sonoridad en los datos de audio decodificados mediante el uso de los LPSM (y, de manera opcional, también los metadatos de límite de programa), o lleva a cabo la validación de los LPSM y luego lleva a cabo el procesamiento de sonoridad en los datos de audio decodificados mediante el uso de los LPSM (y, de manera opcional, también metadatos de límite de programa) si la validación indica que los LPSM son válidos.
En algunas realizaciones, si el decodificador 200 recibe un tren de bits de audio generado según una realización de la invención con hash criptográfico, el decodificador se configura para analizar y recuperar el hash criptográfico de un bloque de datos determinado del tren de bits, dicho bloque comprendiendo metadatos de estado de procesamiento de sonoridad (LPSM). El validador 203 puede usar el hash criptográfico para validar el tren de bits recibido y/o metadatos asociados. Por ejemplo, si el validador 203 descubre que los LPSM son válidos según una concordancia entre un hash criptográfico de referencia y el hash criptográfico recuperado del bloque de datos, entonces puede señalizar a una unidad de procesamiento de audio corriente abajo (p.ej., postprocesador 300, que puede ser o incluir una unidad de nivelación de volumen) que transmita (sin cambios) los datos de audio del tren de bits. De manera adicional, opcional o alternativa, otros tipos de técnicas criptográficas pueden usarse en lugar de un método según un hash criptográfico.
En algunas implementaciones del decodificador 200, el tren de bits codificado recibido (y con almacenamiento intermedio en la memoria 201) es un tren de bits AC-3 o un tren de bits E-AC-3, y comprende segmentos de datos de audio (p.ej., los segmentos BA0-BA5 de la trama que se muestra en la Figura 4) y segmentos de metadatos, donde los segmentos de datos de audio son indicativos de datos de audio, y cada uno de al menos algunos de los segmentos de metadatos incluye metadatos de estado de procesamiento de sonoridad (LPSM) y, de manera opcional, también metadatos de límite de programa. La etapa de decodificador 202 (y/o analizador 205) se configura para extraer del tren de bits LPSM (y, de manera opcional, también metadatos de límite de programa) que tienen el siguiente formato. Cada uno de los segmentos de metadatos que incluye LPSM (y, de manera opcional, también metadatos de límite de programa) se incluye en un segmento de bits de residuo de una trama del tren de bits, o un campo "addbsi" del segmento de Información de Tren de Bits ("BSI") de una trama del tren de bits, o en un campo auxdata (p.ej., el segmento AUX que se muestra en la Figura 4) al final de una trama del tren de bits. Una trama del tren de bits puede incluir uno o dos segmentos de metadatos, cada uno de los cuales puede incluir LPSM, y si la trama incluye dos segmentos de metadatos, uno puede estar presente en el campo addbsi de la trama y el otro puede estar presente en el campo AUX de la trama. En algunas realizaciones, cada segmento de metadatos, incluidos los LPSM, incluye un segmento de carga útil LPSM (o contenedor) que tiene el siguiente formato:
un encabezamiento (que normalmente incluye una palabra de sincronización que identifica el comienzo de la carga útil LPSM, seguida de valores de identificación, p.ej., versión de formato de LPSM, longitud, período, cómputo y valores de asociación de subtren indicados en la Tabla 2 más abajo); y
después del encabezamiento,
al menos un valor de indicación de diálogo (p.ej., parámetro "Canal(es) de diálogo" de la Tabla 2) que indica si los datos de audio correspondientes indican diálogo o no indican diálogo (p.ej., qué canales de los datos de audio correspondientes indican diálogo);
al menos un valor de cumplimiento de regulación de sonoridad (p.ej., el parámetro "Tipo de Regulación de Sonoridad" de la Tabla 2) que indica si los datos de audio correspondientes cumplen con un conjunto indicado de regulaciones de sonoridad;
al menos un valor de procesamiento de sonoridad (p.ej., uno o más de los parámetros "bandera de Corrección de Sonoridad con puerta de Diálogo", "Tipo de Corrección de Sonoridad", de la Tabla 2) que indica al menos un tipo de procesamiento de sonoridad que se ha llevado a cabo en los datos de audio correspondientes; y
al menos un valor de sonoridad (p.ej., uno o más de los parámetros "Sonoridad con Puerta Relativa a ITU", "Sonoridad con Puerta de Voz ITU", "Sonoridad 3s a Corto Plazo ITU (EBU 3341)", y "Pico Verdadero" de la Tabla 2) que indica al menos una característica de sonoridad (p.ej., sonoridad pico o promedio) de los datos de audio correspondientes.
En algunas realizaciones, cada segmento de metadatos que contiene LPSM y metadatos de límite de programa contiene un encabezamiento principal (y, de forma opcional, también elementos principales adicionales), y después del encabezamiento principal (o el encabezamiento principal y otros elementos principales) un segmento de carga útil LPSM (o contenedor) que tiene el siguiente formato:
un encabezamiento, que normalmente incluye al menos un valor de identificación (p.ej., versión de formato de LPSM, longitud, período, cómputo y valores de asociación de subtren, como se indica en la Tabla 2 más abajo), y
después del encabezamiento, los LPSM y los metadatos de límite de programa. Los metadatos de límite de programa pueden incluir un cómputo de tramas de límite de programa y un valor de código (p.ej., un valor "desplazamiento_existe") indicativo de si la trama incluye solamente un cómputo de tramas de límite de programa o tanto un cómputo de tramas de límite de programa como un valor de desplazamiento), y (en algunos casos) un valor de desplazamiento.
En algunas implementaciones, el analizador 205 (y/o etapa de decodificador 202) se configura para extraer, de un segmento de bits de residuo, o un campo "addbsi", o un campo auxdata, de una trama del tren de bits, cada segmento de metadatos que tiene el siguiente formato:
un encabezamiento principal (que, normalmente, incluye una palabra de sincronización que identifica el comienzo del segmento de metadatos, seguida de al menos un valor de identificación, p.ej., la versión de elemento Principal, longitud y período, cómputo de elementos extendidos, y valores de asociación de subtren indicados en la Tabla 1 más abajo); y
después del encabezamiento principal, al menos un valor de protección (p.ej., el digest HMAC y valores de Huella Digital de Audio de la Tabla 1) útil para al menos una de la descriptación, autenticación o validación de al menos uno de los metadatos de estado de procesamiento de sonoridad o los datos de audio correspondientes); y
también después del encabezamiento principal, si el segmento de metadatos incluye LPSM, identificación ("ID") de carga útil LPSM y valores de tamaño de carga útil LPSM que identifican los siguientes metadatos como una carga útil LPSM e indican el tamaño de la carga útil LPSM.
El segmento de carga útil LPSM (o contenedor) (que, preferiblemente, tiene el formato especificado más arriba) sigue a la ID de carga útil LPSM y valores de tamaño de carga útil LPSM.
De manera más general, el tren de bits de audio codificado generado por realizaciones preferidas de la invención tiene una estructura que provee un mecanismo para etiquetar elementos de metadatos y subelementos como principales (obligatorios) o expandidos (elementos opcionales). Ello permite a la velocidad de datos del tren de bits (incluidos sus metadatos) escalar a lo largo de numerosas aplicaciones. Los elementos principales (obligatorios) de la sintaxis del tren de bits preferido deben también poder señalizar que los elementos expandidos (opcionales) asociados al contenido de audio están presentes (en banda) y/o en una ubicación remota (fuera de banda).
Se requiere que los elementos principales estén presentes en cada trama del tren de bits. Algunos subelementos de los elementos principales son opcionales y pueden estar presentes en cualquier combinación. No se requiere que los elementos expandidos estén presentes en cada trama (para limitar la sobrecarga de velocidad binaria). Por consiguiente, los elementos expandidos pueden estar presentes en algunas tramas y no en otras. Algunos subelementos de un elemento expandido son opcionales y pueden estar presentes en cualquier combinación, mientras que otros subelementos de un elemento expandido pueden ser obligatorios (a saber, si el elemento expandido está presente en una trama del tren de bits).
En una clase de realizaciones, se genera un tren de bits de audio codificado que comprende una secuencia de segmentos de datos de audio y segmentos de metadatos (p.ej., por una unidad de procesamiento de audio que realiza la invención). Los segmentos de datos de audio son indicativos de datos de audio, cada uno de al menos algunos de los segmentos de metadatos incluye metadatos de estado de procesamiento de sonoridad (LPSM) y, de manera opcional, también metadatos de límite de programa, y los segmentos de datos de audio se multiplexan por división del tiempo con los segmentos de metadatos. En realizaciones preferidas en la presente clase, cada uno de los segmentos de metadatos tiene un formato preferido que se describirá en la presente memoria.
En un formato preferido, el tren de bits codificado es un tren de bits AC-3 o un tren de bits E-AC-3, y cada uno de los segmentos de metadatos que incluye LPSM se incluye (p.ej., por la etapa 107 de una implementación preferida del codificador 100) como información adicional del tren de bits en el campo "addbsi" (que se muestra en la Figura 6) del segmento de Información de Tren de Bits ("BSI") de una trama del tren de bits, o en un campo auxdata de una trama del tren de bits, o en un segmento de bits de residuo de una trama del tren de bits.
En el formato preferido, cada una de las tramas incluye un elemento principal que tiene el formato que se muestra en la Tabla 1 más abajo, en el campo addbsi (o segmento de bits de residuo) de la trama:
Tabla 1
Figure imgf000016_0001
En el formato preferido, cada uno de los campos addbsi (o auxdata) o segmentos de bits de residuo que contienen LPSM contiene un encabezamiento principal (y, de manera opcional, también elementos principales adicionales) y después del encabezamiento principal (o el encabezamiento principal y otros elementos principales), los siguientes valores LPSM (parámetros):
una ID de carga útil (que identifica los metadatos como LPSM) que sigue a los valores de elemento principal (p.ej., según se especifica en la Tabla 1);
un tamaño de carga útil (que indica el tamaño de la carga útil LPSM) que sigue a la ID de carga útil; y datos LPSM (que siguen a la ID de carga útil y valor de tamaño de carga útil) que tienen el formato según se indica en la siguiente tabla (Tabla 2):
Tabla 2
Figure imgf000017_0001
Figure imgf000018_0001
En otro formato preferido de un tren de bits codificado generado según la invención, el tren de bits es un tren de bits AC-3 o un tren de bits E-AC-3, y cada uno de los segmentos de metadatos que incluye LPSM (y, de manera opcional, también metadatos de límite de programa) se incluye (p.ej., por la etapa 107 de una implementación preferida del codificador 100) en cualquiera de: un segmento de bits de residuo de una trama del tren de bits; o un campo "addbsi" (que se muestra en la Figura 6) del segmento de Información de Tren de Bits ("BSI") de una trama del tren de bits; o un campo auxdata (p.ej., el segmento AUX que se muestra en la Figura 4) al final de una trama del tren de bits. Una trama puede incluir uno o dos segmentos de metadatos, cada uno de los cuales incluye LPSM, y si la trama incluye dos segmentos de metadatos, uno puede estar presente en el campo addbsi de la trama y el otro, en el campo AUX de la trama. Cada segmento de metadatos, incluidos los LPSM, tiene el formato especificado más arriba con referencia a las Tablas 1 y 2 más arriba (a saber, incluye los elementos principales especificados en la Tabla 1, seguidos de la ID de carga útil (que identifica los metadatos como LPSM) y valores de tamaño de carga útil especificados más arriba, seguidos de la carga útil (los datos LPSM que tienen el formato indicado en la Tabla 2).
En otro formato preferido, el tren de bits codificado es un tren de bits Dolby E y cada uno de los segmentos de metadatos que incluye LPSM (y, de forma opcional, también metadatos de límite de programa) son las primeras N ubicaciones de muestra del intervalo de banda de guarda de Dolby E. Un tren de bits Dolby E que incluye dicho segmento de metadatos que incluye LPSM preferiblemente incluye un valor indicativo de longitud de carga útil LPSM señalizado en la palabra Pd del preámbulo SMPTE 337M (la velocidad de repetición de palabra Pa SMPTE 337M preferiblemente permanece idéntica a la velocidad de trama de vídeo asociada).
En un formato preferido, en el cual el tren de bits codificado es un tren de bits E-AC-3, cada uno de los segmentos de metadatos incluye LPSM (y, de manera opcional, también metadatos de límite de programa) se incluye (p.ej., por la etapa 107 de una implementación preferida del codificador 100) como información de tren de bits adicional en un segmento de bits de residuo, o en el campo "addbsi" del segmento de Información de Tren de Bits ("BSI"), de una trama del tren de bits. A continuación se describen aspectos adicionales de la codificación de un tren de bits E-AC-3 con LPSM en el presente formato preferido:
1. durante la generación de un tren de bits E-AC-3, mientras el codificador E-AC-3 (que inserta los valores LPSM en el tren de bits) es "activo", para cada trama (syncframe) generada, el tren de bits debe incluir un bloque de metadatos (incluidos los LPSM) transportado en el campo addbsi (o segmento de bits de residuo) de la trama. Los bits requeridos para transportar el bloque de metadatos no deben aumentar la velocidad binaria del codificador (longitud de trama);
2. cada bloque de metadatos (que contiene LPSM) debe contener la siguiente información: sonoridad_corrección_tipo_bandera: donde '1' indica que la sonoridad de los datos de audio correspondientes se ha corregido corriente arriba desde el codificador, y '0' indica que la sonoridad se ha corregido por un corrector de sonoridad incorporado en el codificador (p.ej., procesador de sonoridad 103 del codificador 100 de la Figura 2); voz_canal: indica qué canal(es) de origen contiene(n) voz (en los 0,5 segundos previos). Si no se detecta voz alguna, debe indicarse como tal;
voz_sonoridad: indica la sonoridad de voz integrada de cada canal de audio correspondiente que contiene voz (en los 0,5 segundos previos);
ITU_sonoridad: indica la sonoridad ITU BS.1770-3 integrada de cada canal de audio correspondiente; y ganancia: ganancia compuesta de sonoridad para alternancias en un decodificador (para demostrar la reversibilidad);
3. mientras el codificador E-AC-3 (que inserta los valores LPSM en el tren de bits) es "activo" y recibe una trama AC-3 con una bandera de "fiabilidad", el controlador de sonoridad en el codificador (p.ej., el procesador de sonoridad 103 del codificador 100 de la Figura 2) debe desviarse. Los valores DRC y dialnorm de origen "fiables" deben transmitirse (p.ej., por el generador 106 del codificador 100) al componente de codificador E-AC-3 (p.ej., etapa 107 del codificador 100). La generación del bloque LPSM continúa y sonoridad_corrección_tipo_bandera se establece en '1'. La secuencia de desvío de controlador de sonoridad debe sincronizarse con el comienzo de la trama AC-3 decodificada donde aparece la bandera "fiabilidad". La secuencia de desvío de controlador de sonoridad debe implementarse de la siguiente manera: el control nivelador_cantidad disminuye de un valor de 9 a un valor de 0 en 10 períodos de bloques de audio (a saber, 53,3 ms) y el control nivelador_posterior_extremo_medidor se coloca en modo desvío (dicha función debe resultar en una transición sin discontinuidades). El término desvío "fiable" del nivelador implica que el valor dialnorm del tren de bits de origen también se reutiliza en la salida del codificador (p.ej., si el tren de bits de origen "fiable" tiene un valor dialnorm de -30 entonces la salida del codificador debe utilizar -30 para el valor dialnorm de salida);
4. mientras el codificador E-AC-3 (que inserta los valores LPSM en el tren de bits) es "activo" y recibe una trama AC-3 sin la bandera de "fiabilidad", el controlador de sonoridad incorporado al codificador (p.ej., procesador de sonoridad 103 del codificador 100 de la Figura 2) debe estar activo. La generación del bloque LPSM continúa y sonoridad_corrección_tipo_bandera se establece en '0'. La secuencia de activación de controlador de sonoridad debe sincronizarse con el comienzo de la trama AC-3 decodificada donde desaparece la bandera "fiabilidad". La secuencia de activación de controlador de sonoridad debe implementarse de la siguiente manera: el control nivelador_cantidad aumenta de un valor de 0 a un valor de 9 en 1 período de bloques de audio (a saber, 5,3 ms) y el control nivelador_posterior_extremo_medidor se coloca en modo "activo" (dicha función debe resultar en una transición sin discontinuidades e incluir un restablecimiento de integración posterior_extremo_medidor); y
5. durante la codificación, una interfaz gráfica de usuario (GUI, por sus siglas en inglés) debe indicar a un usuario los siguientes parámetros: "Programa de Audio de Entrada:
[Fiable/No Fiable]" -el estado de dicho parámetro se basa en la presencia de la bandera "fiabilidad" dentro de la señal de entrada; y "Corrección de Sonoridad en Tiempo Real: [Habilitado/Inhabilitado]" -el estado de dicho parámetro se basa en si dicho controlador de sonoridad incorporado al codificador se encuentra activo.
Cuando se decodifica un tren de bits AC-3 o E-AC-3 que tiene LPSM (en el formato preferido) incluidos en un segmento de bits de residuo, o el campo "addbsi" del segmento de Información de Tren de Bits ("BSI"), de cada trama del tren de bits, el decodificador debe analizar los datos de bloque LPSM (en el segmento de bits de residuo o campo addbsi) y pasar todos los valores LPSM extraídos a una interfaz gráfica de usuario (GUI). El conjunto de valores LPSM extraídos se actualiza en cada trama.
En otro formato preferido de un tren de bits codificado generado según la invención, el tren de bits codificado es un tren de bits AC-3 o un tren de bits E-AC-3, y cada uno de los segmentos de metadatos que incluye LPSM se incluye (p.ej., por la etapa 107 de una implementación preferida del codificador 100) en un segmento de bits de residuo, o en un segmento Aux, o como información de tren de bits adicional en el campo "addbsi" (que se muestra en la Figura 6) del segmento de Información de Tren de Bits ("BSI"), de una trama del tren de bits. En el presente formato (que es una variación del formato descrito más arriba con referencia a las Tablas 1 y 2), cada uno de los campos addbsi (o Aux o de bits de residuo) que contiene LPSM contiene los siguientes valores LPSM:
los elementos principales especificados en la Tabla 1, seguidos de la ID de carga útil (que identifica los metadatos como LPSM) y valores de tamaño de carga útil, seguidos de la carga útil (datos LPSM) que tiene el siguiente formato (similar a los elementos obligatorios indicados en la Tabla 2 más arriba):
versión de carga útil LPSM: un campo de 2 bits que indica la versión de la carga útil LPSM;
dialchan: un campo de 3 bits que indica si los canales Izquierdo, Derecho y/o Central de los datos de audio correspondientes contienen diálogo hablado. La asignación de bits del campo dialchan puede ser como se describe a continuación: bit 0, que indica la presencia de diálogo en el canal izquierdo, se almacena en el bit más significativo del campo dialchan; y bit 2, que indica la presencia de diálogo en el canal central, se almacena en el bit menos significativo del campo dialchan. Cada bit del campo dialchan se establece en "1" si el canal correspondiente contiene diálogo hablado durante los 0,5 segundos anteriores del programa; loudregtyp: un campo de 4 bits que indica con qué estándar de regulación de sonoridad cumple la sonoridad de programa. Establecer el campo "loudregtyp" en "000" indica que los LPSM no indican cumplimiento de la regulación de sonoridad. Por ejemplo, un valor de dicho campo (p.ej., 0000) puede indicar que el cumplimiento del estándar de regulación de sonoridad no se indica, otro valor de dicho campo (p.ej., 0001) puede indicar que los datos de audio del programa cumplen con el estándar ATSC A/85, y otro valor de dicho campo (p.ej., 0010) puede indicar que los datos de audio del programa cumplen con el estándar EBU R128. En el ejemplo, si el campo se establece en cualquier valor diferente de "0000", los campos loudcorrdialgat y loudcorrtyp deben seguir a la carga útil;
loudcorrdialgat: un campo de un bit que indica si se ha aplicado la corrección de sonoridad con puerta de diálogo. Si la sonoridad del programa se ha corregido mediante el uso de puertas de diálogo, el valor del campo loudcorrdialgat se establece en "1". De lo contrario, se establece en "0";
loudcorrtyp: un campo de un bit que indica el tipo de corrección de sonoridad aplicada al programa. Si la sonoridad del programa se ha corregido con un proceso de corrección de sonoridad de previsión de compatibilidad infinita (basada en archivos), el valor del campo loudcorrtyp se establece en "0". Si la sonoridad del programa se ha corregido mediante el uso de una combinación de medición de sonoridad en tiempo real y control de rango dinámico, el valor de dicho campo se establece en "1";
loudrelgate: un campo de un bit que indica si existen datos de sonoridad con puerta relativa (ITU). Si el campo loudrelgate se establece en "1", un campo ituloudrelgat de 7 bits debe seguir a la carga útil; loudrelgat: un campo de 7 bits que indica la sonoridad de programa con puerta relativa (ITU). Dicho campo indica la sonoridad integrada del programa de audio, medida según ITU-R BS.1770-3 sin ajustes de ganancia debido a la compresión de dialnorm y rango dinámico aplicada. Los valores de 0 a 127 se interpretan como -58 LKFS a 5.5 LKFS, en las etapas 0.5 LKFS;
loudspchgate: un campo de un bit que indica si existen datos de sonoridad con puerta de voz (ITU). Si el campo loudspchgate se establece en "1", un campo loudspchgat de 7 bits debe seguir a la carga útil; loudspchgat: un campo de 7 bits que indica la sonoridad de programa con puerta de voz. Dicho campo indica la sonoridad integrada de todo el programa de audio correspondiente, medida según la fórmula (2) de ITU-R BS.1770-3 y sin ajustes de ganancia debido a la compresión de dialnorm y rango dinámico aplicada. Los valores de 0 a 127 se interpretan como - 58 a 5.5 LKFS, en las etapas 0.5 LKFS; loudstrm3se: un campo de un bit que indica si existen datos de sonoridad a corto plazo (3 segundos). Si el campo se establece en "1", un campo loudstrm3s de 7 bits debe seguir a la carga útil;
loudstrm3s: un campo de 7 bits que indica la sonoridad sin puerta de los 3 segundos anteriores del programa de audio correspondiente, medida según ITU-R BS.1771-1 y sin ajustes de ganancia debido a la compresión de dialnorm y rango dinámico aplicada. Los valores de 0 a 256 se interpretan como -116 LKFS a 11.5 LKFS en las etapas 0.5 LKFS;
truepke: un campo de un bit que indica si existen datos de sonoridad de pico verdadero. Si el campo truepke se establece en "1", un campo truepk de 8 bits debe seguir a la carga útil; y
truepk: un campo de 8 bits que indica el valor de muestra de pico verdadero del programa, medido según el Anexo 2 de ITU-R BS.1770-3 y sin ajustes de ganancia debido a la compresión aplicada de dialnorm y rango dinámico. Los valores de 0 a 256 se interpretan como -116 LKFS a 11.5 LKFS en las etapas 0.5 LKFS.
En algunas realizaciones, el elemento principal de un segmento de metadatos en un segmento de bits de residuo o en un campo auxdata (o "addbsi") de una trama de un tren de bits AC-3 o un tren de bits E-AC-3 comprende un encabezamiento principal (que, normalmente, incluye valores de identificación, p.ej., versión de elemento principal) y después del encabezamiento principal: valores indicativos de si los datos de huella digital (u otros valores de protección) se incluyen para metadatos del segmento de metadatos, valores indicativos de si existen datos externos (relacionados con datos de audio correspondientes a los metadatos del segmento de metadatos), ID de carga útil y valores de tamaño de carga útil para cada tipo de metadatos (p.ej., LPSM y/o metadatos de un tipo diferente de LPSM) identificados por el elemento principal, y valores de protección para al menos un tipo de metadatos identificado por el elemento principal. Las cargas útiles de metadatos del segmento de metadatos siguen al encabezamiento principal, y se anidan (en algunos casos) dentro de valores del elemento principal.
Las realizaciones típicas de la invención incluyen metadatos de límite de programa en un tren de bits de audio codificado de manera eficaz, lo cual permite la determinación exacta y robusta de al menos un límite entre programas de audio consecutivos indicados por el tren de bits. Las realizaciones típicas permiten la determinación exacta y robusta de un límite de programa en el sentido de que permiten la determinación exacta de límite de programa incluso en casos en los cuales los trenes de bits indicativos de diferentes programas se empalman entre sí (para generar el tren de bits inventivo) de una manera que trunca uno o ambos trenes de bits empalmados (y, por consiguiente, descarta metadatos de límite de programa que se habían incluido en al menos uno de los trenes de bits de preempalme).
En realizaciones típicas, los metadatos de límite de programa en una trama del tren de bits inventivo son una bandera de límite de programa indicativa de un cómputo de tramas. Normalmente, la bandera es indicativa del número de tramas entre la trama actual (la trama que incluye la bandera) y un límite de programa (el comienzo o fin del programa de audio actual). En algunas realizaciones preferidas, las banderas de límite de programa se insertan de una manera simétrica y eficaz al comienzo y fin de cada segmento de tren de bits que es indicativo de un solo programa (a saber, en tramas que ocurren dentro de cierto número predeterminado de tramas después del comienzo del segmento, y en tramas que ocurren dentro de cierto número predeterminado de tramas antes del fin del segmento), de modo que cuando dos de dichos segmentos del tren de bits se concatenan (para ser indicativos de una secuencia de dos programas), los metadatos de límite de programa pueden estar presentes (p.ej., de forma simétrica) a ambos lados del límite entre los dos programas.
La robustez máxima puede lograrse insertando una bandera de límite de programa en cada trama de un tren de bits indicativo de un programa, pero ello normalmente no será práctico debido al aumento asociado de la velocidad de datos. En realizaciones típicas, las banderas de límite de programa se insertan solamente en un subconjunto de las tramas de un tren de bits de audio codificado (el cual puede ser indicativo de un programa de audio o una secuencia de programas de audio), y la velocidad de inserción de bandera de límite es una función no creciente de aumentar la separación de cada una de las tramas del tren de bits (en las cuales se inserta una bandera) del límite de programa que está más cerca de cada una de las tramas, donde "velocidad de inserción de bandera de límite" denota la relación promedio del número de tramas (indicativas de un programa) que incluyen una bandera de límite de programa y el número de tramas (indicativas del programa) que no incluyen una bandera de límite de programa, donde el promedio es un promedio móvil de un número (p.ej., un número relativamente pequeño) de tramas consecutivas del tren de bits de audio codificado.
Aumentar la velocidad de inserción de bandera de límite (p.ej., en ubicaciones en el tren de bits más cercanas a un límite de programa) aumenta la velocidad de datos requerida para la entrega del tren de bits. Para compensar ello, el tamaño (número de bits) de cada bandera insertada se reduce, preferiblemente, mientras la velocidad de inserción de bandera de límite aumenta (p.ej., de modo que el tamaño de la bandera de límite de programa en la "N"ésima trama del tren de bits, donde N es un entero, es una función no creciente de la distancia (número de tramas) entre la "N"ésima trama y el límite de programa más cercano). En una clase de realizaciones, la velocidad de inserción de bandera de límite es una función logarítmicamente decreciente de aumentar la distancia (de cada ubicación de inserción de bandera) del límite de programa más cercano, y para cada trama que contiene una bandera que incluye una de las banderas, el tamaño de la bandera en dicha trama que contiene una bandera es igual a o mayor que el tamaño de cada bandera en una trama ubicada más cerca del límite de programa más cercano que lo que se encuentra dicha trama que contiene la bandera. Normalmente, el tamaño de cada bandera se determina por una función creciente del número de tramas de la ubicación de inserción de bandera al límite de programa más cercano.
Por ejemplo, consideremos la realización de las Figuras 8 y 9, en las cuales cada columna identificada por un número de trama (en la fila superior) indica una trama de un tren de bits de audio codificado. El tren de bits es indicativo de un programa de audio que tiene un primer límite de programa (indicativo del comienzo del programa) que ocurre inmediatamente a la izquierda de la columna identificada por el número de trama "17" en el lado izquierdo de la Figura 9, y un segundo límite de programa (indicativo del fin del programa) que ocurre inmediatamente a la derecha de la columna identificada por el número de trama "1" en el lado derecho de la Figura 8. Las banderas de límite de programa incluidas en las tramas que se muestran en la Figura 8 cuentan, de manera regresiva, el número de tramas entre la trama actual y el segundo límite de programa. Las banderas de límite de programa incluidas en las tramas que se muestran en la Figura 9 cuentan, de manera ascendente, el número de tramas entre la trama actual y el primer límite de programa.
En la realización de las Figuras 8 y 9, una bandera de límite de programa se inserta solamente en cada una de las "2N"ésimas tramas de las primeras X tramas del tren de bits codificado después del comienzo del programa de audio indicado por el tren de bits, y en cada una de las "2N"ésimas tramas (de las últimas X tramas del tren de bits) más cercanas al fin del programa indicado por el tren de bits, donde el programa comprende Y tramas, X es un entero menor que o igual a Y/2 y N es un entero positivo en un rango de 1 a log2 (X). Por consiguiente (según se indica en las Figuras 8 y 9), una bandera de límite de programa se inserta en la segunda trama (N = 1) del tren de bits (la trama que contiene la bandera más cercana al comienzo del programa), en la cuarta trama (N = 2), en la octava trama (N = 3) y así sucesivamente, y en la octava trama del final del tren de bits, en la cuarta trama del final del tren de bits, y en la segunda trama del final del tren de bits (la trama que contiene la bandera más cercana al fin del programa). En el presente ejemplo, la bandera de límite de programa en la "2N"ésima trama del comienzo (o fin) del programa comprende log2(2N+2) bits binarios, como se indica en las Figuras 8 y 9. Por consiguiente, la bandera de límite de programa en la segunda trama (N = 1) del comienzo (o fin) del programa comprende log2(2N+2) = log2(23) = 3 bits binarios, y la bandera en la cuarta trama (N = 2) del comienzo (o fin) del programa comprende log2(2N+2) = log2(24) = 4 bits binarios, y así sucesivamente.
En el ejemplo de las Figuras 8 y 9, el formato de cada bandera de límite de programa es como se describe a continuación. Cada bandera de límite de programa consiste en un bit "1" anterior, una secuencia de "0" bits (ya sea ningún "0" bit o uno o más "0" bits consecutivos) después del bit anterior, y un código de dos bits posterior. El código posterior es "11" para las banderas en las últimas X tramas del tren de bits (las tramas más cercanas al fin del programa), como se indica en la Figura 8. El código posterior es "10" para las banderas en las primeras X tramas del tren de bits (las tramas más cercanas al comienzo del programa), como se indica en la Figura 9. Por consiguiente, para leer (decodificar) cada bandera, el número de ceros entre el bit anterior "1" y el código posterior se computa. Si se identifica que el código posterior es "11", la bandera indica que hay (2Z+ 1 - 1) tramas entre la trama actual (la trama que incluye la bandera) y el fin del programa, donde Z es el número de ceros entre el bit "1" anterior de la bandera y el código posterior. El decodificador puede implementarse, de manera eficaz, para ignorar el primer y último bit de cada bandera, para determinar el inverso de la secuencia de otros bits (intermedios) de la bandera (p.ej., si la secuencia de bits intermedios es "0001" con el bit "1" siendo el último bit en la secuencia, la secuencia invertida de bits intermedios es "1000" con el bit "1" siendo el primer bit en la secuencia invertida), y para identificar el valor binario de la secuencia invertida de bits intermedios como el índice de la trama actual (la trama en la cual se incluye la bandera) respecto al fin del programa. Por ejemplo, si la secuencia invertida de bits intermedios es "1000", dicha secuencia invertida tiene el valor binario 24 = 16, y la trama se identifica como la 16ésima trama antes del fin del programa (como se indica en la columna de la Figura 8 que describe la trama "0").
Si se identifica que el código posterior es "10", la bandera indica que hay (2Z+1 - 1) tramas entre el comienzo del programa y la trama actual (la trama que incluye la bandera), donde Z es el número de ceros entre el bit "1" anterior de la bandera y el código posterior. El decodificador puede implementarse, de manera eficaz, para ignorar el primer y último bit de cada bandera, para determinar el inverso de la secuencia de los bits intermedios de la bandera (p.ej., si la secuencia de bits intermedios es "0001" con el bit "1" siendo el último bit en la secuencia, la secuencia invertida de bits intermedios es "1000" con el bit "1" siendo el primer bit en la secuencia invertida), y para identificar el valor binario de la secuencia invertida de bits intermedios como el índice de la trama actual (la trama en la cual se incluye la bandera) respecto al comienzo del programa. Por ejemplo, si la secuencia invertida de bits intermedios es "1000", dicha secuencia invertida tiene el valor binario 24 = 16, y la trama se identifica como la 16ésima trama después del comienzo del programa (como se indica en la columna de la Figura 9 que describe la trama "32").
En el ejemplo de las Figuras 8 y 9, una bandera de límite de programa está presente solamente en cada una de las ""2N"ésimas tramas de las primeras X tramas de un tren de bits codificado después del comienzo de un programa de audio indicado por el tren de bits, y en cada una de las "2N"ésimas tramas (de las últimas X tramas del tren de bits) más cercanas al fin del programa indicado por el tren de bits, donde el programa comprende Y tramas, X es un entero menor que o igual a Y/2 y N es un entero positivo en un rango de 1 a log2(X). La inclusión de las banderas de límite de programa solo añade una velocidad binaria promedio de 1.875 bits/trama a la velocidad binaria requerida para transmitir el tren de bits sin las banderas.
En una implementación típica de la realización de las Figuras 8 y 9 en la cual el tren de bits es un tren de bits de audio codificado AC-3, cada trama contiene contenido de audio y metadatos para 1536 muestras de audio digital. Para una velocidad de muestreo de 48 kHz, ello representa 32 milisegundos de audio digital o una velocidad de 31.25 tramas por segundo de audio. Por consiguiente, en dicha realización, una bandera de límite de programa en una trama separada de cierto número de tramas ("X" tramas) de un límite de programa indica que el límite ocurre 32X milisegundos después del final de la trama que contiene la bandera (o 32X milisegundos antes del comienzo de la trama que contiene la bandera).
En una implementación típica de la realización de las Figuras 8 y 9 en la cual el tren de bits es un tren de bits de audio codificado E-AC-3, cada trama del tren de bits contiene contenido de audio y metadatos para 256, 512, 768 o 1536 muestras de audio digital, dependiendo de si la trama contiene uno, dos, tres o seis bloques de datos de audio, respectivamente. Para una velocidad de muestreo de 48 kHz, ello representa 5.333, 10.667, 16 o 32 milisegundos de audio digital respectivamente o una velocidad de 189.9, 93.75, 62.5 o 31.25 tramas por segundo de audio, respectivamente. Por consiguiente, en dicha realización (suponiendo que cada trama es indicativa de 32 milisegundos de audio digital), una bandera de límite de programa en una trama separada por cierto número de tramas ("X" tramas) de un límite de programa indica que el límite ocurre 32X milisegundos después del final de la trama que contiene la bandera (o 32X milisegundos antes del comienzo de la trama que contiene la bandera).
En algunas realizaciones en las cuales un límite de programa puede ocurrir dentro de una trama de un tren de bits de audio (a saber, no en alineación con el comienzo o final de una trama), los metadatos de límite de programa incluidos en una trama del tren de bits incluyen un cómputo de tramas de límite de programa (a saber, metadatos indicativos del número de tramas completas entre el comienzo o final de la trama que contiene el cómputo de tramas y un límite de programa) y un valor de desplazamiento. El valor de desplazamiento es indicativo de un desplazamiento (normalmente, un número de muestras) entre el comienzo o fin de una trama que contiene el límite de programa y la ubicación real del límite de programa dentro de la trama que contiene el límite de programa.
Un tren de bits de audio codificado puede ser indicativo de una secuencia de programas (pistas de audio) de una secuencia correspondiente de programas de vídeo, y los límites de dichos programas de audio tienden a ocurrir en los bordes de las tramas de vídeo antes que en los bordes de las tramas de audio. Asimismo, algunos códecs de audio (p.ej., códecs E-AC-3) usan tamaños de trama de audio que no se alinean con las tramas de vídeo. Asimismo, en algunos casos un tren de bits de audio inicialmente codificado experimenta la transcodificación para generar un tren de bits transcodificado, y el tren de bits inicialmente codificado tiene un tamaño de trama diferente que el tren de bits transcodificado de modo que no se garantiza que un límite de programa (determinado por el tren de bits inicialmente codificado) ocurra en un límite de trama del tren de bits transcodificado. Por ejemplo, si el tren de bits inicialmente codificado (p.ej., el tren de bits "IEB" de la Figura 10) tiene un tamaño de trama de 1536 muestras por trama, y el tren de bits transcodificado (p.ej., tren de bits "TB" de la Figura 10) tiene un tamaño de trama de 1024 muestras por trama, el proceso de transcodificación puede hacer que el límite de programa real ocurra no en un límite de trama del tren de bits transcodificado sino en un lugar en una trama de aquel (p.ej., 512 muestras en una trama del tren de bits transcodificado, como se indica en la Figura 10), debido a diferentes tamaños de trama de los diferentes códecs. Las realizaciones de la presente invención en las cuales los metadatos de límite de programa incluidos en una trama de un tren de bits de audio codificado incluyen un valor de desplazamiento así como un cómputo de tramas de límite de programa son útiles en los tres casos descritos en el presente párrafo (así como en otros casos).
La realización descrita más arriba con referencia a las Figuras 8 y 9 no incluye un valor de desplazamiento (p.ej., un campo de desplazamiento) en las tramas del tren de bits codificado. En variaciones de la presente realización, un valor de desplazamiento se incluye en cada trama de un tren de bits de audio codificado que incluye una bandera de límite de programa (p.ej., en tramas correspondientes a las tramas numeradas 0, 8, 12 y 14 en la Figura 8, y las tramas numeradas 18, 20, 24 y 32 en la Figura 9).
En una clase de realizaciones, una estructura de datos (en cada trama de un tren de bits codificado que contiene los metadatos de límite de programa inventivos) incluye un valor de código indicativo de si la trama incluye solamente un cómputo de tramas de límite de programa o tanto un cómputo de tramas de límite de programa como un valor de desplazamiento. Por ejemplo, el valor de código puede ser el valor de un campo de un solo bit (al que se hará referencia en la presente memoria como un campo "desplazamiento_existe"), el valor "desplazamiento_existe" = 0 puede indicar que no se incluye valor de desplazamiento alguno en la trama, y el valor "desplazamiento_existe" = 1 puede indicar que tanto un cómputo de tramas de límite de programa como un valor de desplazamiento se incluyen en la trama.
En algunas realizaciones, al menos una trama de un tren de bits de audio codificado AC-3 o E-AC-3 incluye un segmento de metadatos que incluye LPSM y metadatos de límite de programa (y, de manera opcional, también otros metadatos) para un programa de audio determinado por el tren de bits. Cada segmento de metadatos (que pueden incluirse en un campo addbsi, o un campo auxdata o un segmento de bits de residuo del tren de bits) contiene un encabezamiento principal (y, de forma opcional, también elementos principales adicionales), y después del encabezamiento principal (o el encabezamiento principal y otros elementos principales) un segmento de carga útil LPSM (o contenedor) que tiene el siguiente formato:
un encabezamiento (que normalmente incluye al menos un valor de identificación, p.ej., versión de formato de LPSM, longitud, período, cómputo y valores de asociación de subtren), y
después del encabezamiento, los metadatos de límite de programa (que pueden incluir un cómputo de tramas de límite de programa, un valor de código (p.ej., un valor "desplazamiento_existe") indicativo de si la trama incluye solamente un cómputo de tramas de límite de programa o tanto un cómputo de tramas de límite de programa como un valor de desplazamiento y, en algunos casos, un valor de desplazamiento) y los LPSM. Los LPSM pueden incluir:
al menos un valor de indicación de diálogo que indica si los datos de audio correspondientes indican diálogo o no indican diálogo (p.ej., qué canales de los datos de audio correspondientes indican diálogo). El valor de indicación de diálogo puede indicar si el diálogo está presente en cualquier combinación de, o todos, los canales de los datos de audio correspondientes;
al menos un valor de cumplimiento de regulación de sonoridad que indica si los datos de audio correspondientes cumplen con un conjunto indicado de regulaciones de sonoridad;
al menos un valor de procesamiento de sonoridad que indica al menos un tipo de procesamiento de sonoridad que se ha llevado a cabo en los datos de audio correspondientes; y
al menos un valor de sonoridad que indica al menos una característica de sonoridad (p.ej., sonoridad pico o promedio) de los datos de audio correspondientes.
En algunas realizaciones, el segmento de carga útil LPSM incluye un valor de código (un valor "desplazamiento_existe") indicativo de si la trama incluye solamente un cómputo de tramas de límite de programa o tanto un cómputo de tramas de límite de programa como un valor de desplazamiento. Por ejemplo, en dicha realización, cuando dicho valor de código indica (p.ej., cuando desplazamiento_existe = 1) que la trama incluye un cómputo de tramas de límite de programa y un valor de desplazamiento, el segmento de carga útil LPSM puede incluir un valor de desplazamiento que es un entero no firmado de 11 bits (a saber, que tiene un valor de 0 a 2048) y que indica el número de muestras de audio adicionales entre el límite de trama señalizado (el límite de la trama que incluye el límite de programa) y el límite de programa real. Si el cómputo de tramas de límite de programa indica el número de tramas (a la velocidad de trama actual) a la trama que contiene el límite de programa, la ubicación precisa (en unidades de número de muestras) del límite de programa (respecto al comienzo o final de la trama que incluye el segmento de carga útil LPSM) debe calcularse de la siguiente manera:
M = ( trama _ cómputo^ tamaño de trama) desplazamiento,
donde M es el número de muestras para el límite de programa (del comienzo o final de la trama que incluye el segmento de carga útil LPSM), "trama_cómputo" es el cómputo de tramas indicado por el cómputo de tramas de límite de programa, "tamaño de trama" es el número de muestras por trama, y "desplazamiento" es el número de muestras indicadas por el valor de desplazamiento.
Algunas realizaciones en las cuales la velocidad de inserción de banderas de límite de programa aumenta cerca del límite de programa real implementan una norma en la que un valor de desplazamiento nunca se incluye en una trama si la trama es menor que o igual a cierto número ("Y") de tramas a partir de la trama que incluye el límite de programa. Normalmente, Y = 32. Para un codificador E-AC-3 que implementa dicha norma (con Y = 32), el codificador nunca inserta un valor de desplazamiento en el segundo final de un programa de audio. En el presente caso, el dispositivo de recepción es responsable de mantener un temporizador y, por consiguiente, de llevar a cabo su propio cálculo de desplazamiento (en respuesta a metadatos de límite de programa, incluido un valor de desplazamiento, en una trama del tren de bits codificado que es mayor que Y tramas a partir de la trama que contiene el límite de programa).
Para programas cuyos programas de audio se conoce que tienen la "trama alineada" a tramas de vídeo de programas de vídeo correspondientes (p.ej., típicas alimentaciones de contribución con audio codificado Dolby E), es superfluo incluir valores de desplazamiento en los trenes de bits codificados indicativos de los programas de audio. Por consiguiente, los valores de desplazamiento no se incluirán, normalmente, en dichos trenes de bits codificados. Con referencia a la Figura 11, a continuación se considerarán casos en los cuales los trenes de bits de audio codificados se empalman, de manera conjunta, para generar una realización del tren de bits de audio inventivo. El tren de bits en la parte superior de la Figura 11 (etiquetado "Escenario 1") es indicativo de todo un primer programa de audio (P1) que incluye metadatos de límite de programa (banderas de límite de programa, B) seguidas de todo un segundo programa de audio (P2) que también incluye metadatos de límite de programa (banderas de límite de programa, B). Las banderas de límite de programa en la porción final del primer programa (algunas de las cuales se muestran en la Figura 11) son idénticas o similares a aquellas descritas con referencia a la Figura 8 y determinan la ubicación del límite entre los dos programas (a saber, el límite al comienzo del segundo programa). Las banderas de límite de programa en la porción inicial del segundo programa (algunas de las cuales se muestran en la Figura 11) son idénticas o similares a aquellas descritas con referencia a la Figura 9 y también determinan la ubicación del límite. En realizaciones típicas, un codificador o decodificador implementa un temporizador (calibrado por las banderas en el primer programa) que cuenta, de manera regresiva, hasta el límite de programa, y el mismo temporizador (calibrado por las banderas en el segundo programa) cuenta, de manera ascendente, desde el mismo límite de programa. Como se indica por el gráfico de temporizador de límite en el Escenario 1 de la Figura 11, dicha cuenta regresiva del temporizador (calibrado por las banderas en el primer programa) alcanza cero en el límite, y la cuenta ascendente del temporizador (calibrado por las banderas en el segundo programa) indica la misma ubicación del límite.
El segundo tren de bits de la parte superior de la Figura 11 (etiquetado "Escenario 2") es indicativo de todo un primer programa de audio (P1) que incluye metadatos de límite de programa (banderas de límite de programa, B) seguidas de todo un segundo programa de audio (P2) que no incluye metadatos de límite de programa. Las banderas de límite de programa en la porción final del primer programa (algunas de las cuales se muestran en la Figura 11) son idénticas o similares a aquellas descritas con referencia a la Figura 8 y determinan la ubicación del límite entre los dos programas (a saber, el límite al comienzo del segundo programa), como en el Escenario 1. En realizaciones típicas, un codificador o decodificador implementa un temporizador (calibrado por las banderas en el primer programa) que cuenta, de manera regresiva, hasta el límite de programa, y el mismo temporizador (sin calibrarse más) continúa contando, de manera ascendente, desde el límite de programa (como se indica por el gráfico de temporizador de límite en el Escenario 2 de la Figura 11).
El tercer tren de bits de la parte superior de la Figura 11 (etiquetado "Escenario 3") es indicativo de un primer programa de audio truncado (P1) que incluye metadatos de límite de programa (banderas de límite de programa, B) y que se han empalmado con todo un segundo programa de audio (P2) que también incluye metadatos de límite de programa (banderas de límite de programa, B). El empalme ha eliminado las últimas "N" tramas del primer programa. Las banderas de límite de programa en la porción inicial del segundo programa (algunas de las cuales se muestran en la Figura 11) son idénticas o similares a aquellas descritas con referencia a la Figura 9 y determinan la ubicación del límite (empalme) entre el primer programa truncado y todo el segundo programa. En realizaciones típicas, un codificador o decodificador implementa un temporizador (calibrado por las banderas en el primer programa) que cuenta, de manera regresiva, hasta el final del primer programa no truncado, y el mismo temporizador (calibrado por las banderas en el segundo programa) cuenta, de manera ascendente, desde el comienzo del segundo programa. El comienzo del segundo programa es el límite de programa en el Escenario 3. Como se indica por el gráfico de temporizador de límite en el Escenario 3 de la Figura 11, dicha cuenta regresiva del temporizador (calibrado por los metadatos de límite de programa en el primer programa) se restablece (en respuesta a los metadatos de límite de programa en el segundo programa) antes de que haya alcanzado cero (en respuesta a los metadatos de límite de programa en el primer programa). Por consiguiente, aunque la truncación del primer programa (por el empalme) evita que el temporizador identifique el límite de programa entre el primer programa truncado y el comienzo del segundo programa en respuesta a (a saber, bajo la calibración por) los metadatos de límite de programa en el primer programa solo, los metadatos de programa en el segundo programa restablecen el temporizador, de modo que el temporizador restablecido correctamente indica (como la ubicación correspondiente al cómputo "cero" del temporizador restablecido) la ubicación del límite de programa entre el primer programa truncado y el comienzo del segundo programa.
El cuarto tren de bits (etiquetado "Escenario 4") es indicativo de un primer programa de audio truncado (P1) que incluye metadatos de límite de programa (banderas de límite de programa, B), y un segundo programa de audio truncado (P2) que incluye metadatos de límite de programa (banderas de límite de programa, B), y que se ha empalmado con una porción (la porción no truncada) del primer programa de audio. Las banderas de límite de programa en la porción inicial de todo el segundo programa (pretruncación) (algunas de las cuales se muestran en la Figura 11) son idénticas o similares a aquellas descritas con referencia a la Figura 9 y las banderas de límite de programa en la porción final de todo el primer programa (pretruncación) (algunas de las cuales se muestran en la Figura 11) son idénticas o similares a aquellas descritas con referencia a la Figura 8. El empalme ha eliminado las últimas "N" tramas del primer programa (y, por consiguiente, algunas de las banderas de límite de programa que se habían incluido allí antes del empalme) y las primeras "M" tramas del segundo programa (y, por consiguiente, algunas de las banderas de límite de programa que se habían incluido allí antes del empalme). En realizaciones típicas, un codificador o decodificador implementa un temporizador (calibrado por las banderas en el primer programa truncado) que cuenta, de manera regresiva, hacia el final del primer programa no truncado, y el mismo temporizador (calibrado por las banderas en el segundo programa truncado) cuenta, de manera ascendente, desde el comienzo del segundo programa no truncado. Como se indica por el gráfico de temporizador de límite en el Escenario 4 de la Figura 11, dicha cuenta regresiva del temporizador (calibrado por los metadatos de límite de programa en el primer programa) se restablece (en respuesta a los metadatos de límite de programa en el segundo programa) antes de que haya alcanzado cero (en respuesta a los metadatos de límite de programa en el primer programa). La truncación del primer programa (por el empalme) evita que el temporizador identifique el límite de programa entre el primer programa truncado y el comienzo del segundo programa truncado) en respuesta a (a saber, bajo la calibración por) los metadatos de límite de programa en el primer programa solo. Sin embargo, el temporizador restablecido no indica correctamente la ubicación del límite de programa entre el fin del primer programa truncado y el comienzo del segundo programa truncado. Por consiguiente, la truncación de ambos trenes de bits empalmados puede prevenir la determinación exacta del límite entre ellos.
Las realizaciones de la presente invención pueden implementarse en hardware, firmware o software, o una combinación de ellos (p.ej., como una matriz lógica programable). Salvo que se especifique lo contrario, los algoritmos o procesos incluidos como parte de la invención no se relacionan de forma inherente con un ordenador particular u otro aparato. En particular, varias máquinas de propósito general pueden usarse con programas escritos según las enseñanzas de la presente memoria, o puede ser más conveniente construir aparatos más especializados (p.ej., circuitos integrados) para llevar a cabo las etapas requeridas del método. Por consiguiente, la invención puede implementarse en uno o más programas de ordenador mediante la ejecución de uno o más sistemas informáticos programables (p.ej., una implementación de cualquiera de los elementos de la Figura 1, o el codificador 100 de la Figura 2 (o un elemento de este), o el decodificador 200 de la Figura 3 (o un elemento de este) o postprocesador 300 de la Figura 3 (o un elemento de este)) comprendiendo, cada uno, al menos un procesador, al menos un sistema de almacenamiento de datos (incluida una memoria y/o elementos de almacenamiento no permanentes y permanentes), al menos un dispositivo o puerto de entrada y al menos un dispositivo o puerto de salida. El código de programa se aplica a los datos de entrada para llevar a cabo las funciones descritas en la presente memoria y generar información de salida. La información de salida se aplica a uno o más dispositivos de salida, de manera conocida.
Cada programa puede implementarse en cualquier lenguaje informático deseado (incluidos lenguajes de programación de procedimiento, lógicos u orientados al objeto de máquina, conjunto o alto nivel) para comunicarse con un sistema informático. En cualquier caso, el lenguaje puede ser un lenguaje compilado o interpretado.
Por ejemplo, cuando se implementan por secuencias de instrucción de software de ordenador, varias funciones y etapas de las realizaciones de la invención pueden implementarse por secuencias de instrucción de software multihilo que se ejecutan en hardware de procesamiento de señal digital apropiado, en cuyo caso los diferentes dispositivos, etapas y funciones de las realizaciones pueden corresponder a porciones de las instrucciones de software.
Cada programa de ordenador se almacena, preferiblemente, en o se descarga a un medio o dispositivo de almacenamiento (p.ej., memoria o medios de estado sólido, o medios magnéticos u ópticos) legible por un ordenador programable de propósito general o especial, para configurar y hacer funcionar el ordenador cuando el medio o dispositivo de almacenamiento se lee por el sistema informático para llevar a cabo los procedimientos descritos en la presente memoria. El sistema inventivo puede también implementarse como un medio de almacenamiento legible por ordenador, configurado con (a saber, que almacena) un programa de ordenador, donde el medio de almacenamiento así configurado hace que un sistema informático funcione de una manera específica y predefinida para llevar a cabo las funciones descritas en la presente memoria.
Se ha descrito un número de realizaciones de la invención. Sin embargo, se comprenderá que varias modificaciones pueden llevarse a cabo sin apartarse del alcance de la invención. Numerosas modificaciones y variaciones de la presente invención son posibles a la luz de las enseñanzas de más arriba. Se comprenderá que dentro del alcance de las reivindicaciones anexas, la invención puede practicarse de manera diferente a como se describe específicamente en la presente memoria.

Claims (15)

REIVINDICACIONES
1. Una unidad de procesamiento de audio (100, 200) que comprende:
una memoria intermedia (110, 201) para almacenar al menos una trama de un tren de bits de audio codificado, en donde el tren de bits de audio codificado incluye datos de audio y un segmento de metadatos, en donde el segmento de metadatos son datos separados y diferentes de los datos de audio e incluyen un encabezamiento, una o más cargas útiles de metadatos y datos de protección;
un decodificador de audio (101, 202) acoplado a la memoria intermedia (110, 201) para decodificar los datos de audio; y
un analizador (111, 205) acoplado o integrado al decodificador de audio (101, 202) para analizar el tren de bits de audio codificado,
en donde el encabezamiento incluye una palabra de sincronización que identifica el comienzo del segmento de metadatos, la única o más cargas útiles de metadatos describen un programa de audio asociado a los datos de audio, los datos de protección se ubican después de la única o más cargas útiles de metadatos, y los datos de protección pueden usarse para verificar la integridad del segmento de metadatos y la única o más cargas útiles dentro del segmento de metadatos, y
donde la única o más cargas útiles de metadatos incluyen una bandera que es indicativa del número de tramas entre la trama actual y un límite de programa del tren de bits de audio codificado, siendo la trama actual la trama que incluye la bandera.
2. La unidad de procesamiento de audio (100, 200) de la reivindicación 1, en donde la única o más cargas útiles de metadatos incluyen una carga útil de sonoridad de programa que contiene datos indicativos de una sonoridad medida de un programa de audio.
3. La unidad de procesamiento de audio (100, 200) de la reivindicación 2, en donde la carga útil de sonoridad de programa incluye: un campo que indica si un canal de audio contiene diálogo hablado.
4. La unidad de procesamiento de audio (100, 200) de la reivindicación 2, en donde la carga útil de sonoridad de programa incluye un campo que indica un método de medición de sonoridad que se ha usado para generar datos de sonoridad contenidos en la carga útil de sonoridad de programa.
5. La unidad de procesamiento de audio (100, 200) de la reivindicación 2, en donde la carga útil de sonoridad de programa incluye: un campo que indica si una sonoridad de un programa de audio se ha corregido usando puertas de diálogo; o un campo que indica si una sonoridad de un programa de audio se ha corregido usando una previsión de compatibilidad infinita o proceso de corrección de sonoridad basado en archivos.
6. La unidad de procesamiento de audio (100, 200) de la reivindicación 2, en donde la carga útil de sonoridad de programa incluye un campo que indica una sonoridad integrada de un programa de audio sin ajustes de ganancia atribuibles a la compresión de rango dinámico.
7. La unidad de procesamiento de audio (100, 200) de la reivindicación 2, en donde la carga útil de sonoridad de programa incluye un campo que indica una sonoridad integrada de un programa de audio sin ajustes de ganancia atribuibles a la normalización de diálogo.
8. La unidad de procesamiento de audio (100, 200) de la reivindicación 2, en donde la unidad de procesamiento de audio (100, 200) se configura para llevar a cabo el procesamiento de sonoridad adaptativo mediante el uso de la carga útil de sonoridad de programa.
9. La unidad de procesamiento de audio (100, 200) según cualquiera de las reivindicaciones 2-8, en donde la unidad de procesamiento de audio (100, 200) se configura para extraer la carga útil de sonoridad de programa del tren de bits de audio codificado y autenticar o validar la carga útil de sonoridad de programa.
10. La unidad de procesamiento de audio (100, 200) según cualquiera de las reivindicaciones 1-9, en donde el tren de bits de audio codificado es un tren de bits AC-3 o un tren de bits E-AC-3.
11. La unidad de procesamiento de audio (100, 200) de la reivindicación 10, en donde el segmento de metadatos se almacena en un espacio de datos reservado AC-3 o E-AC-3 seleccionado del grupo que consiste en un campo de salto, un campo auxdata, un campo addbsi, y una combinación de ellos.
12. La unidad de procesamiento de audio (100, 200) según cualquiera de las reivindicaciones 1-11, en donde la única o más cargas útiles de metadatos incluyen, cada una, un identificador único de carga útil, y el identificador único de carga útil se ubica en el comienzo de cada carga útil de metadatos.
13. La unidad de procesamiento de audio (100, 200) según cualquiera de las reivindicaciones 1-11, en donde la palabra de sincronización es una palabra de sincronización de 16 bits que tiene un valor de 0x5838.
14. Un método para decodificar un tren de bits de audio codificado, método que comprende:
recibir un tren de bits de audio codificado, el tren de bits de audio codificado segmentado en una o más tramas;
extraer datos de audio y un segmento de metadatos del tren de bits de audio codificado, el segmento de metadatos siendo datos separados y diferentes de los datos de audio e incluyendo un encabezamiento seguido de una o más cargas útiles de metadatos seguidas de datos de protección; y
verificar la integridad del segmento y de la única o más cargas útiles de metadatos a través del uso de los datos de protección,
en donde la única o más cargas útiles de metadatos incluyen una carga útil de sonoridad de programa que contiene datos indicativos de una sonoridad medida de un programa de audio asociado a los datos de audio, y
donde la única o más cargas útiles de metadatos incluyen una bandera que es indicativa del número de tramas entre la trama actual y un límite de programa del tren de bits de audio codificado, siendo la trama actual la trama que incluye la bandera.
15. Un medio de almacenamiento legible por ordenador, que almacena un programa de ordenador que cuando es ejecutado por un sistema informático, hace que el sistema informático funcione de una manera específica y predefinida para llevar a cabo el método de la reivindicación 14.
ES17173020T 2013-01-21 2014-01-15 Decodificación de trenes de bits de audio codificados con un contenedor de metadatos situado en un espacio de datos reservado Active ES2843744T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201361754882P 2013-01-21 2013-01-21
US201361824010P 2013-05-16 2013-05-16

Publications (1)

Publication Number Publication Date
ES2843744T3 true ES2843744T3 (es) 2021-07-20

Family

ID=51210033

Family Applications (4)

Application Number Title Priority Date Filing Date
ES16164479.4T Active ES2667871T3 (es) 2013-01-21 2014-01-15 Decodificador de audio con sonoridad y metadatos de límite de programa
ES16164487T Active ES2749089T3 (es) 2013-01-21 2014-01-15 Codificador y descodificador de audio con metadatos de límite y sonoridad de programa
ES14740284.6T Active ES2660487T3 (es) 2013-01-21 2014-01-15 Codificador y decodificador de audio con metadatos de límite y sonoridad de programa
ES17173020T Active ES2843744T3 (es) 2013-01-21 2014-01-15 Decodificación de trenes de bits de audio codificados con un contenedor de metadatos situado en un espacio de datos reservado

Family Applications Before (3)

Application Number Title Priority Date Filing Date
ES16164479.4T Active ES2667871T3 (es) 2013-01-21 2014-01-15 Decodificador de audio con sonoridad y metadatos de límite de programa
ES16164487T Active ES2749089T3 (es) 2013-01-21 2014-01-15 Codificador y descodificador de audio con metadatos de límite y sonoridad de programa
ES14740284.6T Active ES2660487T3 (es) 2013-01-21 2014-01-15 Codificador y decodificador de audio con metadatos de límite y sonoridad de programa

Country Status (22)

Country Link
US (6) US9916838B2 (es)
EP (3) EP3822970A1 (es)
JP (9) JP6212565B2 (es)
KR (8) KR102183712B1 (es)
CN (2) CN104737228B (es)
AU (1) AU2014207590B2 (es)
BR (5) BR112015007723B1 (es)
CA (1) CA2888350C (es)
DK (1) DK2901449T3 (es)
ES (4) ES2667871T3 (es)
HK (3) HK1212091A1 (es)
HU (1) HUE036119T2 (es)
IL (9) IL287218B (es)
MX (6) MX339611B (es)
MY (2) MY193854A (es)
PL (1) PL2901449T3 (es)
RU (3) RU2589362C1 (es)
SG (2) SG10201604643RA (es)
TR (1) TR201802631T4 (es)
TW (9) TWI524329B (es)
UA (3) UA122050C2 (es)
WO (1) WO2014113465A1 (es)

Families Citing this family (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013078056A1 (en) * 2011-11-22 2013-05-30 Dolby Laboratories Licensing Corporation Method and system for generating an audio metadata quality score
US9570090B2 (en) * 2015-05-26 2017-02-14 Google Inc. Dialog system with automatic reactivation of speech acquiring mode
TWM487509U (zh) 2013-06-19 2014-10-01 杜比實驗室特許公司 音訊處理設備及電子裝置
CN109785851B (zh) 2013-09-12 2023-12-01 杜比实验室特许公司 用于各种回放环境的动态范围控制
US9349378B2 (en) 2013-11-19 2016-05-24 Dolby Laboratories Licensing Corporation Haptic signal synthesis and transport in a bit stream
EP2879131A1 (en) 2013-11-27 2015-06-03 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Decoder, encoder and method for informed loudness estimation in object-based audio coding systems
US9621963B2 (en) 2014-01-28 2017-04-11 Dolby Laboratories Licensing Corporation Enabling delivery and synchronization of auxiliary content associated with multimedia data using essence-and-version identifier
US10063207B2 (en) 2014-02-27 2018-08-28 Dts, Inc. Object-based audio loudness management
EP3522554B1 (en) 2014-05-28 2020-12-02 FRAUNHOFER-GESELLSCHAFT zur Förderung der angewandten Forschung e.V. Data processor and transport of user control data to audio decoders and renderers
WO2016039150A1 (ja) * 2014-09-08 2016-03-17 ソニー株式会社 符号化装置および方法、復号装置および方法、並びにプログラム
WO2016057530A1 (en) * 2014-10-10 2016-04-14 Dolby Laboratories Licensing Corporation Transmission-agnostic presentation-based program loudness
US9584911B2 (en) * 2015-03-27 2017-02-28 Cirrus Logic, Inc. Multichip dynamic range enhancement (DRE) audio processing methods and apparatuses
EP4156180A1 (en) 2015-06-17 2023-03-29 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Loudness control for user interactivity in audio coding systems
US9837086B2 (en) * 2015-07-31 2017-12-05 Apple Inc. Encoded audio extended metadata-based dynamic range control
US10140822B2 (en) 2015-08-05 2018-11-27 Dolby Laboratories Licensing Corporation Low bit rate parametric encoding and transport of haptic-tactile signals
US9590580B1 (en) * 2015-09-13 2017-03-07 Guoguang Electric Company Limited Loudness-based audio-signal compensation
US10341770B2 (en) * 2015-09-30 2019-07-02 Apple Inc. Encoded audio metadata-based loudness equalization and dynamic equalization during DRC
US10007713B2 (en) * 2015-10-15 2018-06-26 Disney Enterprises, Inc. Metadata extraction and management
US10594689B1 (en) 2015-12-04 2020-03-17 Digimarc Corporation Robust encoding of machine readable information in host objects and biometrics, and associated decoding and authentication
US10573324B2 (en) 2016-02-24 2020-02-25 Dolby International Ab Method and system for bit reservoir control in case of varying metadata
US10015612B2 (en) * 2016-05-25 2018-07-03 Dolby Laboratories Licensing Corporation Measurement, verification and correction of time alignment of multiple audio channels and associated metadata
US10210881B2 (en) * 2016-09-16 2019-02-19 Nokia Technologies Oy Protected extended playback mode
CN116631415A (zh) 2017-01-10 2023-08-22 弗劳恩霍夫应用研究促进协会 音频解码器、提供解码的音频信号的方法、和计算机程序
US10339947B2 (en) 2017-03-22 2019-07-02 Immersion Networks, Inc. System and method for processing audio data
US10878879B2 (en) * 2017-06-21 2020-12-29 Mediatek Inc. Refresh control method for memory system to perform refresh action on all memory banks of the memory system within refresh window
CN110945494A (zh) 2017-07-28 2020-03-31 杜比实验室特许公司 向客户端提供媒体内容的方法和***
CN114898761A (zh) * 2017-08-10 2022-08-12 华为技术有限公司 立体声信号编解码方法及装置
EP3677037A1 (en) 2017-08-28 2020-07-08 Dolby Laboratories Licensing Corporation Media-aware navigation metadata
RU2762400C1 (ru) 2018-02-22 2021-12-21 Долби Интернешнл Аб Способ и устройство обработки вспомогательных потоков медиаданных, встроенных в поток mpeg-h 3d audio
EP3570279A1 (en) * 2018-05-17 2019-11-20 MediaTek Inc. Audio output monitoring for failure detection of warning sound playback
US10937434B2 (en) * 2018-05-17 2021-03-02 Mediatek Inc. Audio output monitoring for failure detection of warning sound playback
CN113302692A (zh) * 2018-10-26 2021-08-24 弗劳恩霍夫应用研究促进协会 基于方向响度图的音频处理
CN113647120B (zh) * 2019-03-14 2023-08-08 高迪奥实验室公司 用于控制响度级的音频信号处理装置
US11967330B2 (en) 2019-08-15 2024-04-23 Dolby International Ab Methods and devices for generation and processing of modified audio bitstreams
JPWO2021085252A1 (es) 2019-10-30 2021-05-06
US11922532B2 (en) 2020-01-15 2024-03-05 Digimarc Corporation System for mitigating the problem of deepfake media content using watermarking
WO2021183645A1 (en) * 2020-03-11 2021-09-16 Bytedance Inc. Indication of digital media integrity
US11315581B1 (en) * 2020-08-17 2022-04-26 Amazon Technologies, Inc. Encoding audio metadata in an audio frame
CN115292545B (zh) * 2022-10-08 2022-12-20 腾讯科技(深圳)有限公司 一种音频数据处理方法、装置、设备以及可读存储介质
WO2024081785A1 (en) * 2022-10-12 2024-04-18 Sameer Kumar Digital audio measurement systems and method

Family Cites Families (92)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0520068B1 (en) 1991-01-08 1996-05-15 Dolby Laboratories Licensing Corporation Encoder/decoder for multidimensional sound fields
US5632005A (en) 1991-01-08 1997-05-20 Ray Milton Dolby Encoder/decoder for multidimensional sound fields
KR0152037B1 (ko) 1994-09-27 1998-11-02 김광호 다채널 오디오신호의 전송 비트열구조
US5727119A (en) 1995-03-27 1998-03-10 Dolby Laboratories Licensing Corporation Method and apparatus for efficient implementation of single-sideband filter banks providing accurate measures of spectral magnitude and phase
US7224819B2 (en) 1995-05-08 2007-05-29 Digimarc Corporation Integrating digital watermarks in multimedia content
US6446037B1 (en) * 1999-08-09 2002-09-03 Dolby Laboratories Licensing Corporation Scalable coding method for high quality audio
GB2373975B (en) 2001-03-30 2005-04-13 Sony Uk Ltd Digital audio signal processing
US6807528B1 (en) * 2001-05-08 2004-10-19 Dolby Laboratories Licensing Corporation Adding data to a compressed data frame
US7072477B1 (en) 2002-07-09 2006-07-04 Apple Computer, Inc. Method and apparatus for automatically normalizing a perceived volume level in a digitally encoded file
US7454331B2 (en) * 2002-08-30 2008-11-18 Dolby Laboratories Licensing Corporation Controlling loudness of speech in signals that contain speech and other types of audio material
KR100860984B1 (ko) * 2002-10-15 2008-09-30 삼성전자주식회사 메타데이터 관리 방법
US8301884B2 (en) * 2002-09-16 2012-10-30 Samsung Electronics Co., Ltd. Method of managing metadata
US8979655B2 (en) * 2002-12-10 2015-03-17 Ol2, Inc. System and method for securely hosting applications
KR20060022637A (ko) * 2003-02-28 2006-03-10 마츠시타 덴끼 산교 가부시키가이샤 재생장치 및 재생방법
JP2007526588A (ja) * 2003-06-18 2007-09-13 トムソン ライセンシング 映画フィルムへのデータ記録
US7509255B2 (en) 2003-10-03 2009-03-24 Victor Company Of Japan, Limited Apparatuses for adaptively controlling processing of speech signal and adaptively communicating speech in accordance with conditions of transmitting apparatus side and radio wave and methods thereof
US20080273859A1 (en) 2004-01-08 2008-11-06 Kononklijke Philips Electronics N.V. Marking Program Boundaries in a Personal Video Recording Device
US8131134B2 (en) * 2004-04-14 2012-03-06 Microsoft Corporation Digital media universal elementary stream
JP3894948B2 (ja) 2004-06-21 2007-03-22 三菱電機株式会社 動画像符号化装置及び動画像記録装置
US7617109B2 (en) 2004-07-01 2009-11-10 Dolby Laboratories Licensing Corporation Method for correcting metadata affecting the playback loudness and dynamic range of audio information
US7624021B2 (en) 2004-07-02 2009-11-24 Apple Inc. Universal container for audio data
KR100991803B1 (ko) * 2004-07-22 2010-11-04 주식회사 넷앤티비 Saf 동기화 계층 패킷 구조를 제공하는 saf 동기화 계층 패킷 제공 시스템 및 사용자 단말
KR100689443B1 (ko) 2004-08-21 2007-03-08 삼성전자주식회사 방송 데이터를 저장하기 위한 디지털 방송 시스템 및송수신 방법
US7729673B2 (en) 2004-12-30 2010-06-01 Sony Ericsson Mobile Communications Ab Method and apparatus for multichannel signal limiting
AR052601A1 (es) 2005-03-10 2007-03-21 Qualcomm Inc Clasificacion de contenido para procesamiento de multimedia
TWI397903B (zh) 2005-04-13 2013-06-01 Dolby Lab Licensing Corp 編碼音訊之節約音量測量技術
TW200638335A (en) * 2005-04-13 2006-11-01 Dolby Lab Licensing Corp Audio metadata verification
EP1875614A4 (en) * 2005-04-26 2010-06-23 D Box Technologies Inc METHOD AND DEVICE FOR PROVIDING A MOTION SIGNAL WITH A SOUND SIGNAL USING AN EXISTING SOUND SIGNAL CODING FORMAT
US7702279B2 (en) * 2005-12-20 2010-04-20 Apple Inc. Portable media player as a low power remote control and method thereof
EP1987597B1 (en) 2006-02-23 2013-04-10 LG Electronics Inc. Method and apparatus for processing an audio signal
US7983910B2 (en) * 2006-03-03 2011-07-19 International Business Machines Corporation Communicating across voice and text channels with emotion preservation
US20080025530A1 (en) 2006-07-26 2008-01-31 Sony Ericsson Mobile Communications Ab Method and apparatus for normalizing sound playback loudness
US20080080722A1 (en) 2006-09-29 2008-04-03 Carroll Tim J Loudness controller with remote and local control
WO2008136608A1 (en) 2007-05-02 2008-11-13 Pixtree Technologis, Inc. Method of processing media data and receiver, broadcasting system
CN101790886B (zh) * 2007-07-02 2012-12-05 弗劳恩霍夫应用研究促进协会 存储和读取具有媒体数据容器和元数据容器的文件的设备和方法
CN101350604B (zh) 2007-07-19 2012-07-04 鸿富锦精密工业(深圳)有限公司 自动切换音量调节模式的装置及方法
US20090164473A1 (en) 2007-12-19 2009-06-25 Harman International Industries, Incorporated Vehicle infotainment system with virtual personalization settings
US20090164378A1 (en) * 2007-12-21 2009-06-25 Steven Marcus Jason West Music Distribution
JP5142769B2 (ja) * 2008-03-11 2013-02-13 株式会社日立製作所 音声データ検索システム及び音声データの検索方法
US20090253457A1 (en) 2008-04-04 2009-10-08 Apple Inc. Audio signal processing for certification enhancement in a handheld wireless communications device
EP2144230A1 (en) * 2008-07-11 2010-01-13 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Low bitrate audio encoding/decoding scheme having cascaded switches
EP2146522A1 (en) 2008-07-17 2010-01-20 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Apparatus and method for generating audio output signals using object based metadata
KR101638206B1 (ko) * 2008-07-29 2016-07-08 오렌지 필터 보간에 의해 인코더를 업데이트하는 방법
US8218790B2 (en) 2008-08-26 2012-07-10 Apple Inc. Techniques for customizing control of volume level in device playback
JP2010135906A (ja) 2008-12-02 2010-06-17 Sony Corp クリップ防止装置及びクリップ防止方法
JP4519934B2 (ja) * 2008-12-26 2010-08-04 株式会社東芝 音声再生装置
JP5267115B2 (ja) 2008-12-26 2013-08-21 ソニー株式会社 信号処理装置、その処理方法およびプログラム
US8422699B2 (en) 2009-04-17 2013-04-16 Linear Acoustic, Inc. Loudness consistency at program boundaries
KR101842411B1 (ko) * 2009-08-14 2018-03-26 디티에스 엘엘씨 오디오 객체들을 적응적으로 스트리밍하기 위한 시스템
TWI529703B (zh) 2010-02-11 2016-04-11 杜比實驗室特許公司 用以非破壞地正常化可攜式裝置中音訊訊號響度之系統及方法
TWI525987B (zh) 2010-03-10 2016-03-11 杜比實驗室特許公司 在單一播放模式中組合響度量測的系統
PL2381574T3 (pl) 2010-04-22 2015-05-29 Fraunhofer Ges Forschung Urządzenie i sposób do modyfikacji wejściowego sygnału audio
JP2012010311A (ja) * 2010-05-26 2012-01-12 Sony Corp 送信装置、送信方法、受信装置、受信方法および送受信システム
US20120033819A1 (en) 2010-08-06 2012-02-09 Samsung Electronics Co., Ltd. Signal processing method, encoding apparatus therefor, decoding apparatus therefor, and information storage medium
MY156027A (en) * 2010-08-12 2015-12-31 Fraunhofer Ges Forschung Resampling output signals of qmf based audio codecs
JP5903758B2 (ja) 2010-09-08 2016-04-13 ソニー株式会社 信号処理装置および方法、プログラム、並びにデータ記録媒体
TWI800092B (zh) * 2010-12-03 2023-04-21 美商杜比實驗室特許公司 音頻解碼裝置、音頻解碼方法及音頻編碼方法
US8989884B2 (en) 2011-01-11 2015-03-24 Apple Inc. Automatic audio configuration based on an audio output device
US9171549B2 (en) 2011-04-08 2015-10-27 Dolby Laboratories Licensing Corporation Automatic configuration of metadata for use in mixing audio programs from two encoded bitstreams
JP6185457B2 (ja) * 2011-04-28 2017-08-23 ドルビー・インターナショナル・アーベー 効率的なコンテンツ分類及びラウドネス推定
JP2012235310A (ja) 2011-04-28 2012-11-29 Sony Corp 信号処理装置および方法、プログラム、並びにデータ記録媒体
US20120287999A1 (en) 2011-05-11 2012-11-15 Microsoft Corporation Syntax element prediction in error correction
US8965774B2 (en) 2011-08-23 2015-02-24 Apple Inc. Automatic detection of audio compression parameters
JP5845760B2 (ja) 2011-09-15 2016-01-20 ソニー株式会社 音声処理装置および方法、並びにプログラム
JP2013102411A (ja) 2011-10-14 2013-05-23 Sony Corp 音声信号処理装置、および音声信号処理方法、並びにプログラム
RU2586874C1 (ru) 2011-12-15 2016-06-10 Фраунхофер-Гезелльшафт Цур Фердерунг Дер Ангевандтен Форшунг Е.Ф. Устройство, способ и компьютерная программа для устранения артефактов амплитудного ограничения
TWI517142B (zh) 2012-07-02 2016-01-11 Sony Corp Audio decoding apparatus and method, audio coding apparatus and method, and program
EP2757558A1 (en) 2013-01-18 2014-07-23 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Time domain level adjustment for audio signal decoding or encoding
CN105190750B (zh) 2013-01-28 2019-10-25 弗劳恩霍夫应用研究促进协会 解码器设备以及解码比特流的方法
US9607624B2 (en) 2013-03-29 2017-03-28 Apple Inc. Metadata driven dynamic range control
US9559651B2 (en) 2013-03-29 2017-01-31 Apple Inc. Metadata for loudness and dynamic range control
JP2015050685A (ja) 2013-09-03 2015-03-16 ソニー株式会社 オーディオ信号処理装置および方法、並びにプログラム
WO2015041070A1 (ja) 2013-09-19 2015-03-26 ソニー株式会社 符号化装置および方法、復号化装置および方法、並びにプログラム
US9300268B2 (en) 2013-10-18 2016-03-29 Apple Inc. Content aware audio ducking
CN111580772B (zh) 2013-10-22 2023-09-26 弗劳恩霍夫应用研究促进协会 用于音频设备的组合动态范围压缩和引导截断防止的构思
US9240763B2 (en) 2013-11-25 2016-01-19 Apple Inc. Loudness normalization based on user feedback
US9276544B2 (en) 2013-12-10 2016-03-01 Apple Inc. Dynamic range control gain encoding
KR20230042410A (ko) 2013-12-27 2023-03-28 소니그룹주식회사 복호화 장치 및 방법, 및 프로그램
US9608588B2 (en) 2014-01-22 2017-03-28 Apple Inc. Dynamic range control with large look-ahead
RU2678487C2 (ru) 2014-03-25 2019-01-29 Фраунхофер-Гезелльшафт Цур Фердерунг Дер Ангевандтен Форшунг Е.Ф. Устройство аудиокодера и устройство аудиодекодера, имеющие эффективное кодирование усиления при управлении динамическим диапазоном
US9654076B2 (en) 2014-03-25 2017-05-16 Apple Inc. Metadata for ducking control
EP3522554B1 (en) 2014-05-28 2020-12-02 FRAUNHOFER-GESELLSCHAFT zur Förderung der angewandten Forschung e.V. Data processor and transport of user control data to audio decoders and renderers
EP3151240B1 (en) 2014-05-30 2022-12-21 Sony Group Corporation Information processing device and information processing method
KR102422493B1 (ko) 2014-06-30 2022-07-20 소니그룹주식회사 정보 처리 장치 및 정보 처리 방법
TWI631835B (zh) 2014-11-12 2018-08-01 弗勞恩霍夫爾協會 用以解碼媒體信號之解碼器、及用以編碼包含用於主要媒體資料之元資料或控制資料的次要媒體資料之編碼器
US20160315722A1 (en) 2015-04-22 2016-10-27 Apple Inc. Audio stem delivery and control
US10109288B2 (en) 2015-05-27 2018-10-23 Apple Inc. Dynamic range and peak control in audio using nonlinear filters
WO2016193033A1 (de) 2015-05-29 2016-12-08 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Vorrichtung und verfahren zur lautstärkenregulierung
EP4156180A1 (en) 2015-06-17 2023-03-29 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Loudness control for user interactivity in audio coding systems
US9934790B2 (en) 2015-07-31 2018-04-03 Apple Inc. Encoded audio metadata-based equalization
US9837086B2 (en) 2015-07-31 2017-12-05 Apple Inc. Encoded audio extended metadata-based dynamic range control
US10341770B2 (en) 2015-09-30 2019-07-02 Apple Inc. Encoded audio metadata-based loudness equalization and dynamic equalization during DRC

Also Published As

Publication number Publication date
KR101637897B1 (ko) 2016-07-08
JP2023134751A (ja) 2023-09-27
IL269138B (en) 2020-06-30
ES2660487T3 (es) 2018-03-22
MX2015004468A (es) 2015-07-14
SG11201502405RA (en) 2015-04-29
MX2018006149A (es) 2021-09-17
IL287218B (en) 2022-07-01
TW201907390A (zh) 2019-02-16
JP6641058B2 (ja) 2020-02-05
KR20230011500A (ko) 2023-01-20
EP3244406A1 (en) 2017-11-15
TW202111689A (zh) 2021-03-16
EP2901449B1 (en) 2018-01-03
CN107657959B (zh) 2021-06-11
EP3822970A1 (en) 2021-05-19
JP2018022180A (ja) 2018-02-08
US20170206912A1 (en) 2017-07-20
HUE036119T2 (hu) 2018-06-28
HK1245490A1 (zh) 2018-08-24
BR122020018591B1 (pt) 2022-06-14
TW202242849A (zh) 2022-11-01
US20180108367A1 (en) 2018-04-19
TW201944394A (zh) 2019-11-16
US9911426B2 (en) 2018-03-06
CA2888350A1 (en) 2014-07-24
CA2888350C (en) 2016-04-19
TW201442020A (zh) 2014-11-01
TWI754286B (zh) 2022-02-01
EP3244406B1 (en) 2020-12-09
KR102183712B1 (ko) 2020-11-27
KR102488704B1 (ko) 2023-01-17
EP2901449A1 (en) 2015-08-05
JP6212565B2 (ja) 2017-10-11
TW201727621A (zh) 2017-08-01
IL256015A (en) 2018-01-31
IL274397B (en) 2021-02-28
TWI696171B (zh) 2020-06-11
IL256015B (en) 2019-02-28
TWI811934B (zh) 2023-08-11
MX339611B (es) 2016-05-31
US9905237B2 (en) 2018-02-27
IL256016A (en) 2018-01-31
JP2015531498A (ja) 2015-11-02
KR20170073737A (ko) 2017-06-28
RU2016119385A (ru) 2018-11-07
UA112249C2 (uk) 2016-08-10
US10672413B2 (en) 2020-06-02
TR201802631T4 (tr) 2018-03-21
DK2901449T3 (en) 2018-03-05
EP2901449A4 (en) 2016-06-15
KR102153278B1 (ko) 2020-09-09
IL259412B (en) 2019-10-31
IL280583A (en) 2021-03-25
US20170221496A1 (en) 2017-08-03
KR102251763B1 (ko) 2021-05-14
ES2749089T3 (es) 2020-03-19
UA122560C2 (uk) 2020-12-10
RU2713609C2 (ru) 2020-02-05
RU2016119393A3 (es) 2019-12-03
TWI636454B (zh) 2018-09-21
IL274397A (en) 2020-06-30
JP7371067B2 (ja) 2023-10-30
KR20200134343A (ko) 2020-12-01
BR122015008454B1 (pt) 2022-02-15
KR20210055800A (ko) 2021-05-17
MX343571B (es) 2016-11-09
US20150325243A1 (en) 2015-11-12
KR20150047633A (ko) 2015-05-04
JP6561097B2 (ja) 2019-08-14
RU2020100805A (ru) 2021-07-14
HK1212091A1 (en) 2016-06-03
CN107657959A (zh) 2018-02-02
MX2021011251A (es) 2022-10-28
HK1248913A1 (zh) 2018-10-19
KR102192755B1 (ko) 2020-12-18
AU2014207590B2 (en) 2015-08-13
JP2021182160A (ja) 2021-11-25
ES2667871T3 (es) 2018-05-14
UA122050C2 (uk) 2020-09-10
MY193854A (en) 2022-10-28
CN104737228B (zh) 2017-12-29
KR20160032252A (ko) 2016-03-23
MY183382A (en) 2021-02-18
KR20150099709A (ko) 2015-09-01
US9916838B2 (en) 2018-03-13
MX2022013535A (es) 2022-11-16
RU2016119385A3 (es) 2019-11-27
TW201824253A (zh) 2018-07-01
MX356196B (es) 2018-05-18
IL237561A0 (en) 2015-04-30
JP2016191941A (ja) 2016-11-10
IL256016B (en) 2018-06-28
IL287218A (en) 2021-12-01
JP2020074006A (ja) 2020-05-14
JP2017173836A (ja) 2017-09-28
US20200357422A1 (en) 2020-11-12
JP2016197250A (ja) 2016-11-24
BR112015007723A2 (pt) 2017-07-04
JP6371340B2 (ja) 2018-08-08
TWI666628B (zh) 2019-07-21
RU2016119393A (ru) 2018-11-05
AU2014207590A1 (en) 2015-05-07
TW201730875A (zh) 2017-09-01
BR112015007723B1 (pt) 2022-02-15
TWI611395B (zh) 2018-01-11
JP6442443B2 (ja) 2018-12-19
TWI524329B (zh) 2016-03-01
TWI611396B (zh) 2018-01-11
IL259412A (en) 2018-07-31
KR20160075835A (ko) 2016-06-29
IL293618A (en) 2022-08-01
KR102158002B1 (ko) 2020-09-21
JP6929345B2 (ja) 2021-09-01
SG10201604643RA (en) 2016-07-28
IL280583B (en) 2021-12-01
TW201610984A (zh) 2016-03-16
RU2589362C1 (ru) 2016-07-10
TWI590231B (zh) 2017-07-01
BR122016011963A2 (pt) 2020-07-14
CN104737228A (zh) 2015-06-24
BR122015008454A2 (pt) 2019-08-20
JP2019197222A (ja) 2019-11-14
BR122020020608B1 (pt) 2022-05-10
JP6472481B2 (ja) 2019-02-20
PL2901449T3 (pl) 2018-05-30
IL269138A (en) 2019-11-28
IL237561A (en) 2017-12-31
WO2014113465A1 (en) 2014-07-24
BR122016011963B1 (pt) 2022-02-08
RU2719690C2 (ru) 2020-04-21
US20180151188A1 (en) 2018-05-31

Similar Documents

Publication Publication Date Title
ES2843744T3 (es) Decodificación de trenes de bits de audio codificados con un contenedor de metadatos situado en un espacio de datos reservado
ES2777474T3 (es) Codificador y descodificador de audio con metadatos de información de programa
EP3082128B1 (en) Audio decoder with program loudness and boundary metadata