ES2777474T3 - Codificador y descodificador de audio con metadatos de información de programa - Google Patents
Codificador y descodificador de audio con metadatos de información de programa Download PDFInfo
- Publication number
- ES2777474T3 ES2777474T3 ES18156452T ES18156452T ES2777474T3 ES 2777474 T3 ES2777474 T3 ES 2777474T3 ES 18156452 T ES18156452 T ES 18156452T ES 18156452 T ES18156452 T ES 18156452T ES 2777474 T3 ES2777474 T3 ES 2777474T3
- Authority
- ES
- Spain
- Prior art keywords
- metadata
- audio
- program
- bitstream
- frame
- 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
Links
- 238000000034 method Methods 0.000 claims abstract description 44
- 238000012545 processing Methods 0.000 claims description 187
- 238000007781 pre-processing Methods 0.000 claims description 30
- 238000010200 validation analysis Methods 0.000 claims description 18
- 230000003595 spectral effect Effects 0.000 claims description 15
- 230000008878 coupling Effects 0.000 claims description 14
- 238000010168 coupling process Methods 0.000 claims description 14
- 238000005859 coupling reaction Methods 0.000 claims description 14
- 238000003860 storage Methods 0.000 claims description 10
- 238000004590 computer program Methods 0.000 claims description 4
- 230000001419 dependent effect Effects 0.000 description 26
- 230000006835 compression Effects 0.000 description 22
- 238000007906 compression Methods 0.000 description 22
- 238000012937 correction Methods 0.000 description 20
- 230000003044 adaptive effect Effects 0.000 description 19
- 238000005259 measurement Methods 0.000 description 19
- 230000006870 function Effects 0.000 description 17
- 238000010586 diagram Methods 0.000 description 11
- 230000004044 response Effects 0.000 description 11
- 230000008569 process Effects 0.000 description 10
- 238000004458 analytical method Methods 0.000 description 7
- 238000012805 post-processing Methods 0.000 description 6
- 238000001514 detection method Methods 0.000 description 5
- 238000009877 rendering Methods 0.000 description 5
- 230000005540 biological transmission Effects 0.000 description 4
- 238000004422 calculation algorithm Methods 0.000 description 4
- 230000008859 change Effects 0.000 description 4
- 238000004519 manufacturing process Methods 0.000 description 3
- 230000001360 synchronised effect Effects 0.000 description 3
- 230000004913 activation Effects 0.000 description 2
- 230000002238 attenuated effect Effects 0.000 description 2
- 230000006399 behavior Effects 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 230000015556 catabolic process Effects 0.000 description 2
- 238000006731 degradation reaction Methods 0.000 description 2
- 239000000284 extract Substances 0.000 description 2
- 239000000945 filler Substances 0.000 description 2
- 238000001914 filtration Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000010363 phase shift Effects 0.000 description 2
- 239000013316 polymer of intrinsic microporosity Substances 0.000 description 2
- 230000001105 regulatory effect Effects 0.000 description 2
- 230000005236 sound signal Effects 0.000 description 2
- 230000007704 transition Effects 0.000 description 2
- 238000012795 verification Methods 0.000 description 2
- 230000001755 vocal effect Effects 0.000 description 2
- 238000004891 communication Methods 0.000 description 1
- 239000002131 composite material Substances 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000009795 derivation Methods 0.000 description 1
- 238000009826 distribution Methods 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 239000011159 matrix material Substances 0.000 description 1
- 238000000691 measurement method Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000000116 mitigating effect Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 230000001131 transforming effect Effects 0.000 description 1
- 230000001052 transient effect Effects 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
- 238000011144 upstream manufacturing Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G10—MUSICAL INSTRUMENTS; ACOUSTICS
- G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
- G10L19/00—Speech 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/008—Multichannel audio signal coding or decoding using interchannel correlation to reduce redundancy, e.g. joint-stereo, intensity-coding or matrixing
-
- G—PHYSICS
- G10—MUSICAL INSTRUMENTS; ACOUSTICS
- G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
- G10L19/00—Speech 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/018—Audio watermarking, i.e. embedding inaudible data in the audio signal
-
- G—PHYSICS
- G10—MUSICAL INSTRUMENTS; ACOUSTICS
- G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
- G10L19/00—Speech 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/04—Speech 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/16—Vocoder architecture
- G10L19/167—Audio streaming, i.e. formatting and decoding of an encoded audio signal representation into a data stream for transmission or storage purposes
-
- G—PHYSICS
- G10—MUSICAL INSTRUMENTS; ACOUSTICS
- G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
- G10L19/00—Speech 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/04—Speech 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/16—Vocoder architecture
- G10L19/18—Vocoders using multiple modes
- G10L19/22—Mode decision, i.e. based on audio signal content versus external parameters
-
- G—PHYSICS
- G10—MUSICAL INSTRUMENTS; ACOUSTICS
- G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
- G10L19/00—Speech 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/04—Speech 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/26—Pre-filtering or post-filtering
-
- G—PHYSICS
- G10—MUSICAL INSTRUMENTS; ACOUSTICS
- G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
- G10L21/00—Speech or voice signal processing techniques to produce another audible or non-audible signal, e.g. visual or tactile, in order to modify its quality or its intelligibility
- G10L21/02—Speech enhancement, e.g. noise reduction or echo cancellation
- G10L21/0316—Speech enhancement, e.g. noise reduction or echo cancellation by changing the amplitude
-
- G—PHYSICS
- G10—MUSICAL INSTRUMENTS; ACOUSTICS
- G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
- G10L19/00—Speech 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/04—Speech 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/16—Vocoder architecture
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04S—STEREOPHONIC SYSTEMS
- H04S3/00—Systems employing more than two channels, e.g. quadraphonic
Landscapes
- Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- Multimedia (AREA)
- Health & Medical Sciences (AREA)
- Audiology, Speech & Language Pathology (AREA)
- Human Computer Interaction (AREA)
- Signal Processing (AREA)
- Acoustics & Sound (AREA)
- Computational Linguistics (AREA)
- Mathematical Physics (AREA)
- Quality & Reliability (AREA)
- Stereophonic System (AREA)
- Compression, Expansion, Code Conversion, And Decoders (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Time-Division Multiplex Systems (AREA)
- Information Transfer Systems (AREA)
- Application Of Or Painting With Fluid Materials (AREA)
- Input Circuits Of Receivers And Coupling Of Receivers And Audio Equipment (AREA)
- Stereo-Broadcasting Methods (AREA)
Abstract
Un método para generar un flujo de bits de audio codificado, comprendiendo el método: la generación de una secuencia de tramas de un flujo de bits de audio codificado, en el que el flujo de bits de audio codificado es un flujo de bits en AC-3 o un flujo de bits en E-AC-3, siendo indicativo el flujo de bits de audio codificado de al menos un programa de audio, incluyendo cada trama de al menos un subconjunto de dichas tramas: metadatos de información sobre el programa en al menos un segmento de metadatos situado en al menos uno de: a) un campo de omisión de la trama; b) un campo addbsi de la trama; c) un campo aux de la trama; y datos de audio en al menos otro segmento de la trama, en el que el segmento de metadatos incluye al menos una carga útil de metadatos, comprendiendo dicha carga útil de metadatos: una cabecera: y, después de la cabecera, al menos alguno de los metadatos sobre información del programa, en el que los metadatos de información sobre el programa son indicativos de información acerca del al menos un programa de audio no presente en otras porciones del flujo de bits de audio codificado, en el que los metadatos de información sobre el programa incluyen metadatos de canal activo indicativos de cada canal no silencioso y cada canal silencioso del al menos un programa de audio.
Description
DESCRIPCIÓN
Codificador y descodificador de audio con metadatos de información de programa
Referencia cruzada a aplicaciones relacionadas
Esta solicitud reivindica la prioridad de la Solicitud de Patente Provisional de los Estados Unidos N° 61/836.865, presentada el 19 de junio de 2013.
Esta solicitud es una solicitud divisional europea de la solicitud de patente Euro-PCT, EP14813862.1 (referencia: D13004EP01), presentada el 12 de junio de 2014.
Campo técnico
La invención se refiere al procesamiento de señales de audio y, más particularmente, a la codificación y descodificación de flujos de bits de datos de audio con metadatos indicativos de estructura de flujo secundario y/o información de programa con respecto al contenido de audio indicado por los flujos de bits. Algunas formas de realización de la invención generan o descodifican datos de audio en uno de los formatos conocidos como Dolby Digital (AC-3), Dolby Digital Plus (AC-3 Mejorado o E- AC-3) o Dolby E.
Antecedentes de la invención
Dolby, Dolby Digital, Dolby Digital Plus y Dolby E son marcas registradas de Dolby Laboratories Licensing Corporation. Dolby Laboratories proporciona puestas en práctica propietarias en AC-3 y E-AC-3, conocidas como Dolby Digital y Dolby Digital Plus, respectivamente.
Unidades de procesamiento de datos de audio operan normalmente en una forma denominada ‘a ciegas’ y no prestan atención al historial de procesamiento de los datos de audio que se produce antes de que se reciban los datos. Esto puede funcionar en un marco de procesamiento en el que una sola entidad realiza todas las funciones de procesamiento y codificación de los datos de audio para una diversidad de dispositivos de representación de medios objetivo, mientras que un dispositivo de representación de medios objetivo realiza toda la descodificación y representación de los datos de audio codificados. Sin embargo, este procesamiento ‘a ciegas’ no funciona bien (o no funciona) en situaciones en las que una pluralidad de unidades de procesamiento de audio está dispersada a través de una red diversa o se colocan en tándem (es decir, en cadena) y se espera que realicen de forma óptima sus respectivos tipos procesamiento de audio. Por ejemplo, algunos datos de audio pueden estar codificados para sistemas de medios de alto rendimiento, y pueden tener que convertirse a una forma reducida adecuada para un dispositivo móvil a lo largo de una cadena de procesamiento de medios. En consecuencia, una unidad de procesamiento de audio puede realizar, de forma innecesaria, un tipo de procesamiento en los datos de audio que ya se han realizado. Por ejemplo, una unidad de nivelación de sonoridad puede realizar el procesamiento sobre un clip de audio de entrada, independientemente de si se ha realizado anteriormente, o no, la misma o similar nivelación de sonoridad en el clip de audio de entrada. En consecuencia, la unidad de nivelación de sonoridad puede realizar la nivelación incluso cuando no sea necesario. Este procesamiento innecesario puede causar también la degradación y/o la eliminación de características específicas mientras se representa el contenido de los datos de audio. La solicitud internacional WO02/091361A1 describe el uso de bits residuales (campo de omisión) para añadir datos a una trama de datos comprimida. El documento ATSC Standard: Compresión de audio digital (AC-3, E-AC-3), doc. A/52: 2012, 17-12-2012, da a conocer las especificaciones de los flujos de datos de AC-3 y E-AC-3. El documento "Specification of the Broadcast Wave Format; a format for audio data files", EBU Tech 3285 supl.6, octubre de 2009, describe algunos Metadatos en Dolby y segmentos de Metadatos en Dolby.
Compendio de la invención
La invención da a conocer un método para generar un flujo de bits de audio codificado según la reivindicación 1, un método para descodificar un flujo bits de audio codificado según la reivindicación 2, un medio de memorización o almacenamiento legible por ordenador según la reivindicación 6, y una unidad de procesamiento de audio según la reivindicación 7.
En la descripción, a partir de aquí, siempre que aparezca la palabra “realización/realizaciones”, si se refiere a combinaciones de características no compatibles con las definidas en las reivindicaciones, ha de considerarse que define ejemplos que se presentaron originalmente, pero que no representan realizaciones de la invención reivindicada, mostrándose estos ejemplos sólo con fines ilustrativos.
En un tipo de realizaciones, la invención es una unidad de procesamiento de audio capaz de descodificar un flujo de bits codificado que incluye metadatos de estructura de flujo secundario y/o metadatos de información sobre el programa (y, de modo opcional, también otros metadatos, por ejemplo metadatos de estado de procesamiento de sonoridad) en al menos un segmento de al menos una trama del flujo de bits y datos de audio en al menos otro segmento de la trama. En este caso, los metadatos de estructura flujo secundario (o "SSM") indican metadatos de un flujo de bits codificado (o conjunto de flujos de bits codificados), que indican la estructura de flujo secundario del contenido de audio del flujo o flujos de bits codificados y "metadatos de información sobre el programa" (o "PIM")
indican metadatos de un flujo de bits de audio codificado, indicativo de al menos un programa de audio (por ejemplo dos o más programas de audio), en donde los metadatos de información sobre el programa son indicativos de al menos una propiedad o característica del contenido de audio de al menos uno de dichos programas (por ejemplo metadatos que indican un tipo o parámetro de procesamiento realizado en datos de audio del programa, o metadatos que indican qué canales del programa son canales activos).
En casos típicos (por ejemplo, en los que el flujo de bits codificado es un flujo de bits en AC-3 o E-AC-3), los metadatos de información sobre el programa (PIM) son indicativos de información de programa que, prácticamente, no pueden transmitirse en otras partes del flujo de bits. Por ejemplo, los PIM pueden ser indicativos del procesamiento aplicado al audio de PCM antes de la codificación (por ejemplo, codificación AC-3 o E-AC-3), cuyas bandas de frecuencia del programa de audio se han codificado utilizando técnicas específicas de codificación de audio, y el perfil de compresión utilizado para crear datos de compresión de margen dinámico (DRC) en el flujo de bits.
En otro tipo de realizaciones, un método incluye una etapa de multiplexación de datos de audio codificados con SSM y/o PIM en cada trama (o de cada una de al menos algunas tramas) del flujo de bits. En la descodificación típica, un descodificador extrae el SSM y/o PIM del flujo de bits (incluyendo, mediante análisis y desmultiplexación de SSM y/o PIM y los datos de audio) y procesa los datos de audio para generar un flujo de datos de audio descodificados (y, en algunos casos, realiza además un procesamiento adaptativo de los datos de audio). En algunas formas de realización, los datos de audio descodificados y SSM y/o PIM, se reenvían desde el descodificador a un post-procesador configurado para realizar un procesamiento adaptativo sobre los datos de audio descodificados utilizando los SSM y/o los PIM.
En un tipo de realizaciones, el método de codificación inventivo genera un flujo de bits de audio codificado (por ejemplo, un flujo de bits en AC-3 o E-AC-3), que incluye segmentos de datos de audio (por ejemplo, los segmentos AB0-AB5 de la trama ilustrada en la Figura 4, o la totalidad o algunos de los segmentos AB0-AB5 de la trama ilustrada en la Figura 7), que incluye datos de audio codificados y segmentos de metadatos (incluyendo SSM y/o PIM y, opcionalmente, otros metadatos) multiplexados por división de tiempo con los segmentos de datos de audio. En algunas realizaciones, cada segmento de metadatos (a veces denominado en este documento como un "contenedor") tiene un formato que incluye una cabecera de segmento de metadatos (y, de forma opcional, también otros elementos obligatorios o "principales" o de núcleo), y una o más cargas útiles de metadatos después de la cabecera de segmento de metadatos. SIM, si está presente, se incluye en una de las cargas útiles de metadatos (que se identifica por una cabecera de carga útil y, por lo general, tiene un formato de un primer tipo). PIM, si está presente, se incluye en otra de las cargas útiles de metadatos (identificada por una cabecera de carga útil y que tiene normalmente un formato de un segundo tipo). De modo similar, cada otro tipo de metadatos (si está presente) se incluye en una distinta de las cargas útiles de metadatos (que se identifica por una cabecera de carga y que suele tener un formato específico para el tipo de metadatos). El formato, a modo de ejemplo, permite un acceso conveniente para los SSM, PIM y otros metadatos en momentos diferentes a la descodificación (por ejemplo, por un post-procesador que sigue a la descodificación, o mediante un procesador configurado para reconocer los metadatos sin realizar una descodificación completa en el flujo de bits codificado), y permite la detección y corrección de errores de forma conveniente y eficiente (por ejemplo, de identificación de flujo secundario) durante la descodificación del flujo de bits. Por ejemplo, sin acceso a SSM en el formato de ejemplo, un descodificador podría identificar, incorrectamente, el número correcto de flujos secundarios asociados con un programa. Una carga útil de metadatos, en un segmento de metadatos, puede incluir SSM, otra carga útil de metadatos, en el segmento de metadatos, puede incluir PIM y, opcionalmente, al menos otra carga útil de metadatos, en el segmento de metadatos, puede incluir otros metadatos (por ejemplo, metadatos de estado de procesamiento de sonoridad o "LPSM").
Breve descripción de los dibujos
La Figura 1 es un diagrama de bloques de una forma de realización de un sistema que puede configurarse para realizar una forma de realización del método de la invención.
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 descodificador, que es una realización de la unidad de procesamiento de audio inventiva, y un post-procesador acoplado al mismo, que es otra realización de la unidad de procesamiento de audio inventiva.
La Figura 4 es un diagrama de una trama en AC-3, que incluye los segmentos en los que está dividido.
La Figura 5 es un diagrama del segmento de Información de Sincronización (SI) de una trama en AC-3, que incluye los segmentos en los que está dividido.
La Figura 6 es un diagrama del segmento de Información de Flujo de bits (BSI) de una trama en AC-3, incluidos los segmentos en los que está dividido.
La Figura 7 es un diagrama de una trama en E-AC-3, incluidos los segmentos en los que está dividido.
La Figura 8 es un diagrama de un segmento de metadatos de un flujo de bits codificado, generado de conformidad con una forma de realización de la invención, que incluye una cabecera de segmento de metadatos que comprende una palabra de sincronización de contenedor (identificada como “sincronización de contenedor” en la Figura 8) y valores de versión y de ID de clave, seguido de múltiples cargas útiles de metadatos y bits de protección.
NOTACIÓN Y TERMINOLOGÍA
A través de esta descripción, incluyendo las reivindicaciones, la expresión que realiza una operación "sobre" una señal o datos (por ejemplo, filtrado, escalado, transformación o aplicación de ganancia a, la señal o datos) se usa en un sentido amplio para indicar la realización de la operación directamente en la señal o datos o, sobre una versión procesada, de la señal o datos (por ejemplo sobre una versión de la señal que ha sido sometida a filtrado preliminar o pre-procesamiento antes de la ejecución de la propia operación).
A lo largo de esta descripción, que incluye las reivindicaciones, la expresión "sistema" se utiliza en un sentido amplio para designar un dispositivo, sistema o subsistema. A modo de ejemplo, un subsistema que pone en práctica un descodificador se puede referir como un sistema descodificador, y un sistema que incluye dicho subsistema (por ejemplo, un sistema que genera X señales de salida en respuesta a múltiples entradas, en donde el subsistema genera M de las entradas y las otras X - M entradas se reciben desde una fuente externa) se puede denominar también un sistema descodificador.
A través de esta descripción, que incluye las reivindicaciones, el término "procesador" se utiliza en un sentido amplio para designar un sistema o dispositivo programable o, de cualquier otro modo, configurable (por ejemplo, con software o firmware) para realizar operaciones en datos (por ejemplo, audio, o vídeo u otros datos de imagen). Ejemplos de procesadores incluyen una matriz de puertas programable in situ (u otro conjunto de circuitos integrados configurables o de chips), un procesador de señal digital programado y/o, de otro modo, configurado para realizar un procesamiento más eficiente en datos de audio u otros datos de sonido, un procesador u ordenador de uso general programable, y un chip o conjunto de chips o de microprocesador programable.
A lo largo de esta descripción, que incluye las reivindicaciones, las expresiones "procesador de audio" y "unidad de procesamiento de audio" se utilizan indistintamente y, en un sentido amplio, para indicar un sistema configurado para procesar datos de audio. Ejemplos de unidades de procesamiento de audio incluyen, pero sin limitación, codificadores (por ejemplo, transcodificadores), descodificadores, codificadores-descodificadores (codes), sistemas de procesamiento previo, sistemas de procesamiento posterior y sistemas de procesamiento de flujo de bits (a veces referidos como herramientas de procesamiento de flujo de bits).
A través de esta descripción, que incluye las reivindicaciones, la expresión "metadatos" (de un flujo de bits de audio codificado), se refiere a datos separados y diferentes de los datos de audio correspondientes del flujo de bits.
A lo largo de esta descripción, que incluye las reivindicaciones, la expresión "metadatos de estructura de flujo secundario" (o "SSM"), indica metadatos de un flujo de bits de audio codificado (o un conjunto de flujos de bits de audio codificados), que indican la estructura flujo secundario del contenido de audio del o de los flujos de bits codificados.
A través de esta descripción, que incluye las reivindicaciones, la expresión "metadatos de información sobre el programa" (o "PIM") indica metadatos de un flujo de bits de audio codificado, indicativo de al menos un programa de audio (por ejemplo, dos o más programas de audio), en donde dichos metadatos indican, al menos, una propiedad o característica del contenido de audio de al menos uno de dichos programas (por ejemplo, metadatos que indican un tipo o parámetro de procesamiento realizado sobre datos de audio del programa, o metadatos que indican qué canales del programa son canales activos).
A lo largo de esta descripción, que incluye las reivindicaciones, la expresión "metadatos de estado de procesamiento" (por ejemplo, como en la expresión "metadatos de estado de procesamiento de sonoridad"), se refiere a metadatos (de un flujo de bits de audio codificado) asociados con datos de audio del flujo de bits, que indican el estado de procesamiento de los datos de audio correspondientes (asociados) (por ejemplo, qué tipo o tipos de procesamiento ya se han realizado en los datos de audio) y normalmente indica, además, al menos una función o característica de los datos de audio. La asociación de los metadatos del estado de procesamiento con los datos de audio está sincronizada en el tiempo. Por lo tanto, los metadatos de estado de procesamiento presentes (más recientemente recibidos o actualizados) indican que los correspondientes datos de audio comprenden, contemporáneamente, los resultados del tipo o tipos indicados de procesamiento de datos de audio. En algunos casos, metadatos de estado de procesamiento pueden incluir el historial de procesamiento y/o algunos, o la totalidad, de los parámetros que se utilizan y/o derivan de los tipos de procesamiento indicados. Además, los metadatos de estado de procesamiento pueden incluir al menos una función o característica de los correspondientes datos de audio, que se ha calculado o extraído a partir de los datos de audio. Metadatos de estado de procesamiento pueden incluir, además, otros metadatos que no están relacionados, ni derivados, de ningún 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 preferencia de usuario, etc., pueden ser añadidos por una unidad de procesamiento de audio
particular para pasar a otras unidades de procesamiento de audio.
A través de esta descripción, que incluye las reivindicaciones, la expresión "metadatos de estado de procesamiento de sonoridad" (o "LPSM"), indica metadatos de estado de procesamiento, indicativos del estado de procesamiento de sonoridad de los correspondientes datos de audio (por ejemplo, qué tipo(s) de procesamiento(s) de sonoridad se ha(n) realizado en los datos de audio) y normalmente también al menos una función o característica (por ejemplo, sonoridad) de los correspondientes datos de audio. Los metadatos de estado de procesamiento de sonoridad pueden incluir datos (por ejemplo, otros metadatos) que no son (es decir, cuando se considera por sí solos) metadatos de estado de procesamiento de sonoridad.
A lo largo de esta descripción, que incluye las reivindicaciones, la expresión "canal" (o "canal de audio"), indica una señal de audio monofónica.
A través de esta descripción, que incluye las reivindicaciones, la expresión "programa de audio" indica un conjunto de uno o más canales de audio y, opcionalmente, también metadatos asociados (por ejemplo, metadatos que describen una presentación de audio espacial deseada, y/o PIM, y/o SSM, y/o LPSM y/o metadatos de límite de programa).
A lo largo de esta descripción, que incluye las reivindicaciones, la expresión “metadatos de límite de programa”, indica metadatos de un flujo de bits de audio codificado, en donde el flujo de bits de audio codificado es indicativo de al menos un programa de audio (por ejemplo, dos o más programas de audio), y los metadatos de límite del programa indican la ubicación, en el flujo de bits, de al menos un límite (comienzo y/o final) de al menos uno de dichos programas de audio. Por ejemplo, los metadatos de límite de programa (de un flujo de bits de audio codificado, indicativo de un programa de audio), pueden incluir metadatos que indican la localización (por ejemplo, el inicio de la "N"-sima trama del flujo de bits, o la “M”-sima localización de muestra de la "N"-sima trama del flujo de bits), desde el comienzo del programa, y metadatos adicionales indicativos de la ubicación (por ejemplo, la "J"-ésima trama del flujo de bits, o la "K"-ésima localización de muestra de la "J"-ésima trama del flujo de bits) del final de programa.
A través de esta descripción, que incluye las reivindicaciones, el término "acopla" o "acoplado" se utiliza para indicar una conexión directa o indirecta. En consecuencia, si un primer dispositivo se acopla a un segundo dispositivo, esa conexión puede ser a través de una conexión directa, o a través de una conexión indirecta, a través de otros dispositivos y conexiones.
Descripción detallada de las formas de realización de la invención
Un flujo típico de datos de audio incluye tanto contenido de audio (por ejemplo, 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 flujo de bits en AC-3 existen varios parámetros de metadatos de audio que están específicamente previstos para ser utilizados para cambiar el sonido del programa entregado a un entorno de escucha. Uno de los parámetros de metadatos es el parámetro DIALNORM, que está destinado a indicar el nivel medio de diálogo en un programa de audio, y se utiliza para determinar el nivel de señal de reproducción de audio.
Durante la reproducción de un flujo de bits que comprende una secuencia de diferentes segmentos de programa de audio, (cada uno con un parámetro DIALNORM diferente), un descodificador en AC-3 utiliza el parámetro DIALNORM de cada segmento para realizar un tipo de procesamiento de sonoridad, en el que modifica el nivel de reproducción o sonoridad de tal manera que la sonoridad percibida del diálogo de la secuencia de segmentos está en un nivel constante. Cada segmento (ítem) de audio codificado, en una secuencia de ítems de audio codificados, tendría (en general) un parámetro DIALNORM diferente, y el descodificador establecería a escala el nivel de cada uno de los ítems de modo que el nivel de reproducción o la sonoridad del diálogo, para cada elemento, sea igual o muy similar, aunque esto podría requerir la aplicación de diferentes cantidades de ganancia a diferentes ítems durante la reproducción.
El parámetro DIALNORM se suele establecer por un usuario, y no se genera de forma automática, aunque existe un valor por defecto del parámetro DIALNORM 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 en AC-3 y a continuación, transmitir el resultado (indicativo de la intensidad del diálogo hablado de un programa de audio) al codificador para establecer el valor de DIALNORM. Por lo tanto, se confía en el creador del contenido para establecer correctamente el parámetro DIALNORM.
Existen varias razones diferentes por las que el parámetro DIALNORM, en un flujo de bits en AC-3, puede ser incorrecto. En primer lugar, cada codificador en AC-3 tiene un valor de DIALNORM por defecto que se utiliza durante la generación del flujo de bits si el creador de contenido no establece un valor de DIALNORM. Este valor por defecto puede ser esencialmente distinto del nivel de sonoridad de diálogo real del audio. En segundo lugar, incluso si un creador de contenido mide la sonoridad y establece el valor de DIALNORM en consecuencia, es posible que se haya utilizado un algoritmo de medición de sonoridad, o medidor, que no esté en conformidad con el método de medición de sonoridad en AC-3 recomendado, lo que da como resultado un valor de DIALNORM incorrecto. En tercer lugar, incluso si se ha creado un flujo de bits en AC-3 con el valor de DIALNORM medido y establecido correctamente por el creador del contenido, puede haberse cambiado a un valor incorrecto durante la transmisión y/o memorización del flujo de bits. Por ejemplo, no es infrecuente en aplicaciones de difusión de televisión que flujos de bits en AC-3 se
descodifiquen, modifiquen y a continuación, se vuelvan a codificar utilizando información de metadatos de DIALNORM incorrecta. De este modo, un valor de DIALNORM, incluido en un flujo de bits en AC-3, puede ser incorrecto o impreciso y, por lo tanto, puede tener un impacto negativo sobre la calidad de la experiencia de escucha.
Además, el parámetro DIALNORM no indica el estado de procesamiento de la sonoridad de los correspondientes datos de audio (por ejemplo, qué tipo de procesamiento de sonoridad se ha realizado en los datos de audio). Metadatos de estado de procesamiento de sonoridad (en el formato en el que se proporcionan en algunas formas de realización de la presente invención), son útiles para facilitar el procesamiento de sonoridad adaptativo de un flujo de bits de audio y/o la verificación de la validez del estado de procesamiento de sonoridad y la sonoridad del contenido de audio, de una manera particularmente eficiente.
Un flujo de bits codificado en AC-3 comprende metadatos, y uno a seis canales de contenido de audio. El contenido de audio son datos de audio que se han comprimido utilizando una codificación de audio perceptivo. Los metadatos incluyen varios parámetros de metadatos de audio que están destinados a ser utilizados para cambiar el sonido de un programa proporcionado a un entorno de escucha.
Cada trama de un flujo de bits de audio codificado en AC-3, incluye contenido de audio y metadatos para 1536 muestras de audio digital. Para una tasa de muestreo de 48 kHz, esto representa 32 milisegundos de audio digital o una tasa de 31,25 tramas por segundo de audio.
Cada trama de un flujo de bits de audio codificado en E-AC-3, incluye 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 tasa de muestreo de 48 kHz, esto representa 5,333, 10,667, 16 ó 32 milisegundos de audio digital, respectivamente, o una tasa de 189,9, 93,75, 62,5 ó 31,25 tramas por segundo de audio, respectivamente.
Tal como se indica en la Figura 4, cada trama en AC-3 está dividida en secciones (segmentos), que incluyen: una sección de Información de Sincronización (SI), que contiene (tal como se muestra en la Figura 5), una palabra de sincronización (SW) y la primera de dos palabras de corrección de errores (CRC1); una sección de Información de Flujo de Bits (BSI), que contiene la mayoría de los metadatos; seis Bloques de Audio (AB0 a AB5), que tienen contenido de audio comprimidos de datos (y además, pueden incluir metadatos); segmentos de bits residuales (W) (también conocidos como "campos de omisión"), que contienen cualesquiera bits no utilizados que queden después de que se comprima el contenido de audio; una sección de información Auxiliar (AUX) que puede incluir más metadatos; y la segunda de dos palabras de corrección de error (CRC2).
Tal como se indica en la Figura 7, cada trama en E-AC-3 está dividida en secciones (segmentos), que incluyen: una sección de Información de Sincronización (SI), que contiene (tal como se muestra en la Figura 5) una palabra de sincronización (SW); una sección de Información de Flujo de bits (BSI), que contiene la mayoría de los metadatos; entre uno y seis Bloques de Audio (AB0 a AB5), que tienen contenido de audio comprimidos de datos (y, además, pueden incluir metadatos); segmentos de bits residuales (W) (también conocidos como "campos de omisión"), que contienen cualesquiera bits no utilizados que queden después de comprimir el contenido de audio (aunque solamente se ilustra un segmento de bits residuales, un segmento de bits residuales diferente, o segmento de campo de omisión, que normalmente seguiría cada bloque de audio); una sección de información Auxiliar (AUX) que puede incluir más metadatos; y una palabra de corrección de error (CRC).
En un flujo de bits en AC-3 (o E-AC-3) existen varios parámetros de metadatos de audio que están previstos, específicamente, a ser utilizados para cambiar el sonido del programa que se proporciona a un entorno de escucha. Uno de los parámetros de metadatos es el parámetro DIALNORM, que está incluido en el segmento de BSI.
Según se ilustra en la Figura 6, el segmento de BSI de una trama en AC-3 incluye un parámetro de cinco bits ("DIALNORM"), que indica el valor de DIALNORM para el programa. Se incluye un parámetro de cinco bits ("DIALNORM2"), que indica el valor de DIALNORM para un segundo programa de audio que se transmite en la misma trama en AC-3 si el modo de codificación de audio ("acmod"), de la trama en AC-3, es "0", lo que indica que se está utilizando una configuración de canal dual-mono o "1+1".
El segmento de BSI incluye, además, un indicador ("addbsie"), que indica la presencia, (o ausencia), de información de flujo de bits adicional que sigue al bit de "addbsie", un parámetro ("addbsil"), que indica la longitud de cualquier información adicional de flujo de bits que sigue al valor de "addbsil", y hasta 64 bits de información de flujo de bits adicional ("addbsi") que sigue al valor de "addbsil".
El segmento de BSI incluye otros valores de metadatos que no se ilustran específicamente en la Figura 6.
De conformidad con una clase de formas de realización, un flujo de bits de audio codificado es indicativo de múltiples flujos secundarios de contenido de audio. En algunos casos, los flujos secundarios son indicativos del contenido de audio de un programa multicanal, y cada uno de los flujos secundarios indica uno o más de los canales del programa. En otros casos, múltiples flujos secundarios de un flujo bits de audio codificado, son indicativos del contenido de audio de varios programas de audio, normalmente un programa de audio "principal" (que puede ser un programa multicanal), y al menos otro programa de audio (por ejemplo, un programa que es un comentario sobre el programa de audio
principal).
Un flujo de bits de audio codificado, que es indicativo de al menos un programa de audio, incluye necesariamente al menos un flujo secundario "independiente" de contenido de audio. El flujo secundario independiente es indicativo de al menos un canal de un programa de audio (por ejemplo, el flujo secundario independiente puede ser indicativo de los cinco canales de margen completo de un programa de audio de canal 5.1 convencional). En este caso, este programa de audio se refiere como un programa "principal".
En algunas clases de formas de realización, un flujo de bits de audio codificado es indicativo de dos o más programas de audio (un programa "principal" y al menos otro programa de audio). En tales casos, el flujo de bits incluye dos o más flujos secundarios independientes: un primer flujo secundario independiente, que indica al menos un canal del programa principal; y al menos otro flujo secundario independiente, indicativo de al menos un canal de otro programa de audio (un programa distinto del programa principal). Cada flujo de bits independiente se puede descodificar de forma independiente, y un descodificador podría funcionar para descodificar solamente un subconjunto (no la totalidad) de los flujos secundarios independientes de un flujo de bits codificado.
En un ejemplo típico de un flujo de bits de audio codificado, que es indicativo de dos flujos secundarios independientes, uno de los flujos secundarios independientes es indicativo de canales de altavoz de formato estándar de un programa principal multicanal (por ejemplo, Izquierda, Derecha, Centro, Rodeando la Izquierda, Rodeando la Derecha como canales de altavoz de gama completa de un programa principal de canal 5.1), y el otro flujo secundario independiente es indicativo de un comentario de audio monofónico en el programa principal (por ejemplo., un comentario de un director sobre una película, en donde el programa principal es la banda sonora de la película). En otro ejemplo de un flujo de bits de audio codificado, que indica múltiples flujos secundarios independientes, uno de los flujos secundarios independientes es indicativo de canales de altavoz de formato estándar de un programa principal multicanal (por ejemplo, un programa principal de canal 5.1), que incluye diálogo en un primer idioma (por ejemplo, uno de los canales de altavoz del programa principal puede ser indicativo del diálogo), y cada uno de los otros flujos secundarios independientes es indicativo de una traducción monofónica (en un idioma diferente) del diálogo.
Opcionalmente, un flujo de bits de audio codificado, que es indicativo de un programa principal (y, de forma opcional, también de al menos otro programa de audio) incluye al menos un flujo secundario "dependiente" de contenido de audio. Cada flujo secundario dependiente está asociado con un flujo secundario independiente del flujo de bits, y es indicativo de al menos un canal adicional del programa (por ejemplo, el programa principal), cuyo contenido está indicado por el flujo secundario independiente asociado (es decir, el flujo secundario dependiente indica al menos un canal de un programa que no está indicado por el flujo secundario independiente asociado, y el flujo secundario independiente asociado, indica al menos un canal del programa).
En un ejemplo de un flujo de bits codificado que incluye un flujo secundario independiente (indicativo de al menos un canal de un programa principal), el flujo de bits incluye además un flujo secundario dependiente (asociado con el flujo de bits independiente) que es indicativo de uno o más canales de altavoz del programa principal. Dichos canales de altavoz adicionales, son adicionales al canal o los canales del programa principal indicados por el flujo secundario independiente. Por ejemplo, si el flujo secundario independiente es indicativo de los formatos estándar izquierdo, derecho, central, rodeando al izquierdo, rodeando al derecho, como canales de altavoz de gama completa de un programa principal de canal 7.1, pudiendo el flujo secundario dependiente ser indicativo de los otros dos canales de altavoz de gama completa del programa principal.
De conformidad con la norma E-AC-3, un flujo de bits en E-AC-3 debe ser indicativo de al menos un flujo secundario independiente (por ejemplo, un único flujo de bits en AC-3), y puede ser indicativo de hasta ocho flujos secundarios independientes. Cada flujo secundario independiente, de un flujo de bits en E-AC-3, puede asociarse con hasta ocho flujos secundarios dependientes.
Un flujo de bits en E-AC-3 incluye metadatos que indican la estructura de flujo secundario del flujo de bits. Por ejemplo, un campo "chanmap", en la sección de Información de Flujo de Bits (BSI), de un flujo de bits en E-AC-3, determina un mapa de canales para los canales de programa indicados por un flujo secundario dependiente del flujo bits. Sin embargo, los metadatos indicativos de la estructura de flujo secundario se incluyen, de modo convencional, en un flujo de bits en E-AC-3, en un formato tal que es conveniente para el acceso y uso (durante la descodificación del flujo de bits codificado en E-AC-3) solamente por un descodificador en E-AC-3; no para el acceso y uso después de la descodificación (por ejemplo, por un post-procesador), o antes de la descodificación (por ejemplo, por un procesador configurado para reconocer los metadatos). Además, existe el riesgo de que un descodificador identifique incorrectamente los flujos secundarios de un flujo de bits codificado en E-AC-3 convencional, utilizando los metadatos incluidos convencionalmente, y hasta la presente invención no se ha tenido conocimiento de cómo incluir metadatos de estructura de flujo secundario en un flujo de bits codificado (por ejemplo, un flujo de bits en E-AC-3 codificado) en un formato tal que permita la detección y corrección, convenientes y eficientes, de errores en la identificación del flujo secundario durante la descodificación del flujo de bits.
Un flujo de bits en E-AC-3 puede incluir también metadatos con respecto al contenido de audio de un programa de audio. Por ejemplo, un flujo de bits en E-AC-3, indicativo de un programa de audio, incluye metadatos indicativos de frecuencias mínima y máxima en los que se ha utilizado el procesamiento de extensión espectral (y la codificación de
acoplamiento de canal), con el fin de codificar el contenido del programa. Sin embargo, tales metadatos se suelen incluir en un flujo de bits en E-AC-3 en un formato tal que es conveniente para el acceso y uso (durante la descodificación del flujo de bits en E-AC-3 codificado) solamente por un descodificador en E-AC-3; no para el acceso y uso después de la descodificación (por ejemplo, por un post-procesador), o antes de la descodificación (por ejemplo, por un procesador configurado para reconocer los metadatos). Además, dichos metadatos no se incluyen en un flujo de bits en E-AC-3 en un formato que permita la detección de error y la corrección de error convenientes y eficientes de dichos metadatos durante la descodificación del flujo de bits.
De conformidad con las formas de realización típicas de la invención, PIM y/o SSM (y opcionalmente, también otros metadatos, por ejemplo metadatos de estado de procesamiento de sonoridad o "LPSM'') están incluidos en uno o más campos reservados (o ranuras) de segmentos de metadatos de un flujo de bits de audio que incluye, además, datos de audio en otros segmentos (segmentos de datos de audio). Normalmente, al menos un segmento de cada trama del flujo de bits incluye PIM o SSM, y al menos otro segmento de la trama incluye datos de audio correspondientes (es decir, datos de audio cuya estructura de flujo secundario está indicada por SSM y/o tiene al menos una característica o propiedad indicada por los PIM).
En una clase de formas de realización, cada segmento de metadatos es una estructura de datos (a veces referida aquí como un contenedor) que puede incluir una o más cargas útiles de metadatos. Cada carga útil incluye una cabecera que comprende un identificador de carga útil específico (y datos de configuración de carga útil), para proporcionar una indicación inequívoca del tipo de metadatos presentes en la carga útil. El orden de las cargas dentro del contenedor no está definido, de modo que las cargas útiles se pueden memorizar en cualquier orden, y un analizador sintáctico debe poder analizar el contenedor completo con el fin de extraer cargas útiles pertinentes e ignorar las cargas útiles que no son pertinentes o no están soportadas. La Figura 8 (que se describirá a continuación) ilustra la estructura de dicho contenedor y cargas útiles dentro del contenedor.
La comunicación de metadatos (por ejemplo., SSM y/o PIM y/o LPSM) 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 tándem’ entre sí a lo largo de la cadena de procesamiento (o ciclo de vida del contenido). Sin la inclusión de metadatos en un flujo de bits de audio, pueden producirse graves problemas de procesamiento del medio tales como degradaciones de calidad, de nivel y espaciales, por ejemplo, cuando se utilizan dos o más codecs de audio en la cadena y la nivelación de volumen de terminación única se aplica más de una vez durante una ruta de flujo de bits a un dispositivo que consume medios (o un punto de representación del contenido de audio del flujo de bits).
Los metadatos de estado de procesamiento de sonoridad (LPSM), que se incluyen en un flujo de bits de audio de conformidad con algunas formas de realización de la invención, se pueden autenticar y validar, por ejemplo para permitir a las entidades reguladoras de sonoridad la comprobación de si la sonoridad de un programa particular está ya dentro de un margen especificado, y que los propios datos de audio correspondientes no han sido modificados (con lo que se asegura el cumplimiento de la normativa aplicable). Un valor de sonoridad, incluido en un bloque de datos que comprende los metadatos de estado de procesamiento de sonoridad, puede ser objeto de lectura para la verificación de lo que antecede, en lugar de calcular la sonoridad de nuevo. En respuesta a LPSM, una agencia reguladora puede determinar que el contenido de audio correspondiente está en cumplimiento (según lo indicado por el LPSM) con requisitos reglamentarios y/o estatutarios de intensidad sonora (por ejemplo, las normativas promulgadas bajo la Ley de Mitigación de la Sonoridad de Anuncios Comerciales, también conocida como la Ley de "CALM") sin la necesidad de calcular la sonoridad del contenido de audio.
La Figura 1 es un diagrama de bloques de un ejemplo de cadena de procesamiento de audio (un sistema de procesamiento de datos de audio), en el que uno o más de los elementos del sistema se pueden configurar de conformidad con una forma de realización de la presente invención. El sistema incluye los siguientes elementos, acoplados conjuntamente según se ilustra: una unidad de procesamiento previo, un codificador, una unidad de corrección de metadatos y análisis de señal, un transcodificador, un descodificador y una unidad de procesamiento previo. En las variaciones del sistema ilustrado, se omiten uno o más de los elementos, o se incluyen unidades adicionales de procesamiento de datos de audio.
En algunas ejecuciones prácticas, la unidad de procesamiento previo de la Figura 1 está configurada para aceptar muestras de PCM (dominio de tiempo), que comprenden contenido de audio como entrada, y para emitir muestras de PCM procesadas. El codificador se puede configurar para aceptar las muestras de PCM como entrada, y para proporcionar, a la salida, un flujo de bits de audio codificado (por ejemplo, comprimido), que indica el contenido de audio. Los datos del flujo de bits que son indicativos del contenido de audio a veces se denominan aquí "datos de audio". Si el codificador está configurado de conformidad con una forma de realización típica de la presente invención, la salida de flujo de bits de audio desde el codificador incluye PIM y/o SSM (y opcionalmente, además, metadatos de estado de procesamiento de sonoridad y/o otros metadatos) así como datos de audio.
La unidad de corrección de metadatos y análisis de señal de la Figura 1 puede aceptar uno o más flujos de bits de audio codificados como entrada, y determinar (por ejemplo, validar), si los metadatos (por ejemplo, metadatos de estado de procesamiento), en cada flujo de bits de audio codificado son correctos, realizando análisis de señal (por ejemplo, utilizando metadatos de límite de programa en un flujo de bits de audio codificado). Si la unidad de corrección de metadatos y análisis de señal encuentra que los metadatos incluidos no son válidos, normalmente, sustituye los
valores incorrectos con los valores correctos obtenidos a partir del análisis de señal. De este modo, cada salida de flujo de bits de audio codificado, procedente de la unidad de corrección de metadatos y análisis de señal, 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 flujos de bits de audio codificados como entrada, y a la salida, responder con flujos de bits de audio modificados (por ejemplo, codificados de modo distinto) (por ejemplo, descodificando un flujo de entrada y recodificando el flujo descodificado en un formato de codificación diferente). Si el transcodificador está configurado de conformidad con una forma de realización típica de la presente invención, el flujo de bits de audio de salida, procedente del transcodificador, incluye SSM y/o PIM (y además, normalmente otros metadatos), así como datos de audio codificados. Los metadatos pueden haberse incluido en el flujo de bits de entrada.
El descodificador de la Figura 1 puede aceptar flujos de bits de audio codificados (por ejemplo, comprimidos) como entrada y, a la salida (en respuesta) flujos de muestras de audio de PCM descodificadas. Si el descodificador está configurado de conformidad con una forma de realización típica de la presente invención, la salida del descodificador, en funcionamiento típico, es o incluye cualquiera de lo que sigue:
un flujo de muestras de audio, y al menos un flujo correspondiente de SSM y/o PIM (y normalmente también otros metadatos), extraídos de un flujo de bits codificado de entrada; o
un flujo de muestras de audio, y un flujo correspondiente de bits de control determinados a partir de SSM y/o PIM (y normalmente también otros metadatos, por ejemplo, LPSM), extraídos de un flujo bits codificado de entrada; o
un flujo de muestras de audio, sin un flujo correspondiente de metadatos o bits de control, determinados a partir de metadatos. En este último caso, el descodificador puede extraer metadatos a partir del flujo de bits codificado de entrada y realizar al menos una operación en los metadatos extraídos (por ejemplo, validación), aun cuando no da la salida los metadatos extraídos o bits de control determinados a partir de los mismos.
Mediante la configuración de la unidad de procesamiento posterior de la Figura 1 de conformidad con una forma de realización típica de la presente invención, la unidad de procesamiento posterior está configurada para aceptar un flujo de muestras de audio de PCM descodificadas, y para realizar un procesamiento posterior sobre el mismo (por ejemplo, nivelación de volumen del contenido de audio) utilizando SSM y/o PIM (y, normalmente, también otros metadatos, por ejemplo, LPSM), recibidos con las muestras, o bits de control determinados por el descodificador a partir de los metadatos recibidos con las muestras. La unidad de post-procesamiento está configurada normalmente, además, para interpretar el contenido de audio procesado posteriormente para su reproducción por uno o más altavoces.
Formas de realización típicas de la presente invención proporcionan una cadena de procesamiento de audio mejorada, en la que unidades de procesamiento de audio (por ejemplo, codificadores, descodificadores, transcodificadores y unidades de procesamiento previo y posterior), adaptan su respectivo procesamiento para aplicarlo a datos de audio de conformidad con un estado contemporáneo de los datos del medio, según lo indicado por los metadatos recibidos, respectivamente, por las unidades de procesamiento de audio.
La entrada de datos de audio a cualquier unidad de procesamiento de audio del sistema de la Figura 1 (por ejemplo, el codificador o transcodificador de la Figura 1) puede incluir SSM y/o PIM (y, opcionalmente, también otros metadatos) así como datos de audio (por ejemplo, datos de audio codificados). Estos metadatos pueden haber sido incluidos en el audio de entrada por otro elemento del sistema de la Figura 1 (u otra fuente, no ilustrada en la Figura 1), de conformidad con una forma de realización de la presente invención. La unidad de procesamiento que recibe el audio de entrada (con metadatos) se puede configurar para realizar al menos una operación en los metadatos (por ejemplo, validación), o en respuesta a los metadatos (por ejemplo, procesamiento adaptativo del audio de entrada) y normalmente incluir además 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 forma de realización típica de la unidad de procesamiento de audio inventiva (o procesador de audio) está configurada para realizar un procesamiento adaptativo de datos de audio, sobre la base del estado de los datos de audio, tal como se indica por los metadatos correspondientes a los datos de audio. En algunas formas de realización, el procesamiento adaptativo es, (o incluye) procesamiento de sonoridad (si los metadatos indican que el procesamiento de sonoridad, o procesamiento similar al mismo, aún no se ha realizado en los datos de audio, pero no es (y no incluye) procesamiento de sonoridad (si los metadatos indican que dicho procesamiento de sonoridad, o procesamiento similar al mismo, ya se ha realizado en los datos de audio). En algunas formas de realización, el procesamiento adaptativo es, o incluye, la validación de metadatos (por ejemplo, realizada en una sub-unidad de validación de metadatos) con el fin de garantizar que la unidad de procesamiento de audio realice otro procesamiento adaptativo de los datos de audio sobre la base del estado de los datos de audio, según lo indicado por los metadatos. En algunas formas de realización, la validación determina la fiabilidad de los metadatos asociados (por ejemplo, incluidos en un flujo de bits) con los datos de audio. Por ejemplo, si los metadatos se validan para ser fiables, en ese caso los resultados de un tipo de procesamiento de audio previamente realizado se pueden reutilizar y se puede evitar una nueva ejecución del mismo tipo de procesamiento de audio. Por otro lado, si se descubre que los metadatos han sido manipulados (o de otro modo, no son fiables) entonces, se puede repetir el tipo de procesamiento multimedia supuestamente realizado con anterioridad por la unidad de procesamiento de audio sobre los metadatos y/o los datos
de audio. La unidad de procesamiento de audio puede, además, estar configurada para señalar a otras unidades de procesamiento de audio, aguas abajo en una cadena de procesamiento del medio mejorada, que los metadatos (por ejemplo, presentes en un flujo de bits del medio) son válidos, si la unidad determina que los metadatos son válidos (por ejemplo, sobre la base de una coincidencia 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 forma de realización de la unidad de procesamiento de audio inventiva. Cualquiera de los componentes o elementos del codificador 100 se puede poner en práctica como uno o más procesos y/o uno o más circuitos (por ejemplo, ASICs, FPGAs u otros circuitos integrados) en hardware, software o una combinación de hardware y software. El codificador 100 comprende una memoria intermedia de trama 110, un analizador sintáctico 111, un descodificador 101, un validador de estado de audio 102, una etapa de procesamiento de sonoridad 103, una etapa de selección de flujo de audio 104, un codificador 105, una etapa de rellenador/formateador 107, una etapa de generación de metadatos 106, un subsistema 108 de medición de sonoridad de diálogo y una memoria intermedia de trama 109, conectados según se ilustra. Normalmente, también el codificador 100 incluye otros elementos de procesamiento (no ilustrados).
El codificador 100 (que es un transcodificador) está configurado para convertir un flujo de bits de audio de entrada (que, por ejemplo, puede ser uno de entre un flujo de bits en AC-3, un flujo de bits en E-AC-3 o un flujo de bits en Dolby E), en un flujo de bits de audio de salida codificado (que, por ejemplo, puede ser otro de entre un flujo de bits en AC-3, un flujo de bits en E-AC-3 o un flujo de bits en Dolby E) que incluye la realización de un procesamiento de sonoridad automatizado y adaptativo, utilizando metadatos de estado de procesamiento de sonoridad incluidos en el flujo de bits de entrada. Por ejemplo, el codificador 100 se puede configurar para convertir un flujo de bits en Dolby E de entrada (un formato normalmente utilizado en instalaciones de producción y difusión, pero no en dispositivos de consumo que reciben programas de audio que han sido difundidos) a un flujo de bits de audio codificado de salida (adecuado para la difusión a dispositivos de consumo) en formato AC-3 o E-AC-3.
El sistema de la Figura 2 incluye, además, el subsistema 150 de entrega de audio codificado (que memoriza y/o entrega, los flujos de bits codificados procedentes del codificador 100) y el descodificador 152. El subsistema 150 puede memorizar un flujo de bits de audio codificado, de salida, procedente del codificador 100 (por ejemplo, en la forma de un DVD o disco de Blu-ray), o transmitido por el subsistema 150 (que puede poner en práctica un enlace o red de transmisión), o puede ser, a la vez, memorizado y transmitido por el subsistema 150. El descodificador 152 está configurado para descodificar un flujo de bits de audio codificado (generado por el codificador 100), que se recibe a través del subsistema 150, incluyendo mediante la extracción de metadatos (PIM y/o SSM y, opcionalmente, también metadatos de estado de procesamiento de sonoridad y/u otros metadatos) desde cada trama del flujo de bits (y, opcionalmente, extrayendo, además, metadatos de límite de programa del flujo de bits), y generando datos de audio descodificados. En condiciones normales, el descodificador 152 está configurado para realizar un procesamiento adaptativo sobre los datos de audio descodificados utilizando PIM y/o SSM, y/o LPSM (y, de modo opcional, también metadatos de límite de programa), y/o para enviar los datos de audio descodificados y los metadatos a un post procesador configurado para realizar un procesamiento adaptativo en los datos de audio descodificados utilizando los metadatos. Normalmente, el descodificador 152 incluye una memoria intermedia que memoriza (por ejemplo, de manera no transitoria) el flujo de bits de audio codificado, que se recibe desde el subsistema 150.
Diversas ejecuciones prácticas del codificador 100 y del descodificador 152 están configuradas para realizar diferentes formas de realización del método inventivo. La memoria intermedia de trama 110 es una memoria intermedia acoplada para recibir un flujo de bits de audio de entrada codificado. En funcionamiento, la memoria intermedia 110 memoriza (por ejemplo, de forma no transitoria), al menos una trama del flujo de bits de audio codificado, y una secuencia de las tramas del flujo de bits de audio codificada se reafirma desde la memoria intermedia 110 al analizador 111.
El analizador 111 está acoplado y configurado para extraer PIM y/o SSM, y metadatos de estado de procesamiento de sonoridad (LPSM) y, opcionalmente, también metadatos de límite de programa (y/u otros metadatos) desde cada trama del audio de entrada codificado en donde están incluidos dichos metadatos, para establecer al menos el LPSM (y, opcionalmente, 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 llevar los datos de audio al descodificador 101. El descodificador 101, del codificador 100, está configurado para descodificar los datos de audio para generar datos de audio descodificados, y para llevar los datos de audio descodificados a la etapa de procesamiento de sonoridad 103, a la etapa de selección de flujo de audio 104, al subsistema 108, y normalmente, también al validador de estado 102.
El validador de estado 102 está configurado para autenticar y validar el LPSM (y, opcionalmente, otros metadatos) establecido en el mismo. En algunas formas de realización, el LPSM es, (o está incluido en), un bloque de datos que se ha incluido en el flujo de bits de entrada (por ejemplo, de conformidad con una forma de realización de la presente invención). El bloque puede incluir un denominado hash criptográfico (un código de autenticación de mensaje basado en hash o "HMAC") para el procesamiento de los LPSM (y, opcionalmente, también otros metadatos) y/o los datos de audio subyacentes (que se proporcionan a partir del descodificador 101, al validador 102). El bloque de datos puede estar firmado digitalmente en estas formas de realización, de modo que una unidad de procesamiento de audio de flujo del pueda autentificar y validar, con relativa facilidad, los metadatos del estado de procesamiento.
A modo de ejemplo, el HMAC se usa para generar un digest, y el o los valores de protección incluidos en el flujo de
bits de la invención pueden incluir el digest. El digestse puede generar del modo siguiente para una trama en AC-3:
1. Después de que se codifiquen los datos de AC-3 y LPSM, bytes de datos de trama (concatenadas frame_data (trama_datos) #1 y frame_data #2) y los bytes de datos de LPSM se utilizan como entrada para la función de hash HMAC.. Otros datos, que pueden estar presentes dentro de un campo auxdata, no se tienen en cuenta para calcular el digest. Dichos otros datos pueden ser bytes que no pertenezcan a los datos en AC-3, ni a los datos de LSPSM. Bits de protección, incluidos en LPSM, pueden no ser considerados para el cálculo del digest de HMAC.
2. Después de calcular el digest, se escribe en el flujo de bits en un campo reservado para bits de protección.
3. La última etapa de la generación de la trama en AC-3 completa es el cálculo de la verificación de CRC. Esto se escribe en el mismo extremo de la trama, y se tienen en cuenta todos los datos que pertenecen a esta trama, incluidos los bits de LPSM.
Otros métodos criptográficos que incluyen, pero no se limitan a, uno o más métodos criptográficos no de HMAC, se pueden utilizar para la validación de LPSM y/u otros metadatos (por ejemplo, en el validador 102) con el fin de garantizar la transmisión y recepción seguras de los metadatos y/o los datos de audio subyacentes. Por ejemplo, la validación (utilizando dicho método criptográfico) se puede realizar en cada unidad de procesamiento de audio que recibe, en una forma de realización de la invención, el flujo de bits de audio para determinar si los metadatos y los datos de audio correspondientes, incluidos en el flujo de bits, se han sometido (y/o son el resultado del) al procesamiento específico (como lo indican los metadatos) y no se han modificado después de la realización de dicho procesamiento específico.
El validador de estado 102 establece datos de control para la etapa de selección de flujo de audio 104, el generador de metadatos 106 y el subsistema de medición de sonoridad de diálogo 108, para indicar los resultados de la operación de validación. En respuesta a los datos de control, la etapa 104 puede seleccionar (y pasar a través del codificador 105), ya sea:
la salida procesada adaptativamente de la etapa de procesamiento de sonoridad 103 (por ejemplo, cuando LPSM indican que la salida de datos de audio desde el descodificador 101 no ha experimentado un tipo específico de procesamiento de sonoridad, y los bits de control procedentes del validador 102 indican que los LPSM son válidos); o
los datos de audio de salida del descodificador 101 (por ejemplo, cuando LPSM indica que los datos de audio, a la salida del descodificador 101, ya ha experimentado el tipo específico de procesamiento de sonoridad que se realizaría en la etapa 103, y los bits de control del validador 102 indican que los LPSM son válidos).
La etapa 103 del codificador 100 está configurada para realizar un procesamiento de sonoridad adaptativo sobre la salida de datos de audio descodificados procedentes del descodificador 101, sobre la base de una o más características de datos de audio que se indican por LPSM, extraídas por el descodificador 101. La etapa 103 puede ser un procesador de dominio-transformación adaptativo de sonoridad en tiempo real y de control de margen dinámico. La etapa 103 puede recibir una entrada del usuario (por ejemplo valores del margen de sonoridad objetivo /margen dinámico del usuario o valores de dialnorm) u otra entrada de metadatos (por ejemplo, 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 del usuario, datos de preferencia del usuario, etc.) y/u otra entrada (por ejemplo, desde un proceso de huella dactilar), y utilizar dicha entrada para procesar la salida de datos de audio descodificados, procedentes del descodificador 101. La etapa 103 puede realizar un procesamiento de sonoridad adaptativo sobre datos de audio descodificados (salida del descodificador 101), indicativo de un único programa de audio (como es indicado por los metadatos de límite de programa extraídos por el analizador sintáctico 111) y puede reiniciar el procesamiento de sonoridad en respuesta a la recepción de datos de audio descodificados (salida del descodificador 101), que indican un programa de audio diferente, tal como es indicado por metadatos de límite de programa extraídos por el analizador sintáctico 111.
El subsistema 108 de medición de sonoridad de diálogo puede funcionar para determinar la sonoridad de segmentos del audio descodificado (procedente del descodificador 101) que son indicativos de diálogo (u otra expresión vocal), por ejemplo utilizando LPSM (y/u otros metadatos) extraídos por el descodificador 101, cuando los bits de control del validador 102 indican que los LPSM no son válidos. La operación del subsistema 108 de medición de sonoridad de diálogo puede desactivarse cuando los LPSM indican previamente una determinada sonoridad de segmentos de diálogo (u otra expresión vocal) del audio descodificado (procedente del descodificador 101) cuando los bits de control del validador 102 indican que los LPSM son válidos. El subsistema 108 puede realizar una medición de sonoridad en datos de audio descodificados, indicativos de un único programa de audio (según lo indicado por los metadatos de límites del programa extraídos por el analizador 111), y puede reiniciar la medición en respuesta a la recepción de datos de audio descodificados indicativos de un programa de audio diferente, según lo indicado por tales metadatos de límites del programa.
Existen herramientas útiles (por ejemplo el medidor de sonoridad en Dolby LM100) para medir el nivel del diálogo en contenido de audio, de manera conveniente y fácil. Algunas formas de realización de la APU inventiva (por ejemplo, etapa 108 del codificador 100) se ponen en práctica para incluir (o para realizar las funciones de) dicha herramienta para medir la sonoridad media de diálogo del contenido de audio de un flujo de bits de audio (por ejemplo, un flujo de bits en AC-3 descodificado, establecido en la etapa 108 del descodificador 101, del codificador 100).
Si la etapa 108 se ejecuta para medir la sonoridad de diálogo media real de los datos de audio, la medición puede incluir una etapa de aislamiento de segmentos del contenido de audio que contienen, de forma predominante, voz. Los segmentos de audio predominantemente hablados se procesan entonces de conformidad con un algoritmo de medición de sonoridad. Para datos de audio descodificados a partir de un flujo de bits en AC-3, este algoritmo puede ser una medida de sonoridad ponderada K estándar (de conformidad con la norma internacional ITU-R BS.1770). Como alternativa, se pueden utilizar otras medidas de sonoridad (por ejemplo, las basadas en modelos psico-acústicos de sonoridad).
El aislamiento de los segmentos de voz no es esencial para medir la sonoridad de diálogo media de los datos de audio. Sin embargo, mejora la precisión de la medida y, por lo general, proporciona resultados más satisfactorios desde la perspectiva del oyente. Puesto que no todo el contenido de audio incluye diálogo (expresión vocal), la medición de sonoridad del contenido de audio completo puede proporcionar una aproximación suficiente del nivel de diálogo del audio, si la expresión vocal hubiera estado presente.
El generador de metadatos 106 genera (y/o pasa a través de la etapa 107) metadatos para ser incluidos por la etapa 107 en el flujo de bits codificado, a proporcionarse, para ser emitidos desde el codificador 100. El generador de metadatos 106 puede pasar a través de la etapa 107 los LPSM (y además, opcionalmente, LIM y/o PIM y/o metadatos de límite de programa y/u otros metadatos) extraídos por el codificador 101 y/o el analizador sintáctico 111 (por ejemplo cuando los bits de control procedentes del validador 102 indican que los LPSM y/u otros metadatos son válidos), o generar nuevos LIM y/o PIM y/o LPSM y/o metadatos de límite de programa y/u otros metadatos y establecer los nuevos metadatos para la etapa 107 (por ejemplo, cuando los bits de control del validador 102 indican que los metadatos extraídos por el descodificador 101 no son válidos) o puede establecer, en la etapa 107, una combinación de metadatos extraídos por el descodificador 101 y/o el analizador 111, y los 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 realizado por el subsistema 108, en LPSM que son establecidos en la etapa 107 para su inclusión en el flujo de bits codificado que se enviará 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 el hash, o "HMAC") útil para al menos una de entre las funciones de desencriptación, autenticación o validación de los LPSM (y, opcionalmente, también otros metadatos) que han de incluirse en el flujo de bits codificado, y/o los datos de audio subyacentes que han de incluirse en el flujo de bits codificado. El generador de metadatos 106 puede proporcionar dichos bits de protección a la etapa 107 para su inclusión en el flujo de bits codificado.
En una operación típica, el subsistema 108 de medición de sonoridad de diálogo procesa los datos de audio de salida del descodificador 101, para generar en respuesta a sus valores de sonoridad (por ejemplo, valores de sonoridad de diálogo bloqueados y no bloqueados) y valores de margen dinámico. En respuesta a estos valores, el generador de metadatos 106 puede generar metadatos de estado de procesamiento de sonoridad (LPSM) para su inclusión (por el rellenador/formateador 107) en el flujo de bits codificado que se enviará desde el codificador 100.
De forma adicional, opcionalmente o como alternativa, los subsistemas de 106 y/o 108 del codificador 100 pueden realizar 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 flujo de bits codificado para darle salida desde la etapa 107.
El codificador 105 codifica (por ejemplo, realizando una compresión) los datos de audio emitidos desde la etapa de selección 104, y establece el audio codificado a la etapa 107 para su inclusión en el flujo de bits codificado para darle salida, desde la etapa 107.
La etapa 107 realiza la multiplexación del audio codificado procedente del codificador 105, y los metadatos (incluyendo PIM y/o SSM) del generador 106, para generar el flujo de bits codificado que se emitirá desde la etapa 107, preferiblemente de modo que el flujo de bits codificado tiene el formato que se especifica mediante una forma de realización preferida de la presente invención.
La memoria intermedia de trama 109 es una memoria intermedia que memoriza, (por ejemplo, de forma no transitoria), al menos una trama del flujo de bits de audio codificado a la salida de la etapa 107 y, a continuación, una secuencia de las tramas del flujo de bits de audio codificado se establecida desde la memoria intermedia 109 como salida del codificador 100 al sistema de entrega 150.
LPSM generados por el generador de metadatos 106, e incluidos en el flujo de bits codificado por la etapa 107, son normalmente indicativos del estado de procesamiento de sonoridad de los datos de audio correspondientes (por ejemplo, qué tipos de procesamientos de sonoridad se han realizado sobre los datos de audio) y sonoridad (por ejemplo, sonoridad de diálogo medida, sonoridad bloqueada y/o no bloqueada, y/o margen dinámico) de los correspondientes datos de audio.
En este caso, "efecto compuerta" (“gating”) de sonoridad y/o mediciones de nivel realizadas en datos de audio, se refiere a un nivel específico o umbral de sonoridad, en donde el o los valores calculados que superen el umbral se incluyen en la medición final (por ejemplo, ignorando los valores de sonoridad a corto plazo por debajo de -60 dBFS en los valores de medición final). La función gating aplicada sobre un valor absoluto se refiere a un nivel o sonoridad
fijo, mientras que dicha misma función aplicada a un valor relativo se refiere a un valor que depende de un valor de medición "sin gating" actual.
En algunas ejecuciones en prácticas del codificador 100, el flujo de bits codificado que se almacena en memoria intermedia 109 (y se proporciona como salida al sistema de distribución 150), es un flujo de bits en AC-3 o un flujo de bits en E-AC-3, y comprende segmentos de datos de audio (por ejemplo, los segmentos AB0-AB5 de la trama ilustrada en la Figura 4) y segmentos de metadatos, en 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 incluyen PIM y/o SSM (y, opcionalmente, también otros metadatos). La etapa 107 establece segmentos de metadatos (que incluyen metadatos) en el flujo de bits en el siguiente formato. Cada uno de los segmentos de metadatos que incluye PIM y/o SSM se incluye en un segmento de bits residuales del flujo de bits (por ejemplo, un segmento de bits residuales "W", tal como se muestra en la Figura 4 o Figura 7) o un campo "addbsi" del segmento de Información de Flujo De bits ("BSI") de una trama del flujo de bits, o en un campo auxdata (por ejemplo, el segmento AUX, ilustrado en la Figura 4 o la Figura 7) al final de una trama del flujo de bits. Una trama del flujo de bits puede incluir uno o dos segmentos de metadatos, cada uno de los cuales incluya metadatos, 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.
En algunas formas de realización, cada segmento de metadatos (a veces referido aquí como un "contenedor") insertado por la etapa 107 tiene un formato que incluye una cabecera de segmento de metadatos (y, opcionalmente, también otros elementos obligatorios o "principales"), y una o más cargas útiles de metadatos, siguiendo la cabecera del segmento de metadatos. SIM, si está presente, se incluye en una de las cargas útiles de metadatos (identificada por una cabecera de carga útil y, por lo general, tiene un formato de un primer tipo). PIM, se está presente, está incluido en otra de las cargas útiles de metadatos (identificada por una cabecera de carga útil y que, típicamente, tiene un formato de un segundo tipo). De modo similar, cada otro tipo de metadatos (si está presente) se incluye en otra de las cargas útiles de metadatos (que se identifica por una cabecera de carga y, normalmente, tiene un formato específico para el tipo de metadatos). El formato de ejemplo permite un acceso cómodo a los SSM, PIM y otros metadatos en momentos distintos a la duración de la descodificación (por ejemplo, mediante un post-procesador que sigue la descodificación, o mediante un procesador configurado para reconocer los metadatos sin realizar una descodificación completa en el flujo de bits codificado), y permite la detección y corrección de errores, cómoda y eficiente, (por ejemplo, de identificación del flujo secundario) durante la descodificación del flujo de bits. A modo de ejemplo, sin acceso a SSM en el formato de ejemplo, un descodificador podría identificar, de forma incorrecta, el número correcto de flujos secundarios asociados con un programa. Una carga útil de metadatos, en un segmento de metadatos, puede incluir SSM, otra carga útil de metadatos, en el segmento de metadatos, puede incluir PIM y, opcionalmente, además al menos otra carga útil de metadatos en el segmento de metadatos puede incluir otros metadatos (por ejemplo, metadatos de estado de procesamiento de sonoridad o "LPSM").
En algunas formas de realización, una carga útil de metadatos de estructura de flujo secundario (SSM) incluida (por la etapa 107), en una trama de un flujo de bits codificado (por ejemplo, un flujo de bits en E-AC-3 indicativo de al menos un programa de audio), incluye SSM en el siguiente formato:
una cabecera de carga útil, que incluye normalmente al menos un valor de identificación (por ejemplo, un valor de 2 bits indicativo de la versión de formato SSM y, de forma opcional, también valores de longitud, período, conteo y de asociación de flujos secundario); y después de la cabecera:
metadatos de flujo secundario independientes, que indican el número de flujos secundarios independientes del programa indicado por el flujo de bits; y
metadatos de flujo secundario dependientes, que indican si cada flujo secundario independiente del programa tiene al menos un flujo secundario dependiente asociado (es decir, si al menos un flujo secundario dependiente está asociado con dicho flujo secundario independiente) y, de ser así, el número de flujos secundarios dependientes asociados con cada flujo secundario independiente del programa.
Se contempla que un flujo secundario independiente, de un flujo de bits codificado, puede ser indicativo de un conjunto de canales de altavoz de un programa de audio (por ejemplo, los canales de altavoz de un programa de audio de canal de altavoz 5.1), y que cada uno de entre los uno o más flujos secundarios dependientes (asociados con el flujo secundario independiente, tal como se indica por los metadatos de flujo secundario dependiente) puede ser indicativo de un canal de objeto del programa. Normalmente, sin embargo, un flujo secundario independiente de un flujo de bits codificado, es indicativo de un conjunto de canales de altavoz de un programa, y cada flujo secundario dependiente, asociado con el flujo secundario independiente (tal como lo indican los metadatos de flujo secundario dependiente) es indicativo de al menos un canal de altavoz adicional del programa.
En algunas formas de realización, una carga útil de metadatos de información sobre el programa (PIM), incluida (por la etapa 107) en una trama de un flujo de bits codificado (por ejemplo, un flujo de bits en E-AC-3 indicativo de al menos un programa de audio) tiene el siguiente formato:
una cabecera de carga útil, que suele incluir, al menos un valor de identificación (por ejemplo, un valor indicativo de la versión de formato PIM y, de forma opcional, también valores de asociación de longitud, período, conteo y flujo
secundario); y
después de la cabecera, PIM en el siguiente formato:
metadatos de canales activos, indicativos de cada canal silencioso y cada canal no silencioso, de un programa de audio (es decir, qué canal(es) del programa contiene(n) información de audio y cuáles (si los hay) contienen solamente silencio (normalmente durante la duración de la trama)). En formas de realización en las que el flujo de bits codificado es un flujo de bits en AC-3 o E-AC-3, los metadatos de canal activo, en una trama del flujo de bits, se pueden utilizar junto con metadatos adicionales del flujo de bits (por ejemplo, el campo de modo de codificación de audio ("acmod") de la trama y, si está presente, el campo ‘chanmap’ en la trama o las tramas de flujo secundario dependiente asociadas) para determinar qué canal(es) del programa contiene(n) información de audio y cuáles contienen silencio. El campo "acmod" de una trama en AC-3 o E-AC-3 indica el número de canales de margen completo de un programa de audio, indicado por el contenido de audio de la trama (por ejemplo, si el programa es un programa monofónico de canal 1.0, un programa estéreo de canal 2.0, o un programa que comprende canales de margen completo L, R, C, Ls, Rs), o que la trama es indicativa de dos programas monofónicos de canal 1.0 independientes. Un campo "chanmap" de un flujo de bits en E-AC-3 indica un mapa de canales para un flujo secundario dependiente, indicado por el flujo de bits. Los metadatos de canal activo pueden ser útiles para poner en práctica la mezcla ascendente (en un post procesador) aguas abajo de un descodificador, por ejemplo para añadir audio a canales que contienen silencio en la salida del descodificador;
los metadatos de estado de procesamiento de mezcla descendente indican si el programa fue objeto de mezcla descendente (antes o durante la codificación), y si es así, el tipo de operación de mezcla descendente que se aplicó. Los metadatos de estado de procesamiento de mezcla descendente pueden ser útiles para poner en práctica una mezcla ascendente (en un post-procesador) aguas abajo de un descodificador, por ejemplo para la mezcla ascendente del contenido de audio del programa utilizando los parámetros que más se asemejan a un tipo de operación de mezcla descendente que se aplicó. En formas de realización en las que el flujo de bits codificado es un flujo de bits en AC-3 o E-AC-3, los metadatos de estado de procesamiento de mezcla descendente pueden utilizarse junto con el campo de modo de codificación de audio ("acmod") de la trama para determinar el tipo de operación de mezcla descendente (si corresponde) aplicado al(a los) canal(es) del programa;
metadatos de estado de procesamiento de mezcla ascendente, indicativos de si el programa fue objeto de mezcla ascendente (por ejemplo de un número menor de canales) antes, o durante, la codificación y, de ser así, el tipo de mezcla ascendente que se aplicó. Los metadatos de estado de procesamiento de mezcla ascendente pueden ser útiles para poner en práctica una operación de mezcla descendente (en un post-procesador) aguas abajo de un descodificador, por ejemplo para la mezcla descendente del contenido de audio del programa de un modo que sea compatible con un tipo de operación de mezcla ascendente (por ejemplo, Dolby Pro Logic, o Dolby Pro Logic II Movie Mode, o Dolby Pro Logic II Music Mode, o Dolby Professional Upmixer) que se aplicó al programa. En formas de realización en las que el flujo de bits codificado es un flujo de bits en E-AC-3, los metadatos de estado de procesamiento de mezcla ascendente se pueden utilizar junto con otros metadatos (por ejemplo, el valor de un campo "strmtyp" de la trama), para determinar el tipo de operación de mezcla ascendente (si corresponde) aplicado al (a los) canal(es) del programa. El valor del campo "strmtyp" (en el segmento BSI de una trama de un flujo de bits en E-AC-3) indica si el contenido de audio de la trama pertenece a un flujo independiente (que determina un programa) o un flujo secundario independiente (de un programa que incluye, o está asociado con, múltiples flujos secundarios) y por lo tanto, puede descodificarse independientemente de cualquier otro flujo secundario indicado por el flujo de bits en E-AC-3, o si el contenido de audio de la trama pertenece a un flujo secundario dependiente (de un programa que incluye, o está asociado con, múltiples flujos secundarios) y, en consecuencia, debe descodificarse junto con un flujo secundario independiente con el que está asociado; y
metadatos de estado de pre-procesamiento, que indican si el pre-procesamiento se realizó en el contenido de audio de la trama (antes de la codificación del contenido de audio para generar el flujo de bits codificado) y, en ese caso, el tipo de pre-procesamiento que se realizó.
En algunas realizaciones, los metadatos del estado de pre-procesamiento son indicativos de:
si se aplicó una atenuación circundante (por ejemplo, si los canales circundantes del programa de audio fueron atenuados en 3 dB antes de la codificación),
si se aplicó un cambio de fase de 90 grados (por ejemplo, para canales Ls circundantes y canales Rs del programa de audio antes de la codificación),
si se aplicó un filtro de paso bajo a un canal de LFE del programa de audio antes de la codificación,
si el nivel de un canal de LFE del programa fue supervisado durante la producción y, de ser así, el nivel supervisado del canal de LFE relativo al nivel de los canales de audio de margen completo del programa,
si se debe realizar una compresión de margen dinámico (por ejemplo, en el descodificador) en cada bloque de contenido de audio descodificado del programa y, si es así, el tipo (y/o parámetros) de compresión de margen dinámico que ha de realizarse (por ejemplo, este tipo de estado de pre-procesamiento los metadatos pueden ser indicativo de
cuál de los siguientes tipos de perfil de compresión fue asumido por el codificador para generar valores de control de compresión de margen dinámico que están incluidos en el flujo de bits codificado: Clase de Película, Luz de película, Clase de Música, Luz de Música o Voz. Como alternativa, este tipo de metadatos de estado de pre-procesamiento puede indicar que ha de realizarse la compresión de margen dinámico intensa (compresión "compr") en cada trama de contenido de audio descodificado del programa, de un modo determinado por los valores de control de compresión de margen dinámico que se incluyen en el flujo de bits codificado).
si el procesamiento de extensión espectral y/o codificación de acoplamiento de canal se empleó para codificar márgenes de frecuencia específicos del contenido del programa y, en caso afirmativo, las frecuencias mínima y máxima de los componentes de frecuencia del contenido en que se realizó la codificación de extensión espectral, y las frecuencias mínima y máxima de componentes de frecuencia del contenido en el que se realizó la codificación de acoplamiento de canal. Este tipo de información de metadatos de estado de pre-procesamiento puede ser útil para realizar la igualación (en un post-procesador) aguas abajo de un descodificador. Tanto el acoplamiento de canales como la información de extensión espectral son útiles, además, para optimizar la calidad durante las operaciones y aplicaciones de trans-codificación. Por ejemplo, un codificador puede optimizar su comportamiento (incluida la adaptación de etapas de pre-procesado, como la virtualización de auriculares, operación de mezcla ascendente, etc.) sobre la base del estado de los parámetros, tales como la extensión espectral y la información de acoplamiento de canal. Además, el codificador podría adaptar sus parámetros de acoplamiento y extensión espectral de forma dinámica para que coincidan y/o para valores óptimos, en función del estado de los metadatos entrantes (y autenticados), y
si los datos de margen de ajuste de mejora de diálogo se incluyen en el flujo de bits codificado y, si es así, el margen de ajuste disponible durante la realización del procesamiento de mejora de diálogo (por ejemplo, en un post procesador de aguas abajo de un descodificador) para ajustar el nivel de contenido de diálogo relativo al nivel de contenido sin diálogo en el programa de audio.
En algunas ejecuciones prácticas, metadatos de estado de pre-procesamiento adicionales (por ejemplo, metadatos indicativos de parámetros relacionados con auriculares) se incluyen (por la etapa 107) en una carga útil de PIM de un flujo de bits codificado para darles salida desde el codificador 100.
En algunas formas de realización, una carga útil de LPSM incluida (por la etapa 107) en una trama de un flujo de bits codificado (por ejemplo, un flujo de bits en E-AC-3, indicativo de al menos un programa de audio) incluye LPSM en el siguiente formato:
una cabecera (que incluye normalmente una palabra de sincronización que identifica el inicio de la carga útil de LPSM, seguida por al menos un valor de identificación, por ejemplo la versión de formato de LPSM, longitud, período, conteo y valores de asociación flujo secundario indicados en la Tabla 2 siguiente); y
después de la cabecera,
al menos un valor de indicación de diálogo (por ejemplo parámetro "Canal(es) de Diálogo" de la Tabla 2), que indica si correspondientes datos de audio indican diálogo, o no indican diálogo, (por ejemplo, qué canales de los correspondientes datos de audio indican diálogo);
al menos un valor de cumplimiento de normativa de sonoridad (por ejemplo parámetro "Tipo de Normativa de Sonoridad" de la Tabla 2), que indica si los correspondientes datos de audio cumplen con un conjunto indicado de normativas de sonoridad;
al menos un valor de procesamiento de sonoridad (por ejemplo uno o más de los parámetros "Indicador de corrección de sonoridad bloqueada por 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 realizado en los correspondientes datos de audio; y
al menos un valor de sonoridad (por ejemplo uno o más de los parámetros "Sonoridad bloqueada relativa de ITU", "Sonoridad bloqueada de expresión vocal de ITU", "Sonoridad de corto plazo de 3s de ITU (EBU 3341)" y "Pico verdadero" de la Tabla 2), que indican al menos una característica de sonoridad (por ejemplo, pico o promedio de sonoridad) de los datos de audio correspondientes.
En algunas formas de realización, cada segmento de metadatos que contiene PIM y/o SSM (y opcionalmente, también otros metadatos) contiene una cabecera de segmento de metadatos (y, como opción, elementos principales adicionales) y después de la cabecera del segmento de metadatos (o la cabecera del segmento de metadatos y otros elementos principales), al menos un segmento de carga útil de metadatos que tiene el siguiente formato:
una cabecera de carga útil, que incluye normalmente al menos un valor de identificación (por ejemplo, versión de formato SSM o PIM, longitud, periodo, conteo y valores de asociación de flujo secundario), y
después de la cabecera de la carga útil, los SSM o PIM (o metadatos de otro tipo).
En algunas realizaciones, cada uno de los segmentos de metadatos (a veces denominados en este documento como
"contenedores de metadatos" o "contenedores") insertados en la etapa 107 en un segmento de campo de omisión/bit residual (o un campo "addbsi", o un campo auxdata) de una trama del flujo de bits que tiene el siguiente formato:
una cabecera de segmento de metadatos (que incluye normalmente una palabra de sincronización que identifica el inicio del segmento de metadatos, seguida por valores de identificación, por ejemplo, versión, longitud, período, conteo de elementos expandidos, y valores de asociación de flujo secundario, tal como se indica en la Tabla 1 siguiente); y
después de la cabecera del segmento de metadatos, al menos un valor de protección (por ejemplo, los valores de HMAC digest y de huella dactilar de audio de la Tabla 1), útiles para al menos una función de entre desencriptación, autenticación o validación de al menos uno de los metadatos del segmento de metadatos o los correspondientes datos de audio); y
también después de la cabecera de segmento de metadatos, identificación de carga útil de metadatos ("ID") y valores de configuración de carga útil, que identifican el tipo de metadatos en cada carga útil de metadatos, e indican al menos un aspecto de la configuración (por ejemplo tamaño) de cada carga útil.
Cada carga útil de metadatos sigue a los correspondientes valores de ID de carga útil y de configuración de carga útil.
En algunas formas de realización, cada uno de los segmentos de metadatos, en el segmento de bits residuales (o campo auxdata, o campo "addbsi") de una trama, tiene tres niveles de estructura:
una estructura de alto nivel (por ejemplo una cabecera de segmento de metadatos), que incluye un indicador que indica si el campo de bits residuales (o auxdata o addbsi) incluye metadatos, al menos un valor de ID que indica qué tipo(s) de metadatos está(n) presente(s) y normalmente también un valor que indica cuántos bits de metadatos (por ejemplo, de cada tipo) están presentes (si metadatos están presentes). Un tipo de metadatos que podría estar presente es PIM, otro tipo de metadatos que podría estar presente es SSM, y otros tipos de metadatos que podrían estar presentes son LPSM, y/o metadatos de límite de programa y/o metadatos de investigación de medios;
una estructura de nivel intermedio, que comprende datos asociados con cada tipo de metadatos identificado (por ejemplo valores de cabecera de carga útil de metadatos, de protección, y valores de ID de carga útil y de configuración de carga útil, para cada tipo de metadatos identificado); y
una estructura de nivel bajo, que comprende una carga útil de metadatos para cada tipo de metadatos identificado (por ejemplo una secuencia de valores de PIM, si se identifica PIM como estando presente, y/o valores de metadatos de otro tipo (por ejemplo, SSM o LPSM), si otro tipo de metadatos se identifica como estando presente).
Los valores de datos en dicha estructura de tres niveles pueden estar acoplados. Por ejemplo, los valores de protección para cada carga útil (por ejemplo cada PIM o SSM u otra carga útil de metadatos), que se identifican por las estructuras de nivel alto e intermedio, pueden incluirse después de la carga útil (y, por lo tanto, después de la cabecera de carga útil de metadatos de la carga útil), o el(los) valor(es) de protección para todas las cargas útiles de metadatos, identificados por las estructuras de nivel alto e intermedio pueden incluirse después de la carga útil de metadatos final en el segmento de metadatos (y, por lo tanto, después de las cabeceras de carga útil de metadatos de todas las cargas útiles del segmento de metadatos).
En un ejemplo (que se describirá con referencia al segmento de metadatos o "contenedor" de la Figura 8), una cabecera de segmento de metadatos identifica cuatro cargas útiles de metadatos. Según se ilustra en la Figura 8, la cabecera del segmento de metadatos incluye una palabra de sincronización de contenedor (identificada como "container sync") y valores de ID de versión y clave. La cabecera del segmento de metadatos es seguida por las cuatro cargas útiles de metadatos y bits de protección. Los valores de ID y configuración de carga útil (por ejemplo, tamaño de carga útil), para la primera carga útil (por ejemplo una carga útil de PIM), siguen a la cabecera de segmento de metadatos, la propia primera carga útil sigue los valores de ID y configuración, valores de ID de carga útil y configuración de carga útil (por ejemplo, tamaño de carga útil) para la segunda carga útil (por ejemplo una carga útil de SSM) siguen a la primera carga útil, la propia segunda carga útil sigue a estos valores de ID y configuración, los valores de ID de carga útil y configuración de carga útil (por ejemplo, tamaño de carga útil) para la tercera carga útil (por ejemplo, una carga útil de LPSM) siguen a la segunda carga útil, la propia tercera carga útil sigue a estos valores de ID y configuración, los valores de ID de carga útil y configuración de carga útil (por ejemplo, tamaño de carga útil) para la cuarta carga útil, siguen a la tercera carga útil, la propia cuarta carga útil sigue estos valores de ID y configuración, y los valores de protección (identificados como “Datos de Protección” en la Figura 8) para la totalidad o algunas de las cargas útiles (o para la estructura de niveles alto e intermedio, y la totalidad o algunas de las cargas útiles), siguen a la última carga útil.
En algunas formas de realización, si el descodificador 101 recibe un flujo de bits de audio generado de conformidad con una forma de realización de la invención con un hash criptográfico, el descodificador está configurado para analizar y recuperar el hash criptográfico desde un bloque de datos determinado a partir del flujo de bits, en donde dicho bloque incluye metadatos. El Validador 102 puede utilizar el hash criptográfico para validar el flujo de bits recibido y/o los metadatos asociados. A modo de ejemplo, si el validador 102 encuentra que los metadatos son válidos sobre la base
de una coincidencia entre un hash criptográfico de referencia y el hash criptográfico recuperado del bloque de datos, entonces, se puede inhabilitar la operación del procesador 103 en los datos de audio correspondientes y hacer que la etapa de selección 104 pase a través de (sin cambiar) los datos de audio. De modo adicional, como opción, o de forma alternativa, se pueden utilizar otros tipos de técnicas criptográficas en lugar de un método basado en un hash criptográfico.
El codificador 100 de la Figura 2 puede determinar (en respuesta a LPSM y opcionalmente también metadatos de límite de programa, extraídos por el descodificador 101) que una unidad de post/pre-procesamiento ha realizado un tipo de procesamiento de sonoridad sobre los datos de audio que han de codificarse (en los elementos 105, 106, y 107) y, por lo tanto, pueden crear (en el generador 106) metadatos de estado de procesamiento de sonoridad que incluyan los parámetros específicos utilizados y/o derivados del procesamiento de sonoridad realizado con anterioridad. En algunas ejecuciones prácticas, el codificador 100 puede crear (e incluir en la salida el flujo de bits codificado del mismo) metadatos indicativos del historial de procesamiento sobre el contenido de audio siempre que el codificador conozca los tipos de procesamiento que se han realizado sobre el contenido de audio.
La Figura 3 es un diagrama de bloques de un descodificador (200) que es una forma de realización de la unidad de procesamiento de audio inventiva, y de un post-procesador (300) acoplado al mismo. El post-procesador (300) es también una forma de realización de la unidad de procesamiento de audio inventiva. Cualquiera de los componentes o elementos del descodificador 200 y del post-procesador 300 se puede poner en práctica como uno o más procesos y/o uno o más circuitos (por ejemplo, ASICs, FPGAs u otros circuitos integrados), en hardware, software o una combinación de hardware y software. El descodificador 200 incluye la memoria intermedia de trama 201, el analizador sintáctico 205, el descodificador de audio 202, la etapa 203 de validación de estado de audio (validador), y la etapa 204 de generación de bits de control, conectados según se ilustra. Normalmente también, el descodificador 200 incluye otros elementos de procesamiento (no ilustrados).
La memoria intermedia de trama 201 (una memoria intermedia) memoriza (por ejemplo, de manera no transitoria) al menos una trama del flujo de bits de audio codificado, recibido por el descodificador 200. Una secuencia de las tramas del flujo de bits de audio codificado es establecida desde la memoria intermedia 201 al analizador 205.
El analizador sintáctico 205 está acoplado y configurado para extraer PIM y/o SSM (y, además, como opción, otros metadatos, por ejemplo, LPSM) a partir de cada trama del audio de entrada codificado, para establecer al menos algunos de los metadatos (por ejemplo, LPSM y metadatos de límite de programa, si se extrae alguno, y/o PIM y/o SSM) al validador de estado de audio 203 y la etapa 204, con el fin de establecer los metadatos extraídos como salida (por ejemplo, al post-procesador 300) para extraer datos de audio procedentes del audio de entrada codificado, y para establecer los datos de audio extraídos al descodificador 202.
La entrada del flujo de bits de audio codificado al descodificador 200 puede ser uno de entre un flujo de bits en AC-3, un flujo de bits en E-AC-3, o un flujo de bits en Dolby E.
El sistema de la Figura 3 incluye, además, el post-procesador 300. El post-procesador 300 comprende la memoria intermedia de trama 301 y otros elementos de procesamiento (no ilustrados), que incluyen al menos un elemento de procesamiento acoplado a la memoria intermedia 301. La memoria intermedia de trama 301 realiza la memorización (por ejemplo de forma no transitoria), en al menos una trama del flujo de bits de audio descodificado, recibido por el post-procesador 300 desde el descodificador 200. Los elementos de procesamiento del post-procesador 300 están acoplados y configurados para recibir y procesar, de forma adaptativa, una secuencia de las tramas de la salida de flujo de bits de audio descodificado procedente de la memoria intermedia 301, utilizando la salida de metadatos procedentes del descodificador 200 y/o bits de control de salida desde la etapa 204 del descodificador 200. Normalmente el post-procesador 300 está configurado para realizar un procesamiento adaptativo sobre los datos de audio descodificados utilizando metadatos procedentes del descodificador 200 (por ejemplo, procesamiento de sonoridad adaptativo en los datos de audio descodificados utilizando valores de LPSM y, además, de forma opcional, metadatos de límite de programa, en donde el procesamiento adaptativo puede estar basado en el estado de procesamiento de sonoridad y/o una o más características de datos de audio, indicadas por LPSM para datos de audio indicativos de un único programa de audio).
Varias ejecuciones prácticas del descodificador 200 y el post-procesador 300 están configuradas para realizar diferentes formas de realización del método de la invención.
El descodificador de audio 202, del descodificador 200, está configurado para descodificar los datos de audio extraídos por el analizador sintáctico 205, con el fin de generar datos de audio descodificados, y para establecer los datos de audio descodificados como salida (por ejemplo, al post-procesador 300).
El validador de estado 203 está configurado para autenticar y validar los metadatos establecidos en el mismo. En algunas formas de realización, los metadatos son (o están incluidos en) un bloque de datos que se ha incluido en el flujo de bits de entrada (por ejemplo, de conformidad con una forma de realización de la presente invención). El bloque puede incluir un hash criptográfico (un código de autenticación de mensaje basado en hash, o "HMAC") para el procesamiento de los metadatos y/o los datos de audio subyacentes (proporcionados desde el analizador sintáctico 205 y/o el descodificador 202 al validador 203). El bloque de datos puede estar firmado de forma digital en estas
formas de realización, de modo que una unidad de procesamiento de audio de flujo descendente pueda autentificar y validar con relativa facilidad los metadatos de estado de procesamiento.
Otros métodos criptográficos que incluyen, pero no se limitan a, uno o más métodos criptográficos no de HMAC, se pueden utilizar para la validación de metadatos (por ejemplo, en el validador 203) con el fin de garantizar la transmisión y recepción segura de los metadatos y/o los datos de audio subyacentes. Por ejemplo, la validación (utilizando dicho método criptográfico) se puede realizar en cada unidad de procesamiento de audio que recibe una forma de realización del flujo de bits de audio inventivo, para determinar si los metadatos de estado de procesamiento de sonoridad y los correspondientes datos de audio, incluidos en el flujo de bits, se han sometido a (y/o han resultado de) un procesamiento de sonoridad específico (tal como se indica por los metadatos) y no se han modificado después de la realización de dicho procesamiento de sonoridad específico.
El validador de estado 203 establece datos de control para controlar el generador de bits 204, y/o establece los datos de control como salida (por ejemplo, al post-procesador 300), para indicar los resultados de la operación de validación. En respuesta a los datos de control (y opcionalmente también otros metadatos extraídos del flujo de bits de entrada), la etapa 204 puede generar (y establecer al post-procesador 300) cualquiera de lo que sigue:
bits de control que indican que la salida de datos de audio descodificados, procedentes del descodificador 202, ha experimentado un tipo específico de procesamiento de sonoridad (cuando LPSM indica que la salida de datos de audio del descodificador 202 ha experimentado el tipo específico de procesamiento de sonoridad, y los bits de control, procedentes del validador 203, indican que los LPSM son válidos); o
bits de control que indican que la salida de datos de audio descodificados del descodificador 202, deben someterse a un tipo específico de procesamiento de sonoridad (por ejemplo, cuando LPSM indica que la salida de datos de audio procedentes el descodificador 202, no se han sometido al tipo específico de procesamiento de sonoridad, o cuando el LPSM indica que la salida de datos de audio del descodificador 202 ha experimentado el tipo específico de procesamiento de sonoridad, pero los bits de control del validador 203 indican que los LPSM no son válidos).
Como alternativa, el descodificador 200 establece metadatos extraídos por el descodificador 202 desde el flujo de bits de entrada, y metadatos extraídos por el analizador sintáctico 205 desde el flujo de bits de entrada hasta el post procesador 300, y el post-procesador 300 realiza un procesamiento adaptativo sobre los datos de audio descodificados utilizando los metadatos, o realiza la validación de los metadatos y luego realiza un procesamiento adaptativo en los datos de audio descodificados utilizando los metadatos, si la validación indica que los metadatos son válidos.
En algunas formas de realización, si el descodificador 200 recibe un flujo de bits de audio generado de conformidad con una forma de realización de la invención, con un hash criptográfico, el descodificador está configurado para analizar y recuperar el hash criptográfico desde un bloque de datos determinado a partir del flujo de bits, comprendiendo dicho bloque metadatos de estado de procesamiento de sonoridad (LPSM). El validador 203 puede utilizar el hash criptográfico para validar el flujo de bits recibido y/o metadatos asociados. Por ejemplo, si el validador 203 encuentra que los metadatos LPSM son válidos, sobre la base de una coincidencia entre un hash criptográfico de referencia y el hash criptográfico recuperado del bloque de datos, entonces puede indicar a una unidad de procesamiento de audio de flujo descendente (por ejemplo, post-procesador 300, que puede ser, o incluir, una unidad de nivelación de volumen) para pasar a través (sin cambio) de los datos de audio del flujo de bits. Además, de modo opcional, o como alternativa, se pueden utilizar otros tipos de técnicas criptográficas en lugar de un método basado en un hash criptográfico.
En algunas ejecuciones prácticas del descodificador 200, el flujo de bits codificado recibido (y guardado temporalmente en la memoria 201), es un flujo de bits en AC-3 o un flujo de bits en E-AC-3, e incluye segmentos de datos de audio (por ejemplo, los segmentos AB0-AB5 de la trama ilustrada en la Figura 4) y segmentos de metadatos, en 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 PIM o SSM (u otros metadatos). La etapa del descodificador 202 (y/o el analizador sintáctico 205) está configurada para extraer los metadatos del flujo de bits. Cada uno de los segmentos de metadatos que incluye PIM y/o SSM (y, opcionalmente, también otros metadatos), se incluye en un segmento de bits residuales de una trama del flujo de bits, o un campo "addbsi" del segmento de Información de Flujo de Bits ("BSI") de una trama del flujo de bits, o en un campo auxdata (por ejemplo, el segmento AUX, que se ilustra en la Figura 4) al final de una trama del flujo de bits. Una trama del flujo de bits puede incluir uno o dos segmentos de metadatos, cada uno de los cuales incluya metadatos, 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.
En algunas formas de realización, cada segmento de metadatos (a veces referido aquí como un "contenedor") del flujo de bits guardado en la memoria intermedia 201, tiene un formato que incluye una cabecera de segmento de metadatos (y además, de forma opcional, otros elementos obligatorios o "principales"), y una o más cargas útiles de metadatos que siguen a la cabecera del segmento de metadatos. SIM, si está presente, se incluye en una de las cargas útiles de metadatos (identificada por una cabecera de carga útil y, normalmente, tiene un formato de un primer tipo). PIM, si está presente, se incluye en otra de las cargas útiles de metadatos (identificada por una cabecera de carga útil y que suele tener un formato de un segundo tipo). De modo similar, cada otro tipo de metadatos (si está presente), se incluye en otra de las cargas útiles de metadatos (que se identifica por una cabecera de carga útil y que tiene normalmente
un formato específico para el tipo de metadatos). El formato a modo de ejemplo permite un acceso conveniente a los SSM, PIM y otros metadatos en momentos distintos a cuando se realiza la descodificación (por ejemplo, por del post procesador 300 después de la descodificación, o por un procesador configurado para reconocer los metadatos sin realizar una descodificación completa en el flujo de bits codificado), y permite las cómodas y eficientes detección y corrección de errores, (por ejemplo, de identificación de flujo secundario) durante la descodificación del flujo de bits. A modo de ejemplo, sin acceso a SSM en el formato de ejemplo, el descodificador 200 podría identificar incorrectamente el número correcto de flujos secundarios asociados con un programa. Una carga útil de metadatos, en un segmento de metadatos, puede incluir SSM, otra carga útil de metadatos en el segmento de metadatos puede incluir PIM y, opcionalmente, también al menos otra carga útil de metadatos en el segmento de metadatos puede incluir otros metadatos (por ejemplo, metadatos de estado de procesamiento de sonoridad o "LPSM").)
En algunas formas de realización, una carga útil de metadatos de estructura de flujo secundario (SSM), incluida en una trama de un flujo de bits codificado (por ejemplo, un flujo de bits en E-AC-3 indicativo de al menos un programa de audio), que se guarda en la memoria intermedia 201, incluye SSM en el formato siguiente:
una cabecera de carga útil, que incluye normalmente al menos un valor de identificación (por ejemplo, un valor de 2 bits indicativo de la versión de formato de SSM y, además como opción, valores de longitud, período, conteo y asociación de flujo secundario); y
después de la cabecera:
metadatos de flujo secundario independiente, que indican el número de flujos secundarios independientes del programa, indicados por el flujo de bits; y
metadatos de flujo secundario dependiente, indicativos de si cada flujo secundario independiente del programa tiene al menos un flujo secundario dependiente asociado con el mismo, y, si es así, el número de flujos secundarios dependientes, asociados con cada flujo secundario independiente del programa.
En algunas formas de realización, una carga útil de metadatos de información sobre el programa (PIM), incluida en una trama de un flujo de bits codificado, (por ejemplo un flujo de bits en E-AC-3, indicativo de al menos un programa de audio), que se memoriza, de forma temporal, en la memoria intermedia 201, tiene el siguiente formato:
una cabecera de carga útil, que incluye normalmente al menos un valor de identificación (por ejemplo, un valor indicativo de la versión de formato de PIM y además, de forma opcional, valores de longitud, período, conteo y asociación de flujo secundario); y
después de la cabecera, PIM en el siguiente formato:
metadatos de canales activos de cada canal silencioso y cada canal no silencioso, de un programa de audio (es decir, cuyos canales del programa contienen información de audio y los que (si los hay) contienen solamente silencio (normalmente durante la duración de la trama)). En formas de realización en las que el flujo de bits codificado es un flujo de bits de AC-3 o un flujo de bits en E-AC-3, los metadatos de canal activo en una trama del flujo de bits se pueden utilizar junto con metadatos adicionales del flujo de bits (por ejemplo, el campo de modo de codificación de audio (''acmod'') de la trama y, si está presente, el campo de mapa de canales en la trama o tramas de flujo secundario dependiente asociado, para determinar qué canales del programa contienen información de audio y cuáles contienen silencio;
los metadatos de estado de procesamiento de mezcla descendente que indican si el programa fue objeto de mezcla descendente (antes o durante la codificación), y, si es así, el tipo de operación de mezcla descendente que se aplicó. Los metadatos de estado de procesamiento de mezcla descendente pueden ser útiles para poner en práctica la mezcla ascendente (por ejemplo en el post-procesador 300) de aguas abajo de un descodificador, por ejemplo, para la mezcla ascendente del contenido de audio del programa, utilizando parámetros que coincidan más estrechamente con un tipo de operación de mezcla descendente que fue aplicado. En formas de realización en las que el flujo de bits codificado es un flujo de bits en AC-3 o E-AC-3, los metadatos de estado de procesamiento de mezcla descendente se pueden utilizar junto con el campo de modo de codificación de audio ("acmod") de la trama para determinar el tipo de operación de mezcla descendente (si corresponde) aplicado al(a los) canal(es) del programa;
metadatos de estado de procesamiento de mezcla ascendente, indicativos de si el programa fue objeto de mezcla ascendente, (por ejemplo, a partir de un pequeño número de canales), antes o durante la codificación y, de ser así, el tipo de operación de mezcla ascendente que se aplicó. Los metadatos de estado de procesamiento de mezcla ascendente pueden ser útiles para poner en práctica la operación de mezcla descendente (en un post-procesador) aguas abajo de un descodificador, por ejemplo para la mezcla descendente del contenido de audio del programa, en un modo que sea compatible con un tipo de mezcla ascendente (por ejemplo, Dolby Pro Logic, o Dolby Pro Logic II Movie Mode, o Dolby Pro Logic II Music Mode, o Dolby Professional Upmixer) que se aplicó al programa. En formas de realización en las que el flujo de bits codificado es un flujo de bits en E-AC-3, los metadatos de estado de procesamiento de mezcla ascendente se pueden utilizar junto con otros metadatos (por ejemplo el valor de un campo "strmtyp" de la trama), con el fin de determinar el tipo de operación de mezcla ascendente (si corresponde) aplicado al(a los) canal(es) del programa. El valor del campo "strmtyp" (en el segmento de BSI de una trama de un flujo de bits
en E-AC-3) indica si el contenido de audio de la trama pertenece a un flujo independiente (que determina un programa) o un flujo secundario independiente (de un programa que incluye, o está asociado con, múltiples flujos secundarios) y, por lo tanto, se puede descodificar, con independencia de cualquier otro flujo secundario indicado por el flujo de bits en E-AC-3, o si el contenido de audio de la trama pertenece a un flujo secundario dependiente (de un programa que incluye, o está asociado con, múltiples flujos secundarios) y, por lo tanto, se debe descodificar junto con un flujo secundario independiente con el que está asociado; y
metadatos de estado de pre-procesamiento, que indican si el pre-procesamiento se realizó en el contenido de audio de la trama (antes de la codificación del contenido de audio para generar el flujo de bits codificado), y, de ser así, el tipo de pre-procesamiento que fue realizado.
En algunas realizaciones, los metadatos de estado de pre-procesamiento son indicativos de:
si se aplicó una atenuación circundante (por ejemplo, si los canales circundantes del programa de audio se atenuaron en 3 dB antes de la codificación),
si se aplicó un cambio de fase de 90 grados (por ejemplo para canales circundantes Ls y canales Rs del programa de audio antes de la codificación),
si se aplicó un filtro de paso bajo a un canal de LFE del programa de audio antes de la codificación,
si el nivel de un canal de LFE del programa fue supervisado durante la producción y, de ser así, el nivel supervisado del canal de LFE relativo al nivel de los canales de audio de margen completo del programa,
si se debe realizar una compresión de margen dinámico (por ejemplo en el descodificador) en cada bloque de contenido de audio descodificado del programa y, si es así, el tipo (y/o parámetros) de compresión de margen dinámico que ha de realizarse (por ejemplo este tipo de metadatos de estado de pre-procesamiento puede ser indicativo de cuál de los siguientes tipos de perfil de compresión fue asumido por el codificador para generar valores de control de compresión de margen dinámico que están incluidos en el flujo de bits codificado: Clase de Película, Luz de película, Clase de Música, Luz musical o Voz. Como alternativa, este tipo de metadatos de estado de pre-procesamiento puede indicar que debe realizarse la compresión de margen dinámico intensa (compresión "compr") en cada trama de contenido de audio descodificado del programa, de un modo determinado por los valores de control de compresión de margen dinámico que están incluidos en el flujo de bits codificado),
si el procesamiento de extensión espectral y/o codificación de acoplamiento de canal se empleó para codificar márgenes de frecuencia específicos del contenido del programa y, en caso afirmativo, las frecuencias mínima y máxima de los componentes de frecuencia del contenido en que se realizó la codificación de extensión espectral, y las frecuencias mínima y máxima de componentes de frecuencia del contenido en el que se realizó la codificación de acoplamiento de canal. Este tipo de información de metadatos de estado de pre-procesamiento puede ser útil para realizar la igualación (en un post-procesador) aguas abajo de un descodificador. Tanto el acoplamiento de canales como la información de extensión espectral son útiles, además, para optimizar la calidad durante operaciones y aplicaciones de trans-codificación. Por ejemplo, un codificador puede optimizar su comportamiento (incluida la adaptación de etapas de pre-procesamiento, tales como la virtualización de auriculares, operación de mezcla ascendente, etc.) sobre la base del estado de los parámetros, como la extensión espectral y la información de acoplamiento de canal. Además, el codificador podría adaptar sus parámetros de acoplamiento y extensión espectral, de forma dinámica, para que coincidan y/o a valores óptimos basados en el estado de los metadatos entrantes (y autenticados), y
si los datos de margen de ajuste de mejora de diálogo están incluidos en el flujo de bits codificado y, si es así, el margen de ajuste disponible durante la realización del procesamiento de mejora de diálogo (por ejemplo en un post procesador aguas abajo de un descodificador) para ajustar el nivel de contenido de diálogo relativo al nivel de contenido sin diálogo en el programa de audio.
En algunas formas de realización, una carga útil de LPSM incluida en una trama de un flujo de bits codificado (por ejemplo un flujo de bits en E-AC-3 indicativo de al menos un programa de audio) que se guarda temporalmente en la memoria intermedia 201, incluye LPSM en el siguiente formato:
una cabecera (que incluye típicamente una palabra de sincronización que identifica el inicio de la carga útil de LPSM, seguida de al menos un valor de identificación, por ejemplo la versión de formato de LPSM, longitud, período, recuento y valores de asociación flujo secundario indicados en la Tabla 2 siguiente); y
después de la cabecera,
al menos un valor de indicación de diálogo (por ejemplo, parámetro "Canal(es) de Diálogo" de la Tabla 2), que indica si los correspondientes datos de audio indican diálogo, o no indican diálogo, (por ejemplo, qué canales de los correspondientes datos de audio indican diálogo);
al menos un valor de cumplimiento de normativa de sonoridad (por ejemplo parámetro "Tipo de Normativa de
Sonoridad" de la Tabla 2), que indica si los correspondientes datos de audio cumplen con un conjunto indicado de normativas de sonoridad;
al menos un valor de procesamiento de sonoridad (por ejemplo, uno o más de los parámetros "Indicador de Corrección de Sonoridad bloqueada 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 realizado en los correspondientes datos de audio; y
al menos un valor de sonoridad (por ejemplo, uno o más de los parámetros "Sonoridad Bloqueada Relativa de ITU", " Sonoridad Bloqueada de Expresión vocal de ITU", "Sonoridad de Corto plazo de 3s de ITU (EBU 3341)" y "Pico Verdadero" de la Tabla 2), que indican al menos una característica de sonoridad (por ejemplo pico o promedio de sonoridad) de los datos de audio correspondientes.
En algunas ejecuciones prácticas, el analizador sintáctico 205 (y/o la etapa 202 de descodificador) se configuran para extraer, a partir de un segmento de bits residuales, o un campo "addbsi", o un campo de datos auxiliares, de una trama del flujo de bits, teniendo cada segmento de metadatos el siguiente formato:
una cabecera de segmento de metadatos (que incluye normalmente una palabra de sincronización que identifica el inicio del segmento de metadatos, seguida de al menos un valor de identificación, por ejemplo valores de versión, longitud y período, conteo de elementos expandidos y de asociación de flujo secundario); y
después de la cabecera del segmento de metadatos, al menos un valor de protección (por ejemplo, los valores HMAC digest y de Huella dactilar de Audio de la Tabla 1) útil para al menos una función de entre desencriptación, autenticación o validación de al menos uno de los metadatos del segmento de metadatos, o el correspondiente dato de audio); y
además, después de la cabecera del segmento de metadatos, valores de identificación (“ID”) de carga útil de metadatos y de configuración de carga útil, que identifican el tipo y al menos un aspecto de la configuración (por ejemplo tamaño) de cada carga útil de metadatos siguiente.
Cada segmento de carga útil de metadatos (que tiene, preferentemente, el formato especificado con anterioridad) sigue los correspondientes valores de ID de carga útil de metadatos y de configuración de carga útil.
Más generalmente, el flujo de bits de audio codificado, generado por formas de realización de la invención preferidas, tiene una estructura que proporciona un mecanismo para etiquetar elementos de metadatos y sub-elementos como elementos o sub-elementos principales (obligatorios) o expandidos (de forma opcional). Esto permite que la tasa de datos del flujo de bits (incluidos sus metadatos) sea objeto de escala en numerosas aplicaciones. Los elementos principales (obligatorios) de la sintaxis del flujo de bits preferido deberían ser capaces, además, de señalar que los elementos expandidos (opcionales), asociados con el contenido de audio están presentes (en banda) y/o en una localización distante (fuera de banda).
Se requiere que el(los) elemento(s) principal(es) esté(n) presente(s) en cada trama del flujo de bits. Algunos sub elementos de los elementos principales son opcionales y pueden estar presentes en cualquier combinación. No se requiere que elementos expandidos estén presentes en cada trama (para limitar la sobrecarga de la tasa de bits). En consecuencia, los elementos expandidos pueden estar presentes en algunas tramas y no en otras. Algunos sub elementos de un elemento expandido son opcionales y pueden estar presentes en cualquier combinación, mientras que algunos sub-elementos de un elemento expandido pueden ser obligatorios (es decir, si el elemento expandido está presente en una trama del flujo de bits).
En una clase de formas de realización, se genera un flujo de bits de audio codificado que comprende una secuencia de segmentos de datos de audio y segmentos de metadatos (por ejemplo, mediante una unidad de procesamiento de audio que incorpora la invención). Los segmentos de datos de audio son indicativos de datos de audio, cada uno de al menos alguno de los segmentos de metadatos incluye PIM y/o SSM (y además, de modo opcional, metadatos de al menos otro tipo), y los segmentos de datos de audio son objeto de multiplexación por división de tiempo con los segmentos de metadatos. En formas de realización preferidas de esta clase, cada uno de los segmentos de metadatos tiene un formato preferido que se describirá en este documento.
En un formato preferido, el flujo de bits codificado es un flujo de bits en AC-3 o un flujo de bits en E-AC-3, y cada uno de los segmentos de metadatos que incluye SSM y/o PIM está incluido (por ejemplo por la etapa 107 de una ejecución práctica preferida del codificador 100), como información de flujo de bits adicional en el campo "addbsi" (ilustrado en la Figura 6) del segmento de Información de Flujo de Bits ("BSI") de una trama del flujo de bits, o en un campo auxdata de una trama del flujo de bits, o en un segmento de bits residuales de una trama del flujo de bits.
En el formato preferido, cada una de las tramas incluye un segmento de metadatos (a veces aquí referido como un contenedor de metadatos, o contenedor), en un segmento de bits residuales (o campo addbsi) de la trama. El segmento de metadatos tiene los elementos obligatorios (referidos, de forma colectiva, como el "elemento principal") que se ilustra en la Tabla 1 siguiente (y pueden incluir los elementos opcionales que se ilustran en la Tabla 1). Al menos alguno de los elementos requeridos que se ilustran en la Tabla 1, están incluidos en la cabecera de segmento de metadatos del segmento de metadatos, pero algunos se pueden incluir en cualquier parte del segmento de
metadatos:
Tabla 1
En el formato preferido, cada segmento de metadatos (en un segmento de bits residual, o campo addbsi o auxdata de una trama de un flujo de bits codificado) que contiene metadatos SSM, PIM o LPSM contiene una cabecera de segmento de metadatos (y, además, de modo opcional, elementos principales adicionales), y después de la cabecera del segmento de metadatos (o la cabecera del segmento de metadatos y otros elementos principales), una o más cargas útiles de metadatos. Cada carga útil de metadatos incluye una cabecera de carga útil de metadatos (que indica un tipo específico de metadatos (por ejemplo SSM, PIM o LPSM)) incluido en la carga útil, seguido de metadatos del tipo específico. Normalmente, la cabecera de carga útil de metadatos incluye los valores siguientes (parámetros):
un ID de carga útil (que identifica el tipo de metadatos, por ejemplo SSM, PIM o LPSM) que sigue a la cabecera del segmento de metadatos (que puede incluir los valores especificados en la Tabla 1);
un valor de configuración de carga útil (que generalmente indica el tamaño de la carga útil) que sigue al identificador ID de carga útil;
y además, de modo opcional, valores de configuración adicionales de carga útil (por ejemplo, un valor de compensación que indica el número de muestras de audio desde el inicio de la trama a la primera muestra de audio a la que pertenece la carga útil y el valor de prioridad de la carga útil, que indica, por ejemplo, una condición en la que la carga útil puede descartarse).
Normalmente, los metadatos de la carga útil tienen uno de los siguientes formatos:
los metadatos de la carga útil son SSM, que incluyen metadatos de flujo secundario independiente, que indican el número de flujos secundarios independientes del programa indicado por el flujo de bits; y metadatos de flujo secundario dependiente, indicativos de si cada flujo secundario independiente del programa tiene al menos un flujo secundario dependiente asociada con él, y, de ser así, el número de flujos secundarios dependientes asociados con cada flujo secundario independiente del programa;
los metadatos de la carga útil son PIM, que incluyen metadatos de canal activo, indicativos de qué canales de un programa de audio contienen información de audio, y cuáles (si los hay) contienen solamente silencio (generalmente durante la duración de la trama); metadatos de estado de procesamiento de mezcla descendente, indicativos de si el programa fue objeto de mezcla descendente (antes o durante la codificación), y, si es así, el tipo de operación de mezcla descendente que se aplicó, metadatos de estado de procesamiento de mezcla ascendente, indicativos de si el programa fue objeto de mezcla ascendente (por ejemplo a partir de un menor número de canales) antes o durante la codificación, y, si es así, el tipo de operación de mezcla ascendente que se aplicó, y metadatos de estado de pre-procesamiento, indicativos de si se realizó el pre-procesamiento en el contenido de audio de la trama (antes de codificar el contenido de audio para generar el flujo de bits codificado), y, si es así, el tipo de pre-procesamiento que se realizó; o
los metadatos de la carga útil son LPSM que tienen el formato que se indica en la siguiente tabla (Tabla 2):
Tabla 2
En otro formato preferido de un flujo de bits codificado, generado de conformidad con la invención, el flujo de bits es un flujo de bits en AC-3, o un flujo de bits en E-AC-3, y se incluye cada uno de los segmentos de metadatos que
incluyen PIM y/o SSM (y opcionalmente, también metadatos de al menos otro tipo) (por ejemplo, mediante la etapa 107 de una puesta en práctica preferida del codificador 100) en cualquiera de los segmentos de bits residuales de una trama del flujo de bits; o un campo “addbsi” (ilustrado en la Figura 6) del segmento de Información de Flujo de Bits ("BSI") de una trama del flujo de bits; o un campo auxdata (por ejemplo, el segmento AUX ilustrado en la Figura 4) al final de una trama del flujo de bits. Una trama puede incluir uno o dos segmentos de metadatos, cada uno de los cuales incluye PIM y/o s Sm , y (en algunas formas de realización) 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 tiene preferentemente el formato especificado anteriormente con referencia a la Tabla 1 anterior (es decir, incluye los elementos principales especificados en la Tabla 1, seguidos por ID de carga útil (que identifica el tipo de metadatos en cada carga útil del segmento de metadatos) y valores de configuración de carga útil, y cada carga útil de metadatos). Cada segmento de metadatos que incluye metadatos LPSM tiene, preferentemente, el formato especificado anteriormente con referencia a las Tablas 1 y 2 anteriores (es decir, incluye los elementos principales especificados en la Tabla 1, seguidos por ID de carga útil (que identifica los metadatos como LPSM) y valores de configuración de carga útil, seguidos por la carga útil (datos de LPSM que tienen un formato según se indica en la Tabla 2)).
En otro formato preferido, el flujo de bits codificado es un flujo de bits en Dolby E, y cada uno de los segmentos de metadatos que incluyen PIM y/o SSM (y opcionalmente, también otros metadatos) es la primera ubicación de N muestras del intervalo de banda de guarda en Dolby E. Un flujo de bits en Dolby E que incluye dicho segmento de metadatos que incluye LPSM, incluye preferentemente un valor indicativo de la longitud de carga útil de LPSM señalada en la palabra de Pd del preámbulo de SMPTE 337M (la tasa de repetición de la palabra de SMPTE 337M Pa permanece, preferentemente, idéntica a la tasa de trama de vídeo asociada).
En un formato preferido, en el que el flujo de bits codificado es un flujo de bits en E-AC-3, se incluye cada uno de los segmentos de metadatos que incluyen PIM y/o SSM (y opcionalmente, también LPSM y/u otros metadatos) (por ejemplo mediante la etapa 107 de una ejecución práctica preferida del codificador 100) como información de flujo de bits adicional en un segmento de bits residuales, o en el campo "addbsi" del segmento de Información de Flujo de Bits ("BSI"), de una trama del flujo de bits. A continuación se describen aspectos adicionales de la codificación de un flujo de bits en E-AC-3 con LPSM en este formato preferido:
1. Durante la generación de un flujo de bits en E-AC-3, mientras que el codificador en E-AC-3 (que inserta los valores de LPSM en el flujo de bits) está "activo" para cada trama (trama de sincronización) generada, el flujo de bits debe incluir un bloque de metadatos (incluyendo LPSM) transmitido en el campo addbsi (o segmento de bits residuales) de la trama. Los bits necesarios para transmitir el bloque de metadatos no deberían aumentar la tasa de bits del codificador (longitud de trama);
2. Cada bloque de metadatos (que contiene LPSM) debe contener la siguiente información:
loudness_correction_type_flag (sonoridad_corrección_tipo_indicador): en donde '1' indica que la sonoridad de los datos de audio correspondientes se corrigió aguas arriba del codificador, y '0' indica que la sonoridad fue corregida por un corrector de sonoridad integrado en el codificador (por ejemplo, el procesador de sonoridad 103 del codificador 100 de la Figura 2);
speech_channel (habla_canal): indica qué canal(es) origen contiene(n) voz (en los últimos 0,5 segundos). Si no se detecta la voz, esto se indicará como tal;
speech_loudness (habla_sonoridad): indica la sonoridad de voz integrada de cada canal de audio correspondiente que contiene voz (durante los 0,5 segundos previos);
ITU_loudness: indica la sonoridad integrada de ITU BS.1770-3 de cada canal de audio correspondiente; y
gain: ganancia(s) compuesta(s) de sonoridad para la inversión en un descodificador (para demostrar la reversibilidad);
3. Mientras que el codificador en E-AC-3 (que inserta los valores de LPSM en el flujo de bits) está "activo" y recibe una trama en AC-3 con un indicador de "confianza", el controlador de sonoridad en el codificador (por ejemplo procesador de sonoridad 103 del codificador 100 de la Figura 2) debe ser desviado (bypassed). Los valores de dialnorm y DRC origen “de confianza” deben hacerse pasar a través de (por ejemplo, por medio del generador 106 del codificador 100) al componente del codificador de E-AC-3 (por ejemplo, etapa 107 del codificador 100). La generación del bloque de LPSM continúa y loudness_correction_type_flag se pone a '1'. La secuencia de derivación del controlador de sonoridad debe estar sincronizada con el inicio de la trama descodificada en AC-3, en donde aparece el indicador 'trust' (“confianza”). La secuencia de derivación del controlador de sonoridad debe ponerse en práctica como sigue: el control leveller_amount se disminuye desde un valor de 9 a un valor de 0 sobre 10 periodos de bloque de audio (es decir, 53,3 mseg) y el control leveler_back_end_meter se coloca en modo derivación (esta operación debería dar lugar a una transición sin problemas). El término derivación “de confianza" del nivelador implica que el valor dialnorm del flujo de bits origen se reutiliza también a la salida del codificador, (por ejemplo, si el flujo de bits origen 'de confianza' tiene un valor de dialnorm de -30, entonces la salida del codificador debe utilizar -30 para el valor del parámetro dialnorm de salida);
4. Mientras que el codificador en E-AC-3 (que inserta los valores de LPSM en el flujo de bits) está "activo" y está recibiendo una trama en AC-3 sin el indicador de "confianza", el controlador de sonoridad incluido en el codificador (por ejemplo, procesador de sonoridad 103 del codificador 100 de la Figura 2) debe estar activo. La generación del bloque de LPSM continúa y el loudness_correction_type_flag se establece a '0'. La secuencia de activación del controlador de sonoridad debe sincronizarse con el inicio de la trama en AC-3 descodificada, en donde desaparece el indicador de 'confianza'. La secuencia de activación del controlador de sonoridad debe ponerse en práctica como sigue: el control de leveler_amount (nivelador_cantidad) se incrementa desde un valor de 0 a un valor de 9 sobre 1 período de bloque de audio (es decir, 5,3 mseg) y el control de leveler_back_end_meter (nivelador_atrás_final_medidor) se coloca en el modo "activo" (esta operación debería dar como resultado una transición sin interrupciones e incluir un reinicio de integración de back_end_meter); y
5. Durante la codificación, una interfaz gráfica de usuario (GUI) debe indicar a un usuario los siguientes parámetros: "Programa de Audio de Entrada: [Fiable/no fiable]" -el estado de este parámetro se basa en la presencia del indicador de "confianza" dentro de la señal de entrada y "Corrección de sonoridad en tiempo real: [Habilitado/Deshabilitado]" -el estado de este parámetro se basa en el hecho de si este controlador de sonoridad, integrado en el codificador, está activo.
Cuando se descodifica un flujo de bits en AC-3 o E-AC-3 que tiene LPSM (en el formato preferido), incluido en un segmento de bits residuales o de campo de omisión, o el campo "addbsi" del segmento de Información de Flujo de Bits ("BSI"), de cada trama del flujo de bits, el descodificador debe analizar los datos del bloque de LPSM (en el segmento de bits residual o campo addbsi) y pasar todos los valores LPSM extraídos a una interfaz gráfica de usuario (GUI). El conjunto de valores de LPSM extraídos se renueva cada trama.
En otro formato preferido de un flujo de bits codificado, generado de conformidad con la invención, el flujo de bits codificado es un flujo de bits en AC-3 o un flujo de bits en E-AC-3, y se incluye cada uno de los segmentos de metadatos, que incluye PIM y/o SSM (y, opcionalmente, también LPSM y/u otros metadatos) (por ejemplo, en la etapa 107 de una ejecución práctica preferida del codificador 100) en un segmento de bits residuales, o en un segmento Aux, o como información de flujo de bits adicional en el campo “addbsi” (ilustrado en la Figura 6) del segmento de Información de Flujo de Bits ("BSI"), de una trama del flujo de bits. En este formato (que es una variación del formato descrito anteriormente con referencias a las Tablas 1 y 2), cada uno de los campos addbsi (o Aux o bits residuales), que contiene LPSM, contiene los siguientes valores de LPSM:
los elementos principales especificados en la Tabla 1, seguidos por el ID de carga útil (que identifica los metadatos como LPSM) y valores de configuración de carga útil, seguidos por la carga útil (datos de LPSM) que tiene el siguiente formato (similar a los elementos obligatorios indicados en la Tabla 2 anterior):
versión de la carga útil de LPSM: un campo de 2 bits que indica la versión de la carga útil de 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 sigue: bit 0, que indica la presencia de diálogo en el canal izquierdo, se memoriza en el bit más significativo del campo dialchan; y bit 2, que indica la presencia de diálogo en el canal central, se memoriza en el bit menos significativo del campo dialchan. Cada bit del campo dialchan se establece a '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 la norma de regulación de la intensidad que cumple la sonoridad del programa. Al establecer el campo "loudregtyp" en "000", se indica que los LPSM no indican el cumplimiento de la normativa de intensidad. Por ejemplo, un valor de este campo (por ejemplo, 0000) puede indicar que no está indicado el cumplimiento con una norma de regulación de la sonoridad, otro valor de este campo (por ejemplo, 0001) puede indicar que los datos de audio del programa cumplen con la norma ATSC A/85, y otro valor de este campo (por ejemplo, 0010) puede indicar que los datos de audio del programa cumplen con la norma EBU R128. En el ejemplo, si el campo se pone en cualquier valor distinto de '0000', los campos loudcorrdialgat y loudcorrtyp deberían seguir en la carga útil;
loudcorrdialgat: un campo de un bit que indica si se ha aplicado la corrección de la sonoridad bloqueada de diálogo. Si la sonoridad del programa se ha corregido utilizando el bloqueo (gating) de diálogo, el valor del campo loudcorrdialgat se pone en '1'. En caso contrario, se pone en '0';
loudcorrtyp: un campo de un bit que indica el tipo de corrección de intensidad aplicado al programa. Si la sonoridad del programa se ha corregido con un proceso de corrección de sonoridad infinita anticipada (basado en fichero), el valor del campo loudcorrtyp se establece en '0'. Si la intensidad del programa se ha corregido utilizando una combinación de medición de sonoridad en tiempo real y control de margen dinámico, el valor de este campo se establece en '1';
loudrelgate: un campo de un bit que indica si existen datos de sonoridad bloqueados relativos (ITU). Si el campo loudrelgate se estable en '1', debe seguir un campo ituloudrelgat de 7 bits en la carga útil;
loudrelgat: un campo de 7 bits que indica la sonoridad relativa del programa bloqueado (ITU). Este campo indica la sonoridad integrada del programa de audio, medida de conformidad con la norma ITU-R BS.1770-3 sin ningún ajuste
de ganancia debido a la aplicación de dialnorm y la compresión del margen dinámico (DRC). Los valores de 0 a 127 se interpretan como -58 LKFS a 5.5 LKFS, en pasos de 0,5 LKFS;
loudspchgate: un campo de un bit que indica si existen datos de sonoridad bloqueados por la voz (ITU). Si el campo loudspchgate está establecido en '1', un campo loudspchgat de 7 bits debe seguir en la carga útil;
loudspchgat: un campo de 7 bits que indica la sonoridad del programa bloqueado de voz. Este campo indica la sonoridad integrada del correspondiente programa de audio completo, medido de conformidad con la fórmula (2) de la ITU-R BS.1770-3 y sin ningún ajuste de ganancia debido a la aplicación de dialnorm y compresión de margen dinámico. Los valores de 0 a 127 se interpretan como -58 a 5,5 LKFS, en pasos de 0,5 LKFS;
loudstrm3se: un campo de un bit que indica si existen datos de sonoridad de corto plazo (3 segundos). Si el campo está establecido en '1', un campo loudstrm3s de 7 bits debe permanecer en la carga útil;
loudstrm3s: un campo de 7 bits que indica la sonoridad no bloqueada de los 3 segundos anteriores del programa de audio correspondiente, medida de conformidad con la norma ITU-R BS.1771-1 y sin ningún ajuste de ganancia debido a la aplicación de dialnorm y compresión de margen dinámico. Los valores de 0 a 256 se interpretan como -116 LKFS a 11,5 LKFS en pasos de 0,5 l KfS;
truepke: un campo de un bit que indica si existen datos de sonoridad de pico verdadero. Si el campo truepke está establecido en '1', un campo truepk de 8 bits debe seguir en la carga útil; y
truepk: un campo de 8 bits que indica el valor de muestra de pico verdadero del programa, medido de conformidad con el Anexo 2 de la norma ITU-R BS.1770-3 y sin ningún ajuste de ganancia debido a la aplicación de dialnorm y la compresión de margen dinámico. Los valores de 0 a 256 se interpretan como -116 LKFS a 11,5 LKFS en pasos de 0,5 LKFS.
En algunas formas de realización, el elemento principal de un segmento de metadatos, en un segmento de bits residuales o en un campo auxdata (o "addbsi") de una trama de un flujo de bits en AC-3, o un flujo de bits en E-AC-3, comprende una cabecera de segmento de metadatos (normalmente incluye valores de identificación, por ejemplo, versión) y después la cabecera del segmento de metadatos; valores indicativos de si los datos de huellas dactilares se incluyen (u otros valores de protección) para los metadatos del segmento de metadatos, valores indicativos de si los datos externos existen (relacionados con datos de audio correspondientes a los metadatos del segmento de metadatos), ID de carga útil y valores de configuración de carga útil para cada tipo de metadatos (por ejemplo, PIM y/o SSM y/o LPSM y/o metadatos de un tipo) identificados por el elemento principal , y valores de protección para al menos un tipo de metadatos identificados por la cabecera del segmento de metadatos (u otros elementos principales del segmento de metadatos). Las cargas útiles de metadatos, del segmento de metadatos, siguen a la cabecera del segmento de metadatos y están (en algunos casos), alojadas dentro de elementos principales del segmento de metadatos.
Formas de realización de la presente invención se pueden poner en práctica en hardware, firmware o software, o una combinación de ambos (por ejemplo, como una matriz lógica programable). A no ser que se especifique de otro modo, los algoritmos o procesos incluidos como parte de la invención no están intrínsecamente relacionados con ningún ordenador particular u otro aparato. En particular, se pueden utilizar varias máquinas de uso general con programas escritos de conformidad con las enseñanzas aquí dadas a conocer, o puede ser más conveniente construir aparatos más especializados (por ejemplo, circuitos integrados) para realizar las etapas requeridas del método. Por lo tanto, la invención se puede poner en práctica en uno o más programas informáticos que se ejecutan en uno o más sistemas informáticos programables (por ejemplo, una realización de cualquiera de los elementos de la Figura 1, o el codificador 100 de la Figura 2 (o un elemento del mismo), o descodificador 200 de la Figura 3 (o un elemento del mismo), o post procesador 300 de la Figura 3 (o un elemento del mismo)) que comprenden cada uno al menos un procesador, al menos un sistema de memorización de datos (incluyendo memoria volátil y no volátil/o elementos de memorización), 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 datos de entrada para realizar las funciones descritas en este documento y para generar información de salida. La información de salida se aplica a uno o más dispositivos de salida, de manera conocida.
Cada uno de dichos programas se puede poner en práctica en cualquier lenguaje informático deseado (incluyendo lenguajes de máquina, montaje o de procedimientos de alto nivel, lógicos, o de programación orientados al objeto) para comunicarse con un sistema informático. En cualquier caso, el lenguaje puede ser un lenguaje compilado o interpretado.
A modo de ejemplo, cuando se pone en práctica mediante secuencias de instrucciones de software, varias funciones y etapas de formas de realización de la invención pueden realizarse mediante secuencias de instrucciones de software multiproceso que funcionan en hardware de procesamiento de señal digital adecuado, en cuyo caso los diversos dispositivos, pasos y funciones, de las formas de realización, pueden corresponder a partes de las instrucciones del software.
Cada uno de dichos programas informáticos preferentemente se memoriza, o descarga, en un soporte de almacenamiento o dispositivo (por ejemplo, memoria o medio de estado sólido, o medio magnético u óptico) legible
por un ordenador programable de finalidad general o especial, para la configuración y funcionamiento del ordenador cuando el sistema informático lee el dispositivo o medio de memorización, para realizar los procedimientos aquí descritos. El sistema inventivo puede ponerse en práctica, además, como un medio de memorización legible por ordenador, configurado con (es decir, memorizando) un programa informático, en donde el soporte de memorización así configurado hace que un sistema informático opere de manera específica y predefinida para realizar las funciones aquí descritas.
Se han descrito varias formas de realización de la invención. Sin embargo, ha de entenderse que pueden realizarse diversas modificaciones sin desviarse del alcance de la invención. Numerosas modificaciones y variaciones de la presente invención son posibles a la luz de las enseñanzas anteriores. Se ha de entender que, dentro del alcance de las reivindicaciones adjuntas, la invención se puede poner en práctica de otros modos distintos al que concretamente aquí se describe.
Claims (7)
1. Un método para generar un flujo de bits de audio codificado, comprendiendo el método:
la generación de una secuencia de tramas de un flujo de bits de audio codificado, en el que el flujo de bits de audio codificado es un flujo de bits en AC-3 o un flujo de bits en E-AC-3, siendo indicativo el flujo de bits de audio codificado de al menos un programa de audio, incluyendo cada trama de al menos un subconjunto de dichas tramas:
metadatos de información sobre el programa en al menos un segmento de metadatos situado en al menos uno de: a) un campo de omisión de la trama; b) un campo addbsi de la trama; c) un campo aux de la trama; y datos de audio en al menos otro segmento de la trama,
en el que el segmento de metadatos incluye al menos una carga útil de metadatos, comprendiendo dicha carga útil de metadatos: una cabecera: y, después de la cabecera, al menos alguno de los metadatos sobre información del programa,
en el que los metadatos de información sobre el programa son indicativos de información acerca del al menos un programa de audio no presente en otras porciones del flujo de bits de audio codificado,
en el que los metadatos de información sobre el programa incluyen metadatos de canal activo indicativos de cada canal no silencioso y cada canal silencioso del al menos un programa de audio.
2. Un método para descodificar un flujo de bits de audio codificado, incluyendo dicho método los pasos de:
recibir un flujo de bits de audio codificado, en el que el flujo de bits de audio codificado es un flujo de bits en AC-3 o un flujo de bits en E-AC-3,
en el que el flujo de bits de audio codificado comprende una secuencia de tramas y es indicativo de al menos un programa de audio, incluyendo cada trama de al menos un subconjunto de dichas tramas:
metadatos de información sobre el programa en al menos un segmento de metadatos situado en al menos uno de: a) un campo de omisión de la trama; b) un campo addbsi de la trama; c) un campo aux de la trama; y
los datos de audio en al menos otro segmento de la trama,
en el que el segmento de metadatos incluye al menos una carga útil de metadatos, comprendiendo dicha carga útil de metadatos: una cabecera; y, después de la cabecera, al menos alguno de los metadatos de información sobre el programa,
en el que los metadatos de información sobre el programa son indicativos de información acerca de al menos un programa de audio no presente en otras porciones del flujo de bits de audio codificado,
comprendiendo además el método extraer los datos de audio y los metadatos de información sobre el programa del flujo de bits de audio codificado,
en el que los metadatos de información sobre programa incluyen metadatos de canal activo indicativos de cada canal no silencioso y cada canal silencioso del al menos un programa de audio.
3. El método según la reivindicación 1 o el método según la reivindicación 2, en el que los metadatos de información sobre el programa incluyen además al menos uno de entre:
metadatos del estado de procesamiento de mezcla descendente, que indican si el programa fue objeto de mezcla descendente, y, si es así, un tipo de mezcla descendente que se aplicó al programa;
metadatos del estado de procesamiento de mezcla ascendente, que indican si el programa fue objeto de mezcla ascendente y, de ser así, un tipo de mezcla ascendente que se aplicó al programa;
metadatos de estado de pre-procesamiento, indicativos de si el pre-procesamiento se realizó sobre el contenido de audio de la trama, y, si es así, un tipo de pre-procesamiento que se realizó sobre dicho contenido de audio; o metadatos de procesamiento de extensión espectral o de acoplamiento de canal, indicativos de si se aplicó al programa procesamiento de extensión espectral o acoplamiento de canal, y, si es así, un margen de frecuencia que se aplicó a la extensión espectral o al acoplamiento de canal.
4. El método según la reivindicación 1 o el método de la reivindicación 2, en el que el segmento de metadatos incluye:
una cabecera de segmento de metadatos;
después de la cabecera de segmento de metadatos, valores de identificación de carga útil de metadatos y de
configuración de carga útil, en el que la carga útil de metadatos sigue a valores de identificación de carga útil de metadatos y de configuración de carga útil;
después del segmento de metadatos, al menos un valor de protección útil para al menos una de entre desencriptación, autenticación o validación de los metadatos de información sobre el programa o los datos de audio correspondientes a dichos metadatos de información sobre el programa.
5. El método según la reivindicación 4, en el que la cabecera del segmento de metadatos incluye una palabra de sincronización que identifica el inicio del segmento de metadatos, y al menos un valor de identificación que sigue a la palabra de sincronización, y la cabecera de la carga útil de metadatos incluye al menos un valor de identificación.
6. Un medio de almacenamiento legible por ordenador, que tiene guardado en el mismo un programa informático configurado para hacer que un sistema informático realice el método de cualquier reivindicación precedente.
7. Una unidad de procesamiento de audio, que comprende:
una memoria intermedia o temporal (109, 110, 201,301); y
al menos un subsistema de procesamiento, acoplado a la memoria intermedia, y configurado para realizar el método según cualquiera de las reivindicaciones 1 a 5.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201361836865P | 2013-06-19 | 2013-06-19 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2777474T3 true ES2777474T3 (es) | 2020-08-05 |
Family
ID=49112574
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES18156452T Active ES2777474T3 (es) | 2013-06-19 | 2014-06-12 | Codificador y descodificador de audio con metadatos de información de programa |
| ES14813862.1T Active ES2674924T3 (es) | 2013-06-19 | 2014-06-12 | Decodificador y codificador de audio con información de programa o metadatos de estructura de flujo secundario |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES14813862.1T Active ES2674924T3 (es) | 2013-06-19 | 2014-06-12 | Decodificador y codificador de audio con información de programa o metadatos de estructura de flujo secundario |
Country Status (24)
| Country | Link |
|---|---|
| US (7) | US10037763B2 (es) |
| EP (3) | EP3680900A1 (es) |
| JP (8) | JP3186472U (es) |
| KR (7) | KR200478147Y1 (es) |
| CN (10) | CN110600043A (es) |
| AU (1) | AU2014281794B9 (es) |
| BR (6) | BR122017011368B1 (es) |
| CA (1) | CA2898891C (es) |
| CL (1) | CL2015002234A1 (es) |
| DE (1) | DE202013006242U1 (es) |
| ES (2) | ES2777474T3 (es) |
| FR (1) | FR3007564B3 (es) |
| HK (3) | HK1204135A1 (es) |
| IL (1) | IL239687A (es) |
| IN (1) | IN2015MN01765A (es) |
| MX (5) | MX2021012890A (es) |
| MY (2) | MY192322A (es) |
| PL (1) | PL2954515T3 (es) |
| RU (4) | RU2619536C1 (es) |
| SG (3) | SG10201604617VA (es) |
| TR (1) | TR201808580T4 (es) |
| TW (11) | TWM487509U (es) |
| UA (1) | UA111927C2 (es) |
| WO (1) | WO2014204783A1 (es) |
Families Citing this family (48)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| TWM487509U (zh) | 2013-06-19 | 2014-10-01 | 杜比實驗室特許公司 | 音訊處理設備及電子裝置 |
| WO2015038475A1 (en) | 2013-09-12 | 2015-03-19 | Dolby Laboratories Licensing Corporation | Dynamic range control for a wide variety of playback environments |
| 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 |
| PL3123469T3 (pl) * | 2014-03-25 | 2018-09-28 | Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. | Urządzenie kodera audio i urządzenie dekodera audio z wydajnym kodowaniem wzmocnienia w sterowaniu zakresem dynamiki |
| WO2016009944A1 (ja) * | 2014-07-18 | 2016-01-21 | ソニー株式会社 | 送信装置、送信方法、受信装置および受信方法 |
| US10878828B2 (en) * | 2014-09-12 | 2020-12-29 | Sony Corporation | Transmission device, transmission method, reception device, and reception method |
| JP6809221B2 (ja) * | 2014-09-12 | 2021-01-06 | ソニー株式会社 | 送信装置、送信方法、受信装置および受信方法 |
| CN113257273A (zh) | 2014-10-01 | 2021-08-13 | 杜比国际公司 | 高效drc配置文件传输 |
| JP6812517B2 (ja) * | 2014-10-03 | 2021-01-13 | ドルビー・インターナショナル・アーベー | パーソナル化されたオーディオへのスマート・アクセス |
| CN110364190B (zh) * | 2014-10-03 | 2021-03-12 | 杜比国际公司 | 个性化音频的智能访问 |
| EP4372746A2 (en) * | 2014-10-10 | 2024-05-22 | Dolby Laboratories Licensing Corporation | Transmission-agnostic presentation-based program loudness |
| CN105765943B (zh) | 2014-10-20 | 2019-08-23 | Lg 电子株式会社 | 发送广播信号的装置、接收广播信号的装置、发送广播信号的方法和接收广播信号的方法 |
| TWI631835B (zh) * | 2014-11-12 | 2018-08-01 | 弗勞恩霍夫爾協會 | 用以解碼媒體信號之解碼器、及用以編碼包含用於主要媒體資料之元資料或控制資料的次要媒體資料之編碼器 |
| US10271094B2 (en) | 2015-02-13 | 2019-04-23 | Samsung Electronics Co., Ltd. | Method and device for transmitting/receiving media data |
| WO2016129976A1 (ko) * | 2015-02-14 | 2016-08-18 | 삼성전자 주식회사 | 시스템 데이터를 포함하는 오디오 비트스트림을 디코딩하는 방법 및 장치 |
| TW202242853A (zh) * | 2015-03-13 | 2022-11-01 | 瑞典商杜比國際公司 | 解碼具有增強頻譜帶複製元資料在至少一填充元素中的音訊位元流 |
| CN107533846B (zh) * | 2015-04-24 | 2022-09-16 | 索尼公司 | 发送装置、发送方法、接收装置与接收方法 |
| PL3311379T3 (pl) * | 2015-06-17 | 2023-03-20 | Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. | Kontrola głośności dla interaktywności użytkownika w systemach kodowania audio |
| TWI607655B (zh) * | 2015-06-19 | 2017-12-01 | Sony Corp | Coding apparatus and method, decoding apparatus and method, and program |
| US9934790B2 (en) | 2015-07-31 | 2018-04-03 | Apple Inc. | Encoded audio metadata-based equalization |
| US10140822B2 (en) | 2015-08-05 | 2018-11-27 | Dolby Laboratories Licensing Corporation | Low bit rate parametric encoding and transport of haptic-tactile signals |
| US10341770B2 (en) | 2015-09-30 | 2019-07-02 | Apple Inc. | Encoded audio metadata-based loudness equalization and dynamic equalization during DRC |
| US9691378B1 (en) * | 2015-11-05 | 2017-06-27 | Amazon Technologies, Inc. | Methods and devices for selectively ignoring captured audio data |
| CN105468711A (zh) * | 2015-11-19 | 2016-04-06 | 中央电视台 | 一种音频处理方法及装置 |
| US10573324B2 (en) | 2016-02-24 | 2020-02-25 | Dolby International Ab | Method and system for bit reservoir control in case of varying metadata |
| CN105828272A (zh) * | 2016-04-28 | 2016-08-03 | 乐视控股（北京）有限公司 | 音频信号处理方法和装置 |
| 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 |
| CA3049729C (en) | 2017-01-10 | 2023-09-05 | Fraunhofer-Gesellschaft Zur Foerderung Der Angewandten Forschung E.V. | Audio decoder, audio encoder, method for providing a decoded audio signal, method for providing an encoded audio signal, audio stream, audio stream provider and computer program using a stream identifier |
| 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 |
| JP7274492B2 (ja) | 2018-02-22 | 2023-05-16 | ドルビー・インターナショナル・アーベー | パケット化メディアストリームのサイドロード処理のための方法、機器、およびシステム |
| CN108616313A (zh) * | 2018-04-09 | 2018-10-02 | 电子科技大学 | 一种基于超声波的旁路信息安全隐蔽传送方法 |
| US10937434B2 (en) * | 2018-05-17 | 2021-03-02 | Mediatek Inc. | Audio output monitoring for failure detection of warning sound playback |
| SG11202012937WA (en) | 2018-06-26 | 2021-01-28 | Huawei Tech Co Ltd | High-level syntax designs for point cloud coding |
| US11430463B2 (en) * | 2018-07-12 | 2022-08-30 | Dolby Laboratories Licensing Corporation | Dynamic EQ |
| CN109284080B (zh) * | 2018-09-04 | 2021-01-05 | Oppo广东移动通信有限公司 | 音效调整方法、装置、电子设备以及存储介质 |
| CN113168839B (zh) * | 2018-12-13 | 2024-01-23 | 杜比实验室特许公司 | 双端媒体智能 |
| WO2020164753A1 (en) * | 2019-02-13 | 2020-08-20 | Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. | Decoder and decoding method selecting an error concealment mode, and encoder and encoding method |
| GB2582910A (en) * | 2019-04-02 | 2020-10-14 | Nokia Technologies Oy | Audio codec extension |
| EP4014506B1 (en) | 2019-08-15 | 2023-01-11 | Dolby International AB | Methods and devices for generation and processing of modified audio bitstreams |
| CN114303392A (zh) * | 2019-08-30 | 2022-04-08 | 杜比实验室特许公司 | 多声道音频信号的声道标识 |
| US11533560B2 (en) | 2019-11-15 | 2022-12-20 | Boomcloud 360 Inc. | Dynamic rendering device metadata-informed audio enhancement system |
| US11380344B2 (en) | 2019-12-23 | 2022-07-05 | Motorola Solutions, Inc. | Device and method for controlling a speaker according to priority data |
| CN112634907B (zh) * | 2020-12-24 | 2024-05-17 | 百果园技术(新加坡)有限公司 | 用于语音识别的音频数据处理方法及装置 |
| CN113990355A (zh) * | 2021-09-18 | 2022-01-28 | 赛因芯微(北京)电子科技有限公司 | 音频节目元数据和产生方法、电子设备及存储介质 |
| CN114051194A (zh) * | 2021-10-15 | 2022-02-15 | 赛因芯微(北京)电子科技有限公司 | 一种音频轨道元数据和生成方法、电子设备及存储介质 |
| US20230117444A1 (en) * | 2021-10-19 | 2023-04-20 | Microsoft Technology Licensing, Llc | Ultra-low latency streaming of real-time media |
| CN114363791A (zh) * | 2021-11-26 | 2022-04-15 | 赛因芯微(北京)电子科技有限公司 | 串行音频元数据生成方法、装置、设备及存储介质 |
| WO2023205025A2 (en) * | 2022-04-18 | 2023-10-26 | Dolby Laboratories Licensing Corporation | Multisource methods and systems for coded media |
Family Cites Families (130)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5297236A (en) * | 1989-01-27 | 1994-03-22 | Dolby Laboratories Licensing Corporation | Low computational-complexity digital filter bank for encoder, decoder, and encoder/decoder |
| JPH0746140Y2 (ja) | 1991-05-15 | 1995-10-25 | 岐阜プラスチック工業株式会社 | かん水栽培方法において使用する水位調整タンク |
| JPH0746140A (ja) * | 1993-07-30 | 1995-02-14 | Toshiba Corp | 符号化装置及び復号化装置 |
| US6611607B1 (en) * | 1993-11-18 | 2003-08-26 | Digimarc Corporation | Integrating digital watermarks in multimedia content |
| US5784532A (en) * | 1994-02-16 | 1998-07-21 | Qualcomm Incorporated | Application specific integrated circuit (ASIC) for performing rapid speech compression in a mobile telephone system |
| JP3186472B2 (ja) | 1994-10-04 | 2001-07-11 | キヤノン株式会社 | ファクシミリ装置およびその記録紙選択方法 |
| US7224819B2 (en) * | 1995-05-08 | 2007-05-29 | Digimarc Corporation | Integrating digital watermarks in multimedia content |
| JPH11234068A (ja) | 1998-02-16 | 1999-08-27 | Mitsubishi Electric Corp | ディジタル音声放送受信機 |
| JPH11330980A (ja) * | 1998-05-13 | 1999-11-30 | Matsushita Electric Ind Co Ltd | 復号装置及びその復号方法、並びにその復号の手順を記録した記録媒体 |
| US6530021B1 (en) * | 1998-07-20 | 2003-03-04 | Koninklijke Philips Electronics N.V. | Method and system for preventing unauthorized playback of broadcasted digital data streams |
| US6975254B1 (en) * | 1998-12-28 | 2005-12-13 | Fraunhofer-Gesellschaft Zur Foerderung Der Angewandten Forschung E.V. | Methods and devices for coding or decoding an audio signal or bit stream |
| US6909743B1 (en) | 1999-04-14 | 2005-06-21 | Sarnoff Corporation | Method for generating and processing transition streams |
| US8341662B1 (en) * | 1999-09-30 | 2012-12-25 | International Business Machine Corporation | User-controlled selective overlay in a streaming media |
| US7450734B2 (en) * | 2000-01-13 | 2008-11-11 | Digimarc Corporation | Digital asset management, targeted searching and desktop searching using digital watermarks |
| KR100865247B1 (ko) * | 2000-01-13 | 2008-10-27 | 디지맥 코포레이션 | 메타데이터를 인증하고 매체 신호들의 워터마크들 내에 메타데이터를 임베딩하는 방법 |
| US7266501B2 (en) * | 2000-03-02 | 2007-09-04 | Akiba Electronics Institute Llc | Method and apparatus for accommodating primary content audio and secondary content remaining audio capability in the digital audio production process |
| US8091025B2 (en) * | 2000-03-24 | 2012-01-03 | Digimarc Corporation | Systems and methods for processing content objects |
| US7392287B2 (en) * | 2001-03-27 | 2008-06-24 | Hemisphere Ii Investment Lp | Method and apparatus for sharing information using a handheld device |
| 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 |
| AUPR960601A0 (en) * | 2001-12-18 | 2002-01-24 | Canon Kabushiki Kaisha | Image protection |
| US7535913B2 (en) * | 2002-03-06 | 2009-05-19 | Nvidia Corporation | Gigabit ethernet adapter supporting the iSCSI and IPSEC protocols |
| JP3666463B2 (ja) * | 2002-03-13 | 2005-06-29 | 日本電気株式会社 | 光導波路デバイスおよび光導波路デバイスの製造方法 |
| EP1491033A1 (en) * | 2002-03-27 | 2004-12-29 | Koninklijke Philips Electronics N.V. | Watermarking a digital object with a digital signature |
| JP4355156B2 (ja) | 2002-04-16 | 2009-10-28 | パナソニック株式会社 | 画像復号化方法及び画像復号化装置 |
| 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 |
| US7398207B2 (en) * | 2003-08-25 | 2008-07-08 | Time Warner Interactive Video Group, Inc. | Methods and systems for determining audio loudness levels in programming |
| TWI404419B (zh) | 2004-04-07 | 2013-08-01 | Nielsen Media Res Inc | 與壓縮過音頻／視頻資料一起使用之資料插入方法、系統、機器可讀取媒體及設備 |
| GB0407978D0 (en) * | 2004-04-08 | 2004-05-12 | Holset Engineering Co | Variable geometry turbine |
| US8131134B2 (en) * | 2004-04-14 | 2012-03-06 | Microsoft Corporation | Digital media universal elementary stream |
| 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 |
| US8199933B2 (en) * | 2004-10-26 | 2012-06-12 | Dolby Laboratories Licensing Corporation | Calculating and adjusting the perceived loudness and/or the perceived spectral balance of an audio signal |
| AU2005299410B2 (en) * | 2004-10-26 | 2011-04-07 | Dolby Laboratories Licensing Corporation | Calculating and adjusting the perceived loudness and/or the perceived spectral balance of an audio signal |
| US9639554B2 (en) * | 2004-12-17 | 2017-05-02 | Microsoft Technology Licensing, Llc | Extensible file system |
| US7729673B2 (en) | 2004-12-30 | 2010-06-01 | Sony Ericsson Mobile Communications Ab | Method and apparatus for multichannel signal limiting |
| CN101156208B (zh) * | 2005-04-07 | 2010-05-19 | 松下电器产业株式会社 | 记录媒体、再现装置、记录方法、再现方法 |
| WO2006109718A1 (ja) * | 2005-04-07 | 2006-10-19 | Matsushita Electric Industrial Co., Ltd. | 記録媒体、再生装置、記録方法、再生方法 |
| TW200638335A (en) * | 2005-04-13 | 2006-11-01 | Dolby Lab Licensing Corp | Audio metadata verification |
| US7177804B2 (en) * | 2005-05-31 | 2007-02-13 | Microsoft Corporation | Sub-band voice codec with multi-stage codebooks and redundant coding |
| KR20070025905A (ko) * | 2005-08-30 | 2007-03-08 | 엘지전자 주식회사 | 멀티채널 오디오 코딩에서 효과적인 샘플링 주파수비트스트림 구성방법 |
| WO2007066880A1 (en) * | 2005-09-14 | 2007-06-14 | Lg Electronics Inc. | Method and apparatus for encoding/decoding |
| EP1958430A1 (en) | 2005-12-05 | 2008-08-20 | Thomson Licensing | Watermarking encoded content |
| US8929870B2 (en) * | 2006-02-27 | 2015-01-06 | Qualcomm Incorporated | Methods, apparatus, and system for venue-cast |
| US8244051B2 (en) * | 2006-03-15 | 2012-08-14 | Microsoft Corporation | Efficient encoding of alternative graphic sets |
| US20080025530A1 (en) | 2006-07-26 | 2008-01-31 | Sony Ericsson Mobile Communications Ab | Method and apparatus for normalizing sound playback loudness |
| US8948206B2 (en) * | 2006-08-31 | 2015-02-03 | Telefonaktiebolaget Lm Ericsson (Publ) | Inclusion of quality of service indication in header compression channel |
| CN101529504B (zh) * | 2006-10-16 | 2012-08-22 | 弗劳恩霍夫应用研究促进协会 | 多通道参数转换的装置和方法 |
| EP2111616B1 (en) | 2007-02-14 | 2011-09-28 | LG Electronics Inc. | Method and apparatus for encoding an audio signal |
| US8195454B2 (en) * | 2007-02-26 | 2012-06-05 | Dolby Laboratories Licensing Corporation | Speech enhancement in entertainment audio |
| JP5220840B2 (ja) * | 2007-03-30 | 2013-06-26 | エレクトロニクス アンド テレコミュニケーションズ リサーチ インスチチュート | マルチチャネルで構成されたマルチオブジェクトオーディオ信号のエンコード、並びにデコード装置および方法 |
| US20100208829A1 (en) * | 2007-04-04 | 2010-08-19 | Jang Euee-Seon | Bitstream decoding device and method having decoding solution |
| JP4750759B2 (ja) * | 2007-06-25 | 2011-08-17 | パナソニック株式会社 | 映像音声再生装置 |
| US7961878B2 (en) * | 2007-10-15 | 2011-06-14 | Adobe Systems Incorporated | Imparting cryptographic information in network communications |
| WO2009093867A2 (en) * | 2008-01-23 | 2009-07-30 | Lg Electronics Inc. | A method and an apparatus for processing audio signal |
| US9143329B2 (en) * | 2008-01-30 | 2015-09-22 | Adobe Systems Incorporated | Content integrity and incremental security |
| US20110002469A1 (en) * | 2008-03-03 | 2011-01-06 | Nokia Corporation | Apparatus for Capturing and Rendering a Plurality of Audio Channels |
| US20090253457A1 (en) * | 2008-04-04 | 2009-10-08 | Apple Inc. | Audio signal processing for certification enhancement in a handheld wireless communications device |
| KR100933003B1 (ko) * | 2008-06-20 | 2009-12-21 | 드리머 | Ｂｄ-ｊ 기반 채널 서비스 제공 방법 및 이를 실현시키기위한 프로그램을 기록한 컴퓨터로 판독 가능한 기록 매체 |
| 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 |
| US8374361B2 (en) * | 2008-07-29 | 2013-02-12 | Lg Electronics Inc. | Method and an apparatus for processing an audio signal |
| JP2010081397A (ja) * | 2008-09-26 | 2010-04-08 | Ntt Docomo Inc | データ受信端末、データ配信サーバ、データ配信システム、およびデータ配信方法 |
| JP2010082508A (ja) | 2008-09-29 | 2010-04-15 | Sanyo Electric Co Ltd | 振動モータおよびそれを用いた携帯端末装置 |
| US8798776B2 (en) * | 2008-09-30 | 2014-08-05 | Dolby International Ab | Transcoding of audio metadata |
| EP2353161B1 (en) * | 2008-10-29 | 2017-05-24 | Dolby International AB | Signal clipping protection using pre-existing audio gain metadata |
| JP2010135906A (ja) | 2008-12-02 | 2010-06-17 | Sony Corp | クリップ防止装置及びクリップ防止方法 |
| EP2205007B1 (en) * | 2008-12-30 | 2019-01-09 | Dolby International AB | Method and apparatus for three-dimensional acoustic field encoding and optimal reconstruction |
| WO2010090427A2 (ko) * | 2009-02-03 | 2010-08-12 | 삼성전자주식회사 | 오디오 신호의 부호화 및 복호화 방법 및 그 장치 |
| WO2010143088A1 (en) * | 2009-06-08 | 2010-12-16 | Nds Limited | Secure association of metadata with content |
| EP2309497A3 (en) * | 2009-07-07 | 2011-04-20 | Telefonaktiebolaget LM Ericsson (publ) | Digital audio signal processing system |
| TWI506486B (zh) * | 2009-10-09 | 2015-11-01 | Egalax Empia Technology Inc | 分析位置的方法與裝置 |
| MY154641A (en) * | 2009-11-20 | 2015-07-15 | Fraunhofer Ges Forschung | Apparatus for providing an upmix signal representation on the basis of the downmix signal representation, apparatus for providing a bitstream representing a multi-channel audio signal, methods, computer programs and bitstream representing a multi-channel audio signal using a linear cimbination parameter |
| AP3301A (en) | 2009-12-07 | 2015-06-30 | Dolby Lab Licensing Corp | Decoding of multichannel audio encoded bit streamsusing adaptive hybrid transformation |
| TWI529703B (zh) * | 2010-02-11 | 2016-04-11 | 杜比實驗室特許公司 | 用以非破壞地正常化可攜式裝置中音訊訊號響度之系統及方法 |
| TWI443646B (zh) * | 2010-02-18 | 2014-07-01 | Dolby Lab Licensing Corp | 音訊解碼器及使用有效降混之解碼方法 |
| TWI525987B (zh) * | 2010-03-10 | 2016-03-11 | 杜比實驗室特許公司 | 在單一播放模式中組合響度量測的系統 |
| ES2526761T3 (es) | 2010-04-22 | 2015-01-15 | Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. | Aparato y método para modificar una señal de audio de entrada |
| WO2011141772A1 (en) * | 2010-05-12 | 2011-11-17 | Nokia Corporation | Method and apparatus for processing an audio signal based on an estimated loudness |
| US8948406B2 (en) * | 2010-08-06 | 2015-02-03 | Samsung Electronics Co., Ltd. | Signal processing method, encoding apparatus using the signal processing method, decoding apparatus using the signal processing method, and information storage medium |
| CN103003877B (zh) * | 2010-08-23 | 2014-12-31 | 松下电器产业株式会社 | 声音信号处理装置及声音信号处理方法 |
| US8908874B2 (en) * | 2010-09-08 | 2014-12-09 | Dts, Inc. | Spatial audio encoding and reproduction |
| JP5903758B2 (ja) | 2010-09-08 | 2016-04-13 | ソニー株式会社 | 信号処理装置および方法、プログラム、並びにデータ記録媒体 |
| JP5792821B2 (ja) * | 2010-10-07 | 2015-10-14 | フラウンホーファー−ゲゼルシャフト・ツール・フェルデルング・デル・アンゲヴァンテン・フォルシュング・アインゲトラーゲネル・フェライン | ビットストリーム・ドメインにおけるコード化オーディオフレームのレベルを推定する装置及び方法 |
| TW202405797A (zh) * | 2010-12-03 | 2024-02-01 | 美商杜比實驗室特許公司 | 音頻解碼裝置、音頻解碼方法及音頻編碼方法 |
| US8989884B2 (en) | 2011-01-11 | 2015-03-24 | Apple Inc. | Automatic audio configuration based on an audio output device |
| CN102610229B (zh) * | 2011-01-21 | 2013-11-13 | 安凯(广州)微电子技术有限公司 | 一种音频动态范围压缩方法、装置及设备 |
| JP2012235310A (ja) | 2011-04-28 | 2012-11-29 | Sony Corp | 信号処理装置および方法、プログラム、並びにデータ記録媒体 |
| TWI543642B (zh) | 2011-07-01 | 2016-07-21 | 杜比實驗室特許公司 | 用於適應性音頻信號的產生、譯碼與呈現之系統與方法 |
| KR101547809B1 (ko) | 2011-07-01 | 2015-08-27 | 돌비 레버러토리즈 라이쎈싱 코오포레이션 | 적응형 오디오 시스템을 위한 동기화 및 전환 방법과 시스템 |
| 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 | 音声信号処理装置、および音声信号処理方法、並びにプログラム |
| KR102172279B1 (ko) * | 2011-11-14 | 2020-10-30 | 한국전자통신연구원 | 스케일러블 다채널 오디오 신호를 지원하는 부호화 장치 및 복호화 장치, 상기 장치가 수행하는 방법 |
| EP2783366B1 (en) | 2011-11-22 | 2015-09-16 | Dolby Laboratories Licensing Corporation | Method and system for generating an audio metadata quality score |
| ES2565394T3 (es) | 2011-12-15 | 2016-04-04 | Fraunhofer Gesellschaft zur Förderung der angewandten Forschung e.V. | Aparato, método y programa informático para evitar artefactos de recorte |
| WO2013118476A1 (ja) * | 2012-02-10 | 2013-08-15 | パナソニック株式会社 | 音響／音声符号化装置、音響／音声復号装置、音響／音声符号化方法および音響／音声復号方法 |
| US9633667B2 (en) * | 2012-04-05 | 2017-04-25 | Nokia Technologies Oy | Adaptive audio signal filtering |
| TWI517142B (zh) | 2012-07-02 | 2016-01-11 | Sony Corp | Audio decoding apparatus and method, audio coding apparatus and method, and program |
| US8793506B2 (en) * | 2012-08-31 | 2014-07-29 | Intel Corporation | Mechanism for facilitating encryption-free integrity protection of storage data at computing systems |
| US20140074783A1 (en) * | 2012-09-09 | 2014-03-13 | Apple Inc. | Synchronizing metadata across devices |
| 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 |
| KR102158002B1 (ko) * | 2013-01-21 | 2020-09-21 | 돌비 레버러토리즈 라이쎈싱 코오포레이션 | 프로그램 라우드니스 및 경계 메타데이터를 가진 오디오 인코더 및 디코더 |
| JP6445460B2 (ja) | 2013-01-28 | 2018-12-26 | フラウンホッファー−ゲゼルシャフト ツァ フェルダールング デァ アンゲヴァンテン フォアシュンク エー．ファオ | 新しいメディア装置に関する埋め込み音量メタデータを有する、および、有しないメディアの正規化音声再生のための方法と装置 |
| US9372531B2 (en) * | 2013-03-12 | 2016-06-21 | Gracenote, Inc. | Detecting an event within interactive media including spatialized multi-channel audio content |
| US9559651B2 (en) | 2013-03-29 | 2017-01-31 | Apple Inc. | Metadata for loudness and dynamic range control |
| US9607624B2 (en) | 2013-03-29 | 2017-03-28 | Apple Inc. | Metadata driven dynamic range control |
| TWM487509U (zh) | 2013-06-19 | 2014-10-01 | 杜比實驗室特許公司 | 音訊處理設備及電子裝置 |
| JP2015050685A (ja) | 2013-09-03 | 2015-03-16 | ソニー株式会社 | オーディオ信号処理装置および方法、並びにプログラム |
| CN105531762B (zh) | 2013-09-19 | 2019-10-01 | 索尼公司 | 编码装置和方法、解码装置和方法以及程序 |
| US9300268B2 (en) | 2013-10-18 | 2016-03-29 | Apple Inc. | Content aware audio ducking |
| JP6588899B2 (ja) | 2013-10-22 | 2019-10-09 | フラウンホッファー−ゲゼルシャフト ツァ フェルダールング デァ アンゲヴァンテン フォアシュンク エー．ファオ | オーディオ装置のための組合せダイナミックレンジ圧縮および誘導クリッピング防止のための概念 |
| 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 |
| CA3162763A1 (en) | 2013-12-27 | 2015-07-02 | Sony Corporation | Decoding apparatus and method, and program |
| US9608588B2 (en) | 2014-01-22 | 2017-03-28 | Apple Inc. | Dynamic range control with large look-ahead |
| PL3123469T3 (pl) | 2014-03-25 | 2018-09-28 | Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. | Urządzenie kodera audio i urządzenie dekodera audio z wydajnym kodowaniem wzmocnienia w sterowaniu zakresem dynamiki |
| US9654076B2 (en) | 2014-03-25 | 2017-05-16 | Apple Inc. | Metadata for ducking control |
| PT3149955T (pt) | 2014-05-28 | 2019-08-05 | Fraunhofer Ges Forschung | Processador de dados e transporte de dados de controlo do utilizador para descodificadores e renderizadores de áudio |
| BR112016027506B1 (pt) | 2014-05-30 | 2023-04-11 | Sony Corporation | Aparelho e método de processamento de informação |
| MX368088B (es) | 2014-06-30 | 2019-09-19 | Sony Corp | Procesador de informacion y metodo de procesamiento de informacion. |
| 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 |
| MX371222B (es) | 2015-05-29 | 2020-01-09 | Fraunhofer Ges Forschung | Dispositivo y metodo para control de volumen. |
| PL3311379T3 (pl) | 2015-06-17 | 2023-03-20 | Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. | Kontrola głośności dla interaktywności użytkownika w systemach kodowania audio |
| US9837086B2 (en) | 2015-07-31 | 2017-12-05 | Apple Inc. | Encoded audio extended metadata-based dynamic range control |
| US9934790B2 (en) | 2015-07-31 | 2018-04-03 | Apple Inc. | Encoded audio metadata-based equalization |
| US10341770B2 (en) | 2015-09-30 | 2019-07-02 | Apple Inc. | Encoded audio metadata-based loudness equalization and dynamic equalization during DRC |
-
2013
- 2013-06-26 TW TW102211969U patent/TWM487509U/zh not_active IP Right Cessation
- 2013-07-10 DE DE202013006242U patent/DE202013006242U1/de not_active Expired - Lifetime
- 2013-07-10 FR FR1356768A patent/FR3007564B3/fr not_active Expired - Lifetime
- 2013-07-26 JP JP2013004320U patent/JP3186472U/ja not_active Expired - Lifetime
- 2013-07-31 CN CN201910831687.6A patent/CN110600043A/zh active Pending
- 2013-07-31 CN CN201910832003.4A patent/CN110491396A/zh active Pending
- 2013-07-31 CN CN201320464270.9U patent/CN203415228U/zh not_active Expired - Lifetime
- 2013-07-31 CN CN201910831663.0A patent/CN110459228B/zh active Active
- 2013-07-31 CN CN201310329128.8A patent/CN104240709B/zh active Active
- 2013-07-31 CN CN201910831662.6A patent/CN110491395B/zh active Active
- 2013-07-31 CN CN201910832004.9A patent/CN110473559A/zh active Pending
- 2013-08-19 KR KR2020130006888U patent/KR200478147Y1/ko active IP Right Grant
-
2014
- 2014-05-29 TW TW109121184A patent/TWI719915B/zh active
- 2014-05-29 TW TW106135135A patent/TWI647695B/zh active
- 2014-05-29 TW TW111102327A patent/TWI790902B/zh active
- 2014-05-29 TW TW112101558A patent/TWI831573B/zh active
- 2014-05-29 TW TW103118801A patent/TWI553632B/zh active
- 2014-05-29 TW TW110102543A patent/TWI756033B/zh active
- 2014-05-29 TW TW106111574A patent/TWI613645B/zh active
- 2014-05-29 TW TW105119766A patent/TWI588817B/zh active
- 2014-05-29 TW TW105119765A patent/TWI605449B/zh active
- 2014-05-29 TW TW107136571A patent/TWI708242B/zh active
- 2014-06-12 RU RU2016119396A patent/RU2619536C1/ru active
- 2014-06-12 ES ES18156452T patent/ES2777474T3/es active Active
- 2014-06-12 JP JP2015557247A patent/JP6046275B2/ja active Active
- 2014-06-12 MX MX2021012890A patent/MX2021012890A/es unknown
- 2014-06-12 SG SG10201604617VA patent/SG10201604617VA/en unknown
- 2014-06-12 KR KR1020247012621A patent/KR20240055880A/ko active Application Filing
- 2014-06-12 KR KR1020217027339A patent/KR102358742B1/ko active IP Right Grant
- 2014-06-12 MX MX2015010477A patent/MX342981B/es active IP Right Grant
- 2014-06-12 TR TR2018/08580T patent/TR201808580T4/tr unknown
- 2014-06-12 KR KR1020197032122A patent/KR102297597B1/ko active IP Right Grant
- 2014-06-12 MY MYPI2018002360A patent/MY192322A/en unknown
- 2014-06-12 SG SG11201505426XA patent/SG11201505426XA/en unknown
- 2014-06-12 BR BR122017011368-2A patent/BR122017011368B1/pt active IP Right Grant
- 2014-06-12 CA CA2898891A patent/CA2898891C/en active Active
- 2014-06-12 SG SG10201604619RA patent/SG10201604619RA/en unknown
- 2014-06-12 RU RU2016119397A patent/RU2624099C1/ru active
- 2014-06-12 ES ES14813862.1T patent/ES2674924T3/es active Active
- 2014-06-12 BR BR112015019435-4A patent/BR112015019435B1/pt active IP Right Grant
- 2014-06-12 AU AU2014281794A patent/AU2014281794B9/en active Active
- 2014-06-12 BR BR122017012321-1A patent/BR122017012321B1/pt active IP Right Grant
- 2014-06-12 MY MYPI2015702460A patent/MY171737A/en unknown
- 2014-06-12 RU RU2015133936/08A patent/RU2589370C1/ru active
- 2014-06-12 IN IN1765MUN2015 patent/IN2015MN01765A/en unknown
- 2014-06-12 CN CN201610645174.2A patent/CN106297810B/zh active Active
- 2014-06-12 PL PL14813862T patent/PL2954515T3/pl unknown
- 2014-06-12 KR KR1020157021887A patent/KR101673131B1/ko active IP Right Grant
- 2014-06-12 EP EP20156303.8A patent/EP3680900A1/en active Pending
- 2014-06-12 BR BR122020017897-3A patent/BR122020017897B1/pt active IP Right Grant
- 2014-06-12 WO PCT/US2014/042168 patent/WO2014204783A1/en active Application Filing
- 2014-06-12 MX MX2016013745A patent/MX367355B/es unknown
- 2014-06-12 KR KR1020227003239A patent/KR102659763B1/ko active IP Right Grant
- 2014-06-12 EP EP14813862.1A patent/EP2954515B1/en active Active
- 2014-06-12 CN CN201480008799.7A patent/CN104995677B/zh active Active
- 2014-06-12 BR BR122016001090-2A patent/BR122016001090B1/pt active IP Right Grant
- 2014-06-12 KR KR1020167019530A patent/KR102041098B1/ko active IP Right Grant
- 2014-06-12 BR BR122020017896-5A patent/BR122020017896B1/pt active IP Right Grant
- 2014-06-12 CN CN201610652166.0A patent/CN106297811B/zh active Active
- 2014-06-12 EP EP18156452.7A patent/EP3373295B1/en active Active
- 2014-06-12 US US14/770,375 patent/US10037763B2/en active Active
- 2014-12-06 UA UAA201508059A patent/UA111927C2/uk unknown
-
2015
- 2015-05-13 HK HK15104519.7A patent/HK1204135A1/xx unknown
- 2015-06-29 IL IL239687A patent/IL239687A/en active IP Right Grant
- 2015-08-11 CL CL2015002234A patent/CL2015002234A1/es unknown
-
2016
- 2016-03-11 HK HK16102827.7A patent/HK1214883A1/zh unknown
- 2016-05-11 HK HK16105352.3A patent/HK1217377A1/zh unknown
- 2016-06-20 US US15/187,310 patent/US10147436B2/en active Active
- 2016-06-22 US US15/189,710 patent/US9959878B2/en active Active
- 2016-09-27 JP JP2016188196A patent/JP6571062B2/ja active Active
- 2016-10-19 MX MX2019009765A patent/MX2019009765A/es unknown
- 2016-10-19 MX MX2022015201A patent/MX2022015201A/es unknown
- 2016-11-30 JP JP2016232450A patent/JP6561031B2/ja active Active
-
2017
- 2017-06-22 RU RU2017122050A patent/RU2696465C2/ru active
- 2017-09-01 US US15/694,568 patent/US20180012610A1/en not_active Abandoned
-
2019
- 2019-07-22 JP JP2019134478A patent/JP6866427B2/ja active Active
-
2020
- 2020-03-16 US US16/820,160 patent/US11404071B2/en active Active
-
2021
- 2021-04-07 JP JP2021065161A patent/JP7090196B2/ja active Active
-
2022
- 2022-06-13 JP JP2022095116A patent/JP7427715B2/ja active Active
- 2022-08-01 US US17/878,410 patent/US11823693B2/en active Active
-
2023
- 2023-11-16 US US18/511,495 patent/US20240153515A1/en active Pending
-
2024
- 2024-01-24 JP JP2024008433A patent/JP2024028580A/ja active Pending
Also Published As
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2777474T3 (es) | Codificador y descodificador de audio con metadatos de información de programa |