MX2015004468A - Codificador y decodificador de audio con metadatos de limite y sonoridad de programa. - Google Patents
Codificador y decodificador de audio con metadatos de limite y sonoridad de programa.Info
- Publication number
- MX2015004468A MX2015004468A MX2015004468A MX2015004468A MX2015004468A MX 2015004468 A MX2015004468 A MX 2015004468A MX 2015004468 A MX2015004468 A MX 2015004468A MX 2015004468 A MX2015004468 A MX 2015004468A MX 2015004468 A MX2015004468 A MX 2015004468A
- Authority
- MX
- Mexico
- Prior art keywords
- audio
- metadata
- program
- loudness
- data
- Prior art date
Links
- 238000012545 processing Methods 0.000 claims abstract description 226
- 238000000034 method Methods 0.000 claims abstract description 57
- 230000003044 adaptive effect Effects 0.000 claims abstract description 19
- 238000012937 correction Methods 0.000 claims description 21
- 230000008569 process Effects 0.000 claims description 15
- 230000006835 compression Effects 0.000 claims description 8
- 238000007906 compression Methods 0.000 claims description 8
- 238000000691 measurement method Methods 0.000 claims description 3
- 238000010606 normalization Methods 0.000 claims 2
- 238000010200 validation analysis Methods 0.000 abstract description 18
- 230000006870 function Effects 0.000 description 40
- 238000005259 measurement Methods 0.000 description 22
- 230000004044 response Effects 0.000 description 21
- 230000033228 biological regulation Effects 0.000 description 19
- 238000010586 diagram Methods 0.000 description 14
- 230000001755 vocal effect Effects 0.000 description 13
- 238000003780 insertion Methods 0.000 description 12
- 230000037431 insertion Effects 0.000 description 12
- 230000005540 biological transmission Effects 0.000 description 8
- 238000012805 post-processing Methods 0.000 description 8
- 238000007781 pre-processing Methods 0.000 description 8
- 238000004458 analytical method Methods 0.000 description 7
- 238000003860 storage Methods 0.000 description 7
- 238000004422 calculation algorithm Methods 0.000 description 5
- 239000007787 solid Substances 0.000 description 5
- 230000001105 regulatory effect Effects 0.000 description 4
- 238000005070 sampling Methods 0.000 description 4
- 230000001360 synchronised effect Effects 0.000 description 4
- 230000007704 transition Effects 0.000 description 4
- 230000008859 change Effects 0.000 description 3
- 238000004590 computer program Methods 0.000 description 3
- 230000003247 decreasing effect Effects 0.000 description 3
- 238000011160 research Methods 0.000 description 3
- 238000000926 separation method Methods 0.000 description 3
- 230000004913 activation Effects 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 230000015556 catabolic process Effects 0.000 description 2
- 238000013479 data entry Methods 0.000 description 2
- 230000007423 decrease Effects 0.000 description 2
- 238000006731 degradation reaction Methods 0.000 description 2
- 238000001914 filtration Methods 0.000 description 2
- 238000002955 isolation Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000005236 sound signal Effects 0.000 description 2
- 230000001052 transient effect Effects 0.000 description 2
- 206010023204 Joint dislocation Diseases 0.000 description 1
- 230000000712 assembly Effects 0.000 description 1
- 238000000429 assembly Methods 0.000 description 1
- 230000003190 augmentative effect Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 150000001875 compounds Chemical class 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000009826 distribution Methods 0.000 description 1
- 230000008030 elimination Effects 0.000 description 1
- 238000003379 elimination reaction Methods 0.000 description 1
- 239000000945 filler Substances 0.000 description 1
- 238000005111 flow chemistry technique Methods 0.000 description 1
- 230000004907 flux Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000002372 labelling Methods 0.000 description 1
- PWPJGUXAGUPAHP-UHFFFAOYSA-N lufenuron Chemical compound C1=C(Cl)C(OC(F)(F)C(C(F)(F)F)F)=CC(Cl)=C1NC(=O)NC(=O)C1=C(F)C=CC=C1F PWPJGUXAGUPAHP-UHFFFAOYSA-N 0.000 description 1
- 238000004519 manufacturing process 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
- 238000013139 quantization Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000001131 transforming effect Effects 0.000 description 1
- 238000012795 verification 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/002—Dynamic bit allocation
-
- 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/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/06—Determination or coding of the spectral characteristics, e.g. of the short-term prediction coefficients
-
- 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
-
- 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
-
- H—ELECTRICITY
- H03—ELECTRONIC CIRCUITRY
- H03G—CONTROL OF AMPLIFICATION
- H03G9/00—Combinations of two or more types of control, e.g. gain control and tone control
- H03G9/005—Combinations of two or more types of control, e.g. gain control and tone control of digital or coded signals
-
- H—ELECTRICITY
- H03—ELECTRONIC CIRCUITRY
- H03G—CONTROL OF AMPLIFICATION
- H03G9/00—Combinations of two or more types of control, e.g. gain control and tone control
- H03G9/02—Combinations of two or more types of control, e.g. gain control and tone control in untuned amplifiers
- H03G9/025—Combinations of two or more types of control, e.g. gain control and tone control in untuned amplifiers frequency-dependent volume compression or expansion, e.g. multiple-band systems
Landscapes
- Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- Multimedia (AREA)
- Audiology, Speech & Language Pathology (AREA)
- Human Computer Interaction (AREA)
- Signal Processing (AREA)
- Acoustics & Sound (AREA)
- Computational Linguistics (AREA)
- Health & Medical Sciences (AREA)
- Spectroscopy & Molecular Physics (AREA)
- Mathematical Physics (AREA)
- Stereophonic System (AREA)
- Compression, Expansion, Code Conversion, And Decoders (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Signal Processing For Digital Recording And Reproducing (AREA)
- Circuit For Audible Band Transducer (AREA)
- Reverberation, Karaoke And Other Acoustics (AREA)
Abstract
Aparatos y métodos para generar un flujo de bits de audio codificado, que incluyen incluir metadatos de sonoridad de programa y datos de audio en el flujo de bits, y opcionalmente también metadatos de límite de programa en al menos un segmento (por ejemplo, trama) del flujo de bits. Otros aspectos son aparatos y métodos para decodificar dicho flujo de bits, por ejemplo, que incluye mediante la realización de procesamiento de sonoridad adaptativo de los datos de audio de un programa de audio indicado por el flujo de bits, o autenticación y/o validación de metadatos y/o datos de audio de dicho programa de audio. Otro aspecto es una unidad de procesamiento de audio (por ejemplo, un codificador, decodificador o postprocesador) configurado (por ejemplo, programado) para que realice cualquier modalidad del método o que incluye una memoria intermedia que almacena al menos una trama de un flujo de bits de audio generado de acuerdo con cualquier modalidad del método.
Description
CODIFICADOR Y DECODIFICADOR DE AUDIO CON
METADATOS DE LÍMITE Y SONORIDAD DE PROGRAMA
REFERENCIA CRUZADA A SOLICITUDES RELACIONADAS
Esta solicitud reivindica prioridad de la solicitud de patente provisional estadounidense n.° 61/754,882, presentada el 21 de enero de 2013 y la aplicación de patente provisional estadounidense n.° 61/824,010, presentada el 16 de mayo de 2013, cada una de las cuales está incorporada en la presente en su totalidad.
CAMPO TÉCNICO
La invención se refiere al procesamiento de señales de audio, y más particularmente, a codificar y decodificar flujos de bits de datos de audio con metadatos que indican el estado de procesamiento de la sonoridad del contenido de audio y la ubicación de los límites de programas de audio indicados por los flujos de bits. Algunas modalidades de la invención generan o decodifican datos de audio en uno de los formatos conocidos como AC-3, 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 comerciales de Dolby Laboratories Licensing Corporation. Dolby Laboratories proporciona implementaciones patentadas de AC-3 y E-AC-3 conocido como Dolby Digital y Dolby Digital
Plus, respectivamente.
Las unidades de procesamiento de datos funcionan típicamente de manera ciega y no prestan atención al historial de procesamiento de datos de audio que ocurre antes de que se reciban los datos. Esto puede funcionar en un marco de procesamiento en el que una única entidad realiza todo el procesamiento de datos de audio y que codifica una variedad de dispositivos de reproducción de medios objetivo, mientras que un dispositivo de reproducción de medios objetivo realiza toda la decodificación y reproducción de datos de audio codificado. Sin embargo, este procesamiento ciego no funciona bien (o directamente no funciona) en situaciones en la que las múltiples unidades de procesamiento de audio están dispersas a lo largo de una red diversa o están ubicadas en tándem (es decir, cadena) y se espera que realicen de manera óptima sus respectivos tipos de procesamiento de audio. Por ejemplo, algunos datos de audio se pueden codificar sistemas de medios de alto rendimiento y pueden tener que convertirse a una forma reducida adecuada para un dispositivo móvil junto con una cadena de procesamiento de medios. Por consiguiente, una unidad de procesamiento de audio puede realizar innecesariamente un tipo de procesamiento en los datos de audio que ya se ha realizado. Por ejemplo, una unidad de
nivelación de volumen puede realizar el procesamiento en un clip de audio de entrada, sin perjuicio de si se ha realizado o no anteriormente la misma nivelación de volumen o una nivelación de volumen similar en el clip de audio de entrada. Como resultado, la unidad de nivelación de volumen puede realizar la nivelación aun cuando no es necesario. Este procesamiento innecesario también puede causar la degradación y/o la eliminación de características específicas a la vez que reproduce los datos de audio.
Un flujo de datos de audio típico incluye tanto contenido de audio (por ejemplo, uno o más canales de contenido de audio) como metadatos que indican al menos una característica del contenido de audio. Por ejemplo, en un flujo de bits AC-3 hay varios parámetros de metadatos de audio que están previstos específicamente para cambiar el sonido del programa suministrado a un entorno de escucha. Uno de los parámetros de metadatos en el parámetro DIALNORM, que pretende indicar el nivel promedio de diálogo que se produce en un programa de audio, y se usa para determinar el nivel de señal de reproducción de audio.
Durante la reproducción de un flujo de bits que comprende una secuencia de segmentos de programa de audio diferentes (cada uno con un parámetro DIALNORM diferente), un decodificador
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 manera que la sonoridad percibida del diálogo de la secuencia de segmentos esté a un nivel consistente. Cada segmento de audio codificado (ítem) en una secuencia de ítems de audio codificado tendría (en general) un parámetro DIALNORM diferente, y el decodificador aumentará el nivel de cada uno de los ítems de manera que el nivel de reproducción o sonoridad del diálogo para cada ítem sea el mismo o muy similar, aunque esto puede requerir la aplicación de diferentes cantidades de ganancia a diferentes ítems durante la reproducción.
DIALNORM típicamente está fijado por un usuario, y no se genera automáticamente, aunque hay un valor DIALNORM por defecto si no se fija ningún valor por parte del usuario. Por ejemplo, un creador de contenidos puede realizar mediciones de sonoridad con un dispositivo externo a un codificador AC-3 y luego transferir el resultado (que indica la sonoridad del diálogo hablado de un programa de audio) al codificador para fijar el valor DIALNORM. Por lo tanto, se confía en que el creador del contenido fijará correctamente el parámetro
DIALNORM.
Hay varias razones diferentes por las que el parámetro DIALNORM en un flujo de bits AC-3 puede estar incorrecto. Primero, cada codificador AC-3 tiene un valor de DIALNORM por defecto que se usa durante la generación del flujo de bits si un valor de DIALNORM no está fijado por el creador de contenido. Este valor por defecto puede ser considerablemente diferente al nivel de sonoridad de diálogo real del audio. Segundo, incluso si un creador de contenido mide la sonoridad y fija el valor de DIALNORM de acuerdo con esta, se puede haber usado un medidor o algoritmo de medición de la sonoridad que no cumple con el método de medición de la sonoridad AC-3 recomendado, lo que da como resultado un valor de DIALNORM incorrecto. Tercero, incluso si un flujo de bits AC-3 ha sido creado con el valor de DIALNORM medido y fue fijado correctamente por el creador de contenido, se puede haber cambiado a un valor incorrecto durante la transmisión y/o almacenamiento del flujo de bits. Por ejemplo, en las aplicaciones de transmisión de televisión es común que los flujos de bits AC-3 se decodifiquen, modifiquen y se recodifiquen usando información de metadatos de DIALNORM incorrectos. Por lo tanto, un valor de DIALNORM incluido en un flujo de bits AC-3 puede ser incorrecto o inexacto y por lo tanto puede tener un impacto negativo en la calidad de la
experiencia auditiva.
Además, el parámetro DIALNORM no indica el estado de procesamiento de sonoridad de los datos de audio correspondientes (por ejemplo, qué tipos de procesamientos de sonoridad se han realizado en los datos de audio). Hasta la presente invención, un flujo de bits no incluía metadatos, que indican el estado de procesamiento de la sonoridad (por ejemplo, tipos de procesamiento de sonoridad aplicado a) el contenido de audio del flujo de bits o el estado de procesamiento de sonoridad y la sonoridad del contenido de audio del flujo de bits, en un formato de un tipo descrito en la presente descripción. Los metadatos en estado de procesamiento de sonoridad en dicho formato son útiles para facilitar el procesamiento de sonoridad adaptativo de un flujo de bits de audio y/o la verificación de validez del estado de procesamiento de sonoridad y la sonoridad del contenido de audio, de una manera particularmente eficiente. Aunque la presente invención no está limitada al uso con un flujo de bits AC-3, un flujo de bits E-AC-3, o un flujo de bits Dolby E, por comodidad se describirá en modalidades en la que genera, decodifica o de otra manera procesa dicho flujo de bits que incluye metadatos en estado de procesamiento de sonoridad.
Un flujo de bits AC-3 codificado comprende metadatos y uno a seis canales de contenido de audio. El contenido de audio son datos de audio que fueron comprimidos usando codificación de audio perceptual. Los metadatos incluyen varios parámetros de metadatos de audio que están previstos para cambiar el sonido de un programa suministrado a un entorno de escucha.
Los detalles de la codificación de AC-3 (también conocida como Dolby Digital) son bien conocidos y se establecen en muchas referencias publicadas incluyendo en las siguientes: ATSC Standard A52/A: Digital Audio Compression Standard [Norma A52/A de la ATSC: Norma de compresión de audio digital] (AC-3) , Revisión A, Advanced Televisión Systems Committee [Comité de Sistemas de Televisión Avanzada], 20 agosto de 2001; y
patentes estadounidenses 5,583,962; 5,632,005; 5,633,981;
5,727,119; y 6,021,386, las cuales se incorporan a la presente en su totalidad mediante esta referencia.
Los detalles de la codificación de Dolby Digital Plus (E-AC-3) están establecidos en "Introduction to Dolby Digital Plus, an Enhancement to the Dolby Digital Coding System", AES Convention Paper 6196, 117.a Convención de la AES[Sociedad de Ingenieros de Audio], 28 de octubre, 2004.
Los detalles de la codificación de Dolby E están establecidos
en "Efficient Bit Allocation, Quantization, and Coding in an Audio Distribution System", AES Preprint 5068, 107.a Conferencia de la AES, agosto de 1999 y en "Professional Audio Coder Optimized for Use with Video", AES Preprint 5033, 107.a Conferencia de la, agosto de 1999.
Cada trama de un flujo de bits de audio codificado AC-3 contiene contenido de audio y metadatos para 1536 muestras de audio digital. Para una velocidad de muestreo de 48 kHz, esto representa 32 milisegundos de audio digital o una velocidad de 31,25 tramas por segundo de audio.
Cada trama de un flujo de bits de audio codificado E-AC-3 contiene contenido de audio y metadatos para 256, 512, 768 o 1536 muestras de audio digital, dependiendo de si la trama contiene uno, dos, tres o seis bloques de datos de audio respectivamente. Para una velocidad de muestreo de 48 kHz, esto representa 5,333, 10,667, 16 o 32 milisegundos de audio digital respectivamente o una velocidad de 189,9, 93,75, 62,5 o 31,25 tramas por segundo de audio respectivamente.
Como se indica en la Figura 4, cada trama AC-3 se divide en secciones (segmentos), que incluyen: una sección de Información de Sincronización (SI, por sus siglas en inglés) que contiene (como se muestra en la Figura 5) una palabra de sincronización (SW, por sus siglas en inglés) y la primera de
dos palabras de corrección de error (CRC1, por sus siglas en inglés); una sección de Información de Flujo de Bits (BSI, por sus siglas en inglés) que contiene la mayoría de los metadatos; seis Bloques de Audio (ABO a AB5) que contienen contenido de audio comprimido de datos (y también puede contener metadatos); segmentos de bits sobrantes (W) que contienen cualquier bit sin usar sobrante luego de que comprime el contenido de audio; una sección de información Auxiliar (AUX) que puede contener más metadatos; y la segunda de dos palabras de corrección de errores (CRC2). El segmento de bits sobrantes (W) también se puede denominar un "campo de salto".
Como se indica en la Figura 7, cada trama E-AC-3 se divide en secciones (segmentos), que incluyen: una sección de Información de Sincronización (SI) que contiene (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 (ABO a AB5) que contienen contenido de audio comprimido de datos (y también puede contener metadatos); segmentos de bits sobrantes (W) que contienen cualquier bit sin usar sobrante luego de que se comprime el contenido de audio (aunque solo se muestra un segmento de bits sobrantes,
un segmento de bits sobrantes diferente seguirá típicamente cada bloque de audio); una sección de información Auxiliar (AUX) que puede contener más metadatos; y una palabra de corrección de errores (CRC). El segmento de bits sobrantes (W) también se puede denominar un "campo de salto".
En un flujo de bits AC-3 (o E-AC-3) hay varios parámetros de metadatos de audio que están previstos específicamente para cambiar el sonido del programa suministrado 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.
Tal como se muestra en la Figura 6, el segmento de BSI de una trama 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 en la misma trama AC-3 si el modo de codificación de audio ( "acmod") de la trama de AC-3 es "0", que indica que se está usando una configuración de canal dual-mono o "1+1".
El segmento de BSI también incluye un indicador ("addbsie") que indica la presencia (o ausencia) de información de flujo de bits adicional a continuación del bit "addbsie", un parámetro ("addbsil") que indica la longitud de cualquier información de flujo de bits adicional a continuación del
valor "addbsil", y hasta 64 bits de información de flujo de bits adicional ("addbsi") después del valor "addbsil".
El segmento de BSI incluye otros valores de metadatos que no se muestran específicamente en la Figura 6.
Breve descripción de la invención
En una clase de modalidades, la invención es una unidad de procesamiento de audio que incluye una memoria intermedia, un decodificador de audio y un analizador sintáctico. La memoria intermedia almacena al menos una trama de un flujo de bits de audio codificado. El flujo de bits de audio codificado incluye datos de audio y un contenedor de metadatos. El contenedor de metadatos incluye un encabezado, una o más cargas útiles de metadatos y datos de protección. El encabezado incluye una palabra de sincronización que identifica el inicio del contenedor. La una o más cargas útiles de metadatos describe un programa de audio asociado con los datos de audio. Los datos de protección se ubican después de la una o más cargas útiles de metadatos. Los datos de protección también se pueden usar para verificar la integridad del contenedor de metadatos y la una o más cargas útiles dentro del contenedor de metadatos. El decodificador de audio está acoplado a la memoria intermedia y es capaz de decodificar los datos de audio. El analizador sintáctico está
acoplado o integrado al decodificador de audio y es capaz de analizar sintácticamente el contenedor de metadatos.
En modalidades típicas, el método incluye recibir un flujo de bits de audio codificado donde el flujo de bits de audio codificado está segmentado en una o más tramas. Los datos de audio se extraen del flujo de bits de audio codificado, junto con un contenedor de metadatos. El contenedor de metadatos incluye un encabezado a continuación de una o más cargas útiles de metadatos a continuación de datos de protección. Finalmente, la integridad del contenedor y la una o más cargas útiles de metadatos se verifica a través del uso de los datos de protección. La una o más cargas útiles de metadatos pueden incluir una carga útil de sonoridad de programa que contiene datos que indican la sonoridad medida de un programa de audio asociado con los datos de audio.
Una carga útil de metadatos de sonoridad de programa, referida como metadatos en estado de procesamiento de sonoridad ("LPSM", por sus siglas en inglés), incrustados en un flujo de bits de audio de acuerdo con modalidades típicas de la invención se pueden autenticar y validar, por ejemplo, para permitir entidades reguladoras de sonoridad para verificar si una sonoridad de programa particular ya se encuentra dentro de un intervalo especificado y que los datos
de audio correspondientes no han sido modificados (asegurando de esa manera el cumplimiento con regulaciones aplicables). Un valor de sonoridad incluido en un bloque de datos que comprende los metadatos en estado de procesamiento de sonoridad se puede leer para verificar eso, en vez de computar la sonoridad nuevamente. En respuesta a los LPSM, una agencia reguladora puede determinar que el contenido de audio correspondiente cumple (como está indicado por los LPSM) con los requisitos reguladores y/o legales de sonoridad (por ejemplo, las regulaciones promulgadas por la Lcy de Mitigación de Sonoridad en la Publicidad Comercial, también conocida como la Ley "CALM") sin la necesidad de computar la sonoridad del contenido de audio.
Las mediciones de sonoridad necesarias para cumplir con algunos requisitos reguladores y/o legales (por ejemplo, las regulaciones promulgadas por la Ley CALM) están basadas en la sonoridad de programa integrado. La sonoridad de programa integrado requiere que se realice una medición de sonoridad, ya sea del nivel de diálogo o nivel de mezcla completa en un programa de audio completo. Por lo tanto, para realizar mediciones de la sonoridad de programa (por ejemplo, en varias etapas en la cadena de transmisión) para verificar el cumplimiento de los requisitos legales típicos, es esencial
que las mediciones se realicen con el conocimiento de qué datos de audio (y metadatos) determinan un programa de audio entero, y típicamente, esto requiere el conocimiento de la ubicación del inicio y el final del programa (por ejemplo, durante el procesamiento de flujo de bits que indica una secuencia de programas de audio).
De acuerdo con modalidades típicas de la presente invención, un flujo de bits de audio codificado indica al menos un programa de audio (por ejemplo, una secuencia de programas de audio), y los metadatos de límite de programa y LPSM incluidos en el flujo de bits permiten reinicializar las mediciones de sonoridad de programa al final de un programa y proporcionar de esa forma una manera automática de medir la sonoridad de programa integrado. Modalidades típicas de la invención incluyen metadatos de límite de programa en un flujo de bits de audio codificado de manera eficiente, que permite la determinación sólida y exacta de al menos un límite entre programas de audio consecutivos indicados por el flujo de bits. Las modalidades típicas permiten la determinación sólida y exacta de un límite de programa en el sentido que permiten la determinación del límite de programa de manera exacta aun en casos en donde los flujos de bits que indican programas diferentes se empalman (para generar el
flujo de bits de la invención) de manera que trunque uno o ambos de los flujos de bits empalmados (y de esa manera descarte los metadatos de límite de programa que han sido incluidos en al menos uno de los flujos de bits anteriores al empalme).
En modalidades típicas, los metadatos de límite de sonoridad en una trama del flujo de bits de la invención es un indicador de límite de programa que indica un conteo de tramas. Típicamente, el indicador indica la cantidad de tramas entre la trama actual (la trama que incluye el indicador) y un límite de programa (el inicio o fin del programa de audio actual). En algunas modalidades preferidas, los indicadores de límite de programa se insertan de manera eficiente y simétrica al principio y fin de cada segmento de flujo de bits que indica un único programa (es decir, en tramas que se producen dentro de alguna cantidad de tramas predeterminadas después del inicio del segmento y en tramas que se producen dentro de alguna cantidad de tramas predeterminadas antes del final del segmento), para que cuando dos de dichos segmentos de flujos de bits se concatenen (para indicar una secuencia de dos programas), los metadatos de límite de programa pueden estar presente (por ejemplo, simétricamente) en ambos lados del límite entre dos
programas).
Para limitar el aumento de la tasa de datos que resulta de incluir metadatos de límites de programa en un flujo de bits de audio codificado (que puede indicar un programa de audio o una secuencia de programas de audio), en modalidades típicas, los indicadores de límites de programa se insertan solo en un subconjunto de las tramas del flujo de bits. Típicamente, la tasa de inserción de indicadores de límites es una función que no aumenta de separación en aumento de cada una de las tramas de flujo de bits (donde se inserta un indicador) del límite de programa que está más cerca de cada una de dichas tramas, donde la "tasa de inserción de indicadores de límites" denota la proporción promedio de la cantidad de tramas (que indican un programa) que incluye un indicador de límite de programa con respecto a la cantidad de tramas (que indican el programa) que no incluye un indicador de límite de programa, donde el promedio es una media móvil de una cantidad (por ejemplo, cantidad relativamente pequeña) de tramas consecutivas del flujo de bits de audio codificado. En una clase de modalidades, la tasa de inserción de indicadores de límites es una función que disminuye de manera logarítmica de distancia en aumento (de cada ubicación de inserción de indicador) desde el límite de programa más cercano, y para
cada trama que contiene indicadores que incluye uno de los indicadores, el tamaño del indicador en dicha trama que contiene indicadores es igual o mayor que el tamaño de cada indicador en una trama ubicada más cerca del límite de programa más cercano que es dicha trama que contiene indicadores (es decir, el tamaño del indicador de límite de programa en cada trama que contiene indicadores es una función que no disminuye de separación en aumento de dicha trama que contiene indicadores desde el límite de programa más cercano).
Otro aspecto de la invención es una unidad de procesamiento de audio (APU, por sus siglas en inglés) configurada para realizar cualquier modalidad del método de la invención. En otra clase de modalidades, la invención es una APU que incluye una memoria intermedia (buffer) que almacena (por ejemplo, de manera no transitoria) al menos una trama de un flujo de bits de audio codificado que ha sido generado por cualquier modalidad del método de la invención. Los ejemplos de APU incluyen, de modo no taxativo, codificadores (por ejemplo, transcodificadores), decodificadores, codees, sistemas de preprocesamiento (preprocesadores), sistemas de postprocesamiento (postprocesadores), sistemas de procesamiento de flujo de bits de audio y combinaciones de
dichos elementos.
En otra clase de modalidades, la invención es una unidad de procesamiento de audio (APU) configurada para generar un flujo de bits de audio codificado que comprende segmentos de datos de audio y segmentos de metadatos, donde los segmentos de datos de audio indican los datos de audio y cada uno de al menos algunos de los segmentos de metadatos incluye metadatos en estado de procesamiento de sonoridad (LPSM) y opcionalmente también metadatos de límite de programa. Típicamente, al menos uno de dichos segmentos de metadatos en una trama del flujo de bits incluye al menos un segmento de LPSM que indica si se ha realizado un primer tipo de sonoridad en los datos de audio de la trama (es decir, los datos de audio en al menos un segmento de datos de audio de la trama) y al menos otro segmento de LPSM que indica la sonoridad de al menos alguno de los datos de audio de la trama (por ejemplo, la sonoridad del diálogo de al menos algunos de los datos de audio de la trama que indican el diálogo). En una modalidad en esta clase, la APU es un codificador configurado para codificar audio de entrada para generar audio codificado, y los segmentos de datos de audio incluyen el audio codificado. En modalidades típicas en esta clase, cada uno de los segmentos de metadatos tiene un
formato preferido que se describirá en la presente.
En algunas modalidades, cada uno de los segmentos de metadatos del flujo de bits codificado (un flujo de bits AC-3 o un flujo de bits E-AC-3 en algunas modalidades) que incluye LPSM (por ejemplo, LPSM y metadatos de límite de programa) se incluyen en un bit sobrante de segmento de campo de salto de una trama del flujo de bits (por ejemplo, un segmento de bits sobrantes W del tipo que se muestra en la Figura 4 o Figura 7). En otras modalidades, cada uno de los segmentos de metadatos de los bits de flujos codificados (un flujo de bits AC-3 o un flujo de bits E-AC-3 en algunas modalidades) que incluye LPSM (por ejemplo, LPSM y metadatos de límite de programa) se incluye como información de flujo de bits adicional en el campo "addbsi" del segmento de la Información de Flujo de Bits ("BSI") de una trama del flujo de bits o en un campo de datos auxiliar (por ejemplo, un segmento AUX del tipo que se muestra en la Figura 4 o Figura 7) al final de una trama del flujo de bits. Cada segmento de metadatos que incluye LPSM puede tener el formato especificado en la presente con referencia a las Tablas 1 y 2 a continuación (es decir, incluye los elementos nucleares especificados en la
Tabla 1 o una variación de estos, seguido de una ID de carga útil (que identifica los metadatos como LPSM) y los valores
de tamaño de carga útil, seguido por carga útil (datos de LPSM que tienen el formato indicado en la Tabla 2, o el formato como se indica en una variación en la Tabla 2 descrita en la presente). En algunas modalidades, una trama puede incluir uno o dos segmentos de metadatos, cada uno de los cuales incluye LPSM, y si la trama incluye dos segmentos de metadatos, uno puede estar presente en el campo addbsi de la trama y el otro en el campo AUX de la trama.
En una clase de modalidades, la invención es un método que incluye las etapas de codificar datos de audio para generar un flujo de bits de audio codificado AC-3 o E-AC-3, que incluye incluir en un segmento de metadatos (de al menos una trama del flujo de bits) LPSM y metadatos de límite de programa y opcionalmente también otros metadatos para el programa de audio al que pertenezca la trama. En algunas modalidades, cada uno de dichos segmentos de metadatos está incluido en un campo de addbsi de la trama, o un campo de datos auxiliares de la trama. En otras modalidades, cada uno de los segmentos de metadatos está incluido en un segmento de bits sobrantes de la trama. En algunas modalidades, cada segmento de metadatos que contiene LPSM y los metadatos de límite de programa contienen un encabezado nuclear (y opcionalmente también elementos nucleares adicionales) y
después del encabezado nuclear (o el encabezado nuclear y otros elementos nucleares) un segmento de carga útil de LPSM (o contenedor) que tiene el siguiente formato:
un encabezado, típicamente que incluye al menos un valor de identificación (por ejemplo, versión de formato, longitud, período, conteo, y valores de asociación de subflujo de LPSM, como se indican en la Tabla 2 de la presente), y
después del encabezado, los LPSM y los metadatos de límite de programa. Los metadatos de límite de programa pueden incluir un conteo de tramas de límite de programa y un valor de código (por ejemplo, un valor "offset_exist ") que indica si la trama incluye solo un conteo de trama de límite de programa o tanto un conteo de trama de límite de programa como un valor offset), y (en algunos casos) un valor offset. Los LPSM pueden incluir:
al menos un valor de indicación de diálogo que indica si los datos de audio correspondientes indican diálogo o no indican diálogo (por ejemplo, qué canales de datos de audio correspondiente indican diálogo). Los valores de indicación de diálogo pueden indicar si el diálogo está presente en cualquier combinación o todos los canales de los datos de audio correspondientes;
al menos un valor de cumplimiento de regulación de sonoridad
que indica si los datos de audio correspondientes cumplen con un conjunto indicado de regulaciones de sonoridad;
al menos un valor de procesamiento de sonoridad que indica un tipo de procesamiento de sonoridad que ha sido realizado en los datos de audio correspondientes; y
al menos un valor de sonoridad que indica al menos una característica de sonoridad (por ejemplo, pico o sonoridad promedio) de los datos de audio correspondientes.
En otras modalidades, el flujo de bits codificado es un flujo de bits que no es un flujo de bits AC-3 o un flujo de bits E-AC-3, y cada uno de los segmentos de metadatos que incluye LPSM (y opcionalmente también metadatos de límite de programa) está incluido en un segmento (o campo o ranura) del flujo de bits reservado para el almacenamiento de datos adicionales. Cada segmento de metadatos que incluye LPSM puede tener un formato similar o idéntico al especificado en la presente con referencia a las Tablas 1 y 2 a continuación (es decir, incluye elementos nucleares similares o idénticos a los especificados en la Tabla 1, seguido de una ID de carga útil (que identifica los metadatos como LPSM) y los valores de tamaño de carga útil, seguido por la carga útil (datos de LPSM que tienen el formato similar o idéntico al formato indicado en la Tabla 2, o una variación en la Tabla 2
descrita en la presente).
En algunas modalidades, el flujo de bits codificado comprende una secuencia de tramas, cada una de las tramas incluye un segmento de Información de Flujo de Bits ("BSI") que incluye un campo "addbsi" (a veces denominado como un segmento o ranura) y un campo o ranura de datos auxiliares (por ejemplo, el flujo de bits codificado es un flujo de bits AC-3 o un flujo de bits E-AC-3), y comprende segmentos de datos de audio (por ejemplo, los segmentos AB0-AB5 de la trama que se muestra en la Figura 4) y segmentos de etadatos, donde los segmentos de datos de audio indican datos de audio, y cada uno de al menos algunos de los segmentos de metadatos incluye metadatos en estado de procesamiento de sonoridad (LPSM) y opcionalmente también metadatos de límites de programa. Los LPSM están presentes en el flujo de bits en el siguiente formato. Cada uno de los segmentos de metadatos que incluye LPSM está incluido en un campo de "addbsi" del segmento de BSI de una trama de flujo de bits, o en un campo de datos auxiliares de una trama del flujo de bits, o en un segmento de bits sobrantes de una trama del flujo de bits. Cada segmento de metadatos que incluye LPSM incluye un segmento de carga útil de LPSM (o contenedor) que tiene el siguiente formato :
un encabezado (típicamente que incluye al menos un valor de identificación, por ejemplo, la versión de formato, longitud, período, conteo, y valores de asociación de subflujo de LPSM indicados en la Tabla 2 a continuación); y
después del encabezado, los LPSM y opcionalmente también los metadatos de límite de programa. Los metadatos de límite de programa pueden incluir un conteo de tramas de límite de programa y un valor de código (por ejemplo, un valor "offset_exist ") que indica si la trama incluye solo un conteo de trama de límite de programa o tanto un conteo de trama de límite de programa y un valor offset), y (en algunos casos) un valor offset. Los LPSM pueden incluir:
al menos un valor de indicación de diálogo (por ejemplo, parámetros "Canales de Diálogo" de la Tabla 2) que indica si los datos de audio correspondientes indican diálogo o no indican diálogo (por ejemplo, qué canales de datos de audio correspondiente indican diálogo). Los valores de indicación de diálogo pueden indicar si el diálogo está presente en cualquier combinación o todos los canales de los datos de audio correspondientes,-al menos un valor de cumplimiento de regulación de sonoridad (por ejemplo, parámetro "Tipo de Regulación de Sonoridad" de la Tabla 2) que indica si los datos de audio correspondientes
cumplen con un conjunto indicado de regulaciones de sonoridad;
al menos un valor de procesamiento de sonoridad (por ejemplo, uno o más de los parámetros "Indicador de Corrección de Sonoridad con Función de Puerta de Diálogo", "Tipo de Corrección de Sonoridad" de la Tabla 2) que indica al menos un tipo de procesamiento de sonoridad que se ha realizado en los datos de audio correspondientes; y
al menos un valor de sonoridad (por ejemplo, uno o más de los parámetros "Sonoridad con Función de Puerta relativa a ITU", "Sonoridad con Función de Puerta de Discurso ITU", "Sonoridad de 3s a Corto Plazo ITU (EBU 3341)" y "Pico Verdadero" de la Tabla 2) que indica al menos una característica de sonoridad (por ejemplo, sonoridad pico o promedio) de los datos de audio correspondientes.
En cualquier modalidad de la invención que contempla usos o genera al menos un valor de sonoridad que indica los datos de audio correspondientes, los valores de sonoridad pueden indicar al menos una característica de medición de sonoridad utilizada para procesar la sonoridad y/o rango dinámico de los datos de audio.
En algunas implementaciones, cada uno de lo segmentos de metadatos en un campo "addbsi", o un campo de datos auxiliar,
o un segmento de bits sobrantes, de una trama del flujo de bits tiene el siguiente formato:
un encabezado nuclear (que típicamente incluye una palabra de sincronización que identifica el inicio del segmento de metadatos seguido por valores de identificación, por ejemplo, la versión del elemento nuclear, longitud, y período, conteo de elemento extendido, y valores de asociación de subflujo indicados en la Tabla 1 a continuación); y
después del encabezado nuclear, al menos un valor de protección (por ejemplo, un digest de HMAC y valores de huellas digitales de audio, donde el digest de HMAC puede ser un digest de HMAC de 256 bits (utilizando el algoritmo SHA-2) computarizado sobre los datos de audio, el elemento nuclear, y todos los elementos expandidos, de una trama entera, como se indica en la Tabla 1) útil para al menos una de descriptación, autenticación, o validación de al menos uno de metadatos en estado de procesamiento de sonoridad o de los datos de audio correspondiente); y
también después del encabezado nuclear, si el segmento de metadatos incluye LPSM, identificación de carga útil de LPSM ("ID") y valores de tamaño de carga útil de LPSM que identifican los metadatos siguientes como una carga útil de LPSM e indican el tamaño de la carga útil de LPSM. El
segmento de carga útil de LPSM (preferentemente que tiene el formato antes especificado) sigue a la ID de la carga útil de LPSM y los valores de tamaño de carga útil de LPSM.
En algunas modalidades del tipo descritas en el párrafo anterior, cada uno de los segmentos de metadatos en el campo de datos auxiliares (o campo de "addbsi" o segmento de bits sobrantes) de la trama tiene tres niveles de estructura: una estructura de nivel alto, que incluye un indicador que indica si el campo de datos auxiliares (o addbsi) incluye metadatos, al menos un valor de ID que indica qué tipo de metadatos está presente, y típicamente también un valor que indica cuántos bits de metadatos (por ejemplo, de cada tipo) están presentes (si existen metadatos). Un tipo de metadatos que podría estar presente es LPSM, otro tipo de metadatos que podría estar presente es metadatos de límite de programa y otro tipo de metadatos que podría estar presente es de metadatos de investigación de medios;
una estructura de nivel intermedio, que comprende un elemento nuclear para cada tipo de metadatos identificado (por ejemplo, encabezado nuclear, valores de protección e ID de carga útil y valores de tamaño de carga útil, por ejemplo, del tipo mencionado anteriormente, para cada tipo identificado de metadatos); y
una estructura de nivel bajo, que comprende cada carga útil para un elemento nuclear (por ejemplo, una carga útil de LPSM, si el elemento nuclear identifica que una está presente, y/o una carga útil de metadatos de otro tipo, si el elemento nuclear identifica que una está presente).
Se pueden anidar los valores de datos en dicha estructura de tres niveles. Por ejemplo, los valores de protección para una carga útil de LPSM y/o otra carga útil de metadatos identificados por un elemento nuclear se pueden incluir después de cada carga útil identificada por el elemento nuclear (y por lo tanto, después del encabezado nuclear del elemento nuclear). En un ejemplo, un encabezado nuclear podría identificar una carga útil de LPSM y otra carga útil de metadatos, ID de carga útil y valores de tamaño de carga útil para la primera carga útil (por ejemplo, la carga útil de LPSM) podría seguir el encabezado nuclear, la primera carga útil podría seguir los valores de tamaño e ID, la ID de carga útil y el valor de tamaño de carga útil para la segunda carga útil podría seguir la primera carga útil, la segunda carga útil podría seguir estos valores de tamaño e ID, y valores de protección para una o ambas de las cargas útiles (o para los valores de elementos nucleares y una o ambas de las cargas útiles) podría seguir la última carga útil.
En algunas modalidades, el elemento nuclear de un segmento de metadatos en un campo de datos auxiliares (o campo "addbsi" o segmento de bits sobrantes) de una trama comprende un encabezado nuclear (típicamente que incluye valores de identificación, por ejemplo, versión de elemento nuclear) y después del encabezado nuclear: valores que indican si los datos de huellas digitales están incluidos para los metadatos del segmento de metadatos, valores que indican si existen datos externos (relacionados con los datos de audio que corresponden a los metadatos del segmento de metadatos), la ID de carga útil y los valores de tamaño de carga útil para cada tipo de metadatos (por ejemplo, LPSM, y/o metadatos de un tipo que no sea LPSM) identificado por el elemento nuclear, y valores de protección para al menos un tipo de metadatos identificado por el elemento nuclear. Las cargas útiles de metadatos de los segmentos de metadatos siguen el encabezado nuclear, y (en algunos casos) se anidan dentro de los valores del elemento nuclear.
En otro formato preferido, el flujo de bits codificado es un flujo de bits de Dolby E, y cada uno de los segmentos de metadatos que incluye LPSM (y opcionalmente también metadatos de límite de programa) se incluye en las primeras ubicaciones de muestras N del intervalo de banda de guarda de Dolby E.
En otra clase de modalidades, la invención es un APU (por ejemplo, un decodificador) acoplado y configurado para recibir un flujo de bits de audio codificado que comprende segmentos de datos de audio y segmentos de metadatos, donde los segmentos de datos de audio indican los datos de audio, y cada uno de al menos algunos de los segmentos de metadatos incluye metadatos en estado de procesamiento de sonoridad (LPSM) y opcionalmente también metadatos de límite de programa, y para extraer los LPSM del flujo de bits, para generar datos de audio decodificado en respuesta a los datos de audio y realizar al menos una operación de procesamiento de sonoridad adaptativo en los datos de audio usando los LPSM. Algunas modalidades en esta clase también incluyen un postprocesador acoplado a la APU, donde el postprocesador está acoplado y configurado para realizar al menos una operación de procesamiento de sonoridad adaptativo en los datos de audio usando los LPSM.
En otra clase de modalidades, la invención es una unidad de procesamiento de audio (APU) que incluye una memoria intermedia (buffer) y un subsistema de procesamiento acoplado al buffer, donde la APU está acoplada para recibir un flujo de bits de audio codificado que comprende segmentos de datos de audio y segmentos de metadatos, donde los segmentos de
datos de audio indican datos de audio, y cada uno de al menos algunos de los segmentos de metadatos incluye metadatos en estado de procesamiento de sonoridad (LPSM) y opcionalmente también metadatos de límite de programa, el buffer almacena (por ejemplo, de manera no transitoria) al menos una trama del flujo de bits de audio codificado, y el subsistema de procesamiento está configurado para extraer los LPSM del flujo de bits y para realizar al menos una operación de procesamiento de sonoridad adaptativo en los datos de audio usando los LPSM. En modalidades típicas en esta clase, la APU es una de un codificador, un decodificador y un postprocesador.
En algunas implementaciones del método de la invención, el flujo de bits de audio generado es uno de un flujo de bits AC-3, un flujo de bits E-AC-3, o un flujo de bits Dolby E, que incluye metadatos en estado de procesamiento de sonoridad, así como también otros metadatos (por ejemplo, un parámetro de metadatos DIALNORM, parámetros de metadatos de control de rango dinámico, y otros parámetros de metadatos). En algunas otras implementaciones del método, el flujo de bits de audio generado es un flujo de bits codificado de otro tipo.
Los aspectos de la invención incluyen un sistema o dispositivo configurado (por ejemplo, programado) para realizar cualquier modalidad del método de la invención, y un medio legible por computadora (por ejemplo, un disco) que almacena códigos (por ejemplo, de manera no transitoria) para implementar cualquier modalidad del método de la invención o etapas de este. Por ejemplo, el sistema de la invención puede ser o puede incluir un procesador programable de uso general, procesador de señales digitales, o microprocesador, programado con software o firmware y/o configurado de otra manera para realizar cualquiera de una variedad de operaciones de datos, incluyendo una modalidad del método de la invención o etapas de este. Dicho procesador de uso general puede ser o puede incluir un sistema informático que incluye un dispositivo de entrada de datos, una memoria, y circuitos de procesamiento programados (y/o configurados de otra manera) para realizar una modalidad del método de la invención (o etapas de este) en respuesta a los datos afirmados en este.
Breve descripción de las figuras
La Figura 1 es un diagrama de bloques de una modalidad de un sistema que se puede configurar para que realice una modalidad del método de la invención.
La Figura 2 es un diagrama de bloques de un codificador que es una modalidad de la unidad de procesamiento de audio de la invención.
La Figura 3 es un diagrama de bloques de un decodificador que es una modalidad de la unidad de procesamiento de audio de la invención, y un postprocesador acoplado a esta que es otra modalidad de la unidad de procesamiento de audio de la invención.
La Figura 4 es un diagrama de una trama AC-3, que incluye los segmentos en los que está dividida.
La Figura 5 es un diagrama del segmento de Información de Sincronización (SI) de una trama AC-3, que incluye los segmentos en los que está dividida.
La Figura 6 es un diagrama del segmento de Información de Flujo de bits (BSI) de una trama AC-3, que incluye los segmentos en los que está dividida.
La Figura 7 es un diagrama de una trama E-AC-3, que incluye los segmentos en los que está dividida.
La Figura 8 es un diagrama de tramas de un flujo de bits de audio codificado que incluye metadatos de límite de programa con un formato de acuerdo con una modalidad de la invención. La Figura 9 es un diagrama de otras tramas del flujo de bits de audio codificado de la Figura 9. Algunas de estas tramas
incluyen metadatos de límite de programa con un formato de acuerdo con una modalidad de la invención.
La Figura 10 es un diagrama de dos flujos de bits codificados: un flujo de bits (IEB) en el que un límite de programa (etiquetado "Límite") está alineado con una transición entre dos tramas del flujo de bits, y otro flujo de bits (TB) en el que un límite de programa (etiquetado "Límite verdadero") está desviado por 512 muestras de una transición entre dos tramas del flujo de bits.
La Figura 11 es un conjunto de diagramas que muestra cuatro flujos de bits de audio codificados. El flujo de bits en la parte superior de la Figura 11 (etiquetado "Escenario 1") indica un primer programa de audio (Pl) que incluye metadatos de límite de programa seguidos por un segundo programa de audio (P2) que también incluye metadatos de límite de programa; el segundo flujo de bits (etiquetado "Escenario 2" ) indica un primer programa de audio (Pl) que incluye metadatos de límite de programa seguidos por un segundo programa de audio (P2) que no incluye metadatos de límite de programa; el tercer flujo de bits (etiquetado "Escenario 3") indica un primer programa de audio truncado (Pl) que incluye metadatos de límite de programa, y que sido empalmado con un segundo programa de audio entero (P2) que incluye metadatos de límite
de programa; y el cuarto flujo de bits (etiquetado "Escenario 4") indica un primer programa de audio truncado (Pl) que incluye metadatos de límite de programa, y un segundo programa de audio truncado (P2) que incluye metadatos de límite de programa, y que sido empalmado con una parte del primer programa de audio.
Notación y Nomenclatura
A lo largo de la presente descripción incluyendo en las reivindicaciones, la expresión realizar una operación "en" una señal o datos (por ejemplo, filtrar, aumentar, transformar o aplicar ganancia a la señal o datos) se usa en sentido amplio para indicar la realización de una operación directamente en la señal o datos, o en una versión procesada de la señal o datos (por ejemplo, en una versión de la señal que ha experimentado filtrado preliminar o preprocesamiento antes de la realización de la operación en estos).
A lo largo de la presente descripción incluyendo en las reivindicaciones, la expresión "sistema" se usa en sentido amplio para indicar un dispositivo, sistema o subsistema. Por ejemplo, un subsistema que implementa un decodificador puede hacer referencia a un sistema decodificador, y un sistema que incluye a dicho subsistema (por ejemplo, un sistema que genera señales de salida X en respuesta a múltiples entradas
de datos, en el que el subsistema genera M de las entradas de datos y las otras entradas de datos X - M son recibidas de una fuente externa) también pueden hacer referencia a un sistema decodificador.
A lo largo de la presente descripción incluyendo en las reivindicaciones, el término "procesador" se usa en sentido amplio para indicar un sistema o dispositivo programable o configurable de otra manera (por ejemplo, con software o firmware) para realizar operaciones en los datos (por ejemplo, datos de audio o video u otros datos de imagen). Los ejemplos de procesadores incluyen una matriz de puertas campo de programable (u otro circuito integrado o conjunto de chips configurable), un procesador de señal digital programado y/o configurados de otra forma para realizar el procesamiento de conductos en datos de audio u otros datos de sonido, un procesador o computadora programable de uso general y un chip microprocesador o conjunto de chips programables.
A lo largo de la presente descripción incluyendo en las reivindicaciones, las expresiones "procesador de audio" y "unidad de procesamiento de audio" se usan de manera intercambiable, y en sentido amplio, para indicar un sistema configurado para procesar datos de audio. Los ejemplos de unidades de procesamiento de audio incluyen, de modo no
taxativo, codificadores (por ejemplo, transcodificadores), decodificadores, codees, sistemas de preprocesamiento, sistemas de postprocesamiento y sistemas de procesamiento de flujo de bits (a veces denominados herramientas de procesamiento de flujo de bits).
A lo largo de la presente descripción incluyendo en las reivindicaciones, la expresión "metadatos en estado de procesamiento" (por ejemplo, como en la expresión "metadatos en estado de procesamiento de sonoridad") hace referencia a datos separados y diferentes de datos de audio correspondientes (el contenido de audio de un flujo de datos de audio que también incluye metadatos en estado de procesamiento). Los metadatos en estado de procesamiento están asociados a datos de audio, indica el estado de procesamiento de sonoridad de los datos de audio correspondientes (por ejemplo, qué tipo o tipos de procesamiento ya se han realizado en los datos de audio), y típicamente también indica al menos un rasgo o característica de los datos de audio. La asociación de los metadatos en estado de procesamiento con los datos de audio es sincrónica. Por lo tanto, los metadatos en estado de procesamiento actuales (recibidos o actualizados más recientemente) indican que los datos de audio correspondientes comprenden, de forma
contemporánea, los resultados del o los tipos indicados de procesamiento de datos de audio. En algunos casos, los metadatos en estado de procesamiento pueden incluir historial de procesamiento y/o algunos o todos los parámetros que se usan en y/o derivan de los tipos indicados de procesamiento. De manera adicional, los metadatos en estado de procesamiento pueden incluir al menos un rasgo o característica de los datos de audio correspondientes, que se han computado o extraído de los datos de audio. Los metadatos en estado de procesamiento también pueden incluir otros metadatos que no se relacionan con o derivan de cualquiera de los datos de audio correspondientes. Por ejemplo, se pueden agregar datos de terceros, información de rastreo, identificadores, información específica o estándar, datos de anotación del usuario, datos de preferencia del usuario, etc. mediante una unidad de procesamiento de audio particular para pasar a otras unidades de procesamiento de audio.
A lo largo de la presente descripción incluyendo en las reivindicaciones, la expresión "metadatos en estado de procesamiento de sonoridad" (o "LPS") significa metadatos en estado de procesamiento que indican el estado de procesamiento de sonoridad de los datos de audio correspondientes (por ejemplo, qué tipo o tipos de
procesamiento ya se han realizado en los datos de audio) y típicamente también al menos un rasgo o característica (por ejemplo, sonoridad) de los datos de audio correspondientes. Los metadatos en estado de procesamiento de sonoridad pueden incluir datos (por ejemplo, otros metadatos) que no son (es decir, cuando se consideran solos) metadatos en estado de procesamiento de sonoridad.
A lo largo de la presente descripción incluyendo en las reivindicaciones, la expresión "canal" (o "canal de audio") significa una señal de audio monofónica.
A lo largo de la presente descripción incluyendo en las reivindicaciones, la expresión "programa de audio" significa un conjunto de uno o más a canales de audio y opcionalmente también metadatos asociados (por ejemplo, metadatos que describen una presentación de audio espacial deseada, y/o LPSM, y/o metadatos de límite de programa).
A lo largo de la presente descripción incluyendo en las reivindicaciones, la expresión "metadatos de límite de programa" indica metadatos de un flujo de bits de audio codificado, donde el flujo de bits de audio codificado indica al menos un programa de audio (por ejemplo, dos o más programas de audio), y los metadatos de límite de programa indican la ubicación en el flujo de bits de al menos un
límite (comienzo y/o fin) 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 que indican un programa de audio) pueden incluir metadatos que indican la ubicación (por ejemplo, el comienzo de la trama "N" del flujo de bits, o la ubicación de la muestra "M" de la trama "N" del flujo de bits) del comienzo del programa, y metadatos adicionales que indican la ubicación (por ejemplo, el comienzo de la trama "J" del flujo de bits, o la ubicación de la muestra "K" de la trama "J" del flujo de bits) del fin del programa.
A lo largo de la presente descripción incluyendo en las reivindicaciones, el término "se acopla" o "acoplado" se usa para indicar una conexión ya sea directa o indirecta. Por lo tanto, 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 mediante otros dispositivos y conexiones.
Descripción detallada de las modalidades de la invención De acuerdo con modalidades típicas de la invención, una carga útil de metadatos de sonoridad de programa, denominados metadatos en estado de procesamiento de sonoridad ( "LPSM") y opcionalmente también metadatos de límite de programa están
incrustados en uno o más campos reservados (o ranuras) de segmentos de metadatos de un flujo de bits de audio, que también incluyen datos de audio en otros segmentos (segmentos de datos de audio). Típicamente, al menos un segmento de cada tramo del flujo de bits incluye LPSM, y al menos otro segmento del tramo incluye los datos de audio correspondientes (es decir, datos de audio cuyo estado de procesamiento de sonoridad y sonoridad están indicados por los LPSM). En algunas modalidades, el volumen de datos de los LPSM puede ser lo suficientemente pequeño para ser llevado a cabo sin afectar la tasa de bits asignada para llevar los datos de audio.
La comunicación de metadatos en estado de procesamiento de sonoridad en una cadena de procesamiento de audio es particularmente útil cuando dos o más unidades de procesamiento de audio necesitan trabajar en tándem entre ellas a través de la cadena de procesamiento (o ciclo de vida del contenido). Sin la inclusión de metadatos en estado de procesamiento de sonoridad en un flujo de bits de audio, pueden ocurrir problemas graves de procesamiento tal como las degradaciones de calidad, nivel y espaciales, por ejemplo, cuando se utilizan dos o más codees de audio en la cadena y se aplica la nivelación de volumen asimétrica más de una vez
durante el recorrido del flujo de bits a un dispositivo consumidor de medios (o un punto de reproducción del contenido de audio del flujo de bits).
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 la que uno o más elementos del sistema se pueden configurar de acuerdo con una modalidad de la presente invención. El sistema incluye los siguientes elementos, acoplados juntos tal como se muestra: una unidad de preprocesamiento, un codificador, una unidad de análisis de señal y corrección de metadatos, un transcodificador, un decodificador y una unidad de preprocesamiento. En variaciones en el sistema mostrado, se omite uno o más de los elementos, o se incluyen unidad de procesamiento de datos de audio adicionales.
En algunas implementaciones, la unidad de preprocesamiento de la Figura 1 está configurada para aceptar muestras de PCM (tiempo-dominio) que comprenden contenido de audio como entrada, y para generar muestras de PCM procesadas. El codificador se puede configurar para que acepte las muestras de PCM como entrada y para que genere un flujo de bits de audio codificado (por ejemplo, comprimido) que indica el contenido de audio. Los datos del flujo de bits que indican
el contenido de audio a veces se denominan en la presente "datos de audio". Si el codificador está configurado de acuerdo con una modalidad típica de la presente invención, la salida de flujo de bits de audio del codificador incluye metadatos en estado de procesamiento de sonoridad (y típicamente también otros metadatos, que opcionalmente incluyen metadatos de límite de programa) así como también datos de audio.
La unidad de análisis de señal y corrección de metadatos de la Figura 1 puede aceptar uno o más flujos de bits de audio codificados como entrada y determinar (por ejemplo, validar) si los metadatos en estado de procesamiento en cada flujo de bits de audio codificado son correctos, al realizar el análisis de señal (por ejemplo, usando metadatos de límite de programa en un flujo de bits de audio codificado). Si la unidad de análisis de señal y corrección de metadatos descubre que los metadatos incluidos son inválidos, reemplaza típicamente el o los valores incorrectos con el o los valores correctos obtenidos del análisis de señal. Por lo tanto, cada salida de flujo de bits de audio codificado de la unidad de análisis de señal y corrección de metadatos puede incluir metadatos del estado de procesamiento corregidos (o no corregidos) así como también datos de audio codificados.
El transcodificador de la Figura 1 puede aceptar flujos de bits de audio codificados como entrada, y generar flujos de bits de audio modificados (por ejemplo, codificados de forma diferente) en respuesta (por ejemplo, al decodificar un flujo de entrada y volver a decodificar el flujo decodificado en un formato de codificación diferente). Si el transcodificador está configurado de acuerdo con una modalidad típica de la presente invención, la salida de flujo de bits de audio del codificador incluye metadatos en estado de procesamiento de sonoridad (y típicamente también otros metadatos) así como también datos de audio codificados. Los metadatos pueden haber sido incluidos en el flujo de bits.
El decodificador de la Figura 1 puede aceptar flujos de bits de audio codificados (por ejemplo, comprimidos) como entrada, y flujos de salida (en respuesta) de muestras de audio de PCM decodificadas. Si el decodificador está configurado de acuerdo con una modalidad típica de la presente invención, la salida de un decodificador en funcionamiento normal es o incluye cualquiera de los siguientes elementos:
un flujo de muestras de audio, y un flujo correspondiente de metadatos en estado de procesamiento de sonoridad (y típicamente también otros metadatos) extraídos de un flujo de bits codificados de entrada; o
un flujo de muestras de audio, y un flujo correspondiente de bits de control determinados a partir de metadatos en estado de procesamiento de sonoridad (y típicamente también otros metadatos) extraídos de un flujo de bits codificados de entrada; o
un flujo de muestras de audio, sin un flujo correspondiente de metadatos en estado de procesamiento o bits de control determinados a partir de metadatos en estado de procesamiento. En este último caso, el decodificador puede extraer metadatos en estado de procesamiento de sonoridad (y/u otros metadatos) del flujo de bits codificados de entrada y realizar al menos una operación en los metadatos extraídos (por ejemplo, validación), incluso si no genera los metadatos o bits de control extraídos determinados a partir de este.
Al configurar la unidad de postprocesamiento de la Figura 1 de acuerdo con una modalidad típica de la presente invención, la unidad de postprocesamiento se configura para que acepte un flujo de muestras de audio de PCM decodificadas, y para que realice el postprocesamiento de estas (por ejemplo, nivelación de volumen del contenido de audio) usando metadatos en estado de procesamiento de sonoridad (y típicamente también otros metadatos) recibidos con las
muestras, o bits control (determinados por el decodificador a partir de metadatos en estado de procesamiento de sonoridad y típicamente también otros metadatos) recibidos con las muestras. La unidad de postprocesamiento también está configurada típicamente para reproducir el contenido de audio postprocesado para que uno o más parlantes lo reproduzcan.
Las modalidades típicas de la presente invención proporcionan una cadena de procesamiento de audio mejorada en donde las unidades de procesamiento de audio (por ejemplo, codificadores, decodificadores, transcodificadores, y unidades de pre y postprocesamiento) adaptan su procesamiento respectivo para que se aplique a datos de data de acuerdo con un estado simultáneo de los datos de medios tal como lo indican los metadatos en estado de procesamiento de sonoridad respectivamente recibidos 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 metadatos en estado de procesamiento de sonoridad (y opcionalmente también otros metadatos) así como también datos de audio (por ejemplo, datos de audio codificados). Estos metadatos se podrían haber incluido en el
audio de entrada mediante otro elemento del sistema de la
Figura 1 (u otra fuente, no mostrada en la Figura 1) de acuerdo con una modalidad de la presente invención. La unidad de procesamiento que recibe el audio de entrada (con metadatos) puede configurarse para que realice 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 típicamente también para que incluya los metadatos en el audio de salida, una versión procesada de los metadatos, o bits de control determinados a partir de los metadatos.
Una modalidad típica de la unidad de procesamiento de audio de la invención (o procesador de audio) está configurada para realizar el procesamiento adaptativo de datos de audio en función del estado de los datos de audio tal como lo indican los metadatos en estado de procesamiento de sonoridad correspondientes a los datos de audio. En algunas modalidades, el procesamiento adaptativo es (o incluye) el procesamiento de sonoridad (si los metadatos indican que el procesamiento de sonoridad, o procesamiento similar a este, no se ha realizado todavía en los datos de audio, pero no es (y no incluye) el procesamiento de sonoridad (si los metadatos indican que dicho procesamiento de sonoridad, o
procesamiento similar a este, ya se ha realizado en los datos de audio). En algunas modalidades, el procesamiento adaptativo es o incluye la validación de metadatos (por ejemplo, realizada en una subunidad de validación de metadatos) para garantizar que la unidad de procesamiento de audio realiza otros procesamientos adaptativos de los datos de audio en función del estado de los datos de audio tal como lo indican los metadatos en estado de procesamiento de sonoridad. En algunas modalidades, la validación determina la confiabilidad de los metadatos en estado de procesamiento de sonoridad asociados a (por ejemplo, incluidos en un flujo de bits con) los datos de audio. Por ejemplo, si se valida que los metadatos son confiables, entonces se pueden volver a utilizar los resultados de un tipo de procesamiento realizado previamente y se puede evitar que se realice el mismo tipo de procesamiento de audio. Por otro lado, si se descubre que los metadatos han sido alterados (o son no confiables de otra forma), entonces el tipo de procesamiento de medios supuestamente realizado de forma previa (tal como lo indican los datos no confiables) puede ser repetido por parte de la unidad de procesamiento de audio, y/o se puede realizar otro procesamiento por parte de la unidad de procesamiento de audio en los metadatos y/o los datos de audio. La unidad de
procesamiento de audio también puede estar configurada para que envíe señales a otras unidades de procesamiento de audio posteriores en una cadena de procesamiento de medios mejorada indicando que los metadatos en estado de procesamiento de sonoridad (por ejemplo, presentes en un flujo de bits de medios) son válidos, si la unidad determina que los metadatos en estado de procesamiento son válidos (por ejemplo, en función 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 modalidad de la unidad de procesamiento de audio de la invención. Cualquiera de los componentes o elementos del codificador 100 se pueden implementar como uno o más procesos y/o uno o más circuitos (por ejemplo, ASIC, FPGA u otros circuitos integrados), en hardware, software o una combinación de hardware y software. El codificador 100 comprende framebuffer 110, analizador sintáctico 111, decodificador 101, validador de estado de audio 102, etapa de procesamiento de sonoridad 103, etapa de selección de flujo de audio 104, codificador 105, etapa de relleno/formateado 107, etapa de generación de metadatos 106, subsistema de medición de sonoridad de diálogo 108 y framebuffer 109, conectado tal como se muestra. Típicamente también, el
codificador loo incluye otros elementos procesadores (no mostrados).
El codificador 100 (que es un transcodificador) está configurado para que convierta un flujo de bits de audio de entrada (que, por ejemplo, puede ser uno de un flujo de bits AC-3, un flujo de bits E-AC-3 o un flujo de bits Dolby E) en un flujo de bits de audio de salida codificado (que, por ejemplo, puede ser otro de un flujo de bits AC-3, un flujo de bits E-AC-3 o un flujo de bits Dolby E) que incluye la realización de un procesamiento de sonoridad adaptativo y automatizado usando los metadatos en estado de procesamiento de sonoridad incluidos en el flujo de bits de entrada. Por ejemplo, el codificador 100 se puede configurar para que convierta un flujo de bits Dolby E de entrada (un formato típicamente usado en instalaciones de producción y transmisión pero no en dispositivos de consumidor que reciben programas de audio que han sido trasmitidos en este) en un flujo de bits de audio de salida codificado (adecuado para la transmisión a dispositivos de consumidor) en formato AC-3 o E-AC-3.
El sistema de la Figura 2 también incluye un subsistema de suministro de audio codificado 150 (que almacena y/o suministra la salida de flujos de bits codificados desde el
codificador 100) y decodificador 152. Una salida de flujo de bits de audio codificado de un codificador 100 puede ser almacenada por el subsistema 150 (por ejemplo, en forma de un disco DVD o Blu ray), o transmitida por el subsistema 150 (que puede implementar un enlace o red de transmisión), o se puede tanto almacenar como transmitir mediante el subsistema 150. El decodificador 152 está configurado para que decodifique un flujo de bits de audio codificado (generado por el codificador 100) que es recibido mediante un subsistema 150, que incluye mediante la extracción de los metadatos en estado de procesamiento de sonoridad (LPSM) de cada trama del flujo de bits (y opcionalmente también la extracción de metadatos de límite de programa del flujo de bits), y genere datos de audio decodificados. Típicamente, el decodificador 152 está configurado para que realice el procesamiento de sonoridad adaptativo en los datos de audio decodificados usando los LPSM (y opcionalmente también metadatos de límite de programa), y/o para que envíe los datos de audio decodificados y los LPSM a un postprocesador configurado para que realice el procesamiento de sonoridad adaptativo en los datos de audio decodificados usando los
LPSM (y opcionalmente también metadatos de límite de programa). Típicamente, el decodificador 152 incluye un
buffer que almacena (por ejemplo, de manera no transitoria) el flujo de bits de audio codificado recibidos desde el subsistema 150.
Se configuran varias implementaciones del codificador 100 y decodificador 152 para realizar diferentes modalidades del método de la invención.
El framebuffer 110 es una memoria intermedia acoplada para recibir un flujo de bits de audio de entrada codificado. En funcionamiento, el buffer 110 almacena (por ejemplo, de manera no transitoria) al menos una trama del flujo de bits de audio codificado, y se confirma una secuencia de las tramas del flujo de bits de audio codificado desde el buffer 110 al analizador sintáctico 111.
El analizador sintáctico 111 está acoplado y configurado para que extraiga metadatos en estado de procesamiento de sonoridad (LPSM), y opcionalmente también metadatos de límite de programa (y/u otros metadatos) de cada trama del audio de entrada codificado en la que se incluyen dichos metadatos, para confirmar los LPSM (y opcionalmente también metadatos de límite de programa y/u otros metadatos) en el 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 confirmar los datos de
audio en el decodificador 101. El decodificador 101 del codificador 100 está configurado para decodificar los datos de audio para generar datos de audio decodificados, y para confirmar los datos de audio decodificados en la etapa de procesamiento de sonoridad 103, etapa de selección de flujo de audio 104, subsistema 108, y típicamente también para el validador de estado 102.
El validador de estado 102 está configurado para autenticar y validar los LPSM (y opcionalmente otros metadatos) confirmados en este. En algunas modalidades, los LPSM son (o están incluidos en) un bloque de datos que han sido incluidos en el flujo de bits de entrada (por ejemplo, de acuerdo con una modalidad de la presente invención). El bloque puede comprender un hash criptográfico (un código de autenticación de mensajes basado en hash o "HMAC", por sus siglas en inglés) para procesar los LPSM (y opcionalmente otros metadatos) y/o los datos de audio subyacentes (proporcionados desde el decodificador 101 hasta el validador 102). El bloque de datos puede estar firmado digitalmente en estas modalidades, de modo que una unidad de procesamiento de audio posterior pueda autenticar y validar de forma relativamente fácil los metadatos en estado de procesamiento.
Por 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 digest se puede generar de la siguiente manera para una trama AC- 3:
1. Después que se codifican los datos AC-3 y LPSM, los bytes de datos de la trama (frame_data #1 y frame_data #2 concatenados) y los bytes de datos de LPSM se usan como entrada para la función hash HMAC. Otros datos, que pueden estar presentes dentro de un campo de datos auxiliar, no se toman en cuenta para calcular el digest. Otros datos pueden ser bytes que no pertenecen a datos AC-3 ni a los datos LSPSM. Puede que los bits de protección incluidos en los LPSM no se tomen en cuenta para calcular el digest de HMAC.
2. Después de que se calcula el digest, se escribe en el flujo de bits en un campo reservado para los bits de protección.
3. El último paso de la generación de la trama AC-3 completa es el cálculo de la verificación CRC. Esto se escribe en el extremo final de la trama y se toman en cuenta todos los datos que pertenecen a esta trama, incluyendo los bits de LPSM.
Otros métodos criptográficos, que incluyen de modo no taxativo cualquiera de uno o más métodos criptográficos no
HMAC pueden usarse para la validación de los LPSM (por ejemplo, en el validador 102) para garantizar la transmisión segura y recepción de los LPSM y/o los datos de audio subyacentes. Por ejemplo, la validación (usando dicho método criptográfico) se puede realizar en cada unidad de procesamiento de audio que recibe una modalidad del flujo de bits de audio de la invención para determinar si los metadatos en estado de procesamiento de sonoridad y los datos de audio correspondientes incluidos en el flujo de bits han experimentado (y/o han sido el resultado de) procesamiento de sonoridad específico (tal como lo indican los metadatos) y no han sido modificados después de la realización de dicho procesamiento de sonoridad específico.
El validador de estado 102 confirma los datos de control en la etapa de selección de flujo de audio 104, generador de metadatos 106, y 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 hacia el codificador 105) ya sea:
la salida procesada de forma adaptativa de la etapa de procesamiento de sonoridad 103 (por ejemplo, cuando los LPSM indican que la salida de datos de audio desde decodificador
101 no ha experimentado un tipo especifico de procesamiento de sonoridad, y los bits de control del validador 102 indican que los LPSM son válidos); o
la salida de datos de audio del decodificador 101 (por ejemplo, cuando los LPSM indican que la salida de datos de audio desde decodificador 101 ya han experimentado el tipo específico de procesamiento de sonoridad que sería realizado por la etapa 103, y los bits de control del validador 102 indican que los LPSM son válidos).
La etapa 103 del codificador 100 está configurada para que realice el procesamiento de sonoridad adaptativo en la salida de datos de audio decodificados desde el decodificador 101, en función de una o más características de datos de audio indicadas por los LPSM extraídos por el decodificador 101. La etapa 103 puede ser un procesador adaptativo de sonoridad en tiempo real de transformación-dominio y de control de rango dinámico. La etapa 103 puede recibir entrada de datos del usuario (por ejemplo, valores de sonoridad/rango dinámico objetivo 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 rastreo, identificadores, información específica o estándar, datos de anotación del usuario, datos de preferencia del usuario, etc.) y/u otra
entrada de datos (por ejemplo, de un proceso de huellas digitales), y usar dicha entrada de datos para procesar la salida de datos de audio decodificados desde el decodificador 101. La etapa 103 puede realizar el procesamiento de sonoridad adaptativo en la salida de datos de audio decodificados (salida desde el decodificador 101) que indica un solo programa de audio (tal como lo indican los metadatos de límite de programa extraídos por el analizador sintáctico 111), y puede reinicializar el procesamiento de sonoridad en respuesta a la recepción de los datos de audio decodificados (salida desde el decodificador 101) que indica un programa de audio diferente tal como lo indican los metadatos de límite de programa extraídos por el analizador sintáctico 111.
El subsistema de medición de sonoridad de diálogo 108 puede funcionar para determinar la sonoridad de segmentos de audio decodificados (desde el decodificador 101) que indican un diálogo (u otras emisiones vocales), por ejemplo, usando los LPSM (y/u otros metadatos) extraídos por el decodificador 101, cuando los bits de control del validador 102 indican que los LPSM son inválidos. El funcionamiento del subsistema de medición de sonoridad de diálogo 108 se puede inhabilitar cuando los LPSM indican segmentos de sonoridad de diálogo (u otras emisiones vocales) previamente determinados del audio
decodificado (desde el decodificador 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 los datos de audio decodificados que indican un solo programa de audio (tal como lo indican los metadatos de límite de programa extraídos por el analizador sintáctico 111), y pueden reinicializar la medición en respuesta a la recepción de los datos de audio decodificados que indican un programa de audio diferente tal como lo indican dichos metadatos de límite de programa.
Existen herramientas útiles (por ejemplo, el medidor de sonoridad Dolby LM100) para medir el nivel de diálogo en el contenido de audio de forma fácil y conveniente. Algunas modalidades de la APU de la invención (por ejemplo, etapa 108 del codificador 100) se implementan para que incluya (o para que realice las funciones de) dicha herramienta para medir la sonoridad de diálogo media del contenido de audio de un flujo de bits de audio (por ejemplo, un flujo de bits AC-3 decodificado confirmado para la etapa 108 desde el decodificador 101 del codificador 100).
Si se implementa la etapa 108 para medir la verdadera sonoridad de diálogo media de los datos de audio, la medición puede incluir un paso de aislamiento de segmentos del
contenido de audio que contienen principalmente emisiones vocales. Los segmentos de audio que son principalmente emisiones vocales luego se procesan de acuerdo con un algoritmo de medición de sonoridad. Para los datos de audio decodificados a partir de un flujo de bits AC-3, este algoritmo puede ser una medida estándar de sonoridad ponderada K (de acuerdo con la norma internacional ITU-R BS.1770). De manera alternativa, se pueden utilizar otras medidas de sonoridad (por ejemplo, aquellas basadas en modelos psicoacústicos de sonoridad).
El aislamiento de segmentos de emisiones vocales 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 típicamente proporciona resultados más satisfactorios desde la perspectiva de un oyente. Dado que no todo el contenido de audio contiene diálogo (emisiones vocales), la medida de sonoridad del contenido de audio entero puede proporcionar una aproximación suficiente del nivel de diálogo del audio, de estar presente las emisiones vocales.
El generador de metadatos 106 genera (y/o pasa a través hacia la etapa 107) metadatos que serán incluidos en el flujo de bits codificados mediante la etapa 107 para que el codificador 100 los genere como salida. El generador de
metadatos 106 puede pasar, a través de la etapa 107, los LPSM (y opcionalmente también 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 del validador 102 indican que los LPSM y/u otros metadatos son válidos), o generar nuevos LPSM (y opcionalmente también metadatos de límite de programa y/u otros metadatos) y confirmar los nuevos metadatos en la etapa 107 (por ejemplo, cuando los bits de control del validador 102 indican que los LPSM y/u otros metadatos extraídos por el decodificador 101 son inválidos, o puede confirmar en la etapa 107 una combinación de metadatos extraídos por el decodificador 101 y/o analizador sintáctico 111 y metadatos recién generados. El generador de metadatos 106 puede incluir datos de sonoridad generados por un subsistema 108, y al menos un valor que indica el tipo de procesamiento de sonoridad realizado por el subsistema 108, en los LPSM este confirma en la etapa 107 para la inclusión en el flujo de bits codificados para que el codificador 100 los genere como salida.
El generador de metadatos 106 puede generar bits de protección (que pueden consistir en o incluir un código de autenticación de mensajes basado en hash o "HMAC") útil para
al menos uno de descriptación, autenticación, o validación de los LPSM (y opcionalmente también otros metadatos) que se incluirán en el flujo de bits codificados y/o los datos de audio subyacentes que se incluirán en el flujo de bits codificados. El generador de metadatos 106 puede proporcionar dichos bits de protección en la etapa 107 para la inclusión en el flujo de bits codificados.
En funcionamiento normal, el subsistema de medición de sonoridad de diálogo 108 procesa la salida de datos de audio desde el decodificador 101 para generar, en respuesta a esto, valores de sonoridad (por ejemplo, valores de sonoridad de diálogo con función de puerta o sin función de puerta) y valores de rango dinámico. En respuesta a otros valores, el generador de metadatos 106 puede generar metadatos en estado de procesamiento de sonoridad (LPSM) para la inclusión (mediante reíleño/formateado 107) en el flujo de bits codificados para que el codificador 100 los genere como salida.
De manera adicional, opcional o alternativa, los subsistemas de 106 y/o 108 del codificador 100 puede realizar el análisis adicional de datos de audio para generar metadatos que indican al menos una característica de los datos de audio para la inclusión en el flujo de bits codificados para que la
etapa 107 los genere como salida.
El codificador 105 codifica (por ejemplo, al realizar la compresión de estos) la salida de datos de audio desde la etapa de selección 104, y confirma el audio codificado en la etapa 107 para la inclusión en el flujo de bits codificados para que la etapa 107 los genere como salida.
La etapa 107 multiplexa el audio codificado desde el codificador 105 y los metadatos (incluyendo los LPSM) desde el generador 106 para generar el flujo de bits codificados para que la etapa 107 los genere como salida, preferentemente de modo que el flujo de bits codificados tenga el formato especificado por una modalidad preferida de la presente invención.
El framebuffer 109 es una memoria intermedia que almacena (por ejemplo, de manera no transitoria) al menos una trama de la salida del flujo de bits de audio codificado de la etapa 107, y entonces se reconfirma una secuencia de las tramas del flujo de bits de audio codificado desde el buffer 109 como salida de datos desde el codificador 100 al sistema de suministro 150.
Los LPSM generados por el generador de metadatos 106 e incluido en el flujo de bits codificados por la etapa 107 indica el estado de procesamiento de sonoridad de los datos
de audio correspondientes (por ejemplo, qué tipo o tipos de procesamiento de sonoridad se han realizado en los datos de audio) y sonoridad (por ejemplo, sonoridad de diálogo medida, sonoridad con función de puerta y/o sin función de puerta, y/o rango dinámico) de los datos de audio correspondientes.
En la presente, "función de puerta" de sonoridad y/o mediciones de nivel realizadas en los datos de audio hace referencia a un nivel específico o umbral de sonoridad donde el o los valores computados que exceden el umbral están incluidos en la medición final (por ejemplo, ignorando los valores de sonoridad a corto plazo por debajo de -60 dBFS en los valores medidos finales). Función de puerta en un valor absoluto se refiere a un nivel o sonoridad fijo, mientras función de puerta en un valor relativo se refiere a un valor que depende de un valor de medición actual "sin función de puerta".
En algunas implementaciones del codificador 100, el flujo de bits codificados almacenado en la memoria intermedia 109 (y generado como salida hacia el sistema de suministro 150) es un flujo de bits AC-3 o un flujo de bits E-AC-3, y comprende segmentos de datos de audio (por ejemplo, los segmentos AB0-AB5 de la trama mostrada en la Figura 4) y segmentos de metadatos, donde los segmentos de datos de audio indican
datos de audio, y cada uno de al menos algunos de los segmentos de metadatos incluye metadatos en estado de procesamiento de sonoridad (LPSM). La etapa 107 inserta los LPSM (y opcionalmente también metadatos de límite de programa) en el flujo de bits en el siguiente formato. Cada uno de los segmentos de metadatos que incluyen LPSM (y opcionalmente también metadatos de límite de programa) está incluido en un segmento de bits sobrantes del flujo de bits (por ejemplo, segmento de bits sobrantes "W" tal como se muestra en la Figura 4 o Figura 7), o un campo "addbsi" del segmento de información del flujo de bits ("BSI") de una trama del flujo de bits, o en un campo de datos auxiliar (por ejemplo, el segmento AUX mostrado en la Figura 4 o Figura 7) 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 LPSM, y si la trama incluye dos segmentos de metadatos, uno puede estar presente en el campo addbsi de la trama y el otro en el campo AUX de la trama. En algunas modalidades, cada segmento de metadatos que incluye LPSM incluye un segmento de carga útil de LPSM (o contenedor) que tiene el siguiente formato:
un encabezado (que típicamente incluye 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, longitud, período, conteo, y valores de asociación de subflujo de LPSM indicados en la Tabla 2 a continuación); y
después del encabezado,
al menos un valor de indicación de diálogo (por ejemplo, parámetro "Canales de Diálogo" de la Tabla 2) que indica si los datos de audio correspondientes indican diálogo o no indican diálogo (por ejemplo, qué canales de datos de audio correspondiente indican diálogo);
al menos un valor de cumplimiento de regulación de sonoridad (por ejemplo, parámetro "Tipo de Regulación de Sonoridad" de la Tabla 2) que indica si los datos de audio correspondientes cumplen con un conjunto indicado de regulaciones de sonoridad;
al menos un valor de procesamiento de sonoridad (por ejemplo, uno o más de los parámetros "Indicador de Corrección de Sonoridad con Función de Puerta de Diálogo", "Tipo de Corrección de Sonoridad" de la Tabla 2) que indica al menos un tipo de procesamiento de sonoridad que se ha realizado en los datos de audio correspondientes; y
al menos un valor de sonoridad (por ejemplo, uno o más de los parámetros "Sonoridad con Función de Puerta relativa a ITU",
"Sonoridad con Función de Puerta de Emisiones vocales ITU", "Sonoridad de 3s a Corto Plazo ITU (EBU 3341)" y "Pico Verdadero" de la Tabla 2) que indica al menos una característica de sonoridad (por ejemplo, sonoridad pico o promedio) de los datos de audio correspondientes.
En algunas modalidades, cada segmento de metadatos que contiene LPSM y los metadatos de límite de programa contienen un encabezado nuclear (y opcionalmente también elementos nucleares adicionales) y después del encabezado nuclear (o el encabezado nuclear y otros elementos nucleares) un segmento de carga útil de LPSM (o contenedor) que tiene el siguiente formato:
un encabezado, típicamente que incluye al menos un valor de identificación (por ejemplo, versión de formato, longitud, período, conteo, y valores de asociación de subflujo de LPSM, como se indican en la Tabla 2 de la presente), y
después del encabezado, los LPSM y los metadatos de límite de programa. Los metadatos de límite de programa pueden incluir un conteo de tramas de límite de programa y un valor de código (por ejemplo, un valor "offset_exist ") que indica si la trama incluye solo un conteo de trama de límite de programa o tanto un conteo de trama de límite de programa y un valor offset), y (en algunos casos) un valor offset.
En algunas implementaciones, cada uno de los segmentos de metadatos insertados por la etapa 107 en un segmento de bits sobrantes o un campo "addbsi" o un campo de datos auxiliares de una trama del flujo de bits tiene el siguiente formato: un encabezado nuclear (que típicamente incluye una palabra de sincronización que identifica el inicio del segmento de metadatos seguido por valores de identificación, por ejemplo, la versión, longitud, y período, conteo de elemento extendido, y valores de asociación de subflujo del elemento nuclear indicados en la Tabla 1 a continuación); y
después del encabezado nuclear, al menos un valor de protección (por ejemplo, el digest de HMAC y valores de huellas digitales de audio de la Tabla 1) útil para al menos una de descriptación, autenticación, o validación de al menos uno de metadatos en estado de procesamiento de sonoridad o de los datos de audio correspondientes); y
y también después del encabezado nuclear, si el segmento de metadatos incluye LPSM, identificación de carga útil de LPSM ("ID") y valores de tamaño de carga útil de LPSM que identifican los metadatos siguientes como una carga útil de LPSM e indican el tamaño de la carga útil de LPSM.
El segmento de carga útil (o contenedor) de LPSM (preferentemente que tiene el formato antes especificado)
sigue a la ID de la carga útil de LPSM y los valores de tamaño de carga útil de LPSM.
En algunas modalidades, cada uno de los segmentos de metadatos en el campo de datos auxiliares (o campo "addbsi") de una trama tiene tres niveles de estructura:
una estructura de nivel alto, que incluye un indicador que indica si el campo de datos auxiliares (o addbsi) incluye metadatos, al menos un valor de ID que indica qué tipo de metadatos está presente, y típicamente también un valor que indica cuántos bits de metadatos (por ejemplo, de cada tipo) están presentes (si hay metadatos presentes). Un tipo de metadatos que podría estar presente es LPSM, otro tipo de metadatos que podría estar presente es metadatos de límite de programa y otro tipo de metadatos que podría estar presente es de metadatos de investigación de medios (por ejemplo, metadatos de Investigación de Medios de Nielsen);
una estructura de nivel intermedio, que comprende un elemento nuclear para cada tipo de metadatos identificado (por ejemplo, encabezado nuclear, valores de protección, e ID de carga útil de LPSM y valores de tamaño de LPSM, como se mencionó anteriormente, para cada tipo identificado de metadatos); y
una estructura de nivel bajo, que comprende cada carga útil para un elemento nuclear (por ejemplo, una carga útil de LPSM, si el elemento nuclear identifica que una está presente, y/o una carga útil de metadatos de otro tipo, si el elemento nuclear identifica que una está presente).
Se pueden anidar los valores de datos en dicha estructura de tres niveles. Por ejemplo, los valores de protección para una carga útil y/u otra carga útil de metadatos identificados por un elemento nuclear se pueden incluir después de cada carga útil identificada por el elemento nuclear (y por lo tanto, después del encabezado nuclear del elemento nuclear). En un ejemplo, un encabezado nuclear podría identificar una carga útil de LPSM y otra carga útil de metadatos, ID de carga útil y valores de tamaño de carga útil para la primera carga útil (por ejemplo, la carga útil de LPSM) podría seguir el encabezado nuclear, la primera carga útil podría seguir los valores de tamaño e ID, la ID de carga útil y el valor de tamaño de carga útil para la segunda carga útil podría seguir la primera carga útil, la segunda carga útil podría seguir estas ID y valores de tamaño, y bits de protección para ambas cargas útiles (o para los valores de elementos nucleares y ambas cargas útiles) podría seguir la última carga útil.
En algunas modalidades, si el decodificador 101 recibe un flujo de bits de audio generado de acuerdo con una modalidad de la invención con hash criptográfico, el decodificador se configura para analizar sintácticamente y recuperar el hash criptográfico de un bloque de datos determinados a partir de los flujos de bits, dicho bloque que comprende metadatos en estado de procesamiento de sonoridad (LPSM) y opcionalmente también metadatos de límite de programa. El validador 102 puede usar el hash criptográfico para validar el flujo de bits recibido y/o metadatos asociados. Por ejemplo, si el validador 102 encuentra que los LPSM son válidos en función de una coincidencia de valor entre un hash criptográfico de referencia y el hash criptográfico recuperado del bloque de datos, después puede inhabilitar la operación del procesador 103 en los datos de audio correspondientes y provocar que la etapa de selección 104 pase a través (incambiada) de los datos de audio. De manera adicional, opcionalmente o alternativamente, otros tipos de téenicas criptográficas se pueden usar en vez 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 decodificador 101) que una
unidad de post/preprocesamiento ha realizado un tipo de procesamiento de sonoridad en los datos de audio a codificar (en los elementos 105, 106 y 107) y por lo tanto, puede crear (en el generador 106) metadatos en estado de procesamiento de sonoridad que incluye los parámetros específicos utilizados en y/o derivados del procesamiento de sonoridad realizado anteriormente. En algunas impleraentaciones, el codificador 100 puede crear (e incluir en la salida de flujos de bits codificados en este) metadatos en estado de procesamiento que indican el historial de procesamiento en el contenido de audio siempre que el codificador detecte los tipos de procesamiento que han sido realizados en el contenido de audio.
La Figura 3 es un diagrama de bloques de un decodificador (200) que es una modalidad de la unidad de procesamiento de audio de la invención, y de un postprocesador (300) acoplado a este. El postprocesador (300) también es una modalidad de la unidad de procesamiento de audio de la invención. Cualquiera de los componentes o elementos del decodificador 200 y postprocesador 300 se pueden implementar como uno o más procesos y/o uno o más circuitos (por ejemplo, ASIC, FPGA u otros circuitos integrados), en hardware, software o una combinación de hardware y software. El decodificador 200
comprende el framebuffer 201, analizador sintáctico 205, decodificador de audio 202, etapa de validación de estado de audio (validador) 203 y etapa de generación de bits de control 204, conectado de la manera que se muestra. Típicamente además, el decodificador 200 incluye otros elementos de procesamiento (que no se muestran).
El framebuffer 201 (una memoria intermedia) almacena (por ejemplo, de manera no transitoria) al menos una trama del flujo de bits de audio codificado recibido por el decodificador 200. Una secuencia de las tramas del flujo de bits de audio codificado se confirma desde el buffer 201 hasta el analizador sintáctico 205.
El analizador sintáctico 205 está acoplado y configurado para extraer los metadatos en estado de procesamiento de sonoridad (LPSM) y opcionalmente también metadatos de límite de programa, y otros metadatos de cada trama del audio de entrada codificado, para confirmar al menos los LPSM (y metadatos de límite de programa si alguno se extrae) al validador de estado de audio 203 y etapa 204, para confirmar los LPSM (y opcionalmente también metadatos de límite de programa) como salida (por ejemplo, al postprocesador 300) para extraer datos de audio del audio de entrada codificado, y para confirmar los datos de audio extraídos al
decodificador 202.
La entrada de flujo de bits de audio codificado al decodificador 200 puede ser uno de un flujo de bits AC-3, un flujo de bits E-AC-3, o un flujo de bits Dolby E.
El sistema de la Figura 3 también incluye un postprocesador
300. El postprocesador 300 comprende un framebuffer 301 y otros elementos de procesamiento (que no se muestran) que incluyen al menos un elemento de procesamiento acoplado al buffer 301. El framebuffer 301 almacena (por ejemplo, de manera no transitoria) al menos una trama del flujo de bits de audio decodificado recibido por el postprocesador 300 del decodificador 200. Los elementos de procesamiento del postprocesador 300 se acoplan y configuran para recibir y procesar de manera adaptativa una secuencia de las tramas de la salida de flujo de bits de audio decodificado del buffer
301, usando salida de metadatos (incluyendo valores de LPSM) del decodificador 202 y/o salida de bits de control de la etapa 204 del decodificador 200. Típicamente, el postprocesador 300 está configurado para realizar procesamiento de sonoridad adaptativo en los datos de audio decodificados usando los valores de LPSM y opcionalmente también metadatos de límite de programa (por ejemplo, en función del estado de procesamiento de sonoridad, y/o una o
más características de datos de audio, indicada por LPSM para los datos de audio que indican un programa de audio único).
Se configuran varias implementaciones del decodificador 200 y del postprocesador 300 para realizar diferentes modalidades del método de la invención.
El decodificador de audio 202 del decodificador 200 está configurado para decodificar los datos de audio extraídos por el analizador sintáctico 205 para generar datos de audio decodificados y para confirmar los datos de audio decodificados como salida (por ejemplo, al postprocesador 300).
El validador de estado 203 está configurado para autenticar y validar los LPSM (y opcionalmente otros metadatos) confirmados en este. En algunas modalidades, los LPSM son (o están incluidos en) un bloque de datos que ha sido incluido en el flujo de bits de entrada (por ejemplo, de acuerdo con una modalidad de la presente invención). El bloque puede comprender un hash criptográfico (un código de autenticación de mensajes basado en hash o "HMAC") para procesar los LPSM (y opcionalmente también otros metadatos) y/o los datos de audio subyacentes (proporcionados desde el analizador sintáctico 205 y/o decodificador 202 hasta el validador 203). El bloque de datos puede estar firmado digitalmente en estas
modalidades, de modo que una unidad de procesamiento de audio posterior pueda autenticar y validar de forma relativamente fácil los metadatos en estado de procesamiento.
Otros métodos criptográficos, que incluyen de modo no taxativo cualquiera de uno o más métodos criptográficos no HMAC pueden usarse para la validación de los LPSM (por ejemplo, en el validador 203) para garantizar la transmisión segura y recepción de los LPSM y/o los datos de audio subyacentes. Por ejemplo, la validación (usando dicho método criptográfico) se puede realizar en cada unidad de procesamiento de audio que recibe una modalidad del flujo de bits de audio de la invención para determinar si los metadatos en estado de procesamiento de sonoridad y los datos de audio correspondientes incluidos en el flujo de bits han experimentado (y/o han sido el resultado de) procesamiento de sonoridad específico (tal como lo indican los metadatos) y no han sido modificados después de la realización de dicho procesamiento de sonoridad específico.
El validador de estado 203 confirma los datos de control para el generador de bits de control 204, y/o confirma los datos de control como salida (por ejemplo, al postprocesador 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), etapa 204 puede generar (y confirmar al postprocesador 300) si:
Los bits de control que indican que la salida de datos de audio decodificada del decodificador 202 ha experimentado un tipo de procesamiento de sonoridad específico (cuando los LPSM indican que la salida de datos de audio data desde decodificador 202 ha experimentado el tipo específico de procesamiento de sonoridad, y los bits de control del validador 203 indican que los LPSM son válidos); o
los bits de control que indican que la salida de datos de audio decodificado del decodificador 202 deben experimentar un tipo específico de procesamiento de sonoridad (por ejemplo, cuando los LPSM indican que la salida de datos de audio del decodificador 202 no han experimentado el tipo específico de procesamiento de sonoridad, o cuando los LPSM indican que la salida de datos de audio del decodificador 202 han 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).
De manera alternativa, el decodificador 200 confirma los metadatos extraídos por el decodificador 202 del flujo de bits de entrada, y los LPSM (y opcionalmente también
metadatos de límite de programa) extraídos por el analizador sintáctico 205 desde el flujo de bits de entrada al postprocesador 300, y el postprocesador 300 realiza procesamiento de sonoridad en los datos de audio decodificados usando los LPSM (y opcionalmente también metadatos de límite de programa) o realiza validación de los LPSM y después realiza procesamiento de sonoridad en los datos de audio decodificados utilizando los LPSM (y opcionalmente también metadatos de límite de programa) si la validación indica que los LPSM son válidos.
En algunas modalidades, si el codificador 200 recibe un flujo de bits de audio generado de acuerdo con una modalidad de la invención con hash criptográfico, el codificador se configura para analizar sintácticamente y recuperar el hash criptográfico de un bloque de datos determinado a partir de los flujos de bits, dicho bloque que comprende metadatos en estado de procesamiento de sonoridad (LPSM). El validador 203 puede usar el hash criptográfico para validar el flujo de bits recibido y/o metadatos asociados. Por ejemplo, si el validador 203 encuentra que los LPSM son válidos en función de una coincidencia de valor entre un hash criptográfico de referencia y el hash criptográfico recuperado del bloque de datos, después puede enviar una señal a una unidad de
procesamiento de audio posterior (por ejemplo, postprocesador 300, que puede ser o incluir una unidad de nivelación de volumen) para que pase a través (incambiado) los datos de audio del flujo de bits. De manera adicional, opcionalmente o alternativamente, otros tipos de téenicas criptográficas se pueden usar en vez de un método basado en un hash criptográfico.
En algunas implementaciones del decodificador 200, el flujo de bits codificado (y almacenado en la memoria 201) es un flujo de bits AC-3 o un flujo de bits E-AC-3, y comprende segmentos de datos de audio (por ejemplo, los segmentos AB0-AB5 de la trama mostrada en la Figura 4) y segmentos de metadatos, donde los segmentos de datos de audio indican datos de audio, y cada uno de al menos algunos de los segmentos de metadatos incluye metadatos en estado de procesamiento de sonoridad (LPSM) y opcionalmente también metadatos de límite de programa. La etapa de decodificador 202 (y/o analizador sintáctico 205) está configurada para extraer de los LPSM de flujo de bits (y opcionalmente también metadatos de límite de programa) que tienen el siguiente formato. Cada uno de los segmentos de metadatos que incluyen LPSM (y opcionalmente también metadatos de límite de programa) está incluido en un segmento de bits sobrantes de
una trama de flujo de bits, o un campo "addbsi" del segmento de información del flujo de bits ("BSI") de una trama del flujo de bits, o en un campo de datos auxiliar (por ejemplo, el segmento AUX mostrado en la Figura 4) al final de una trama del flujo de bits. Una trama del flujo de bits puede incluir uno o más segmentos de metadatos, cada uno de los cuales puede incluir LPSM, y si la trama incluye dos segmentos de metadatos, uno puede estar presente en el campo addbsi de la trama y el otro en el campo AUX de la trama. En algunas modalidades, cada segmento de metadatos que incluye LPSM incluye un segmento de carga útil de LPSM (o contenedor) que tiene el siguiente formato:
un encabezado (que típicamente incluye una palabra de sincronización que identifica el inicio de la carga útil de LPSM seguida por valores de identificación, por ejemplo, la versión de formato, longitud, período, conteo, y valores de asociación de subflujo de LPSM indicados en la Tabla 2 a continuación); y
después del encabezado,
al menos un valor de indicación de diálogo (por ejemplo, parámetro "Canales de Diálogo" de la Tabla 2) que indica si los datos de audio correspondientes indican diálogo o no indican diálogo (por ejemplo, qué canales de datos de audio
correspondiente indican diálogo);
al menos un valor de cumplimiento de regulación de sonoridad (por ejemplo, parámetro "Tipo de Regulación de Sonoridad" de la Tabla 2) que indica si los datos de audio correspondientes cumplen con un conjunto indicado de regulaciones de sonoridad;
al menos un valor de procesamiento de sonoridad (por ejemplo, uno o más de los parámetros "Indicador de Corrección de Sonoridad con Función de Puerta de Diálogo", "Tipo de Corrección de Sonoridad" de la Tabla 2) que indica al menos un tipo de procesamiento de sonoridad que se ha realizado en los datos de audio correspondientes; y
al menos un valor de sonoridad (por ejemplo, uno o más de los parámetros "Sonoridad con Función de Puerta relativa a ITU", "Sonoridad con Función de Puerta de Discurso ITU", "Sonoridad de 3s a Corto Plazo ITU (EBU 3341)" y "Pico Verdadero" de la Tabla 2) que indica al menos una característica de sonoridad (por ejemplo, sonoridad pico o promedio) de los datos de audio correspondientes.
En algunas modalidades, cada segmento de metadatos que contiene LPSM y los metadatos de límite de programa contienen un encabezado nuclear (y opcionalmente también elementos nucleares adicionales) y después del encabezado nuclear (o el
encabezado nuclear y otros elementos nucleares) un segmento de carga útil de LPSM (o contenedor) que tiene el siguiente formato:
un encabezado, típicamente que incluye al menos un valor de identificación (por ejemplo, versión de formato, longitud, período, conteo, y valores de asociación de subflujo de LPSM, como se indican en la Tabla 2 a continuación), y
después del encabezado, los LPSM y los metadatos de límite de programa. Los metadatos de límite de programa pueden incluir un conteo de tramas de límite de programa y un valor de código (por ejemplo, un valor "offset_exist ") que indica si la trama incluye solo un conteo de trama de límite de programa o tanto un conteo de trama de límite de programa como un valor offset), y (en algunos casos) un valor offset. En algunas implementaciones, el analizador sintáctico 205 (y/o etapa de decodificador 202) está configurado para extraer, desde un segmento de bits sobrantes o un campo "addbsi" o un campo de datos auxiliares de una trama del flujo de bits, cada segmento de metadatos tiene el siguiente formato:
un encabezado nuclear (que típicamente incluye una palabra de sincronización que identifica el inicio del segmento de metadatos seguido por al menos un valor de identificación,
por ejemplo, la versión, longitud, y período, conteo de elemento extendido, y valores de asociación de subflujo del elemento nuclear indicados en la Tabla 1 a continuación); y después del encabezado nuclear, al menos un valor de protección (por ejemplo, el digest de HMAC y valores de huellas digitales de audio de la Tabla 1) útil para al menos una de descriptación, autenticación, o validación de al menos uno de metadatos en estado de procesamiento de sonoridad o de los datos de audio correspondientes); y
y también después del encabezado nuclear, si el segmento de metadatos incluye LPSM, identificación de carga útil de LPSM ("ID") y valores de tamaño de carga útil de LPSM que identifican los metadatos siguientes como una carga útil de LPSM e indican el tamaño de la carga útil de LPSM.
El segmento de carga útil (o contenedor) de LPSM (preferentemente que tiene el formato antes especificado) sigue a la ID de la carga útil de LPSM y los valores de tamaño de carga útil de LPSM.
Más en general, el flujo de bits de audio codificado generados por modalidades preferidas de la invención tiene una estructura que proporciona un mecanismo para etiquetar elementos de metadatos y subelementos como (elementos opcionales) expandidos u (obligatorios) nucleares. Esto
permite que la tasa de datos del flujo de bits (incluyendo sus metadatos) aumente a lo largo de varias aplicaciones. Los elementos nucleares (obligatorios) de la sintaxis de flujo de bits preferida deberían ser capaces de señalar que los elementos expandidos (opcionales) asociados con el contenido de audio están presentes (dentro de banda) y/o en una ubicación remota (fuera de banda).
Se requiere que los elementos nucleares estén presentes en cada trama del flujo de bits. Algunos subelementos de los elementos nucleares son opcionales y pueden estar presentes en cualquier combinación. No se requiere que los elementos expandidos estén presentes en cada trama (para limitar la sobre carga de tasa de bits). Por lo tanto, los elementos expandidos pueden estar presentes en algunas tramas y no en otras. Algunos subelementos de un elemento expandido son opcionales y pueden estar presentes en cualquier combinación, mientras que algunos subelementos 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 modalidades, un flujo de bits de audio codificado que comprende una secuencia de segmentos de datos de audio y segmentos de metadatos se genera (por ejemplo, por una unidad de procesamiento de audio que plasma
invención). Los segmentos de datos de audio indican los datos de audio, cada uno de al menos algunos de los segmentos de metadatos incluye metadatos en estado de procesamiento de sonoridad (LPSM) y opcionalmente también metadatos de límite de programa, y los segmentos de datos de audio se transmiten simultáneamente con una división de tiempo con los segmentos de metadatos. En modalidades preferidas en esta clase, cada uno de los segmentos de metadatos tienen un formato preferido que se describirá en la presente.
En un formato preferido, el flujo de bits codificado es un flujo de bits AC-3 o un flujo de bits E-AC-3 y cada uno de los segmentos de metadatos que incluye LPSM está incluido (por ejemplo, por la etapa 107 de una implementación preferida del codificador 100) como una información de flujo de bits adicional en el campo "addbsi" (que se muestra 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 de datos auxiliares de una trama del flujo de bits o en un segmento de bits sobrantes de una trama del flujo de bits. En el formato preferido, cada una de las tramas incluye un elemento nuclear que tiene el formato que se muestra en la Tabla 1 a continuación, en el campo addbsi (o segmento de bits sobrante) de la trama:
Tabla 1
En el formato preferido, cada uno de los campos addbsi (o datos auxiliares) o segmentos de bits sobrantes que contienen LPSM contienen un encabezado nuclear (y opcionalmente también elementos nucleares adicionales) y después del encabezado nuclear (o el encabezado nuclear y otros elementos nucleares), los siguientes valores de LPSM (parámetros):
una ID de carga útil (que identifica los metadatos como LPSM) después de los valores de elementos nucleares (por ejemplo,
como se especifican en la Tabla 1);
un tamaño de carga útil (que indica el tamaño de la carga útil de LPSM) después de la ID de carga útil; y
datos de LPSM (después de la ID de carga útil y el valor de tamaño de carga útil) que tiene el formato como se indica en la siguiente tabla (Tabla 2):
Tabla 2
En otro formato preferido de un flujo de bits codificado generado de acuerdo con la invención, el flujo de bits es un flujo de bits AC-3 o un flujo de bits E-AC-3, y se incluye cada uno de los segmentos de metadatos que incluye LPSM (y opcionalmente también metadatos de límite de programa) (por ejemplo, mediante la etapa 107 de una implementación preferida del codificador 100) en cualquiera de: un segmento de bits sobrante de una trama del flujo de bits; o un campo "addbsi" (que se muestra en la Figura 6) del segmento de Información de Flujo de Bits ("BSI") de una trama del flujo de bits; o un campo de datos auxiliares (por ejemplo, el segmento AUX que se muestra en la Figura 4) en el final de una trama del flujo de bits. Una trama puede incluir uno o más segmentos de metadatos, cada uno de los cuales incluye
LPSM, y si la trama incluye dos segmentos de metadatos, uno puede estar presente en el campo addbsi de la trama y el otro en el campo AUX de la trama. Cada segmento de metadatos que incluye LPSM tiene el formato especificado anteriormente con referencia a las Tablas 1 y 2 a continuación (es decir, incluye los elementos nucleares especificados en la Tabla 1, seguido de la ID de carga útil (que identifica los metadatos como LPSM) y los valores de tamaño de carga útil especificados anteriormente, seguido por carga útil (datos de los LPSM que tienen el formato que se indica en la Tabla 2). En otro formato preferido, el flujo de bits codificado es un flujo de bits de Dolby E, y cada uno de los segmentos de metadatos que incluye LPSM (y opcionalmente también metadatos de límite de programa) está en las primeras ubicaciones de muestras N del intervalo de banda de guarda de Dolby E. Un flujo de bits Dolby E que incluye tal segmento de metadatos que incluye LPSM preferentemente incluye un valor que indica la longitud de carga útil de LPSM señalada en la palabra Pd del preámbulo SMPTE 337M (la tasa de repetición de palabra SMPTE 337M Pa permanece preferentemente idéntica a la tasa de trama de video asociada).
En un formato adicional, donde el flujo de bits codificado es un flujo de bits E-AC-3, se incluye cada uno de los segmentos
de metadatos que incluye LPSM (y opcionalmente también metadatos de límite de programa) (por ejemplo, por la etapa 107 de una implementación preferida del codificador 100) como una información de flujo de bits adicional en un segmento de bits sobrantes 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 codificar un flujo de bits E-AC-3 con LPSM en este formato preferido:
1. durante la generación de un flujo de bits E-AC-3, mientras que el codificador E-AC-3 (que inserta los valores de LPSM en el flujo de bits) está "activo", para cada trama (trama sincronizada) generada, el flujo de bits debe incluir un bloque de metadatos (que incluye LPSM) llevados en el campo addbsi (o segmento de bits sobrantes) de la trama. Los bits requeridos para llevar el bloque de metadatos no debe aumentar la tasa de bits del codificador (longitud de trama);
2. Todos los bloques de metadatos (que contienen LPSM) deben contener la siguiente información: loudness_correction_type_flag: donde '1' indica que la sonoridad de los datos de audio correspondientes se corrigió antes del codificador, y '0' indica que la sonoridad se corrigió con un corrector de sonoridad incrustado en el
codificador (por ejemplo, procesador de sonoridad 103 del codificador 100 de la Figura 2);
speech_channel: indica cuáles canales de fuente contienen emisiones vocales (en los 0,5 s anteriores). Si no se detectan emisiones vocales, esto se debe indicar; speech_loudness: indica la sonoridad de las emisiones vocales integradas de cada canal de audio correspondiente que contiene emisiones vocales (en los 0,5 s anteriores); ITU_loudness: indica la sonoridad de ITU BS.1770-3 integrada de cada canal de audio correspondiente; y
ganancia: las ganancias de compuesto de sonoridad para invertir en un decodificador (para demostrar la capacidad de inversión);
3. Mientras que el codificador E-AC-3 (que inserta los valores de LPSM en el flujo de bits) está "activo" y recibe una trama de AC-3 con un indicador de 'confianza', se debería evitar el controlador de sonoridad en el codificador (por ejemplo, el procesador de sonoridad 103 del codificador 100 de la Figura 2). El dialnorm de fuente 'confiable' y los valores de DRC deberían pasarse a través (por ejemplo, por el generador 106 del codificador 100) al componente de codificador E-AC-3 (por ejemplo, etapa 107 del codificador 100). La generación de bloque de LPSM continúa y
loudness_correction_type_flag se fija en 'I'. La secuencia de desviación de controlador de sonoridad se debe sincronizar al inicio de la trama AC-3 decodificada donde aparece el indicador de 'confianza'. La secuencia de desviación de controlador de sonoridad se debe implementar de la siguiente manera: el control de leveler_amount se disminuye de un valor de 9 a un valor de 0 sobre 10 períodos de bloque de audio (es decir, 53,3 ms) y el control leveler_back_end_meter se coloca en el modo de desviación (esta operación debe dar como resultado una transición sin interrupciones). El término desviación "confiable" del nivelador implica que el valor de dialnorm del flujo de bits de fuente también se reutiliza en la salida del codificador (por ejemplo, si el flujo de bits de fuente "confiable" tiene un valor de dialnorm de -30 entonces la salida del codificador debe utilizar -30 para el valor de dialnorm de salida);
4. Mientras que el codificador E-AC-3 (que inserta los valores de LPSM en el flujo de bits) está "activo" y recibe una trama de AC-3 sin el indicador de 'confianza', el controlador de sonoridad insertado en el codificador (por ejemplo, el procesador de sonoridad 103 del codificador 100 de la Figura 2) debería estar activo. La generación de bloque de LPSM continúa y loudness_correction_type_flag se fija en
'O'. La secuencia de activación de controlador de sonoridad se debe sincronizar al inicio de la trama AC-3 decodifica donde desaparece el indicador de 'confianza'. La secuencia de activación de controlador de sonoridad se debe implementar de la siguiente manera: el control de leveler_amount se incrementa de un valor de 0 a un valor de 9 sobre 1 período de bloque de audio. (es decir, 5,3 ms) y el control leveler_back_end_meter se coloca en el modo 'activo' (esta operación debe resultar en una transición sin interrupciones e incluir una reinicialización de integración back_end_meter); y
5. durante la codificación, una interfaz de usuario gráfica (GUI, por sus siglas en inglés) debe indicar a un usuario los siguientes parámetros: "Programa de audio de entrada: [Confiable/No confiable] " - 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 de Tiempo Real: [Habilitado/Inhabilitado]" - el estado de este parámetro está basado en si este controlador de sonoridad incrustado en el codificador está activo.
Cuando se decodifica un flujo de bits AC-3 o E-AC-3 que tiene LPSM (en el formato preferido) incluido en un segmento de bits sobrantes, o el campo "addbsi" del segmento de
Información de Flujo de bits ("BSI"), de cada una de las tramas del flujo de bits, el decodificador debe analizar sintácticamente los datos de bloque de LPSM (en el segmento de bits sobrantes o campo de addbsi) y pasar todos los valores LPSM extraídos a una interfaz de usuario gráfica (GUI). El conjunto de valores de LPSM extraídos se actualizan en cada trama.
En otro formato preferido de un flujo de bits codificado generado de acuerdo con la invención, el flujo de bits codificado es un flujo de bits AC-3 o un flujo de bits E-AC-3, y se incluyen cada uno de los segmentos de metadatos que incluyen LPSM (por ejemplo, mediante la etapa 107 de una implementación preferida del codificador 100) en un segmento de bits sobrantes, o en un segmento Aux, o como una información de flujo de bits adicional en el campo "addbsi" (que se muestra 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 en el formato descrito anteriormente con referencia a las Tablas 1 y 2), cada uno de los campos addbsi (o Aux o bit sobrante) que contiene LPSM contiene los siguientes valores de LPSM:
los elementos nucleares especificados en la Tabla 1, seguido de la ID de carga útil (que identifica los metadatos como
LPSM) y valores de tamaño de carga útil, seguido de carga útil (datos de LPSM) que tiene el siguiente formato (similar a los elementos obligatorios indicados en la Tabla 2 anterior):
versión de 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álogos hablados. La ubicación de los bits del campo de dialchan puede ser de la siguiente manera: bit 0, que indica la presencia de diálogo en el canal izquierdo, se almacena en el bit más significativo del campo de dialchan; y bit 2, que indica la presencia de diálogo en el canal central, se almacena en el bit menos significativo del campo de dialchan.
Cada bit del campo de dialchan se fija en 11' si el canal correspondiente contiene diálogo hablado durante los 0,5 segundos anteriores del programa;
loudregtyp: un campo de 4 bits que indica con qué norma de regulación de sonoridad cumple la sonoridad del programa. Fijar el campo "loudregtyp" en '000' indica que los LPSM no indican el cumplimiento de regulación de sonoridad. Por ejemplo, un valor de este campo (por ejemplo, 0000) puede
indicar que el cumplimiento con una norma de regulación de sonoridad no está indicado, 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 fija en cualquier valor que no sea '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 sonoridad con función de puerta de diálogo. Si se ha corregido la sonoridad del programa usando la función de puerta de diálogo, el valor del campo loudcorrdialgat se fija en 'I'. De lo contrario, se fija en '0';
loudcorrtyp: un campo de un bit que indica el tipo de corrección de sonoridad aplicada al programa. Si se ha corregido la sonoridad del programa con un proceso de corrección de sonoridad prospectivo infinito (basado en archivos), el valor del loudcorrtyp se fija en 'O'. Si se ha corregido la sonoridad del programa usando una combinación de medición de sonoridad en tiempo real y control de rango dinámico, el valor de este campo se fija en '1';
loudrelgate: un campo de un bit que indica si existen los datos de sonoridad con función de puerta relativos (ITU). Si el campo loudrelgate se fija en '1', un campo ituloudrelgat de 7 bits debe seguir en la carga útil;
loudrelgat: un campo de 7 bits que indica la sonoridad de programa con función de puerta relativa (ITU). Este campo indica la sonoridad integrada del programa de audio, medida de acuerdo con ITU-R BS.1770-3 sin ningún ajuste de ganancia debido a que se aplica la compresión de rango dinámico y dialnorm. Los valores de 0 a 127 se interpretan como -58 LKFS a +5,5 LKFS, en 0,5 LKFS etapas;
loudspchgate: un campo de un bit que indica si existen los datos de sonoridad con función de puerta de emisiones vocales (ITU). Si el campo loudspchgate se fija en '1', un campo loudspchgat de 7 bits debe seguir en la carga útil; loudspchgat: un campo de 7 bits que indica la sonoridad de programa con función de puerta de emisiones vocales. Este campo indica la sonoridad integrada del programa de audio entero correspondiente, medida de acuerdo con la fórmula (2) de ITU-R BS.1770-3 y sin ningún ajuste de ganancia debido a que se aplica la compresión de rango dinámico y dialnorm. Los valores de 0 a 127 se interpretan como -58 a +5,5 LKFS, en
0,5 LKFS etapas
loudstrm3se: un campo de un bit que indica si existen datos de sonoridad a corto plazo (3 segundos). Si el campo se fija en '1', un campo loudstrm3s de 7 bits debe seguir en la carga útil;
loudstrm3s: un campo de 7 bits que indica la sonoridad sin función de puerta de los 3 segundos anteriores del programa de audio correspondiente, medida de acuerdo con ITU-R BS.1771-1 y sin ningún ajuste de ganancia debido a que se aplica la compresión de rango dinámico y dialnorm. Los valores de 0 a 256 se interpretan como -116 LKFS a +11,5
LKFS, en 0,5 LKFS etapas;
truepke: un campo de un bit que indica si existen datos de sonoridad de pico verdadero. Si el campo truepke se fija en 11', 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 acuerdo con el Anexo 2 de ITU-R BS.1770-3 y sin ningún ajuste de ganancia debido a que se aplica la compresión de rango dinámico y dialnorm. Los valores de 0 a 256 se interpretan como -116 LKFS a +11,5
LKFS, en 0,5 LKFS etapas;
En algunas modalidades, el elemento nuclear de un segmento de metadatos en un segmento de bits sobrantes o en un campo de
datos auxiliares (o campo "addbsi") de una trama de un flujo de bits AC-3 o flujo de bits E-AC-3 comprende un encabezado nuclear (típicamente que incluye valores de identificación, por ejemplo, versión de elemento nuclear) y después del encabezado nuclear: valores que indican si los datos de huellas digitales (u otros datos de protección) están incluidos para los metadatos del segmento de metadatos, valores que indican si existen datos externos (relacionados con los datos de audio que corresponden a los metadatos del segmento de metadatos), la ID de carga útil y los valores de tamaño de carga útil para cada tipo de metadatos (por ejemplo, LPSM, y/o metadatos de un tipo que no sea LPSM) identificado por el elemento nuclear, y valores de protección por al menos un tipo de metadatos identificado por el elemento nuclear. Las cargas útiles de metadatos de los segmentos de metadatos siguen el encabezado nuclear, y (en algunos casos) se anidan dentro de los valores del elemento nuclear.
Modalidades típicas de la invención incluyen metadatos de límite de programa en un flujo de bits de audio codificado de manera eficiente, que permite la determinación sólida y exacta de al menos un límite entre programas de audio consecutivos indicados por el flujo de bits. Las modalidades
típicas permiten la determinación sólida y exacta de un límite de programa en el sentido que permiten la determinación del límite de programa de manera exacta, aun en casos en donde los flujos de bits que indican programas diferentes se combinan (para generar el flujo de bits de la invención) de manera que se trunca uno o ambos de los flujos de bits empalmados (y de esa manera descarte los metadatos de límite de programa que han sido incluidos en al menos uno de los flujos de bits anteriores al empalme).
En modalidades típicas, los metadatos de límite de programa en una trama del flujo de bits de la invención es un indicador de límite de programa que indica el conteo de tramas. Típicamente, el indicador indica la cantidad de tramas entre la trama actual (la trama que incluye el indicador) y un límite de programa (el inicio o fin del programa de audio actual). En algunas modalidades preferidas, los indicadores de límite de programa se insertan de manera eficiente y simétrica al principio y fin de cada segmento de flujo de bits que indica un único programa (es decir, en tramas que se producen dentro de alguna cantidad de tramas predeterminadas después del inicio del segmento y en tramas que se producen dentro de alguna cantidad de tramas predeterminadas antes del final del segmento), para que
cuando dos de dichos segmentos de flujos de bits se concatenen (para indicar una secuencia de dos programas), los metadatos de límite de programa pueden estar presentes (por ejemplo, simétricamente) o ambos lados del límite entre dos programas).
La solidez máxima se puede lograr mediante la inserción de un indicador de límite de programa en cada trama de un flujo de bits que indican un programa, pero esto no sería práctico típicamente debido al aumento asociado en la tasa de datos. En modalidades típicas, los indicadores de límite de programas están insertados solamente en un subconjunto de las tramas de un flujo de bits de audio codificado (que pueden indicar un programa de audio o una secuencia de programas de audio) y la tasa de inserción de indicadores de límites es una función que no aumenta de separación en aumento de cada una de las tramas de flujo de bits (donde se inserta un indicador) del límite de programa que está más cerca de cada una de dichas tramas, donde la "tasa de inserción de indicadores de límites" denota la proporción promedio de la cantidad de tramas (que indican un programa) que incluye un indicador de límite de programa a la cantidad de tramas (que indican el programa) que no incluye un indicador de límite de programa, donde el promedio es una media móvil de una
cantidad (por ejemplo, cantidad relativamente pequeña) de tramas consecutivas del flujo de bits de audio codificado.
Al aumentar la tasa de inserción de indicadores de límite (por ejemplo, en ubicaciones en el flujo de bits cercanas a un límite de programa) aumentan la tasa de datos necesarios para el suministro del flujo de bits. Para compensar esto, el tamaño (número de bits) de cada indicador insertado disminuye preferentemente a medida que aumenta la tasa de inserción del indicador de límite (por ejemplo, de modo que el tamaño del indicador de límite de programa en la trama "N" del flujo de bits, donde N es un entero, es una función que no aumenta de la distancia (número de tramas) entre la trama "N" y el límite de programa más cercano). En una clase de modalidades, la tasa de inserción de indicadores de límites es una función que disminuye de manera logarítmica de distancia en aumento (de cada ubicación de inserción de indicador) desde el límite de programa más cercano, y para cada trama que contiene indicadores que incluye uno de los indicadores, el tamaño del indicador en dicha trama que contiene indicadores es igual o mayor que el tamaño de cada indicador en una trama ubicada más cerca al límite de programa más cercano que dicha trama que contiene indicadores. Típicamente, el tamaño de cada indicador es determinado por una función en aumento del
número de tramas desde la ubicación de la inserción del indicador hasta el límite de programa más cercano.
Por ejemplo, se consideran las modalidades de las Figuras 8 y 9, en donde cada columna identificada por un número de trama (en la fila superior) indica una trama de un flujo de bits de audio codificado. El flujo de bits indica un programa de audio que tiene un primer límite de programa (que indica el inicio del programa) que ocurre inmediatamente a la izquierda de la columna identificada con el número de trama "17" en el lado izquierdo de la Figura 9, y un segundo límite de programa (que indica el fin del programa) que ocurre inmediatamente a la derecha de la columna identificada con el número de trama "1" en el lado derecho de la Figura 8. Los indicadores de límite de programa incluidos en las tramas mostradas en la Figura 8 cuentan hacia atrás el número de tramas entre la trama actual y el segundo límite de programa. Los indicadores de límite de programa incluidos en las tramas mostradas en la Figura 9 cuentan hacia adelante el número de tramas entre la trama actual y el primer límite de programa. En la modalidad de las Figuras 8 y 9, un indicador de límite de programa está insertado solo en cada una de las tramas "2N" de las primeras tramas X del flujo de bits codificados después del inicio del programa de audio indicado por el
flujo de bits, y en cada una de las tramas "2N" (de las últimas tramas X en el flujo de bits) más cercana al fin del programa indicado por el flujo de bits, donde el programa comprende tramas Y, X es un entero menor o igual a Y/2, y N es un entero positivo en un intervalo de 1 a log2(X). Por lo tanto, (tal como se indica en las Figuras 8 y 9), un indicador de límite de programa está insertado en la segunda trama (N = 1) del flujo de bits (la trama que contiene indicador más cercana al inicio del programa), en la cuarta trama (N = 2), en la octava trama (N = 3), y así sucesivamente, y en la octava trama desde el fin del flujo de bits, en la cuarta trama desde el fin del flujo de bits y en la segunda trama desde el fin del flujo de bits (la trama que contiene indicador más cercana al fin del programa). En este ejemplo, el indicador de límite de programa en la trama "2N" desde el inicio (o fin) del programa comprende bits binarios log2(2N+2), tal como se indica en las Figuras 8 y 9. Por lo tanto, el indicador de límite de programa en la segunda trama
(N = 1) desde el inicio (o fin) del programa comprende log2(2N+2) = log2(23) = 3 bits binarios, y el indicador en la cuarta trama (N = 2) desde el inicio (o fin) del programa comprende log2(2N+2) = log2(24) = 4 bits binarios, y así sucesivamente.
En el ejemplo de las Figuras 8 y 9, el formato de cada indicador de programa es el siguiente. Cada indicador de límite de programa consiste en un bit "1" delantero, una secuencia de bits "0" (ya sea ningún bit "0" o uno o más bits "0" consecutivos) después del bit delantero, y un código trasero de dos bits. El código trasero es "11" para los indicadores en las últimas tramas X del flujo de bits (las tramas más cercanas al fin del programa), tal como se indica en la Figura 8. El código trasero es "10" para los indicadores en las primeras tramas X del flujo de bits (las tramas más cercanas al inicio del programa), tal como se indica en la Figura 9. Por lo tanto, para leer (decodificar) cada indicador, se cuenta el número de ceros entre el bit "1" delantero y el código trasero. Si se identifica que el código trasero es "11", el indicador indica que hay (2Z+1- 1) tramas entre la trama actual (la trama que incluye el indicador) y el fin del programa, donde Z es el número de ceros entre el bit "1" delantero y código trasero del indicador. El decodificador se puede implementar de forma eficaz para que ignore el primer y último bit de cada dicho indicador, para determinar el inverso de la secuencia de los otros bits
(intermedios) del indicador (por ejemplo, si la secuencia de bits intermedios es "0001" donde el bit "1" es el último bit
en la secuencia, las secuencia invertida de bits intermedios es "1000" donde el bit "1" es el primer bit en la secuencia invertida), y para identificar el valor binario de la secuencia invertida de bits intermedios como el índice de la trama actual (la trama en la cual está incluido el indicador) con respecto al fin del programa. Por ejemplo, si secuencia invertida de bits intermedios es "1000", esta secuencia invertida tiene el valor binario 24 = 16, y la trama se identifica como la 16.a trama antes del fin del programa (tal como se indica en la columna de la Figura 8 que describe la trama "0").
Si se identifica que el código trasero es "10", el indicador indica que hay (2Z+1 - 1) tramas entre el inicio del programa y la trama actual (la trama que incluye el indicador), donde Z es el número de ceros entre el bit "1" delantero y código trasero del indicador. El decodificador se puede implementar de forma eficaz para que ignore el primer y último bit de cada dicho indicador, para determinar el inverso de la secuencia de los bits intermedios del indicador (por ejemplo, si la secuencia de bits intermedios es "0001" donde el bit "1" es el último bit en la secuencia, las secuencia invertida de bits intermedios es "1000" donde el bit "1" es el primer bit en la secuencia invertida), y para identificar el valor
binario de la secuencia invertida de bits intermedios como el índice de la trama actual (la trama en la cual está incluido el indicador) con respecto al inicio del programa. Por ejemplo, si secuencia invertida de bits intermedios es "1000", esta secuencia invertida tiene el valor binario 24 = 16, y la trama se identifica como la 16.a trama después del inicio del programa (tal como se indica en la columna de la Figura 9 que describe la trama "32").
En el ejemplo de las Figuras 8 y 9, un indicador de límite de programa está presente solo en cada una de las tramas "2N" de las primeras tramas X de un flujo de bits codificados después del inicio de un programa de audio indicado por el flujo de bits, y en cada una de las tramas "2N" (de las últimas tramas X en el flujo de bits) más cercana al fin del programa indicado por el flujo de bits, donde el programa comprende tramas Y, X es un entero menor o igual a Y/2, y N es un entero positivo en un intervalo de 1 a log2(X). La inclusión de indicadores de límites de programa le agrega solamente una tasa de bits promedio de 1,875 bits/trama a la tasa de bits necesaria para transmitir el flujo de bits sin los indicadores.
En una implementación típica de la modalidad de las Figuras 8 y 9, donde el flujo de bits es un flujo de bits de audio
codificado AC-3, cada trama contiene contenido de audio y metadatos para 1536 muestras de audio digital. Para una velocidad de muestreo de 48 kHz, esto representa 32 milisegundos de audio digital o una velocidad de 31,25 tramas por segundo de audio. Por lo tanto, en dicha modalidad, un indicador de límite de programa en una trama separado por algún número de tramas (tramas "X") de un límite de programa indica que el límite ocurre 32X milisegundos después del fin de la trama que contiene el indicador (o 32X milisegundos antes del inicio de la trama que contiene el indicador).
En una implementación típica de la modalidad de las Figuras 8 y 9, donde el flujo de bits es un flujo de bits de audio codificado E-AC-3, cada trama del flujo de bits contiene contenido de audio y metadatos para 256, 512, 768 o 1536 muestras de audio digital, dependiendo de si la trama contiene uno, dos, tres o seis bloques de datos de audio respectivamente. Para una velocidad de muestreo de 48 kHz, esto representa 5,333, 10,667, 16 o 32 milisegundos de audio digital respectivamente o una velocidad de 189,9, 93,75, 62,5 o 31,25 tramas por segundo de audio respectivamente. Por lo tanto, en dicha modalidad, (asumiendo que cada trama indica 32 milisegundos de audio digital), un indicador de límite de programa en una trama separado por algún número de tramas
(tramas "X") de un límite de programa indica que el límite ocurre 32X milisegundos después del fin de la trama que contiene el indicador (o 32X milisegundos antes del inicio de la trama que contiene el indicador).
En algunas modalidades donde puede ocurrir un límite de programa dentro de una trama de un flujo de bits de audio (es decir, no alineados con el inicio o el fin de una trama), los metadatos de límite de programa incluidos en una trama del flujo de bits incluye un conteo de tramas de límite de programa (es decir, metadatos que indican el número de tramas enteras entre el inicio o fin de la trama que contiene el conteo de tramas y un límite de programa) y un valor offset. El valor offset indica un offset (típicamente un número de muestras) entre el inicio o el fin de una trama que contiene límite de programa, y la ubicación real del límite de programa dentro de la trama que contiene límite de programa. Un flujo de bits de audio codificado puede indicar una secuencia de programas (pistas de audio) de una secuencia correspondiente de programas de video, y los límites de dichos programas de audio tienden a ocurrir en los bordes de los fotogramas en vez de en los bordes de las tramas de audio. Además, algunos codees de audio (por ejemplo, codees E-AC-3) utilizan los tamaños de las tramas de audio que no
están alineadas con los fotogramas. También, en algunos casos, un flujo de bits de audio codificado inicialmente experimenta la transcodificación para generar un flujo de bits transcodificados, y el flujo de bits codificados inicialmente tiene un tamaño de trama diferente que el del flujo de bits transcodificados de modo que no se garantiza que ocurra un límite de programa (determinado por el flujo de bits codificados inicialmente) en un límite de trama del flujo de bits transcodificados. Por ejemplo, si el flujo de bits codificados inicialmente (por ejemplo, flujo de bits
"IEB" de la Figura 10) tiene un tamaño de trama de 1536 muestras por trama, y el flujo de bits transcodificados (por ejemplo, flujo de bits "TB" de la Figura 10) tiene un tamaño de trama de 1024 muestras por trama, el proceso de transcodificación pueden provocar que el límite de programa real ocurra no en un límite de trama del flujo de bits transcodificados sino en algún lado en una trama de este (por ejemplo, 512 muestras en una trama del flujo de bits transcodificados, tal como se indica en la Figura 10), debido a tamaños de trama diferenciados de los diferentes codees. Las modalidades de la presente invención en las que los metadatos de límite de programa incluidos en una trama de un flujo de bits de audio codificado incluyen un valor offset
así como tambien un conteo de trama de límite de programa son útiles en los tres casos destacados en este párrafo (así como también en otros casos).
La modalidad descrita anteriormente con referencia a las Figuras 8 y 9 no incluye un valor offset (por ejemplo, un campo offset) en ninguna de las tramas del flujo de bits codificados. En variaciones de esta modalidad, un valor offset está incluido en cada trama de un flujo de bits de audio codificado que incluye un indicador de límite de programa (por ejemplo, en tramas que correspondes a las tramas numeradas 0, 8, 12 y 14 en la Figura 8, y tramas numeradas 18, 20, 24 y 32 en la Figura 9).
En una clase de modalidades, una estructura de datos (en cada trama de un flujo de bits codificados que contiene los metadatos de límite de programa de la invención) incluye un valor de código que indica si la trama incluye solamente un conteo de trama de límite de programa, o ambos, un conteo de trama de límite de programa y un valor offset. Por ejemplo, un valor de código puede ser el valor de un campo de bit único (que en la presente se denominará campo "offset_exist"), el valor "offset_exist" = 0 puede indicar que no se incluyen valores offset en la trama, y el valor "offset_exist" = 1 puede indicar que tanto un conteo de trama
de límite de programa como un valor offset están incluidos en la trama.
En algunas modalidades, al menos una trama de un flujo de bits de audio codificado AC-3 o E-AC-3 incluye un segmento de metadatos que incluye los LPSM y metadatos de límite de programa (y opcionalmente otros metadatos) para un programa de audio determinado por el flujo de bits. Cada uno de dichos segmentos de metadatos (que pueden estar incluidos en un campo addbsi, o un campo de datos auxiliares, o un segmento de bits sobrantes del flujo de bits) contiene un encabezado nuclear, (y opcionalmente también elementos nucleares adicionales), y después del encabezado nuclear (o el encabezado nuclear y otros elementos nucleares) un segmento de carga útil de LPSM (o contenedor) que tiene el siguiente formato:
un encabezado (típicamente que incluye al menos un valor de identificación, por ejemplo, versión de formato, longitud, período, conteo, y valores de asociación de subflujo de LPSM) y
después del encabezado, los metadatos de límite de programa (que pueden incluir un conteo de tramas de límite de programa, un valor de código (por ejemplo, un valor "offset_exist ") que indica si la trama incluye solo un conteo
de trama de límite de programa o tanto un conteo de trama de límite de programa como un valor offset, y en algunos casos un valor offset) y los LPSM. Los LPSM pueden incluir:
al menos un valor de indicación de diálogo que indica si los datos de audio correspondientes indican diálogo o no indican diálogo (por ejemplo, qué canales de datos de audio correspondiente indican diálogo). Los valores de indicación de diálogo pueden indicar si el diálogo está presente en cualquier combinación o todos los canales de los datos de audio correspondientes;
al menos un valor de cumplimiento de regulación de sonoridad que indica si los datos de audio correspondientes cumplen con un conjunto indicado de regulaciones de sonoridad;
al menos un valor de procesamiento de sonoridad que indica un tipo de procesamiento de sonoridad que ha sido realizado en los datos de audio correspondientes; y
al menos un valor de sonoridad que indica al menos una característica de sonoridad (por ejemplo, sonoridad pico o promedio) de los datos de audio correspondientes.
En algunas modalidades, el segmento de carga útil de LPSM incluye un valor de código (un valor "offset_exist") que indica si la trama incluye solamente un conteo de trama de límite de programa o ambos, un conteo de trama de límite de
programa y un valor offset. Por ejemplo, en una de dichas modalidades, cuando dicho valor de código indica (por ejemplo, cuando offset_exist = 1) que la trama incluye un conteo de trama de límite de programa y un valor offset, el segmento de carga útil de LPSM puede incluir un valor offset que es un entero sin firmar de 11 bits (es decir, que tiene un valor de 0 a 2048) y que indica el número de muestras de audio adicionales entre el límite de trama señalado (el límite de la trama que incluye el límite de programa) y el límite de programa real. Si el conteo de trama de límite de programa indica el número de tramas (con la velocidad de trama actual) hasta la trama que contiene límites de programa, la ubicación exacta (en unidades de números de muestras) del límite de programa (con respecto al comienzo o fin de la trama que incluye el segmento de carga útil de LPSM) se calcularía como:
S = (frame_counter * tamaño de trama) + offset,
donde S es el número de muestras hasta el límite de programa (desde el comienzo o fin de la trama que incluye el segmento de carga útil de LPSM), "frame_counter" es el conteo de tramas indicado por el conteo de trama de límite de programa, "tamaño de trama" es el número de muestras por trama, y
"offset" es el número de muestras indicado por el valor
offset .
Algunas modalidades en las que la tasa de inserción de indicadores de límite de programa aumenta cerca del límite de programa real implementa una regla que establece que nunca se incluye un valor offset en una trama si la trama es menor o igual que algún número ("Y") de tramas desde la trama que incluye el límite de programa. Típicamente, Y = 32. Para un codificador E-AC-3 que implementa esta regla (con Y = 32), el codificador nunca inserta un valor offset en el segundo final de un programa de audio. En este caso, el dispositivo receptor es responsable de mantener un temporizador y, por lo tanto, realizar su propio cálculo de offset (en respuesta a metadatos de límite de programa, que incluyen un valor offset, en una trama del flujo de bits codificados que es más que tramas Y desde la trama que contiene límite de programa). Para los programas cuyos programas de audio son conocidos por estar "alineados en tramas" con fotogramas de programas de video correspondientes (por ejemplo, alimentación de contribución típica con audio codificado Dolby E), sería superfluo incluir valores offset en los flujos de bits codificados que indican programas de audio. Por lo tanto, los valores offset no estarán típicamente incluidos en dichos flujos de bits codificados.
Con referencia a la Figura 11, se consideran a continuación casos en los que los flujos de bits de audio codificados se empalman juntos para generar una modalidad del flujo de bits de audio de la invención.
El flujo de bits en la parte superior de la Figura 11 (etiquetado "Escenario 1") indica un primer programa de audio (Pl) entero que incluye metadatos de límite de programa (indicadores de límite de programa, F) seguido por un segundo programa de audio (P2) entero que también incluye metadatos de límite de programa (indicadores de límite de programa, F). Los indicadores de límite de programa en la parte final del primer programa (algunos de los cuales se muestran en la Figura 11) son idénticos o similares a los descritos con referencia a la Figura 8, y determinan la ubicación del límite entre los dos programas (es decir, el límite en el inicio del segundo programa). Los indicadores de límite de programa en la parte inicial del segundo programa (algunas de las cuales se muestran en la Figura 11) son idénticos o similares a los descritos con referencia a la Figura 9, y también determinan la ubicación del límite. En modalidades típicas, un codificador o decodificador implementa un temporizador (calibrado por los indicadores en el primer programa) que cuenta hacia atrás hasta el límite del
programa, y el mismo temporizador (calibrado por los indicadores en el segundo programa) cuenta hacia adelante desde el mismo límite del programa. Tal como lo indica la gráfica de temporizador de límite en el Escenario 1 de la Figura 11, dicho conteo regresivo del temporizador (calibrado por los indicadores en el primer programa) llega a cero en el límite, y el conteo hacia adelante del temporizador (calibrado por los indicadores en el segundo programa) indica la misma ubicación del límite.
El segundo flujo de bits de la parte superior de la Figura 11 (etiquetado "Escenario 2" ) indica un primer programa de audio (Pl) entero que incluye metadatos de límite de programa (indicadores de límite de programa, F) seguido por un segundo programa de audio (P2) entero que no incluye metadatos de límite de programa. Los indicadores de límite de programa en la parte final del primer programa (algunas de las cuales se muestran en la Figura 11) son idénticos o similares a los descritos con referencia a la Figura 8, y determinan la ubicación del límite entre los dos programas (es decir, el límite en el inicio del segundo programa), igual que en el Escenario 1. En modalidades típicas, un codificador o decodificador implementa un temporizador (calibrado por los indicadores en el primer programa) que cuenta hacia atrás
hasta el límite del programa, y el mismo temporizador (sin calibrado adicional) continúa contando hacia adelante desde el límite del programa (tal como lo indica la gráfica de temporizador de límite en el Escenario 2 de la Figura 11). El tercer flujo de bits de la parte superior de la Figura 11 (etiquetado "Escenario 3") indica un primer programa de audio (Pl) truncado que incluye metadatos de límite de programa (indicadores de límite de programa, F) y que ha sido empalmado con un segundo programa de audio (P2) entero que también incluye metadatos de límite de programa (indicadores de límite de programa, F). El empalme ha retirado las últimas tramas "N" del primer programa. Los indicadores de límite de programa en la parte inicial del segundo programa (algunas de las cuales se muestran en la Figura 11) son idénticos o similares a los descritos con referencia a la Figura 9, y determinan la ubicación del límite (empalme) entre el primer programa truncado y el segundo programa entero. En modalidades típicas, un codificador o decodificador implementa un temporizador (calibrado por los indicadores en el primer programa) que cuenta hacia atrás hasta el fin del primer programa no truncado, y el mismo temporizador (calibrado por los indicadores en el segundo programa) cuenta hacia adelante desde el inicio del segundo programa. El
inicio del segundo programa es el límite de programa en el Escenario 3. Tal como lo indica la gráfica de temporizador de límite en el Escenario 3 de la Figura 11, dicho conteo regresivo del temporizador (calibrado por los indicadores en el primer programa) se reinicializa (en respuesta a los metadatos de límite de programa en el segundo programa) antes de que alcance el cero (en respuestas a los metadatos de límite de programa en el primer programa). Por lo tanto, aunque la truncación del primer programa (mediante el empalme) evita que el temporizador identifique el límite de programa entre el primer programa truncado y el inicio del segundo programa en respuesta a (es decir, calibrado por) metadatos de límite de programa solo en el primer programa, los metadatos de programa en el segundo programa reinicializan el temporizador, de modo que el temporizador reinicializado indica correctamente (como la ubicación que corresponde al conteo "cero" del temporizador reinicializado) la ubicación del límite de programa entre el primer programa y el inicio del segundo programa.
El cuarto flujo de bits (etiquetado "Escenario 4") indica un primer programa de audio (Pl) truncado que incluye metadatos de límite de programa (indicadores de límite de programa, F), y un segundo programa de audio (P2) truncado que incluye
metadatos de límite de programa (indicadores de límite de programa, F) y que ha sido empalmado con una parte (la parte no truncada) del primer programa de audio. Los indicadores de límite de programa en la parte inicial del segundo programa entero (pretruncación) (algunos de los cuales se muestran en la Figura 11) son idénticos o similares a los descritos con referencia a la Figura 9, y los indicadores de límite de programa en la parte final del primer programa entero (pretruncación) (algunos de los cuales se muestran en la Figura 11) son idénticos o similares a los descritos con referencia a la Figura 8. El empalme ha retirado las últimas tramas "N" del primer programa (y por lo tanto algunos de los indicadores de límite de programa que habían sido incluidos en estas antes del empalme) y las primeras tramas "M" del segundo programa (y por lo tanto algunos de los indicadores de límite de programa que habían sido incluidos en estas antes del empalme). En modalidades típicas, un codificador o decodificador implementa un temporizador (calibrado por los indicadores en el primer programa truncado) que cuenta hacia atrás hacia el fin del primer programa no truncado, y el mismo temporizador (calibrado por los indicadores en el segundo programa truncado) cuenta hacia adelante desde el inicio del segundo programa no truncado. Tal como lo indica
la gráfica de temporizador de límite en el Escenario 4 de la Figura 11, dicho conteo regresivo del temporizador (calibrado por los metadatos de límite de programa en el primer programa) se reinicializa (en respuesta a los metadatos de límite de programa en el segundo programa) antes de que alcance el cero (en respuestas a los metadatos de límite de programa en el primer programa). La truncación del primer programa (mediante el empalme) evita que el temporizador identifique el límite de programa entre el primer programa truncado y el inicio del segundo programa en respuesta a (es decir, calibrado por) metadatos de límite de programa solo en el primer programa. Sin embargo, el temporizador reinicializado no indica correctamente la ubicación del límite de programa entre el fin del primer programa truncado y el inicio del segundo programa truncado. Por lo tanto, la truncación de ambos flujos de bits empalmados puede evitar la determinación precisa entre el límite entre ellos.
Las modalidades de la presente invención se pueden implementar en hardware, firmware, o software, o una combinación de ambos (por ejemplo, como una matriz lógica programable). A menos que se especifique lo contrario, los algoritmos o procesos incluidos como parte de la invención no se refieren inherentemente a ninguna computadora u otro
aparato particular. En particular, se pueden utilizar varias máquinas de uso general con programas escritos de acuerdo con las indicaciones de la presente, o puede ser conveniente construir aparatos más especializados (por ejemplo, circuitos integrados) para realizar los pasos necesarios del método. Por lo tanto, la invención se puede implementar en uno o más programas informáticos que se ejecutan en uno o más sistemas informáticos programables (por ejemplo, una implementación de cualquiera de los elementos de la Figura 1, o codificador 100 de la Figura 2 (o un elemento de este), o decodificador 200 de la Figura 3 (o un elemento de este), o postprocesador 300 de la Figura 3 (o un elemento de este)) donde cada uno comprende al menos un procesador, al menos un sistema de almacenamiento de datos (que incluye memoria volátil y no volátil y/o elementos de almacenamiento), 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 la presente y generar información de salida. La información de salida se aplica a uno o más dispositivos de salida de forma conocida. Cada uno de dichos programas se puede implementar en cualquier lenguaje informático deseado (que incluye lenguajes de máquinas, ensamblajes, o de procedimiento de alto nivel,
lógicos, o lenguajes de programación orientados a objetos) para comunicarse con un sistema informático. En cualquier caso, el lenguaje puede ser un lenguaje compilado o interpretado.
Por ejemplo, cuando se implementa mediante secuencias de instrucciones de software informático, se pueden implementar varias funciones y pasos de las modalidades de la invención mediante secuencias de instrucciones de software multihilo que se ejecutan en un hardware de procesamiento de señales digitales adecuado, en cuyo caso los diversos dispositivos, pasos y funciones de las modalidades pueden corresponder a partes de las instrucciones de software.
Cada programa informático se almacena o se descarga preferentemente en un medio o dispositivo de almacenamiento (por ejemplo, memoria o medio de estado sólido, o medio magnético u óptico) legible por una computadora programable de uso general o especial, para configurar y operar la computadora cuando el medio o dispositivo de almacenamiento es leído por un sistema informático para realizar los procedimientos descritos en la presente. El sistema de la invención también se puede implementar como un medio de almacenamiento legible por computadora, configurado con (es decir, que almacena) un programa informático, donde el medio
de almacenamiento configurado de esta forma provoca que un sistema informático funcione de una manera específica y predefinida para realizar las funciones descritas en la presente.
Se han descrito una cantidad de modalidades de la invención. Sin embargo, se comprenderá que podrán realizarse distintas modificaciones sin apartarse del espíritu ni el alcance de la descripción. Se pueden realizar diversas modificaciones y variaciones de la presente invención a la luz de las indicaciones anteriores. Se entiende que, dentro del alcance de las reivindicaciones adjuntas, la invención puede ser llevada a cabo de otra manera que no sea la específicamente descrita en la presente.
Claims (27)
1. Una unidad de procesamiento de audio que comprende: una memoria intermedia para almacenar al menos una trama de un flujo de bits de audio codificado, donde el flujo de bits de audio codificado incluye datos de audio y un contenedor de metadatos, donde el contenedor de metadatos incluye un encabezado, una o más cargas útiles de metadatos, y datos de protección; un decodificador de audio acoplado a la memoria intermedia para decodificar los datos de audio; y un analizador sintáctico acoplado o integrado al decodificador de audio para realizar el análisis sintáctico del flujo de bits de audio codificado, donde el encabezado incluye una palabra de sincronización que identifica el inicio del contenedor de metadatos, la una o más cargas útiles de metadatos describe un programa de audio asociado a los datos de audio, los datos de protección se ubican después de la una o más cargas útiles de metadatos, y los datos de protección se pueden utilizar para verificar la integridad del contenedor de metadatos y la una o más cargas útiles de metadatos dentro del contenedor de metadatos.
2 . La unidad de procesamiento de audio de la reivindicación 1, donde el contenedor de metadatos se almacena en un espacio de datos reservado AC-3 o E-AC-3 que se selecciona del grupo que consiste un campo de salto, un campo de datos auxiliares, un campo addbsi y una combinación de estos.
3. La unidad de procesamiento de audio de las reivindicaciones 1 o 2, donde la una o más cargas útiles de metadatos incluye metadatos que indican al menos un límite entre programas de audio consecutivos.
4. La unidad de procesamiento de audio de las reivindicaciones 1 o 2, donde la una o más cargas útiles de metadatos incluyen una carga útil de sonoridad de programa que contiene datos que indican una sonoridad medida de un programa de audio.
5. La unidad de procesamiento de audio de la reivindicación 4, donde la carga útil de sonoridad de programa incluye un campo que indica si un canal de audio contiene diálogo hablado.
6. La unidad de procesamiento de audio de la reivindicación 4, donde la carga útil de sonoridad de programa incluye un campo que indica un método de medición de sonoridad que se ha utilizado para generar datos de sonoridad contenidos en la carga útil de sonoridad de programa.
7 . La unidad de procesamiento de audio de la reivindicación 4, donde la carga útil de sonoridad de programa incluye un campo que indica si un programa de audio ha sido corregido usando función de puerta de diálogo.
8. La unidad de procesamiento de audio de la reivindicación 4, donde la carga útil de sonoridad de programa incluye un campo que indica si una sonoridad de un programa de audio ha sido corregida usando un proceso de corrección de sonoridad basado en prospectivo infinito o basado en archivos.
9. La unidad de procesamiento de audio de la reivindicación 4, donde la carga útil de sonoridad de programa incluye un campo que indica una sonoridad integrada de un programa de audio sin ningún ajuste de ganancia atribuible a la compresión de rango dinámico.
10. La unidad de procesamiento de audio de la reivindicación 4, donde la carga útil de sonoridad de programa incluye un campo que indica una sonoridad integrada de un programa de audio sin ningún ajuste de ganancia atribuible a la normalización del diálogo.
11. La unidad de procesamiento de audio de la reivindicación 4, donde la unidad de procesamiento de audio está configurada para que realice el procesamiento de sonoridad adaptativo usando la carga útil de sonoridad de programa.
12. La unidad de procesamiento de audio de acuerdo con cualquiera de las reivindicaciones 1-11, donde el flujo de bits de audio codificado es un flujo de bits AC-3 o un flujo de bits E-AC-3.
13. La unidad de procesamiento de audio de acuerdo con cualquiera de las reivindicaciones 4-11, donde la unidad de procesamiento de audio está configurada para que extraiga la carga útil de sonoridad de programa del flujo de bits de audio codificado y autenticar o validar la carga útil de sonoridad de programa.
14. La unidad de procesamiento de audio de acuerdo con cualquiera de las reivindicaciones 1-13, donde cada una de una o más cargas útiles de metadatos incluye un identificador de carga útil único, y el identificador de carga útil único está ubicado al inicio de cada carga útil de metadatos.
15. La unidad de procesamiento de audio de acuerdo con cualquiera de las reivindicaciones 1-13, donde la palabra de sincronización es una palabra de sincronización de 16 bits que tiene un valor de 0x5838.
16. Un método para decodificar un flujo de bits de audio codificado, donde el método comprende: recibir un flujo de bits de audio codificado, el flujo de bits de audio codificado segmentado en una o más tramas; extraer datos de audio y un contendedor de metadatos de un flujo de bits de audio codificado, donde el contendedor de metadatos incluye un encabezado seguido por una o más cargas útiles de metadatos seguida por datos de protección; y verificar la integridad del contenedor y la una o más cargas útiles de metadatos a través del uso de datos de protección, donde la una o más cargas útiles de metadatos incluyen una carga útil de sonoridad de programa que contiene datos que indican una sonoridad medida de un programa de audio asociado con los datos de audio.
17. El método de la reivindicación 16, donde el flujo de bits codificados es un flujo de bits AC-3 o un flujo de bits E-AC-3.
18. El método de la reivindicación 16, que comprende adicionalmente: realizar un procesamiento de sonoridad adaptativo en los datos de audio extraídos del flujo de bits de audio codificado usando la carga útil de sonoridad de programa.
19. El método de la reivindicación 16, donde el contenedor está ubicado y se extrae de un espacio de datos reservado AC-3 o E-AC-3 que se selecciona del grupo que consiste un campo de salto, un campo de datos auxiliares, un campo addbsi y una combinación de estos.
20. El método de la reivindicación 16, donde la carga útil de sonoridad de programa incluye un campo que indica si un canal de audio contiene diálogo hablado.
21. El método de la reivindicación 16, donde la carga útil de sonoridad de programa incluye un campo que indica un método de medición de sonoridad que se ha utilizado para generar datos de sonoridad contenidos en la carga útil de sonoridad de programa.
22. El método de la reivindicación 16, donde la carga útil de sonoridad de programa incluye un campo que indica si una sonoridad de un programa de audio ha sido corregido usando función de puerta de diálogo.
23. El método de la reivindicación 16, donde la carga útil de sonoridad de programa incluye un campo que indica si una sonoridad de un programa de audio ha sido corregida usando un proceso de corrección de sonoridad basado en prospectivo infinito o basado en archivos.
24. El método de la reivindicación 16, donde la carga útil de sonoridad de programa incluye un campo que indica una sonoridad integrada de un programa de audio sin ningún ajuste de ganancia debido a la compresión de rango dinámico.
25. El método de la reivindicación 16, donde la carga útil de sonoridad de programa incluye un campo que indica una sonoridad integrada de un programa de audio sin ningún ajuste de ganancia atribuible a la normalización del diálogo.
26. El método de la reivindicación 16, donde el contenedor de metadatos incluye metadatos que indican al menos un límite entre programas de audio consecutivos.
27. El método de la reivindicación 16, donde el contenedor de metadatos está almacenado en uno o más campos de salto o segmentos de bits sobrantes de una trama.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201361754882P | 2013-01-21 | 2013-01-21 | |
| US201361824010P | 2013-05-16 | 2013-05-16 | |
| PCT/US2014/011672 WO2014113465A1 (en) | 2013-01-21 | 2014-01-15 | Audio encoder and decoder with program loudness and boundary metadata |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| MX2015004468A true MX2015004468A (es) | 2015-07-14 |
| MX339611B MX339611B (es) | 2016-05-31 |
Family
ID=51210033
Family Applications (6)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| MX2016004803A MX343571B (es) | 2013-01-21 | 2014-01-15 | Codificador y decodificador de audio con metadatos de limite y sonoridad de programa. |
| MX2021011251A MX2021011251A (es) | 2013-01-21 | 2014-01-15 | Codificador y decodificador de audio con metadatos de límite y sonoridad de programa. |
| MX2016004804A MX356196B (es) | 2013-01-21 | 2014-01-15 | Codificador y decodificador de audio con metadatos de límite y sonoridad de programa. |
| MX2018006149A MX2018006149A (es) | 2013-01-21 | 2014-01-15 | Codificador y decodificador de audio con metadatos de limite y sonoridad de programa. |
| MX2015004468A MX339611B (es) | 2013-01-21 | 2014-01-15 | Codificador y decodificador de audio con metadatos de limite y sonoridad de programa. |
| MX2022013535A MX2022013535A (es) | 2013-01-21 | 2015-04-09 | Codificador y decodificador de audio con metadatos de limite y sonoridad de programa. |
Family Applications Before (4)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| MX2016004803A MX343571B (es) | 2013-01-21 | 2014-01-15 | Codificador y decodificador de audio con metadatos de limite y sonoridad de programa. |
| MX2021011251A MX2021011251A (es) | 2013-01-21 | 2014-01-15 | Codificador y decodificador de audio con metadatos de límite y sonoridad de programa. |
| MX2016004804A MX356196B (es) | 2013-01-21 | 2014-01-15 | Codificador y decodificador de audio con metadatos de límite y sonoridad de programa. |
| MX2018006149A MX2018006149A (es) | 2013-01-21 | 2014-01-15 | Codificador y decodificador de audio con metadatos de limite y sonoridad de programa. |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| MX2022013535A MX2022013535A (es) | 2013-01-21 | 2015-04-09 | Codificador y decodificador de audio con metadatos de limite y sonoridad de programa. |
Country Status (22)
| Country | Link |
|---|---|
| US (6) | US9916838B2 (es) |
| EP (3) | EP3244406B1 (es) |
| JP (9) | JP6212565B2 (es) |
| KR (8) | KR102488704B1 (es) |
| CN (2) | CN107657959B (es) |
| AU (1) | AU2014207590B2 (es) |
| BR (5) | BR122020020608B1 (es) |
| CA (1) | CA2888350C (es) |
| DK (1) | DK2901449T3 (es) |
| ES (4) | ES2667871T3 (es) |
| HK (3) | HK1212091A1 (es) |
| HU (1) | HUE036119T2 (es) |
| IL (9) | IL287218B (es) |
| MX (6) | MX343571B (es) |
| MY (2) | MY193854A (es) |
| PL (1) | PL2901449T3 (es) |
| RU (3) | RU2713609C2 (es) |
| SG (2) | SG11201502405RA (es) |
| TR (1) | TR201802631T4 (es) |
| TW (9) | TWI754286B (es) |
| UA (3) | UA112249C2 (es) |
| WO (1) | WO2014113465A1 (es) |
Families Citing this family (39)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9373334B2 (en) * | 2011-11-22 | 2016-06-21 | Dolby Laboratories Licensing Corporation | Method and system for generating an audio metadata quality score |
| US9570090B2 (en) * | 2015-05-26 | 2017-02-14 | Google Inc. | Dialog system with automatic reactivation of speech acquiring mode |
| TWM487509U (zh) | 2013-06-19 | 2014-10-01 | 杜比實驗室特許公司 | 音訊處理設備及電子裝置 |
| CN105556837B (zh) | 2013-09-12 | 2019-04-19 | 杜比实验室特许公司 | 用于各种回放环境的动态范围控制 |
| US9349378B2 (en) | 2013-11-19 | 2016-05-24 | Dolby Laboratories Licensing Corporation | Haptic signal synthesis and transport in a bit stream |
| EP2879131A1 (en) * | 2013-11-27 | 2015-06-03 | Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. | Decoder, encoder and method for informed loudness estimation in object-based audio coding systems |
| US9621963B2 (en) | 2014-01-28 | 2017-04-11 | Dolby Laboratories Licensing Corporation | Enabling delivery and synchronization of auxiliary content associated with multimedia data using essence-and-version identifier |
| US10063207B2 (en) | 2014-02-27 | 2018-08-28 | Dts, Inc. | Object-based audio loudness management |
| EP3800898B1 (en) * | 2014-05-28 | 2023-07-19 | Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. | Data processor and transport of user control data to audio decoders and renderers |
| WO2016039150A1 (ja) * | 2014-09-08 | 2016-03-17 | ソニー株式会社 | 符号化装置および方法、復号装置および方法、並びにプログラム |
| US9584911B2 (en) * | 2015-03-27 | 2017-02-28 | Cirrus Logic, Inc. | Multichip dynamic range enhancement (DRE) audio processing methods and apparatuses |
| ES2936089T3 (es) | 2015-06-17 | 2023-03-14 | Fraunhofer Ges Forschung | Control de intensidad del sonido para interacción del usuario en sistemas de codificación de audio |
| US9837086B2 (en) * | 2015-07-31 | 2017-12-05 | Apple Inc. | Encoded audio extended metadata-based dynamic range control |
| US10140822B2 (en) | 2015-08-05 | 2018-11-27 | Dolby Laboratories Licensing Corporation | Low bit rate parametric encoding and transport of haptic-tactile signals |
| US9590580B1 (en) * | 2015-09-13 | 2017-03-07 | Guoguang Electric Company Limited | Loudness-based audio-signal compensation |
| US10341770B2 (en) * | 2015-09-30 | 2019-07-02 | Apple Inc. | Encoded audio metadata-based loudness equalization and dynamic equalization during DRC |
| US10007713B2 (en) * | 2015-10-15 | 2018-06-26 | Disney Enterprises, Inc. | Metadata extraction and management |
| US10594689B1 (en) | 2015-12-04 | 2020-03-17 | Digimarc Corporation | Robust encoding of machine readable information in host objects and biometrics, and associated decoding and authentication |
| US10573324B2 (en) | 2016-02-24 | 2020-02-25 | Dolby International Ab | Method and system for bit reservoir control in case of varying metadata |
| US10015612B2 (en) * | 2016-05-25 | 2018-07-03 | Dolby Laboratories Licensing Corporation | Measurement, verification and correction of time alignment of multiple audio channels and associated metadata |
| US10210881B2 (en) * | 2016-09-16 | 2019-02-19 | Nokia Technologies Oy | Protected extended playback mode |
| CN116631413A (zh) | 2017-01-10 | 2023-08-22 | 弗劳恩霍夫应用研究促进协会 | 音频解码器、提供解码的音频信号的方法、和计算机程序 |
| US10339947B2 (en) | 2017-03-22 | 2019-07-02 | Immersion Networks, Inc. | System and method for processing audio data |
| US10878879B2 (en) * | 2017-06-21 | 2020-12-29 | Mediatek Inc. | Refresh control method for memory system to perform refresh action on all memory banks of the memory system within refresh window |
| CN110945494B (zh) | 2017-07-28 | 2024-06-21 | 杜比实验室特许公司 | 向客户端提供媒体内容的方法和系统 |
| CN114898761A (zh) | 2017-08-10 | 2022-08-12 | 华为技术有限公司 | 立体声信号编解码方法及装置 |
| EP3677037A1 (en) | 2017-08-28 | 2020-07-08 | Dolby Laboratories Licensing Corporation | Media-aware navigation metadata |
| CN115691519A (zh) | 2018-02-22 | 2023-02-03 | 杜比国际公司 | 用于处理嵌入在mpeg-h 3d音频流中的辅媒体流的方法及设备 |
| US10937434B2 (en) * | 2018-05-17 | 2021-03-02 | Mediatek Inc. | Audio output monitoring for failure detection of warning sound playback |
| EP3570279A1 (en) * | 2018-05-17 | 2019-11-20 | MediaTek Inc. | Audio output monitoring for failure detection of warning sound playback |
| EP4220639A1 (en) * | 2018-10-26 | 2023-08-02 | Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. | Directional loudness map based audio processing |
| KR102502521B1 (ko) | 2019-03-14 | 2023-02-23 | 가우디오랩 주식회사 | 라우드니스 레벨을 제어하는 오디오 신호 처리 방법 및 장치 |
| WO2021030515A1 (en) * | 2019-08-15 | 2021-02-18 | Dolby International Ab | Methods and devices for generation and processing of modified audio bitstreams |
| CA3155346A1 (en) | 2019-10-30 | 2021-05-06 | National University Corporation Okayama University | Prophylactic and/or therapeutic agent for inflammatory pulmonary disease |
| US11922532B2 (en) | 2020-01-15 | 2024-03-05 | Digimarc Corporation | System for mitigating the problem of deepfake media content using watermarking |
| WO2021183645A1 (en) * | 2020-03-11 | 2021-09-16 | Bytedance Inc. | Indication of digital media integrity |
| US11315581B1 (en) | 2020-08-17 | 2022-04-26 | Amazon Technologies, Inc. | Encoding audio metadata in an audio frame |
| CN115292545B (zh) * | 2022-10-08 | 2022-12-20 | 腾讯科技（深圳）有限公司 | 一种音频数据处理方法、装置、设备以及可读存储介质 |
| WO2024081785A1 (en) * | 2022-10-12 | 2024-04-18 | Sameer Kumar | Digital audio measurement systems and method |
Family Cites Families (92)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE69210689T2 (de) | 1991-01-08 | 1996-11-21 | Dolby Lab Licensing Corp | Kodierer/dekodierer für mehrdimensionale schallfelder |
| US5632005A (en) | 1991-01-08 | 1997-05-20 | Ray Milton Dolby | Encoder/decoder for multidimensional sound fields |
| KR0152037B1 (ko) | 1994-09-27 | 1998-11-02 | 김광호 | 다채널 오디오신호의 전송 비트열구조 |
| US5727119A (en) | 1995-03-27 | 1998-03-10 | Dolby Laboratories Licensing Corporation | Method and apparatus for efficient implementation of single-sideband filter banks providing accurate measures of spectral magnitude and phase |
| US7224819B2 (en) | 1995-05-08 | 2007-05-29 | Digimarc Corporation | Integrating digital watermarks in multimedia content |
| US6446037B1 (en) * | 1999-08-09 | 2002-09-03 | Dolby Laboratories Licensing Corporation | Scalable coding method for high quality audio |
| GB2373975B (en) | 2001-03-30 | 2005-04-13 | Sony Uk Ltd | Digital audio signal processing |
| US6807528B1 (en) * | 2001-05-08 | 2004-10-19 | Dolby Laboratories Licensing Corporation | Adding data to a compressed data frame |
| US7072477B1 (en) | 2002-07-09 | 2006-07-04 | Apple Computer, Inc. | Method and apparatus for automatically normalizing a perceived volume level in a digitally encoded file |
| US7454331B2 (en) * | 2002-08-30 | 2008-11-18 | Dolby Laboratories Licensing Corporation | Controlling loudness of speech in signals that contain speech and other types of audio material |
| KR100860984B1 (ko) * | 2002-10-15 | 2008-09-30 | 삼성전자주식회사 | 메타데이터 관리 방법 |
| US8301884B2 (en) * | 2002-09-16 | 2012-10-30 | Samsung Electronics Co., Ltd. | Method of managing metadata |
| US8979655B2 (en) * | 2002-12-10 | 2015-03-17 | Ol2, Inc. | System and method for securely hosting applications |
| KR20060022637A (ko) * | 2003-02-28 | 2006-03-10 | 마츠시타 덴끼 산교 가부시키가이샤 | 재생장치 및 재생방법 |
| WO2004114655A1 (en) * | 2003-06-18 | 2004-12-29 | Thomson Licensing S.A. | Apparatus for recording data on motion picture film |
| US7509255B2 (en) | 2003-10-03 | 2009-03-24 | Victor Company Of Japan, Limited | Apparatuses for adaptively controlling processing of speech signal and adaptively communicating speech in accordance with conditions of transmitting apparatus side and radio wave and methods thereof |
| CN1910913A (zh) | 2004-01-08 | 2007-02-07 | 皇家飞利浦电子股份有限公司 | 用于存储数据的方法和设备 |
| US8131134B2 (en) | 2004-04-14 | 2012-03-06 | Microsoft Corporation | Digital media universal elementary stream |
| EP1768419B1 (en) | 2004-06-21 | 2010-10-06 | Mitsubishi Electric Corporation | Moving picture encoding device, moving picture recording device, and moving picture reproduction device |
| US7617109B2 (en) | 2004-07-01 | 2009-11-10 | Dolby Laboratories Licensing Corporation | Method for correcting metadata affecting the playback loudness and dynamic range of audio information |
| US7624021B2 (en) * | 2004-07-02 | 2009-11-24 | Apple Inc. | Universal container for audio data |
| KR100991803B1 (ko) * | 2004-07-22 | 2010-11-04 | 주식회사 넷앤티비 | Ｓａｆ 동기화 계층 패킷 구조를 제공하는 ｓａｆ 동기화 계층 패킷 제공 시스템 및 사용자 단말 |
| KR100689443B1 (ko) | 2004-08-21 | 2007-03-08 | 삼성전자주식회사 | 방송 데이터를 저장하기 위한 디지털 방송 시스템 및송수신 방법 |
| US7729673B2 (en) | 2004-12-30 | 2010-06-01 | Sony Ericsson Mobile Communications Ab | Method and apparatus for multichannel signal limiting |
| CL2006000541A1 (es) | 2005-03-10 | 2008-01-04 | Qualcomm Inc | Metodo para el procesamiento de datos multimedia que comprende: a) determinar la complejidad de datos multimedia; b) clasificar los datos multimedia en base a la complejidad determinada; y aparato asociado. |
| TWI397903B (zh) | 2005-04-13 | 2013-06-01 | Dolby Lab Licensing Corp | 編碼音訊之節約音量測量技術 |
| TW200638335A (en) * | 2005-04-13 | 2006-11-01 | Dolby Lab Licensing Corp | Audio metadata verification |
| US7680451B2 (en) * | 2005-04-26 | 2010-03-16 | D-Box Technologies Inc. | Method and apparatus for providing a motion signal with a sound signal using an existing sound signal encoding format |
| US7702279B2 (en) * | 2005-12-20 | 2010-04-20 | Apple Inc. | Portable media player as a low power remote control and method thereof |
| JP5394754B2 (ja) * | 2006-02-23 | 2014-01-22 | エルジー エレクトロニクス インコーポレイティド | オーディオ信号の処理方法及び装置 |
| US7983910B2 (en) * | 2006-03-03 | 2011-07-19 | International Business Machines Corporation | Communicating across voice and text channels with emotion preservation |
| US20080025530A1 (en) | 2006-07-26 | 2008-01-31 | Sony Ericsson Mobile Communications Ab | Method and apparatus for normalizing sound playback loudness |
| US20080080722A1 (en) | 2006-09-29 | 2008-04-03 | Carroll Tim J | Loudness controller with remote and local control |
| WO2008136608A1 (en) | 2007-05-02 | 2008-11-13 | Pixtree Technologis, Inc. | Method of processing media data and receiver, broadcasting system |
| JP5334335B2 (ja) * | 2007-07-02 | 2013-11-06 | フラウンホファー・ゲゼルシャフト・ツール・フォルデルング・デル・アンゲバンテン・フォルシュング・アインゲトラーゲネル・フェライン | メディアデータコンテナおよびメタデータコンテナを有するファイルを記憶および読み出すための装置および方法 |
| CN101350604B (zh) | 2007-07-19 | 2012-07-04 | 鸿富锦精密工业（深圳）有限公司 | 自动切换音量调节模式的装置及方法 |
| US20090164473A1 (en) | 2007-12-19 | 2009-06-25 | Harman International Industries, Incorporated | Vehicle infotainment system with virtual personalization settings |
| US20090164378A1 (en) * | 2007-12-21 | 2009-06-25 | Steven Marcus Jason West | Music Distribution |
| JP5142769B2 (ja) * | 2008-03-11 | 2013-02-13 | 株式会社日立製作所 | 音声データ検索システム及び音声データの検索方法 |
| US20090253457A1 (en) | 2008-04-04 | 2009-10-08 | Apple Inc. | Audio signal processing for certification enhancement in a handheld wireless communications device |
| EP2144230A1 (en) * | 2008-07-11 | 2010-01-13 | Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. | Low bitrate audio encoding/decoding scheme having cascaded switches |
| EP2146522A1 (en) | 2008-07-17 | 2010-01-20 | Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. | Apparatus and method for generating audio output signals using object based metadata |
| US8788555B2 (en) * | 2008-07-29 | 2014-07-22 | Orange | Method for updating an encoder by filter interpolation |
| US8218790B2 (en) | 2008-08-26 | 2012-07-10 | Apple Inc. | Techniques for customizing control of volume level in device playback |
| JP2010135906A (ja) | 2008-12-02 | 2010-06-17 | Sony Corp | クリップ防止装置及びクリップ防止方法 |
| JP4519934B2 (ja) * | 2008-12-26 | 2010-08-04 | 株式会社東芝 | 音声再生装置 |
| JP5267115B2 (ja) | 2008-12-26 | 2013-08-21 | ソニー株式会社 | 信号処理装置、その処理方法およびプログラム |
| US8422699B2 (en) | 2009-04-17 | 2013-04-16 | Linear Acoustic, Inc. | Loudness consistency at program boundaries |
| CN102549655B (zh) * | 2009-08-14 | 2014-09-24 | Dts有限责任公司 | 自适应成流音频对象的系统 |
| TWI529703B (zh) | 2010-02-11 | 2016-04-11 | 杜比實驗室特許公司 | 用以非破壞地正常化可攜式裝置中音訊訊號響度之系統及方法 |
| TWI525987B (zh) | 2010-03-10 | 2016-03-11 | 杜比實驗室特許公司 | 在單一播放模式中組合響度量測的系統 |
| EP2381574B1 (en) | 2010-04-22 | 2014-12-03 | Fraunhofer-Gesellschaft zur Förderung der Angewandten Forschung e.V. | Apparatus and method for modifying an input audio signal |
| JP2012010311A (ja) * | 2010-05-26 | 2012-01-12 | Sony Corp | 送信装置、送信方法、受信装置、受信方法および送受信システム |
| US20120033819A1 (en) | 2010-08-06 | 2012-02-09 | Samsung Electronics Co., Ltd. | Signal processing method, encoding apparatus therefor, decoding apparatus therefor, and information storage medium |
| MY156027A (en) * | 2010-08-12 | 2015-12-31 | Fraunhofer Ges Forschung | Resampling output signals of qmf based audio codecs |
| JP5903758B2 (ja) | 2010-09-08 | 2016-04-13 | ソニー株式会社 | 信号処理装置および方法、プログラム、並びにデータ記録媒体 |
| TWI800092B (zh) * | 2010-12-03 | 2023-04-21 | 美商杜比實驗室特許公司 | 音頻解碼裝置、音頻解碼方法及音頻編碼方法 |
| US8989884B2 (en) | 2011-01-11 | 2015-03-24 | Apple Inc. | Automatic audio configuration based on an audio output device |
| CN103443854B (zh) | 2011-04-08 | 2016-06-08 | 杜比实验室特许公司 | 用于混合来自两个编码位流的音频节目的元数据的自动配置 |
| JP2012235310A (ja) | 2011-04-28 | 2012-11-29 | Sony Corp | 信号処理装置および方法、プログラム、並びにデータ記録媒体 |
| CN103582913B (zh) * | 2011-04-28 | 2016-05-11 | 杜比国际公司 | 有效内容分类及响度估计 |
| US20120287999A1 (en) | 2011-05-11 | 2012-11-15 | Microsoft Corporation | Syntax element prediction in error correction |
| US8965774B2 (en) | 2011-08-23 | 2015-02-24 | Apple Inc. | Automatic detection of audio compression parameters |
| JP5845760B2 (ja) | 2011-09-15 | 2016-01-20 | ソニー株式会社 | 音声処理装置および方法、並びにプログラム |
| JP2013102411A (ja) | 2011-10-14 | 2013-05-23 | Sony Corp | 音声信号処理装置、および音声信号処理方法、並びにプログラム |
| AU2012351565B2 (en) | 2011-12-15 | 2015-09-03 | Fraunhofer-Gesellschaft Zur Foerderung Der Angewandten Forschung E.V. | Apparatus, method and computer programm for avoiding clipping artefacts |
| TWI517142B (zh) | 2012-07-02 | 2016-01-11 | Sony Corp | Audio decoding apparatus and method, audio coding apparatus and method, and program |
| EP2757558A1 (en) | 2013-01-18 | 2014-07-23 | Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. | Time domain level adjustment for audio signal decoding or encoding |
| EP2948947B1 (en) | 2013-01-28 | 2017-03-29 | Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. | Method and apparatus for normalized audio playback of media with and without embedded loudness metadata on new media devices |
| 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 |
| JP2015050685A (ja) | 2013-09-03 | 2015-03-16 | ソニー株式会社 | オーディオ信号処理装置および方法、並びにプログラム |
| JP6531649B2 (ja) | 2013-09-19 | 2019-06-19 | ソニー株式会社 | 符号化装置および方法、復号化装置および方法、並びにプログラム |
| 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 |
| CN105849801B (zh) | 2013-12-27 | 2020-02-14 | 索尼公司 | 解码设备和方法以及程序 |
| US9608588B2 (en) | 2014-01-22 | 2017-03-28 | Apple Inc. | Dynamic range control with large look-ahead |
| CA2942743C (en) | 2014-03-25 | 2018-11-13 | Fraunhofer-Gesellschaft Zur Forderung Der Angewandten Forschung E.V. | Audio encoder device and an audio decoder device having efficient gain coding in dynamic range control |
| US9654076B2 (en) | 2014-03-25 | 2017-05-16 | Apple Inc. | Metadata for ducking control |
| EP3800898B1 (en) | 2014-05-28 | 2023-07-19 | Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. | Data processor and transport of user control data to audio decoders and renderers |
| MX369767B (es) | 2014-05-30 | 2019-11-21 | Sony Corp | Dispositivo de procesamiento de informacion y metodo de procesamiento de informacion. |
| EP3163570A4 (en) | 2014-06-30 | 2018-02-14 | Sony Corporation | Information processor and information-processing method |
| 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 |
| BR112017025552B1 (pt) | 2015-05-29 | 2023-01-24 | Fraunhofer - Gesellschaft Zur Förderung Der Angewandten Forschung E.V | Dispositivo e método para controle de volume e sintonizador de rádio |
| ES2936089T3 (es) | 2015-06-17 | 2023-03-14 | Fraunhofer Ges Forschung | Control de intensidad del sonido para interacción del usuario en sistemas de codificación de 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 |
-
2014
- 2014-01-15 UA UAA201503505A patent/UA112249C2/uk unknown
- 2014-01-15 KR KR1020217013811A patent/KR102488704B1/ko active IP Right Grant
- 2014-01-15 BR BR122020020608-0A patent/BR122020020608B1/pt active IP Right Grant
- 2014-01-15 KR KR1020157009559A patent/KR102192755B1/ko active IP Right Grant
- 2014-01-15 HU HUE14740284A patent/HUE036119T2/hu unknown
- 2014-01-15 BR BR122015008454-7A patent/BR122015008454B1/pt active IP Right Grant
- 2014-01-15 RU RU2016119385A patent/RU2713609C2/ru active
- 2014-01-15 BR BR122016011963-7A patent/BR122016011963B1/pt active IP Right Grant
- 2014-01-15 MY MYPI2018002421A patent/MY193854A/en unknown
- 2014-01-15 JP JP2015537032A patent/JP6212565B2/ja active Active
- 2014-01-15 CN CN201710860453.5A patent/CN107657959B/zh active Active
- 2014-01-15 MX MX2016004803A patent/MX343571B/es unknown
- 2014-01-15 KR KR1020177016786A patent/KR102183712B1/ko active IP Right Grant
- 2014-01-15 IL IL287218A patent/IL287218B/en unknown
- 2014-01-15 MX MX2021011251A patent/MX2021011251A/es unknown
- 2014-01-15 ES ES16164479.4T patent/ES2667871T3/es active Active
- 2014-01-15 US US14/434,528 patent/US9916838B2/en active Active
- 2014-01-15 SG SG11201502405RA patent/SG11201502405RA/en unknown
- 2014-01-15 KR KR1020157009454A patent/KR101637897B1/ko active IP Right Grant
- 2014-01-15 MX MX2016004804A patent/MX356196B/es unknown
- 2014-01-15 UA UAA201606020A patent/UA122050C2/uk unknown
- 2014-01-15 MX MX2018006149A patent/MX2018006149A/es unknown
- 2014-01-15 KR KR1020237001019A patent/KR20230011500A/ko not_active Application Discontinuation
- 2014-01-15 AU AU2014207590A patent/AU2014207590B2/en active Active
- 2014-01-15 SG SG10201604643RA patent/SG10201604643RA/en unknown
- 2014-01-15 EP EP17173020.3A patent/EP3244406B1/en active Active
- 2014-01-15 RU RU2015113788/08A patent/RU2589362C1/ru active
- 2014-01-15 KR KR1020167005828A patent/KR102153278B1/ko active IP Right Grant
- 2014-01-15 RU RU2016119393A patent/RU2719690C2/ru active
- 2014-01-15 WO PCT/US2014/011672 patent/WO2014113465A1/en active Application Filing
- 2014-01-15 KR KR1020207033614A patent/KR102251763B1/ko active IP Right Grant
- 2014-01-15 UA UAA201606019A patent/UA122560C2/uk unknown
- 2014-01-15 KR KR1020167015999A patent/KR102158002B1/ko active IP Right Grant
- 2014-01-15 PL PL14740284T patent/PL2901449T3/pl unknown
- 2014-01-15 BR BR122020018591-0A patent/BR122020018591B1/pt active IP Right Grant
- 2014-01-15 ES ES17173020T patent/ES2843744T3/es active Active
- 2014-01-15 ES ES14740284.6T patent/ES2660487T3/es active Active
- 2014-01-15 EP EP20211869.1A patent/EP3822970A1/en active Pending
- 2014-01-15 CN CN201480002687.0A patent/CN104737228B/zh active Active
- 2014-01-15 CA CA2888350A patent/CA2888350C/en active Active
- 2014-01-15 ES ES16164487T patent/ES2749089T3/es active Active
- 2014-01-15 MY MYPI2015701028A patent/MY183382A/en unknown
- 2014-01-15 BR BR112015007723-4A patent/BR112015007723B1/pt active IP Right Grant
- 2014-01-15 MX MX2015004468A patent/MX339611B/es active IP Right Grant
- 2014-01-15 IL IL293618A patent/IL293618A/en unknown
- 2014-01-15 DK DK14740284.6T patent/DK2901449T3/en active
- 2014-01-15 EP EP14740284.6A patent/EP2901449B1/en active Active
- 2014-01-15 TR TR2018/02631T patent/TR201802631T4/tr unknown
- 2014-01-16 TW TW109117299A patent/TWI754286B/zh active
- 2014-01-16 TW TW103101619A patent/TWI524329B/zh active
- 2014-01-16 TW TW106112038A patent/TWI611395B/zh active
- 2014-01-16 TW TW110149670A patent/TWI811934B/zh active
- 2014-01-16 TW TW106115507A patent/TWI611396B/zh active
- 2014-01-16 TW TW107123341A patent/TWI666628B/zh active
- 2014-01-16 TW TW108114777A patent/TWI696171B/zh active
- 2014-01-16 TW TW106137433A patent/TWI636454B/zh active
- 2014-01-16 TW TW104142267A patent/TWI590231B/zh active
-
2015
- 2015-03-04 IL IL237561A patent/IL237561A/en active IP Right Grant
- 2015-04-09 MX MX2022013535A patent/MX2022013535A/es unknown
-
2016
- 2016-01-05 HK HK16100034.0A patent/HK1212091A1/xx unknown
- 2016-07-05 JP JP2016133169A patent/JP6442443B2/ja active Active
- 2016-07-05 JP JP2016133170A patent/JP6371340B2/ja active Active
-
2017
- 2017-04-03 US US15/478,049 patent/US9911426B2/en active Active
- 2017-04-19 US US15/491,661 patent/US9905237B2/en active Active
- 2017-04-25 JP JP2017085923A patent/JP6472481B2/ja active Active
- 2017-09-29 JP JP2017190117A patent/JP6561097B2/ja active Active
- 2017-11-20 US US15/818,102 patent/US10672413B2/en active Active
- 2017-11-30 IL IL256016A patent/IL256016B/en active IP Right Grant
- 2017-11-30 IL IL256015A patent/IL256015B/en active IP Right Grant
-
2018
- 2018-01-23 US US15/877,808 patent/US20180151188A1/en not_active Abandoned
- 2018-04-04 HK HK18104468.5A patent/HK1245490A1/zh unknown
- 2018-05-16 IL IL25941218A patent/IL259412B/en active IP Right Grant
- 2018-07-03 HK HK18108488.2A patent/HK1248913A1/zh unknown
-
2019
- 2019-07-22 JP JP2019134480A patent/JP6641058B2/ja active Active
- 2019-09-05 IL IL269138A patent/IL269138B/en active IP Right Grant
- 2019-12-26 JP JP2019235970A patent/JP6929345B2/ja active Active
-
2020
- 2020-05-03 IL IL274397A patent/IL274397B/en active IP Right Grant
- 2020-05-28 US US16/886,227 patent/US20200357422A1/en not_active Abandoned
-
2021
- 2021-02-02 IL IL280583A patent/IL280583B/en unknown
- 2021-08-10 JP JP2021130749A patent/JP7371067B2/ja active Active
-
2023
- 2023-07-20 JP JP2023117942A patent/JP2023134751A/ja active Pending
Also Published As
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10672413B2 (en) | Decoding of encoded audio bitstream with metadata container located in reserved data space | |
| EP3082128B1 (en) | Audio decoder with program loudness and boundary metadata |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FG | Grant or registration |