DE202013001075U1 - Audio-Codierer und Decodierer mit Lautheits-Verarbeitugszustands-Metadaten - Google Patents

Audio-Codierer und Decodierer mit Lautheits-Verarbeitugszustands-Metadaten Download PDF

Info

Publication number
DE202013001075U1
DE202013001075U1 DE202013001075U DE202013001075U DE202013001075U1 DE 202013001075 U1 DE202013001075 U1 DE 202013001075U1 DE 202013001075 U DE202013001075 U DE 202013001075U DE 202013001075 U DE202013001075 U DE 202013001075U DE 202013001075 U1 DE202013001075 U1 DE 202013001075U1
Authority
DE
Germany
Prior art keywords
audio
loudness
lpsm
metadata
bitstream
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE202013001075U
Other languages
English (en)
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Dolby Laboratories Licensing Corp
Original Assignee
Dolby Laboratories Licensing Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Dolby Laboratories Licensing Corp filed Critical Dolby Laboratories Licensing Corp
Publication of DE202013001075U1 publication Critical patent/DE202013001075U1/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03G—CONTROL OF AMPLIFICATION
    • H03G5/00—Tone control or bandwidth control in amplifiers
    • H03G5/005—Tone control or bandwidth control in amplifiers of digital signals
    • 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)
  • Computational Linguistics (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • Acoustics & Sound (AREA)
  • Multimedia (AREA)
  • Stereophonic System (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)

Abstract

Eine Audioverarbeitungsvorrichtung, die aufweist: einen Eingangspufferspeicher zum Speichern zumindest eines Rahmens eines codierten Audiobitstroms, der Lautheits-Verarbeitungszustands-Metadaten (LPSM – Loudness Processing State Metadata) und Audiodaten aufweist; einen Parser, der mit dem Eingangspufferspeicher gekoppelt ist, zum Extrahieren des codierten Audiobitstroms und/oder der LPSM; einen AC-3- oder E-AC-3-Decodierer, der mit dem Parser gekoppelt ist, zum Erzeugen eines Stroms von decodierten Audiodaten; und einen Ausgangspufferspeicher, der mit dem Decodierer gekoppelt ist, zum Speichern der decodierten Audiodaten.

Description

  • QUERVERWEIS ZU VERWANDTEN ANMELDUNGEN
  • Die vorliegende Anmeldung beansprucht Priorität zu der vorläufigen US-Patentanmeldung Nr. 61/754, 882, eingereicht am 21. Januar 2013 mit dem Titel „Audio Encoder and Decoder with Loudness Processing State Metadata” von Michael Ward und Jeffrey Riedmiller.
  • TECHNISCHES GEBIET
  • Die Erfindung betrifft eine Audiosignalverarbeitung und insbesondere ein Codieren und Decodieren von Audiodaten-Bitströmen mit Metadaten, die für den Lautheits-Verarbeitungszustand von Audioinhalt indikativ sind. Einige Ausführungsbeispiele der Erfindung erzeugen oder decodieren Audiodaten in einem der Formate, die als Dolby Digital (AC-3), Dolby Digital Plus (Enhanced AC-3 oder E-AC-3), oder Dolby E bekannt sind.
  • HINTERGRUND DER ERFINDUNG
  • Dolby, Dolby Digital, Dolby Digital Plus und Dolby E sind Warenzeichen der Dolby Laboratories Licensing Corporation. Dolby Laboratories bietet proprietäre Implementierungen von AC-3 und E-AC-3, bekannt als Dolby Digital beziehungsweise Dolby Digital Plus.
  • Audiodatenverarbeitungseinheiten arbeiten typischerweise in einer blinden Art und Weise und achten nicht auf die Verarbeitungshistorie von Audiodaten, die stattfindet, bevor die Daten empfangen werden. Dies kann in einem Verarbeitungssystem funktionieren, in dem eine einzelne Entität die gesamte Audiodatenverarbeitung und -codierung für eine Vielzahl von Ziel-Mediawiedergabevorrichtungen durchführt, während eine Ziel-Mediawiedergabevorrichtung die gesamte Decodierung und Wiedergabe der codierten Audiodaten durchführt. Allerdings funktioniert diese blinde Verarbeitung nicht gut (oder überhaupt nicht) in Situationen, in denen eine Vielzahl von Audioverarbeitungseinheiten über ein diverses Netzwerk verteilt sind oder in einem Tandem (d. h. eine Kette) platziert sind und von denen erwartet wird, ihre jeweiligen Typen von Audioverarbeitung optimal durchzuführen. Zum Beispiel können einige Audiodaten für Hochleistungs-Mediasysteme codiert sein und müssen eventuell in eine reduzierte Form, die für eine mobile Vorrichtung geeignet ist, entlang einer Medienverarbeitungskette umgewandelt werden. Demgemäß kann eine Audioverarbeitungseinheit unnötigerweise einen Typ einer Verarbeitung auf den Audiodaten durchführen, der bereits durchgeführt wurde. Zum Beispiel kann eine Lautstärkeabgleichungseinheit eine Verarbeitung auf einem Eingangs-Audio-Clip durchführen, unabhängig davon, ob die gleiche oder eine ähnliche Lautstärkeabgleichung früher auf dem Eingangs-Audio-Clips bereits durchgeführt wurde oder nicht. Als ein Ergebnis kann die Lautstärkeabgleichungseinheit eine Abgleichung durchführen, auch wenn dies nicht notwendig ist. Diese unnötige Verarbeitung kann auch eine Verschlechterung und/oder das Entfernen von spezifischen Merkmalen verursachen, während der Inhalt der Audiodaten wiedergegeben wird.
  • Ein typischer Strom von Audiodaten umfasst sowohl Audioinhalt (zum Beispiel einen oder mehrere Kanäle von Audioinhalt) und Metadaten, die zumindest eine Charakteristik des Audioinhalts angeben. Zum Beispiel gibt es in einem AC-3-Bitstrom mehrere Audio-Metadaten-Parameter, die insbesondere vorgesehen sind zur Verwendung bei einem Ändern des Klangs des Programms, das an eine Hörumgebung geliefert wird. Einer der Metadaten-Parameter ist der DIALNORM-Parameter, der vorgesehen ist, um den mittleren Pegel eines Dialogs anzugeben, der in einem Audioprogramm auftritt, und verwendet wird, um einen Audio-Abspielsignalpegel zu bestimmen.
  • Während eines Abspielens eines Bitstroms, der eine Sequenz von verschiedenen Audioprogrammsegmenten aufweist (die jeweils einen anderen DIALNORM-Parameter haben), verwendet ein AC-3-Decodierer den DIALNORM-Parameter jedes Segments, um einen Typ einer Lautheits-Verarbeitung durchzuführen, in der er den Abspielpegel oder die Lautheit derart modifiziert, dass die wahrgenommene Lautheit des Dialogs der Sequenz von Segmenten auf einem konsistenten Pegel ist. Jedes codierte Audiosegment (Element) in einer Sequenz von codierten Audioelementen würde (im Allgemeinen) einen anderen DIALNORM-Parameter haben und der Decodierer würde den Pegel von jedem der Elemente derart skalieren, dass der Abspielpegel oder die Lautheit des Dialogs für jedes Element gleich oder sehr ähnlich ist, auch wenn dies eine Anwendung von unterschiedlich viel Verstärkung auf verschiedene der Elemente während eines Abspielens erforderlich machen kann.
  • DIALNORM wird typischerweise durch einen Benutzer eingestellt und wird nicht automatisch erzeugt, obwohl es einen Standard-DIALNORM-Wert gibt, wenn kein Wert durch den Benutzer eingestellt wird. Zum Beispiel kann ein Inhalt-Erzeuger Lautheitsmessungen mit einer Vorrichtung durchführen, die extern zu einem AC-3-Codierer ist, und dann das Ergebnis (das die Lautheit des gesprochenen Dialogs eines Audioprogramms angibt) an den Codierer übertragen, um den DIALNORM-Wert zu setzen. Somit gibt es einen Verlass auf den Inhalt-Ersteller, den DIALNORM-Parameter richtig einzustellen.
  • Es gibt mehrere verschiedene Gründe, warum der DIALNORM-Parameter in einem AC-3-Bitstrom falsch sein kann. Erstens hat jeder AC-3-Codierer einen Standard-DIALNORM-Wert, der während der Erzeugung des Bitstroms verwendet wird, wenn ein DIALNORM-Wert nicht durch den Inhalt-Erzeuger gesetzt wird. Dieser Standardwert kann erheblich verschieden sein von dem tatsächlichen Dialog-Lautheitspegel des Audios. Zweitens, auch wenn ein Inhalt-Erzeuger eine Lautheit misst und den DIALNORM-Wert entsprechend setzt, kann ein Lautheitsmessungsalgorithmus oder eine Messvorrichtung verwendet worden sein, der/die nicht dem empfohlenen AC-3-Lautheitsmessverfahren entspricht, was zu einem falschen DIALNORM-Wert führt. Drittens, auch wenn ein AC-3-Bitstrom mit dem gemessenen DIALNORM-Wert erzeugt und durch den Inhalt-Erzeuger korrekt eingestellt wurde, kann er während einer Übertragung und/oder Speicherung des Bitstroms auf einen falschen Wert geändert worden sein. Zum Beispiel ist es in Fernseh-Broadcast-Anwendungen nicht ungewöhnlich, dass AC-3-Bitströme decodiert, modifiziert und dann wieder codiert werden unter Verwendung von fehlerhafter DIALNORM-Metadaten-Information. So kann ein DIALNORM-Wert, der in einem AC-3-Bitstrom enthalten ist, falsch oder ungenau sein und kann daher einen negativen Einfluss auf die Qualität des Hörerlebnisses haben.
  • Weiter gibt der DIALNORM-Parameter nicht den Lautheits-Verarbeitungszustand von entsprechenden Audiodaten an (zum Beispiel welche(r) Typ(en) einer Lautheits-Verarbeitung auf den Audiodaten durchgeführt wurde(n)). Bis zu der vorliegenden Erfindung umfasste ein Audiobitstrom keine Metadaten, die indikativ sind für den Lautheits-Verarbeitungszustand (zum Beispiel Typ(en) einer Lautheits-Verarbeitung angewendet auf den Audioinhalt des Audiobitstroms oder den Lautheits-Verarbeitungszustand und die Lautheit des Audioinhalts der Bitstroms in einem Format eines Typs, der in der vorliegenden Offenbarung beschrieben wird). Lautheits-Verarbeitungszustands-Metadaten in einem solchen Format sind nützlich, um eine adaptive Lautheits-Verarbeitung eines Audiobitstroms und/oder eine Verifizierung einer Gültigkeit des Lautheits-Verarbeitungszustands und der Lautheit des Audioinhalts in einer besonders effizienten Art und Weise zu erleichtern.
  • Die Internationale PCT-Anmeldung mit der Veröffentlichungsnummer WO 2012/075246 A2 , mit dem internationalen Anmeldetag 1. Dezember 2011 und der Anmelderin der vorliegenden Anmeldung erteilt, offenbart Verfahren und Systeme zum Erzeugen, Decodieren und Verarbeitung von Audio-Bitströmen mit Metadaten, die den Verarbeitungszustand (zum Beispiel den Lautheits-Verarbeitungszustand) und Eigenschaften (zum Beispiel Lautheit) eines Audioinhalts angeben. Dieses Referenzdokument beschreibt auch eine adaptive Verarbeitung des Audioinhalts der Bitströme unter Verwendung der Metadaten und eine Verifizierung einer Gültigkeit des Lautheits-Verarbeitungszustands und der Lautheit von Audioinhalt der Bitströme unter Verwendung der Metadaten. Allerdings beschreibt dieses Dokument keine Aufnahme von Metadaten (LPSM) in einen Audiobitstrom, die für den Lautheits-Verarbeitungszustand und die Lautheit von Audioinhalt in einem Format eines Typs indikativ sind, der in der vorliegenden Offenbarung beschrieben wird. Wie angeführt, sind LPSM in einem solchen Format nützlich, um eine adaptive Lautheits-Verarbeitung des Stroms und/oder eine Verifizierung einer Gültigkeit des Lautheits-Verarbeitungszustands und der Lautheit des Audioinhalts in einer besonders effizienten Art und Weise zu erleichtern.
  • Obwohl die vorliegende Erfindung nicht auf eine Verwendung mit einem AC-3-Bitstrom, einem E-AC-3-Bitstrom oder einem Dolby-E-Bitstrom beschränkt ist, wird sie zur Einfachheit in Ausführungsbeispielen beschrieben, in denen sie einen derartigen Bitstrom erzeugt, decodiert oder anderweitig verarbeitet, der Lautheits-Verarbeitungszustands-Metadaten umfasst.
  • Ein codierter AC-3-Bitstrom weist Metadaten auf und einen bis sechs Kanäle von Audioinhalt. Bei dem Audioinhalt handelt es sich um Audiodaten, die unter Verwendung einer Wahrnehmungsaudiocodierung komprimiert wurden. Die Metadaten umfassen mehrere Audio-Metadaten-Parameter, die zur Verwendung bei einem Verändern des Klangs eines Programms vorgesehen sind, das an eine Hörumgebung geliefert wird.
  • Details einer AC-3(auch bekannt als Dolby Digital)-Codierung sind weithin bekannt und werden in vielen veröffentlichten Referenzdokumenten dargelegt, einschließlich der folgenden:
    ATSC Standard A52/A: Digital Audio Compression Standard (AC-3), Revision A, Advanced Television Systems Committee, 20. August 2001; und
    United States Patente 5,583,962 ; 5,632,005 ; 5,633,981 ; 5,727,119 ; und 6,021,386 .
  • Details einer Dolby Digital Plus (E-AC-3) Codierung werden dargelegt in „Introduction to Dolby Digital Plus, an Enhancement to the Dolby Digital Coding System," AES Convention Paper 6196, 117. AES Convention, 28. Oktober 2004. Details einer Dolby-E-Codierung werden dargelegt in „Efficient Bit Allocation, Quantization, and Coding in an Audio Distribution System", AES Preprint 5068, 107. AES Conference, August 1999 und „Professional Audio Coder Optimized for Use with Video", AES Preprint 5033, 10. AES Conference August 1999.
  • Jeder Rahmen eines AC-3-codierten Audiobitstroms enthält Audioinhalt und Metadaten für 1536 Abtastwerte von digitalem Audio. Für eine Abtastrate von 48 kHz entspricht dies 32 Millisekunden von digitalem Audio oder einer Rate von 31,25 Rahmen pro Sekunde Audio.
  • Jeder Rahmen eines E-AC-3-codierten Audiobitstroms enthält Audioinhalt und Metadaten für 256, 512, 768 oder 1536 Abtastwerte von digitalem Audio, abhängig davon, ob der Rahmen einen, zwei, drei beziehungsweise sechs Blöcke von Audiodaten enthält. Für eine Abtastrate von 48 kHz entspricht dies 5,333, 10,667, 16 oder 32 Millisekunden von digitalem Audio oder einer Rate von 189,9, 93,75, 62,5 beziehungsweise 31,25 Rahmen pro Sekunde von Audio.
  • Wie in 4 gezeigt, ist jeder AC-3-Rahmen in Abschnitte (Segmente) unterteilt, einschließlich: ein Abschnitt Synchronisationsinformation (SI – Synchronization Information), der (wie in 5 gezeigt) ein Synchronisationswort (SW – Synchronization Word) und das erste von zwei Fehlerkorrekturwörtern (CRC1) enthält; einen Abschnitt Bitstrom-Information (BSI – Bitstream Information), der die meisten der Metadaten enthält; sechs Audio-Blöcke (AB0 bis AB5), die Datenkomprimierten Audioinhalt enthalten (und auch Metadaten umfassen können); Ausschuss-Bits (W – Waste), die alle nicht-verwendeten Bits enthalten, die übrig bleiben, nachdem der Audioinhalt komprimiert ist; einen Abschnitt Hilfs(AUX – Auxiliary)-Information, der mehr Metadaten enthalten kann; und das zweite von zwei Fehlerkorrekturwörtern (CRC2).
  • Wie in 7 gezeigt, ist jeder E-AC-3-Rahmen in Abschnitte (Segmente) unterteilt, einschließlich: ein Abschnitt Synchronisationsinformation (SI – Synchronization Information), der (wie in 5 gezeigt) ein Synchronisationswort (SW – Synchronization Word) enthält; einen Abschnitt Bitstrom-Information (BSI – Bitstream Information), der die meisten der Metadaten enthält; zwischen einem und sechs Audio-Blöcken (AB0 bis AB5), die Daten-komprimierten Audioinhalt enthalten (und auch Metadaten umfassen können); Ausschuss-Bits (W – Waste), die alle nicht-verwendeten Bits enthalten, die übrig bleiben, nachdem der Audioinhalt komprimiert ist; einen Abschnitt Hilfs(AUX – Auxiliary)-Information, der mehr Metadaten enthalten kann; und ein Fehlerkorrekturwort (CRC).
  • In einem AC-3(oder E-AC-3)-Bitstrom gibt es mehrere Audio-Metadaten-Parameter, die spezifisch zur Verwendung bei einem Ändern des Klangs bzw. des erzeugten Schallsignals des Programms vorgesehen sind, das an eine Hörumgebung geliefert wird. Einer der Metadaten-Parameter ist der DIALNORM-Parameter, der in dem BSI-Segment enthalten ist.
  • Wie in 6 gezeigt, umfasst das BSI-Segment eines AC-3-Rahmens einen Fünf-Bit-Parameter („DIALNORM”), der den DIALNORM-Wertfür das Programm angibt. Ein Fünf-Bit-Parameter („DIALNORM2”), der den DIALNORM-Wert für ein zweites Audioprogramm angibt, das in demselben AC-3-Rahmen getragen wird, ist enthalten, wenn der Audiocodiermodus („acmod”) des AC-3-Rahmens „0” ist, was anzeigt, dass eine Dual-Mono- oder „1 + 1”-Kanal-Konfiguration verwendet wird.
  • Das BSI-Segment umfasst auch ein Flag („addbsie”), das das Vorhandensein (oder Fehlen) von zusätzlicher Bitstrom-Information nach dem „addbsie”-Bit angibt, einen Parameter („addbsil”), der die Länge einer zusätzlichen Bitstrom-Information nach dem „addbsil”-Wert angibt, und bis zu 64 Bits von zusätzlicher Bitstrom-Information („addbsi”) nach dem „addbsil”-Wert.
  • Das BSI-Segment umfasst andere Metadaten-Werte, die nicht ausdrücklich in 6 gezeigt werden.
  • Kurze Beschreibung der Erfindung
  • In einer Klasse von Ausführungsbeispielen betrifft die Erfindung ein Codieren von Audiodaten, um einen codierten Audiobitstrom zu erzeugen, einschließlich Aufnehmen von Lautheits-Verarbeitungszustands-Metadaten (LPSM – Loudness Processing State Metadata) in zumindest ein Segment von zumindest einem Rahmen des Bitstroms und von Audiodaten in zumindest ein anderes Segment des Rahmens. In typischen Ausführungsbeispielen werden die Audiodaten mit den LPSM in jedem Rahmen des Bitstroms gemultiplext. In einer typischen Decodierung extrahiert ein Decodierer die LPSM aus dem Bitstrom (einschließlich durch Analysieren bzw. Parsen und Demultiplexen der LPSM und der Audiodaten) und verarbeitet die Audiodaten, um einen Strom von decodierten Audiodaten zu erzeugen (und führt in einigen Fällen auch zumindest eine durch aus einer adaptiven Lautheits-Verarbeitung der Audiodaten oder einer Authentifizierung und/oder Validierung von LPSM und/oder Audiodaten unter Verwendung der LPSM). In einigen Fällen werden die decodierten Audiodaten und die LPSM von dem Decodierer an einen Nach- bzw. Postprozessor weitergeleitet, der konfiguriert ist, eine adaptive Lautheits-Verarbeitung auf den decodierten Audiodaten unter Verwendung der LPSM durchzuführen. Die adaptive Lautheits-Verarbeitung kann umfassen oder bestehen aus einer Dynamikbereich- und/oder Lautheits-Steuerung (zum Beispiel Dialog-Lautheits-Abgleichung oder andere Lautstärkeabgleichung). In Reaktion auf LPSM kann eine Audioverarbeitungseinheit eine Lautheits-Verarbeitung deaktivieren, die bereits auf entsprechendem Audioinhalt durchgeführt wurde (wie durch die LPSM angegeben).
  • Gemäß einem Aspekt der Erfindung ist eine Audioverarbeitungsvorrichtung vorgesehen. Die Audioverarbeitungsvorrichtung weist auf einen Eingangspufferspeicher zum Speichern zumindest eines Rahmens eines codierten Audiobitstroms, der Lautheits-Verarbeitungszustands-Metadaten (LPSM – Loudness Processing State Metadata) und Audiodaten aufweist; einen Parser, der mit dem Eingangspufferspeicher gekoppelt ist, zum Extrahieren des codierten Audiobitstroms und/oder der LPSM; einen AC-3- oder E-AC-3-Decodierer, der mit dem Parser gekoppelt ist, zum Erzeugen eines Stroms von decodierten Audiodaten; und einen Ausgangspufferspeicher, der mit dem Decodierer gekoppelt ist, zum Speichern der decodierten Audiodaten.
  • Die Audioverarbeitungsvorrichtung kann weiter einen Lautheitsprozessor aufweisen, der mit dem AC-3- oder E-AC-3-Decodierer gekoppelt ist, zum Durchführen einer adaptiven Lautheits-Verarbeitung des Stroms von decodierten Audiodaten unter Verwendung der LPSM.
  • Die Audioverarbeitungsvorrichtung kann weiter einen Audio-Zustandsvalidierer aufweisen, der mit dem AC-3- oder E-AC-3-Decodierer gekoppelt ist, zum Authentifizieren und/oder Validieren der LPSM und/oder des Stroms von decodierten Audiodaten unter Verwendung der LPSM. Der Audio-Zustandsvalidierer kann weiter mit dem Lautheitsprozessor gekoppelt sein, um die adaptive Lautheits-Verarbeitung des Lautheitsprozessors zu steuern.
  • Die Audioverarbeitungsvorrichtung kann weiter einen Postprozessor aufweisen, der mit dem AC-3- oder E-AC-3-Decodierer gekoppelt ist, zum Durchführen einer adaptiven Lautheits-Verarbeitung auf dem Strom von decodierten Audiodaten unter Verwendung der LPSM.
  • Die Audioverarbeitungsvorrichtung kann weiter einen Audio-Zustandsvalidierer aufweisen, der mit dem AC-3- oder E-AC-3-Decodierer gekoppelt ist, zum Authentifizieren und/oder Validieren der LPSM und/oder des Stroms von decodierten Audiodaten unter Verwendung der LPSM. Der Audio-Zustandsvalidierer kann weiter mit dem Lautheitsprozessor und dem Postprozessor gekoppelt sein, um die adaptive Lautheits-Verarbeitung des Lautheitsprozessors und des Postprozessors zu steuern.
  • Die LPSM können in einem Container enthalten sein, der ein oder mehrere Lautheits-Verarbeitungszustands-Metadaten aufweist, die sich nach einem Header in dem zumindest einen Rahmen befinden.
  • Die LPSM können einen Lautheitsregulierungstyp-Schlitz und/oder einen Lautheitskorrekturtyp-Schlitz aufweisen.
  • Die Audioverarbeitungsvorrichtung kann weiter eine Kommunikationsschnittstelle aufweisen, die mit dem Eingangspufferspeicher gekoppelt ist, zum Empfangen des zumindest einen Rahmens des codierten Audiobitstroms.
  • Der zumindest eine Rahmen des codierten Audiobitstroms kann weiter Schutzbits aufweisen, die mit einem Hash-basierten Nachrichtenauthentifizierungscode (MAC – Message Authentication Code) assoziiert sind. Die Audioverarbeitungsvorrichtung kann weiter einen Audio-Zustandsvalidierer aufweisen, der mit dem AC-3- oder E-AC-3-Decodierer gekoppelt ist, zum Authentifizieren der Audiodaten unter Verwendung der Schutzbits. Der Hash-basierte Nachrichtenauthentifizierungscode kann aus einem Verschlüsselungsalgorithmus erzeugt werden, der ein SHA-2-Algorithmus sein kann.
  • Die Audioverarbeitungsvorrichtung kann weiter einen Lautheitsprozessor aufweisen, der mit dem AC-3- oder E-AC-3-Decodierer gekoppelt ist, zum Durchführen einer adaptiven Lautheits-Verarbeitung des Stroms von decodierten Audiodaten unter Verwendung der LPSM. Die adaptive Lautheits-Verarbeitung kann deaktiviert sein, wenn der Audio-Zustandsvalidierer die Schutzbits nicht authentifiziert.
  • Lautheits-Verarbeitungszustands-Metadaten, die in einem Audiobitstrom in Übereinstimmung mit typischen Ausführungsbeispielen der Erfindung eingebettet sind, können authentifiziert und validiert werden, um zum Beispiel Lautheits-Regulierungs- bzw. Überwachungsentitäten zu ermöglichen, zu verifizieren, ob eine Lautheit eines bestimmten Programms bereits innerhalb eines spezifizierten Bereichs ist und dass die entsprechenden Audiodaten selbst nicht modifiziert wurden (wodurch eine Übereinstimmung mit anwendbaren Regeln bzw. Vorschriften sichergestellt wird). Ein Lautheitswert, der in einem Datenblock enthalten ist, der die Lautheits-Verarbeitungszustands-Metadaten aufweist, kann ausgelesen werden, um dies zu verifizieren, anstelle eines erneuten Berechnens der Lautheit. In Reaktion auf LPSM kann eine Überwachungsstelle bestimmen, dass entsprechender Audioinhalt in Übereinstimmung (wie durch die LPSM angegeben) mit gesetzlichen und/oder regulatorischen Lautheits-Anforderungen ist (zum Beispiel die Regelungen, die im Rahmen des „Commercial Advertisement Loudness Mitigation Act”, auch bekannt als „CALM”-Gesetz, bekannt gegeben sind), ohne die Notwendigkeit zum Berechnen einer Lautheit des Audioinhalts.
  • Ein weiterer Aspekt der Erfindung ist eine Audioverarbeitungseinheit (APU – Audio Processing Unit). In einer weiteren Klasse von Ausführungsbeispielen ist die Erfindung eine APU, die einen Pufferspeicher (Puffer) umfasst, der zumindest einen Rahmen eines codierten Audiobitstroms speichert (zum Beispiel auf eine nicht-vergängliche bzw. nicht-transitorische Weise), der durch ein Ausführungsbeispiel der Erfindung erzeugt wurde. Beispiele von APUs umfassen Codierer (zum Beispiel Transcodierer), Decodierer, Codecs, Vorverarbeitungssysteme (Pre-Prozessoren), Nachverarbeitungssysteme (Postprozessoren), Audiobitstrom-Verarbeitungssysteme, und Kombinationen solcher Elemente, sind aber nicht darauf beschränkt.
  • In einer weiteren Klasse von Ausführungsbeispielen ist die Erfindung eine Audioverarbeitungseinheit (APU – Audio Processing Unit), die konfiguriert ist, einen codierten Audiobitstrom zu erzeugen, der Audiodaten-Segmente und Metadaten-Segmente aufweist, wobei die Audiodaten-Segmente Audiodaten angeben, und jedes von zumindest einigen der Metadaten-Segmente Lautheits-Verarbeitungszustands-Metadaten (LPSM – Loudness Processing State Metadata) umfasst. Typischerweise umfasst zumindest ein solches Metadaten-Segment in einem Rahmen des Bitstroms zumindest ein Segment der LPSM, das angibt, ob ein erster Typ einer Lautheits-Verarbeitung auf den Audiodaten des Rahmens (d. h. Audiodaten in zumindest einem Audiodaten-Segment des Rahmens) durchgeführt wurde, und zumindest ein anderes Segment der LPSM, das eine Lautheit von zumindest einigen der Audiodaten des Rahmens (zum Beispiel eine Dialog-Lautheit von zumindest einigen der Audiodaten des Rahmens, die für einen Dialog indikativ sind) angibt. In einem Ausführungsbeispiel dieser Klasse ist die APU ein Codierer, der konfiguriert ist, Eingangsaudio zu codieren, um codiertes Audio zu erzeugen, und die Audiodaten-Segmente umfassen das codierte Audio. In typischen Ausführungsbeispielen in dieser Klasse hat jedes der Metadaten-Segmente ein bevorzugtes Format, das hier beschrieben wird.
  • In einem bevorzugten Format ist der codierte Bitstrom ein AC-3-Bitstrom oder ein E-AC-3-Bitstrom und jedes der Metadaten-Segmente, das LPSM umfasst, ist als zusätzliche Bitstrom-Information in dem „addbsi”-Feld des Bitstrom-Information(„BSI – Bitstream Information”)-Segments eines Rahmens des Bitstroms enthalten. Jedes Metadaten-Segment mit LPSM hat das hier spezifizierte Format unter Bezugnahme auf die Tabellen 1 und 2 unten (d. h. es umfasst die Kernelemente, die in Tabelle 1 spezifiziert werden, oder eine Variation davon, gefolgt von einer Nutzlast-ID (die die Metadaten als LPSM identifiziert) und Nutzlastgrößenwerten, gefolgt von der Nutzlast (LPSM-Daten, die ein Format haben, wie in Tabelle 2 angegeben, oder ein Format, wie in einer Variation der Tabelle 2 angegeben, wie hier beschrieben).
  • In einem anderen bevorzugten Format ist der codierte Bitstrom ein AC-3-Bitstrom oder ein E-AC-3-Bitstrom und jedes der Metadaten-Segmente, das LPSM umfasst, ist in einem „addbsi”-Feld des Bitstrom-Information(„BSI”)-Segments eines Rahmens des Bitstroms enthalten, oder in einem auxdata-Feld (zum Beispiel das AUX-Segment, das in 4 gezeigt wird) am Ende eines Rahmens des Bitstroms. Ein Rahmen kann ein oder zwei Metadaten-Segment(e) umfassen, von denen jedes LPSM umfasst, und wenn der Rahmen zwei Metadaten-Segmente umfasst, ist eines in dem addbsi-Feld des Rahmens und das andere in dem AUX-Feld des Rahmens vorhanden. Jedes Metadaten-Segment mit LPSM hat das Format, das hier spezifiziert wird unter Bezugnahme auf die Tabellen 1 und 2 unten (d. h. es umfasst die Kernelemente, die in Tabelle 1 spezifiziert werden, oder eine Variation davon, gefolgt von einer Nutzlast-ID (die die Metadaten als LPSM identifiziert) und Nutzlastgrößenwerten, gefolgt von der Nutzlast (LPSM-Daten, die ein Format haben, wie in Tabelle 2 angegeben, oder ein Format, wie in einer Variation der Tabelle 2 angegeben, wie hier beschrieben).
  • In einem anderen bevorzugten Format ist der codierte Bitstrom ein Bitstrom, der nicht ein AC-3-Bitstrom oder ein E-AC-3-Bitstrom ist, und jedes der Metadaten-Segmente mit LPSM ist in einem Segment (oder Feld oder Schlitz) des Bitstroms enthalten, das zur Speicherung zusätzlicher Daten reserviert ist. Jedes Metadaten-Segment mit LPSM kann ein Format ähnlich oder identisch zu dem hier unter Bezugnahme auf die Tabellen 1 und 2 unten spezifizierten haben (d. h. es umfasst Kernelemente, die ähnlich oder identisch zu den in Tabelle 1 spezifizierten sind, gefolgt von einer Nutzlast-ID (die die Metadaten als LPSM identifiziert) und Nutzlastgrößenwerten, gefolgt von der Nutzlast (LPSM-Daten, die ein Format haben ähnlich oder identisch zu dem Format, das in Tabelle 2 angegeben wird oder eine Variation der Tabelle 2, wie hier beschrieben).
  • In einigen Ausführungsbeispielen weist der codierte Bitstrom eine Sequenz von Rahmen auf, wobei jeder der Rahmen ein Bitstrom-Information(„BSI”)-Segment umfasst mit einem „addbsi”-Feld (manchmal als Segment oder Schlitz bezeichnet) und einem auxdata-Feld oder -Schlitz (zum Beispiel ist der codierte Bitstrom ein AC-3-Bitstrom oder ein E-AC-3-Bitstrom), und weist Audiodaten-Segmente (zum Beispiel die AB0-AB5-Segmente des Rahmens, der in 4 gezeigt wird) und Metadaten-Segmente auf, wobei die Audiodatensegmente für Audiodaten indikativ sind, und jedes von zumindest einigen der Metadaten-Segmente Lautheits-Verarbeitungszustands-Metadaten (LPSM) umfasst. Die LPSM sind in dem Bitstrom in dem folgenden Format vorhanden. Jedes der Metadaten-Segmente mit LPSM ist in einem „addbsi”-Feld des BSI-Segments eines Rahmens des Bitstroms oder in einem auxdata-Feld eines Rahmens des Bitstroms enthalten. Ein Rahmen des Bitstroms kann ein oder zwei Metadaten-Segment(e) umfassen, von denen jedes LPSM umfasst, und wenn der Rahmen zwei Metadaten-Segmente umfasst, ist eines in dem addbsi-Feld des Rahmens und das andere in dem AUX-Feld des Rahmens vorhanden. Jedes Metadaten-Segment mit LPSM umfasst ein LPSM-Nutzlast(oder Container)-Segment mit dem folgenden Format: ein Header (typischerweise mit zumindest einem Identifikationswert, zum Beispiel die LPSM-Format-Version, Länge, Dauer, Anzahl und Teilstrom-Assoziationswerte, die in Tabelle 2 unten angegeben werden); und nach dem Header,
    zumindest ein Dialog-Anzeigewert (zum Beispiel Parameter „Dialog-Kanal/Kanäle” in Tabelle 2), der angibt, ob entsprechende Audiodaten Dialog angeben oder nicht Dialog angeben (zum Beispiel welche Kanäle von entsprechenden Audiodaten Dialog angeben). Der/Die Dialog-Anzeigewert(e) kann/können angeben, ob Dialog in einer Kombination von, oder allen, Kanälen der entsprechenden Audiodaten vorhanden ist;
    zumindest ein Lautheit-Vorschrifteneinhaltungs-Wert (zum Beispiel Parameter „Lautheit-Vorschriften-Typ” in Tabelle 2), der angibt, ob entsprechende Audiodaten mit einem angezeigten Satz von Lautheits-Vorschriften übereinstimmen;
    zumindest ein Lautheits-Verarbeitungswert (zum Beispiel einer oder mehrere der Parameter „Dialog-Gate-gesteuertes Lautheit-Korrektur-Flag”, „Lautheit-Korrektur-Typ” in Tabelle 2), der zumindest einen Typ einer Lautheits-Verarbeitung angibt, die auf den entsprechenden Audiodaten durchgeführt wurde; und
    zumindest ein Lautheitswert (zum Beispiel einer oder mehrere der Parameter „ITU relative Gate-gesteuerte Lautheit”, „ITU Sprache-Gate-gesteuerte Lautheit”, „ITU (EBU 3341) Kurzzeit 3 s Lautheit” und „Wahre Spitze” von Tabelle 2), der zumindest eine Lautheit (zum Beispiel Spitzen- oder durchschnittliche Lautheit) angibt, die für die entsprechenden Audiodaten charakteristisch ist.
  • In den Ausführungsbeispielen der Erfindung, die zumindest einen Lautheitswert, der für entsprechende Audiodaten indikativ ist, in Erwägung ziehen, verwenden oder erzeugen, kann/können der/die Lautheitswert(e) zumindest eine Lautheitsmesscharakteristik angeben, die verwendet wird, um die Lautheit und/oder den Dynamikbereich der Audiodaten zu verarbeiten.
  • In einigen Implementierungen hat jedes der Metadaten-Segmente in einem „addbsi”-Feld oder einem auxdata-Feld eines Rahmens des Bitstroms das folgende Format:
    ein Kern-Header (typischerweise mit einem Synchronisierungswort, das den Beginn des Metadaten-Segments identifiziert, gefolgt von Identifizierungswerten, zum Beispiel die Kernelement-Version, Länge und Dauer, Anzahl erweiterte Elemente, und Teilstrom-Assoziationswerte, in Tabelle 1 unten angegeben); und
    nach dem Kern-Header, zumindest ein Schutzwert (zum Beispiel ein HMAC-Digest und Audio-Fingerabdruck-Werte, wobei der HMAC-Digest ein 256-Bit-HMAC-Digest (unter Verwendung eines SHA-2-Algorithmus) sein kann, berechnet über die Audiodaten, das Kernelement, und alle erweiterten Elemente, eines gesamten Rahmens, wie in Tabelle 1 gezeigt), nützlich für zumindest eines aus einer Entschlüsselung, Authentifizierung oder Validierung von zumindest einem aus Lautheits-Verarbeitungszustands-Metadaten oder den entsprechenden Audiodaten); und
    ebenfalls nach dem Kern-Header, wenn das Metadaten-Segment LPSM umfasst, eine LPSM-Nutzlast-Identifikation („ID”) und LPSM-Nutzlastgrößenwerte, die folgende Metadaten als eine LPSM-Nutzlast identifizieren und eine Größe der LPSM-Nutzlast angeben. Das LPSM-Nutzlast-Segment (vorzugsweise mit dem oben spezifizierten Format) folgt der LPSM-Nutzlast-ID und den LPSM-Nutzlastgrößenwerten.
  • In einigen Ausführungsbeispielen des Typs, der in dem vorhergehenden Absatz beschrieben wurde, hat jedes der Metadaten-Segmente in dem auxdata-Feld (oder „addbsi”-Feld) des Rahmens drei Strukturebenen:
    eine Struktur auf hoher Ebene, einschließlich eines Flags, das anzeigt, ob das auxdata(oder addbsi)-Feld Metadaten umfasst, zumindest einen ID-Wert, der anzeigt, welche(r) Typ(en) von Metadaten vorhanden ist/sind, und typischerweise auch einen Wert, der angibt, wie viele Bits von Metadaten (zum Beispiel von jedem Typ) vorhanden sind (wenn Metadaten vorhanden sind). Ein Typ von Metadaten, die vorhanden sein können, ist LSPM, und ein anderer Typ von Metadaten, die vorhanden sein können, sind Medienforschungs-Metadaten (zum Beispiel „Nielsen Media Research”-Metadaten);
    eine Struktur einer mittleren Ebene, die ein Kernelement für jeden identifizierten Typ von Metadaten aufweist (zum Beispiel Kern-Header, Schutzwerte und Nutzlast-ID und Nutzlastgrößenwerte, zum Beispiel des oben angeführten Typs, für jeden identifizierten Typ von Metadaten); und
    eine Struktur einer unteren Ebene, die jede Nutzlast für ein Kernelement aufweist (zum Beispiel eine LPSM-Nutzlast, wenn eine durch das Kernelement als vorhanden identifiziert wird, und/oder eine Metadaten-Nutzlast eines anderen Typs, wenn eine durch das Kernelement als vorhanden identifiziert wird).
  • Die Datenwerte in einer derartigen Struktur mit drei Ebenen können verschachtelt sein. Zum Beispiel kann/können der/die Schutzwert(e) für eine LPSM-Nutzlast und/oder eine andere Metadaten-Nutzlast, identifiziert von einem Kernelement nach jeder Nutzlast, enthalten sein, die von dem Kernelement identifiziert wird (und somit nach dem Kern-Header des Kernelements). In einem Beispiel kann ein Kern-Header eine LPSM-Nutzlast identifizieren und eine weitere Metadaten-Nutzlast, eine Nutzlast-ID und Nutzlastgrößenwerte für die erste Nutzlast (zum Beispiel die LPSM-Nutzlast) können dem Kern-Header folgen, die erste Nutzlast selbst kann der ID und den Größenwerten folgen, die Nutzlast-ID und der Nutzlastgrößenwert für die zweite Nutzlast können der ersten Nutzlast folgen, die zweite Nutzlast selbst kann dieser ID und den Größenwerten folgen, und Schutzwert(e) für eine oder beide der Nutzlasten (oder für Kernelementwerte und einer oder beide der Nutzlasten) kann/können der letzten Nutzlast folgen.
  • In einigen Ausführungsbeispiele weist das Kernelement eines Metadaten-Segments in einem auxdata-Feld (oder „addbsi”-Feld) eines Rahmens einen Kern-Header auf (typischerweise mit Identifikationswerten, zum Beispiel Kernelementversion), und nach dem Kern-Header: Werte, die angeben, ob Fingerabdruckdaten für Metadaten des Metadaten-Segments enthalten sind, Werte, die angeben, ob externe Daten (in Bezug auf Audiodaten, die den Metadaten des Metadaten-Segments entsprechen) existieren, Nutzlast-ID und Nutzlastgrößenwerte für jeden Typ von Metadaten (zum Beispiel LPSM, und/oder Metadaten eines anderen Typs als LPSM), die durch das Kernelement identifiziert sind, und Schutzwerte für zumindest einen Typ von Metadaten, die durch das Kernelement identifiziert sind. Die Metadaten-Nutzlast(en) des Metadaten-Segments folgt/folgen dem Kern-Header, und ist/sind (in einigen Fällen) in Werten des Kernelements verschachtelt. In einem anderen bevorzugten Format ist der codierte Bitstrom ein Dolby-E-Bitstrom und jedes der Metadaten-Segmente, das LPSM umfasst, ist in den ersten N Abtastpositionen des Dolby-E-Schutzband-Intervalls enthalten.
  • In einer anderen Klasse von Ausführungsbeispielen ist die Erfindung eine APU (zum Beispiel ein Decodierer), die gekoppelt und konfiguriert ist, einen codierten Audiobitstrom zu empfangen, der Audiodaten-Segmente und Metadaten-Segmente aufweist, wobei die Audiodaten-Segmente indikativ sind für Audiodaten, und jedes von zumindest einigen der Metadaten-Segmente Lautheits-Verarbeitungszustands-Metadaten (LPSM – Loudness Processing State Metadata) umfasst, und die LPSM aus dem Bitstrom zu extrahieren, decodierte Audiodaten zu erzeugen in Reaktion auf die Audiodaten und zumindest eine adaptive Lautheits-Verarbeitungsoperation auf den Audiodaten unter Verwendung der LPSM durchzuführen. Einige Ausführungsbeispiele dieser Klasse umfassen auch einen Postprozessor, der mit der APU gekoppelt ist, wobei der Postprozessor gekoppelt und konfiguriert ist, zumindest eine adaptive Lautheits-Verarbeitungsoperation auf den Audiodaten unter Verwendung der LPSM durchzuführen.
  • In einer anderen Klasse von Ausführungsbeispielen ist die Erfindung eine Audioverarbeitungseinheit (APU – Audio Processing Unit) mit einem Pufferspeicher (Puffer) und einem Verarbeitungsteilsystem, das mit dem Puffer gekoppelt ist, wobei die APU gekoppelt ist, um einen codierten Audiobitstrom zu empfangen, der Audiodaten-Segmente und Metadaten-Segmente aufweist, wobei die Audiodaten-Segmente indikativ sind für Audiodaten, und jedes von zumindest einigen der Metadaten-Segmente Lautheits-Verarbeitungszustands-Metadaten (LPSM) umfasst, der Puffer zumindest einen Rahmen des codierten Audiobitstroms speichert (zum Beispiel auf eine nicht-transitorische Weise), und das Verarbeitungsteilsystem konfiguriert ist, die LPSM aus dem Bitstrom zu extrahieren und zumindest eine adaptive Lautheits-Verarbeitungsoperation auf den Audiodaten unter Verwendung der LPSM durchzuführen. In typischen Ausführungsbeispielen in dieser Klasse ist die APU eine aus einem Codierer, einem Decodierer und einem Postprozessor.
  • In einigen Implementierungen ist der erzeugte Audiobitstrom einer aus einem codierten AC-3-Bitstrom, einem E-AC-3-Bitstrom oder einem Dolby-E-Bitstrom, einschließlich Lautheits-Verarbeitungszustands-Metadaten sowie anderer Metadaten (zum Beispiel ein DIALNORM-Metadaten-Parameter, Dynamikregelungs-Metadaten-Parameter und andere Metadaten-Parameter). In einigen anderen Implementierungen ist der erzeugte Audiobitstrom ein codierter Bitstrom eines anderen Typs.
  • Aspekte der Erfindung umfassen ein System oder eine Vorrichtung, die konfiguriert ist (zum Beispiel programmiert), Ausführungsbeispiele der Erfindung durchzuführen, und ein computerlesbares Medium (zum Beispiel eine Disk), das Code speichert (zum Beispiel auf eine nicht-transitorische Weise) zum Implementieren eines Ausführungsbeispiels der Erfindung. Zum Beispiel kann das erfindungsgemäße System ein programmierbarer Universalprozessor, ein digitaler Signalprozessor oder ein Mikroprozessor sein oder diese umfassen, mit Software oder Firmware programmiert und/oder anderweitig konfiguriert, um eine Vielzahl von Operationen auf Daten durchzuführen, einschließlich Ausführungsbeispiele der Erfindung. Ein derartiger Universalprozessor kann ein Computersystem sein oder dieses umfassen, mit einer Eingabeeinrichtung, einem Speicher und Verarbeitungsschaltungen, die programmiert sind (und/oder anderweitig konfiguriert sind), um Ausführungsbeispiele der Erfindung in Reaktion auf zugeführte Daten durchzuführen.
  • Kurze Beschreibung der Zeichnungen
  • 1 ist ein Blockdiagramm eines Ausführungsbeispiels eines Systems, das konfiguriert sein kann, ein Ausführungsbeispiel der Erfindung durchzuführen.
  • 2 ist ein Blockdiagramm eines Codierers, der ein Ausführungsbeispiel der erfindungsgemäßen Audioverarbeitungseinheit ist.
  • 3 ist ein Blockdiagramm eines Decodierers, der ein Ausführungsbeispiel der erfindungsgemäßen Audioverarbeitungseinheit ist, und eines damit gekoppelten Postprozessors, der ein anderes Ausführungsbeispiel der erfindungsgemäßen Audioverarbeitungseinheit ist.
  • 4 ist ein Diagramm eines AC-3-Rahmens, einschließlich der Segmente, in die er unterteilt ist.
  • 5 ist ein Diagramm des Synchronisationsinformation(SI – Synchronization Information)-Segments eines AC-3-Rahmens, einschließlich der Segmente, in die er unterteilt ist.
  • 6 ist ein Diagramm eines Bitstrom-Information(BSI – Bitstream Information)-Segments eines AC-3-Rahmens, einschließlich der Segmente, in die er unterteilt ist.
  • 7 ist ein Diagramm eines E-AC-3-Rahmens, einschließlich der Segmente, in die er unterteilt ist.
  • Bezeichnung und Nomenklatur
  • In dieser Offenbarung, einschließlich in den Ansprüchen, wird der Ausdruck Durchführen einer Operation „auf” einem Signal oder Daten (zum Beispiel Filtern, Skalieren, Transformieren oder Anwenden von Verstärkung auf das Signal oder Daten) in einem weiten Sinn verwendet, um ein Durchführen der Operation direkt auf dem Signal oder den Daten oder auf einer verarbeiteten Version des Signals oder der Daten auszudrücken (zum Beispiel auf einer Version des Signals, das einer vorausgehenden Filterung oder einer Vorverarbeitung vor der Durchführung der Operation darauf unterzogen wurde).
  • In dieser Offenbarung, einschließlich in den Ansprüchen, wird der Ausdruck „System” in einem weiten Sinn verwendet, um eine Vorrichtung, ein System oder ein Teilsystem zu bezeichnen. Zum Beispiel kann ein Teilsystem, das einen Decodierer implementiert, als ein Decodierer-System bezeichnet werden, und ein System mit einem derartigen Teilsystem (zum Beispiel ein System, das X Ausgabesignale erzeugt in Reaktion auf mehrere Eingaben, in denen das Teilsystem M der Eingaben erzeugt und die anderen X-M Eingaben von einer externen Quelle empfangen werden) kann auch als ein Decodierer-System bezeichnet werden.
  • In dieser Offenbarung, einschließlich in den Ansprüchen, wird der Begriff „Prozessor” in einem weiten Sinn verwendet, um ein System oder eine Vorrichtung zu bezeichnen, das/die programmierbar oder anderweitig konfigurierbar ist (zum Beispiel mit Software oder Firmware), um Operationen auf Daten durchzuführen (zum Beispiel Audio- oder Video- oder andere Bilddaten). Beispiele von Prozessoren umfassen einen Field Programmable Gate Array (oder andere konfigurierbare integrierte Schaltung oder Chip-Satz), einen digitalen Signalprozessor, der programmiert und/oder anderweitig konfiguriert ist, um eine Pipeline-Verarbeitung auf Audio oder anderen Tondaten durchzuführen, einen programmierbaren Universalprozessor oder -computer, und einen programmierbaren Mikroprozessor-Chip oder -Chipsatz.
  • In dieser Offenbarung, einschließlich in den Ansprüchen, werden die Ausdrücke „Audioprozessor” und „Audioverarbeitungseinheit” synonym und in einem weiten Sinn verwendet, um ein System zu bezeichnen, das konfiguriert ist, um Audiodaten zu verarbeiten. Beispiele für Audioverarbeitungseinheiten umfassen Codierer (zum Beispiel Transcodierer), Decodierer, Codecs, Vorverarbeitungssysteme, Postverarbeitungssysteme, und Bitstrom-Verarbeitungssysteme (manchmal als Bitstrom-Verarbeitungswerkzeuge bezeichnet), sind aber nicht darauf beschränkt.
  • In dieser Offenbarung, einschließlich in den Ansprüchen, bezeichnet der Ausdruck „Verarbeitungszustands-Metadaten” (zum Beispiel, wie in dem Ausdruck „Lautheits-Verarbeitungszustands-Metadaten”) von entsprechenden Audiodaten (der Audioinhalt eines Audiodatenstroms, der auch Verarbeitungszustands-Metadaten umfasst) getrennte und verschiede Daten. Verarbeitungszustands-Metadaten sind mit Audiodaten assoziiert, geben den Verarbeitungszustand der entsprechenden Audiodaten an (zum Beispiel welche(r) Typ(en) einer Verarbeitung bereits auf den Audiodaten durchgeführt wurde(n), wie eine Lautheits-Verarbeitung), und geben typischerweise auch zumindest ein Merkmal oder eine Charakteristik der Audiodaten an. Die Assoziation der Verarbeitungszustands-Metadaten mit den Audiodaten ist zeitsynchron. Somit geben vorliegende (zuletzt empfangene oder aktualisierte) Verarbeitungszustands-Metadaten an, dass die entsprechenden Audiodaten zeitgleich die Ergebnisse des/der angegebenen Typ(en) einer Audiodatenverarbeitung aufweisen. In einigen Fällen können Verarbeitungszustands-Metadaten eine Verarbeitungshistorie und/oder einige oder alle der Parameter umfassen, die bei den genannten Typen der Verarbeitung verwendet werden und/oder von diesen abgeleitet werden. Zusätzlich können Verarbeitungszustands-Metadaten zumindest ein Merkmal oder eine Charakteristik der entsprechenden Audiodaten umfassen, das/die aus den Audiodaten berechnet oder extrahiert wurde. Verarbeitungszustands-Metadaten können auch andere Metadaten umfassen, die nicht in Bezug zu einer Verarbeitung der entsprechenden Audiodaten stehen oder von diesen abgeleitet sind. Zum Beispiel können Daten Dritter, Verfolgungsinformation, Identifizierer, proprietäre oder Standard-Information, Benutzeranmerkungsdaten, Benutzerpräferenzdaten etc. durch eine bestimmte Audioverarbeitungseinheit hinzugefügt werden zur Weitergabe an andere Audioverarbeitungseinheiten.
  • In dieser Offenbarung, einschließlich in den Ansprüchen, bezeichnet der Ausdruck „Lautheits-Verarbeitungszustands-Metadaten” (oder „LPSM – Loudness Processing State Metadata”) Verarbeitungszustand-Metadaten, die indikativ bzw. aussagekräftig sind für den Lautheits-Verarbeitungszustand von entsprechenden Audiodaten (zum Beispiel welche(r) Typ(en) einer Lautheits-Verarbeitung auf den Audiodaten durchgeführt wurde(n)), und typischerweise auch zumindest ein Merkmal oder eine Charakteristik (zum Beispiel die Lautheit) der entsprechenden Audiodaten. Lautheits-Verarbeitungszustands-Metadaten können Daten (zum Beispiel andere Metadaten) umfassen, die keine Lautheits-Verarbeitungszustands-Metadaten sind (d. h. wenn alleine betrachtet).
  • In dieser Offenbarung, einschließlich in den Ansprüchen, wird der Begriff „koppeln” oder „gekoppelt” verwendet, um entweder eine direkte oder indirekte Verbindung zu bedeuten. Wenn somit eine erste Vorrichtung mit einer zweiten Vorrichtung gekoppelt ist, kann diese Verbindung über eine direkte Verbindung sein oder über eine indirekte Verbindung über andere Vorrichtungen und Verbindungen.
  • Detaillierte Beschreibung von Ausführungsbeispielen der Erfindung
  • Gemäß typischen Ausführungsbeispielen der Erfindung sind Lautheits-Verarbeitungszustands-Metadaten (LPSM) in einem oder mehreren reservierten Feldern (oder Schlitzen) von Metadaten-Segmenten eines Audiobitstroms eingebettet, der auch Audiodaten in anderen Segmenten (Audiodaten-Segmente) umfasst. Typischerweise umfasst zumindest ein Segment jedes Rahmens des Bitstroms LPSM und zumindest ein anderes Segment des Rahmens umfasst entsprechende Audiodaten (d. h. Audiodaten, deren Lautheits-Verarbeitungszustand und Lautheit durch die LPSM angegeben wird). In einigen Ausführungsbeispiele kann die Datenmenge der LPSM ausreichend klein sein, um ohne Beeinträchtigung der Bitrate, die zum Tragen der Audiodaten zugeteilt ist, getragen zu werde.
  • Ein Kommunizieren von Lautheits-Verarbeitungszustands-Metadaten in einer Audiodatenverarbeitungskette ist besonders nützlich, wenn zwei oder mehr Audioverarbeitungseinheiten in der Verarbeitungskette (oder einen Inhalt-Lebenszyklus) miteinander im Tandem arbeiten müssen. Ohne Aufnahme von Lautheits-Verarbeitungszustands-Metadaten in einen Audiobitstrom können schwerwiegende Mediaverarbeitungsprobleme auftreten, wie Qualitäts-, Pegel- und räumliche Verschlechterungen beispielsweise, wenn zwei oder mehr Audio-Codecs in der Kette verwendet werden und eine single-ended-Lautstärkeanpassung während der Reise eines Bitstroms zu einer Mediaverbrauchenden Vorrichtung (oder einem Wiedergabepunkt des Audioinhalts des Bitstroms) mehr als einmal angewendet wird.
  • 1 ist ein Blockdiagramm einer beispielhaften Audioverarbeitungskette (ein Audiodatenverarbeitungssystem), bei der eines oder mehrere der Elemente des Systems in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung konfiguriert werden kann/können. Das System umfasst die folgenden Elemente, miteinander gekoppelt, wie gezeigt: eine Vorverarbeitungseinheit, einen Codierer, eine Signalanalyse- und Metadaten-Korrektureinheit, einen Transcodierer, einen Decodierer und eine Vorverarbeitungseinheit. In Variationen des gezeigten Systems sind ein oder mehrere der Elemente weggelassen oder zusätzlichen Audiodatenverarbeitungseinheiten sind enthalten.
  • In einigen Implementierungen ist die Vorverarbeitungseinheit von 1 konfiguriert, PCM(Zeitdomäne)-Abtastwerte, die Audioinhalt aufweisen, als Eingabe anzunehmen und verarbeitete PCM-Abtastwerte auszugeben. Der Codierer kann konfiguriert sein, die PCM-Abtastwerte als Eingabe anzunehmen und einen codierten (zum Beispiel komprimierten) Audiobitstrom auszugeben, der indikativ ist für den Audioinhalt. Die Daten des Bitstroms, die indikativ sind für den Audioinhalt, werden hier manchmal als „Audiodaten” bezeichnet. Wenn der Codierer gemäß einem typischen Ausführungsbeispiel der vorliegenden Erfindung konfiguriert ist, umfasst der Audiobitstrom, der von dem Codierer ausgegeben wird, Lautheits-Verarbeitungszustands-Metadaten (und typischerweise auch andere Metadaten) sowie Audiodaten.
  • Die Signalanalyse- und Metadaten-Korrektureinheit von 1 kann einen oder mehrere codierte Audio-Bitströme als Eingabe annehmen und bestimmen (zum Beispiel validieren), ob Verarbeitungszustands-Metadaten in jedem codierten Audiobitstrom korrekt sind durch Durchführen einer Signalanalyse. Wenn die Signalanalyse- und Metadaten-Korrektureinheit feststellt, dass enthalte Metadaten ungültig sind, ersetzt sie typischerweise den/die falschen Wert(e) mit dem/den richtigen Wert(en), der/die von der Signalanalyse erlangt wird/werden. Somit kann jeder codierte Audiobitstrom, der von der Signalanalyse- und Metadaten-Korrektureinheit ausgegeben wird, korrigierte (oder nicht-korrigierte) Verarbeitungszustands-Metadaten sowie codierte Audiodaten umfassen.
  • Der Transcodierer von 1 kann codierte Audio-Bitströme als Eingabe annehmen und modifizierte (zum Beispiel anders codierte) Audio-Bitströme in Reaktion darauf ausgeben (zum Beispiel durch Decodieren eines Eingangsstroms und erneutes Codieren des decodierten Stroms in einem anderen Codierungsformat). Wenn der Transcodierer gemäß einem typischen Ausführungsbeispiel der vorliegenden Erfindung konfiguriert ist, umfasst der Audiobitstrom, der von dem Transcodierer ausgegeben wird, Lautheits-Verarbeitungszustands-Metadaten (und typischerweise auch andere Metadaten) sowie codierte Audiodaten. Die Metadaten können in den Bitstrom aufgenommen worden sein.
  • Der Decodierer von 1 kann codierte (zum Beispiel komprimierte) Audio-Bitströme als Eingabe annehmen und (in Reaktion) Ströme von decodierten PCM-Audio-Abtastwerten ausgeben. Wenn der Decodierer gemäß einem typischen Ausführungsbeispiel der vorliegenden Erfindung konfiguriert ist, ist die Ausgabe des Decodierers in einem typischen Betrieb eines der folgenden oder umfasst eines der folgenden:
    ein Strom von Audio-Abtastwerten und ein entsprechender Strom von Lautheits-Verarbeitungszustands-Metadaten (und typischerweise auch andere Metadaten), die aus einem eingegebenen codierten Bitstrom extrahiert sind; oder
    ein Strom von Audio-Abtastwerten und ein entsprechender Strom von Steuerungsbits, die aus Lautheits-Verarbeitungszustands-Metadaten (und typischerweise auch anderen Metadaten) bestimmt werden, die aus einem eingegebenen codierten Bitstrom extrahiert sind; oder
    ein Strom von Audio-Abtastwerten, ohne einen entsprechenden Strom von Verarbeitungszustands-Metadaten oder Steuerungsbits, die aus Verarbeitungszustands-Metadaten bestimmt werden. In diesem letzten Fall kann der Decodierer Lautheits-Verarbeitungszustands-Metadaten (und/oder andere Metadaten) aus dem eingegebenen codierten Bitstrom extrahieren und zumindest eine Operation auf den extrahierten Metadaten durchführen (zum Beispiel eine Validierung), obwohl er die daraus bestimmten extrahierten Metadaten oder Steuerungsbits nicht ausgibt.
  • Durch Konfigurieren der Nachverarbeitungseinheit von 1 in Übereinstimmung mit einem typischen Ausführungsbeispiel der vorliegenden Erfindung ist die Nachverarbeitungseinheit konfiguriert, einen Strom von decodierten PCM-Audioabtastwerten anzunehmen und darauf eine Nachverarbeitung durchzuführen (zum Beispiel eine Lautstärkeabgleichung des Audioinhalts) unter Verwendung von Lautheits-Verarbeitungszustands-Metadaten (und typischerweise auch anderen Metadaten), die mit den Abtastwerten empfangen werden, oder Steuerungsbits (bestimmt durch den Decodierer aus Lautheits-Verarbeitungszustands-Metadaten und typischerweise auch anderen Metadaten), die mit den Abtastwerten empfangen werden. Die Nachverarbeitungseinheit ist typischerweise auch konfiguriert, den nachverarbeiteten Audioinhalt zum Abspielen durch einen oder mehrere Lautsprecher wiederzugeben.
  • Typische Ausführungsbeispiele der vorliegenden Erfindung sehen eine verbesserte Audioverarbeitungskette vor, in der Audioverarbeitungseinheiten (zum Beispiel Codierer, Decodierer, Transcodierer, und Vor- und Nachverarbeitungseinheiten) ihre jeweilige Verarbeitung anpassen, die auf Audiodaten anzuwenden ist, gemäß einem zeitgleichen Zustand der Media-Daten, wie durch Lautheits-Verarbeitungszustands-Metadaten angegeben wird, die jeweils durch die Audioverarbeitungseinheiten empfangen werden.
  • Die Audiodaten-Eingabe an eine Audioverarbeitungseinheit des Systems von 1 (zum Beispiel der Codierer oder Transcodierer von 1) kann Lautheits-Verarbeitungszustands-Metadaten (und optional auch andere Metadaten) sowie Audiodaten (zum Beispiel codierte Audiodaten) umfassen. Diese Metadaten können in dem Eingangs-Audio durch ein anderes Element des Systems von 1 (oder einer anderen Quelle, die in 1 nicht gezeigt wird) in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung aufgenommen worden sein. Die Verarbeitungseinheit, die das Eingangs-Audio (mit Metadaten) empfängt, kann konfiguriert sein, zumindest eine Operation auf den Metadaten (zum Beispiel Validierung) oder in Reaktion auf die Metadaten (zum Beispiel adaptive Verarbeitung des Eingangs-Audios) durchzuführen, und typischerweise die Metadaten, eine verarbeitete Version der Metadaten oder Steuerungsbits, die aus den Metadaten bestimmt werden, auch in ihrem Ausgangs-Audio aufzunehmen.
  • Ein typisches Ausführungsbeispiel der erfindungsgemäßen Audioverarbeitungseinheit (oder Audioprozessor) ist konfiguriert, eine adaptive Verarbeitung von Audiodaten basierend auf dem Zustand der Audiodaten durchzuführen, wie durch Lautheits-Verarbeitungszustands-Metadaten angegeben, die den Audiodaten entsprechen. In einigen Ausführungsbeispielen ist (oder umfasst) die adaptive Verarbeitung eine Lautheits-Verarbeitung, wenn die Metadaten angeben, dass eine Lautheits-Verarbeitung oder eine ähnliche Verarbeitung nicht bereits auf den Audiodaten durchgeführt wurde. Wenn die Metadaten angeben, dass eine Lautheits-Verarbeitung oder eine ähnliche Verarbeitung bereits auf den Audiodaten durchgeführt wurde, kann eine Lautheits-Verarbeitung umgangen werden. In einigen Ausführungsbeispielen ist oder umfasst die adaptive Verarbeitung eine Metadaten-Validierung (zum Beispiel in einer Metadaten-Validierungs-Teileinheit durchgeführt), um sicherzustellen, dass die Audioverarbeitungseinheit eine andere adaptive Verarbeitung der Audiodaten basierend auf dem Zustand der Audiodaten durchführt, wie von den Lautheits-Verarbeitungszustands-Metadaten angegeben. In einigen Ausführungsbeispielen bestimmt die Validierung eine Vertrauenswürdigkeit der Lautheits-Verarbeitungszustands-Metadaten, die mit den Audiodaten assoziiert sind (zum Beispiel enthalten in einem Bitstrom mit den Audiodaten). Wenn zum Beispiel die Metadaten als vertrauenswürdig validiert werden, dann können Ergebnisse von einem Typ einer früher durchgeführten Audioverarbeitung wiederverwendet werden und eine neue Durchführung desselben Typs einer Audioverarbeitung kann vermieden werden. Auf der anderen Seite, wenn festgestellt wird, dass die Metadaten manipuliert wurden (oder anderweitig nicht-vertrauenswürdig sind), kann der Typ einer Media-Verarbeitung, der vermeintlich früher durchgeführt wurde (wie durch die nicht-vertrauenswürdigen Metadaten angegeben), durch die Audioverarbeitungseinheit wiederholt werden und/oder eine andere Verarbeitung kann durch die Audioverarbeitungseinheit auf den Metadaten und/oder den Audiodaten durchgeführt werden. Die Audioverarbeitungseinheit kann auch konfiguriert sein, an andere Audioverarbeitungseinheiten stromabwärts in einer erweiterten Media-Verarbeitungskette zu signalisieren, dass Lautheits-Verarbeitungszustands-Metadaten (zum Beispiel in einem Media-Bitstrom vorhanden) gültig sind, wenn die Einheit feststellt, dass die Verarbeitungszustands-Metadaten gültig sind (zum Beispiel basierend auf einer Übereinstimmung eines extrahierten kryptographischen Werts und eines kryptographischen Referenzwerts).
  • 2 ist ein Blockdiagramm eines Codierers (100), der ein Ausführungsbeispiel der erfindungsgemäßen Audioverarbeitungseinheit ist. Eine/Jede der Komponenten oder Elemente des Codierers 100 kann/können als ein oder mehrere Prozess(e) und/oder eine oder mehrere Schaltung(en) (zum Beispiel ASICs, FPGAs oder andere integrierte Schaltungen), in Hardware, Software oder eine Kombination aus Hardware und Software implementiert werden. Der Codierer 100 weist einen Rahmenpuffer 110, einen Parser 111, einen Decodierer 101, einen Audiozustandsvalidierer 102, eine Lautheits-Verarbeitungsstufe 103, eine Audiostrom-Auswahlstufe 104, einen Codierer 105, eine Füller/Formatierer-Stufe 107, eine Metadaten-Erzeugungsstufe 106, ein Dialog-Lautheitsmessungs-Teilsystem 108 und einen Rahmenpuffer 109 auf, verbunden wie gezeigt. Auch umfasst der Codierer 100 typischerweise andere Verarbeitungselemente (nicht gezeigt).
  • Der Codierer 100 (der ein Transcodierer ist) ist konfiguriert, einen Eingangs-Audiobitstrom (der zum Beispiel einer aus einem AC-3-Bitstrom, einem E-AC-3-Bitstrom oder einem Dolby-E-Bitstrom sein kann) in einen codierten Ausgangs-Audiobitstrom (der zum Beispiel ein anderer aus einem AC-3-Bitstrom, einem E-AC-3-Bitstrom oder einem Dolby-E-Bitstrom sein kann) umzuwandeln, einschließlich durch Durchführen einer adaptiven und automatischen Lautheits-Verarbeitung unter Verwendung von Lautheits-Verarbeitungszustands-Metadaten, die in dem Eingangsbitstrom enthalten sind. Zum Beispiel kann der Codierer 100 konfiguriert sein, einen Eingangs-Dolby-E-Bitstrom (ein Format, das typischerweise in Produktions- und Broadcast-Einrichtungen verwendet wird, aber nicht in Verbrauchergeräten, die Audioprogramme empfangen, die an diese ausgestrahlt wurden) in einen codierten Ausgangs-Audiobitstrom (geeignet zum Aussenden an Verbrauchergeräte) in einem AC-3- oder E-AC-3-Format umzuwandeln.
  • Das System von 2 umfasst auch ein codiertes Audio-Liefer-Teilsystem 150 (das die codierten Bitströme speichert und/oder liefert, die von dem Codierer 100 ausgegeben werden) und einen Decodierer 152. Ein codierter Audiobitstrom, der von dem Codierer 100 ausgegeben wird, kann durch das Teilsystem 150 gespeichert werden (zum Beispiel in der Form einer DVD oder Blu Ray Disc) oder durch das Teilsystem 150 übertragen werden (das eine Übertragungsverbindung oder -Netzwerk implementieren kann), oder kann durch das Teilsystem 150 sowohl gespeichert als auch übertragen werden. Der Decodierer 152 ist konfiguriert, einen codierten Audiobitstrom (der durch den Codierer 100 erzeugt wird) zu decodieren, den er über das Teilsystem 150 empfängt, einschließlich durch Extrahieren von Lautheits-Verarbeitungszustands-Metadaten (LPSM) aus jedem Rahmen des Bitstroms und Erzeugen decodierter Audiodaten. Typischerweise ist der Decodierer 152 konfiguriert, eine adaptive Lautheits-Verarbeitung auf den decodierten Audiodaten unter Verwendung der LPSM durchzuführen, und/oder die decodierten Audiodaten und die LPSM an einen Postprozessor weiterzuleiten, der konfiguriert ist, eine adaptive Lautheits-Verarbeitung auf den decodierten Audiodaten unter Verwendung der LPSM durchzuführen. Typischerweise umfasst der Decodierer 152 einen Puffer, der den codierten Audiobitstrom speichert (zum Beispiel auf eine nicht-transitorische Weise), der von dem Teilsystem 150 empfangen wird.
  • Verschiedene Implementierungen des Codierers 100 und des Decodierers 152 sind konfiguriert, um verschiedene Ausführungsbeispiele der Erfindung durchzuführen.
  • Ein Rahmenpuffer 110 ist ein Pufferspeicher, der gekoppelt ist, um einen codierten Eingangs-Audiobitstrom zu empfangen. In Betrieb speichert der Puffer 110 (zum Beispiel auf eine nicht-transitorische Weise) zumindest einen Rahmen des codierten Audiobitstroms, und eine Sequenz der Rahmen des codierten Audiobitstroms wird von dem Puffer 110 dem Parser 111 zugeführt.
  • Der Parser 111 ist gekoppelt und konfiguriert, Lautheits-Verarbeitungszustands-Metadaten (LPSM) und andere Metadaten aus jedem Rahmen des codierten Eingangsaudios zu extrahieren, um zumindest die LPSM an den Audiozustandsvalidierer 102, die Lautheits-Verarbeitungsstufe 103, die Stufe 106 und das Teilsystem 108 zuzuführen, um Audiodaten aus dem codierten Eingangsaudio zu extrahieren, und um die Audiodaten dem Decodierer 101 zuzuführen. Der Decodierer 101 des Codierers 100 ist konfiguriert, die Audiodaten zu decodieren, um decodierte Audiodaten zu erzeugen, und um die decodierten Audiodaten der Lautheits-Verarbeitungsstufe 103, der Audiostrom-Auswahlstufe 104, dem Teilsystem 108 und typischerweise auch dem Zustandsvalidierer 102 zuzuführen.
  • Der Zustandsvalidierer 102 ist konfiguriert, die ihm zugeführten LPSM (und optional andere Metadaten) zu authentifizieren und zu validieren. In einigen Ausführungsbeispielen sind die LPSM ein Datenblock (oder sind darin enthalten), der in dem Eingangsbitstrom aufgenommen wurde (zum Beispiel in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung). Der Block kann einen kryptographischen Hash (einen Hash-basierten Nachrichtenauthentifizierungscode (HMAC – Hash-Based Message Authentication Code)) zum Verarbeiten der LPSM (und optional auch anderer Metadaten) und/oder der zugrundeliegenden Audiodaten (vorgesehen von dem Decodierer 101 an den Validierer 102) aufweisen. Der Datenblock kann in diesen Ausführungsbeispielen digital signiert sein, so dass eine stromabwärtige Audioverarbeitungseinheit relativ einfach die Verarbeitungszustands-Metadaten authentifizieren und validieren kann.
  • Zum Beispiel wird der HMAC verwendet, um einen Digest zu erzeugen, und der/die Schutzwert(e), der/die in dem erfindungsgemäßen Bitstrom enthalten ist/sind, kann/können den Digest umfassen. Der Digest kann wie folgt für einen AC-3-Rahmen erzeugt werden:
    • 1. Nachdem AC-3-Daten und LPSM codiert sind, werden Rahmen-Datenbytes (verknüpfte bzw. aneinandergereihte frame_data #1 und frame_data #2) und die LPSM-Datenbytes als Eingabe für die Hashing-Funktion HMAC verwendet. Andere Daten, die in einem auxdata-Feld vorhanden sein können, werden zur Berechnung des Digests nicht berücksichtigt. Solche andere Daten können Bytes sein, die weder zu den AC-3-Daten noch zu den LSPSM-Daten gehören. Schutzbits, die in den LPSM enthalten sind, werden eventuell nicht zur Berechnung des HMAC-Digests berücksichtigt.
    • 2. Nachdem der Digest berechnet ist, wird er in den Bitstrom in ein Feld geschrieben, das für Schutzbits reserviert ist.
    • 3. Der letzte Schritt der Erzeugung des vollständigen AC-3-Rahmens ist die Berechnung der CRC-Prüfung. Diese wird ganz am Ende des Rahmens geschrieben und alle Daten, die zu diesem Rahmen gehören, werden berücksichtigt, einschließlich der LPSM-Bits.
  • Andere kryptographische Verfahren, einschließlich, aber nicht auf ein oder mehrere nicht-HMAC-kryptographische Verfahren beschränkt, können verwendet werden zur Validierung von LPSM (zum Beispiel in dem Validierer 102), um eine sichere Übertragung und Empfang der LPSM und/oder der zugrundeliegenden Audiodaten sicherzustellen. Zum Beispiel kann eine Validierung (unter Verwendung eines solchen kryptographischen Verfahrens) in jeder Audioverarbeitungseinheit durchgeführt werden, die ein Ausführungsbeispiel des erfindungsgemäßen Audiobitstroms empfängt, um zu bestimmen, ob die Lautheits-Verarbeitungszustands-Metadaten und entsprechende Audiodaten, die in dem Bitstrom enthalten sind, einer spezifischen Lautheits-Verarbeitung (wie durch die Metadaten angegeben) unterzogen wurden (und/oder daraus resultieren) und nach der Durchführung einer derartigen spezifischen Lautheits-Verarbeitung nicht modifiziert wurden.
  • Der Zustandsvalidierer 102 führt Steuerungsdaten an die Audiostrom-Auswahlstufe 104, den Metadaten-Generator 106 und das Dialoglautheitsmessungs-Teilsystem 108 zu, um die Ergebnisse der Validierungsoperation anzuzeigen. In Reaktion auf die Steuerungsdaten kann die Stufe 104 eines auswählen (und durch den Codierer 105 leiten) aus:
    die adaptiv verarbeitete Ausgabe der Lautheits-Verarbeitungsstufe 103 (zum Beispiel, wenn die LPSM anzeigen, dass die Audiodaten, die von dem Decodierer 101 ausgegeben werden, nicht einem spezifischen Typ einer Lautheits-Verarbeitung unterzogen wurden und die Steuerungsbits von dem Validierer 102 anzeigen, dass die LPSM gültig sind); oder
    die Audiodaten, die von dem Decodierer 101 ausgegeben werden (zum Beispiel, wenn die LPSM anzeigen, dass die Audiodaten, die von dem Decodierer 101 ausgegeben werden, bereits dem spezifischen Typ einer Lautheits-Verarbeitung unterzogen wurden, die durch die Stufe 103 durchgeführt würde, und die Steuerungsbits von dem Validierer 102 anzeigen, dass die LPSM gültig sind).
  • Die Stufe 103 des Codierers 100 ist konfiguriert, eine adaptive Lautheits-Verarbeitung auf den decodierten Audiodaten durchzuführen, die von dem Decodierer 101 ausgegeben werden, basierend auf einer oder mehreren Audiodaten-Charakteristik(en), die durch die LPSM angegeben werden, extrahiert durch den Decodierer 101. Die Stufe 103 kann ein adaptiver Transformations-Domäne-Echtzeit-Lautheits- und Dynamikregelungs-Prozessor sein. Die Stufe 103 kann eine Benutzereingabe (zum Beispiel Benutzer-Ziel-Lautheit/Dynamikregelungswerte oder „dialnorm”-Werte) oder eine andere Metadaten-Eingabe (zum Beispiel ein oder mehrere Typ(en) von Daten Dritter, Verfolgungsinformation, Identifizierern, proprietäre oder Standard-Information, Benutzeranmerkungsdaten, Benutzerpräferenzdaten etc.) und/oder eine andere Eingabe (zum Beispiel von einem Fingerabdruck-Verfahren) empfangen und eine derartige Eingabe verwenden, um die decodierten Audiodaten zu verarbeiten, die von dem Decodierer 101 ausgegeben werden.
  • Das Dialoglautheitsmessungs-Teilsystem 108 kann arbeiten, um eine Lautheit von Segmenten des decodierten Audios (von dem Decodierer 101) zu bestimmen, die für einen Dialog (oder andere Sprache) indikativ sind, zum Beispiel unter Verwendung der LPSM (und/oder anderer Metadaten), die durch den Decodierer 101 extrahiert werden, wenn die Steuerungsbits von dem Validierer 102 anzeigen, dass die LPSM ungültig sind. Ein Betrieb des Dialoglautheitsmessung-Teilsystems 108 kann deaktiviert werden, wenn die LPSM eine zuvor bestimmte Lautheit von Dialog(oder andere Sprach)-Segmenten des decodierten Audios (von dem Decodierer 101) anzeigen, wenn die Steuerungsbits von dem Validierer 102 anzeigen, dass die LPSM gültig sind.
  • Nützliche Werkzeuge (zum Beispiel der „Dolby LM100”-Lautheitsmesser) zum bequemen und einfachen Messen des Pegels eines Dialogs in einem Audioinhalt sind vorhanden. Einige Ausführungsbeispiele der erfindungsgemäßen APU (zum Beispiel die Stufe 108 des Codierers 100) sind implementiert, um ein derartiges Werkzeug zu umfassen (oder dessen Funktionen durchzuführen), um die mittlere Dialoglautheit von Audioinhalt eines Audiobitstroms (zum Beispiel eines decodierten AC-3-Bitstroms, der an die Stufe 108 von dem Decodierer 101 des Codierers 100 zugeführt wird) zu messen.
  • Wenn die Stufe 108 implementiert wird, um die wahre mittlere Dialoglautheit von Audiodaten zu messen, kann die Messung einen Schritt eines Isolierens von Segmenten des Audioinhalts umfassen, die vorwiegend Sprache enthalten. Die Audio-Segmente, die überwiegend Sprache sind, werden dann in Übereinstimmung mit einem Lautheitsmessungsalgorithmus verarbeitet. Für Audiodaten, die aus einem AC-3-Bitstrom decodiert werden, kann dieser Algorithmus ein standardmäßiges K-gewichtetes Lautheitsmaß sein (in Übereinstimmung mit dem internationalen Standard ITU-R BS.1770). Alternativ können andere Lautheitsmaße verwendet werden (zum Beispiel solche, die auf psychoakustischen Modellen von Lautheit basieren).
  • Die Isolierung von Sprachsegmenten ist nicht wesentlich, um die mittlere Dialoglautheit von Audiodaten zu messen. Allerdings verbessert dies die Genauigkeit des Messens und liefert typischerweise zufriedenstellendere Ergebnisse aus der Sicht eines Zuhörers. Da nicht jeder Audioinhalt Dialog (Sprache) enthält, kann das Lautheitsmaß des gesamten Audioinhalts eine ausreichende Annäherung des Dialogpegels des Audios vorsehen, wenn Sprache vorhanden gewesen wäre.
  • Der Metadaten-Generator 106 erzeugt Metadaten, die durch die Stufe 107 in den codierten Bitstrom aufzunehmen sind, der von dem Codierer 100 auszugeben ist. Der Metadaten-Generator 106 kann an die Stufe 107 die LPSM (und/oder andere Metadaten) leiten, die durch den Codierer 101 extrahiert werden (zum Beispiel, wenn Steuerungsbits von dem Validierer 102 anzeigen, dass die LPSM und/oder andere Metadaten gültig sind), oder neue LPSM (und/oder andere Metadaten) erzeugen und die neuen Metadaten an die Stufe 107 zuführen (zum Beispiel, wenn Steuerungsbits von dem Validierer 102 anzeigen, dass die LPSM und/oder andere Metadaten, die durch den Decodierer 101 extrahiert werden, ungültig sind), oder er kann an die Stufe 107 eine Kombination von Metadaten, die von dem Decodierer 101 extrahiert werden, und neu erzeugten Metadaten zuführen. Der Metadaten-Generator 106 kann Lautheit-Daten, die von dem Teilsystem 108 erzeugt werden, und zumindest einen Wert, der den Typ einer Lautheits-Verarbeitung anzeigt, die durch das Teilsystem 108 durchgeführt wird, in die LPSM aufnehmen, die er an die Stufe 107 zuführt zur Aufnahme in den codierten Bitstrom zur Ausgabe von dem Codierer 100.
  • Der Metadaten-Generator 106 kann Schutzbits erzeugen (die aus einem Hash-basierten Nachrichtenauthentifizierungscode (HMAC – Hash-Based Message Authentication Code) bestehen können oder diesen umfassen können), die nützlich sind für zumindest eines aus einer Entschlüsselung, Authentifizierung oder Validierung der LPSM (und optional auch anderer Metadaten), die in den codierten Bitstrom und/oder die zugrundeliegenden Audiodaten, die in den codierten Bitstrom aufzunehmen sind, aufzunehmen sind. Der Metadaten-Generator 106 kann derartige Schutzbits an die Stufe 107 liefern zur Aufnahme in dem codierten Bitstrom.
  • In einem typischen Betrieb verarbeitet das Dialoglautheitsmessung-Teilsystem 108 die Audiodaten, die von dem Decodierer 101 ausgegeben werden, um in Reaktion darauf Lautheitswerte (zum Beispiel Gate-gesteuerte und nicht-Gate-gesteuerte Dialoglautheitswerte) und Dynamikregelungswerte zu erzeugen. In Reaktion auf diese Werte kann der Metadaten-Generator 106 Lautheits-Verarbeitungszustands-Metadaten (LPSM) zur Aufnahme (durch den Füller/Formatierer 107) in den codierten Bitstrom zur Ausgabe von dem Codierer 100 erzeugen.
  • Zusätzlich, optional oder alternativ können Teilsysteme von 106 und/oder 108 des Codierers 100 eine zusätzliche Analyse der Audiodaten durchführen, um Metadaten zu erzeugen, die für zumindest eine Charakteristik der Audiodaten indikativ sind, zur Aufnahme in den codierten Bitstrom zur Ausgabe von der Stufe 107.
  • Der Codierer 105 codiert (zum Beispiel durch Durchführen einer Komprimierung) die Audiodaten, die von der Auswahlstufe 104 ausgegeben werden, und führt das codierte Audio der Stufe 107 zu für eine Aufnahme in den codierten Bitstrom zur Ausgabe von der Stufe 107.
  • Die Stufe 107 multiplext das codierte Audio von dem Codierer 105 und die Metadaten (einschließlich LPSM) von dem Generator 106, um den codierten Bit-Strom zur Ausgabe von der Stufe 107 zu erzeugen, vorzugsweise derart, dass der codierte Bitstrom ein Format hat, das durch ein bevorzugtes Ausführungsbeispiel der vorliegenden Erfindung spezifiziert wird.
  • Der Rahmenpuffer 109 ist ein Pufferspeicher, der zumindest einen Rahmen des codierten Audiobitstroms speichert (zum Beispiel auf eine nicht-transitorische Weise), der von der Stufe 107 ausgegeben wird, und eine Sequenz der Rahmen des codierten Audiobitstroms wird dann von dem Puffer 109 als Ausgabe von dem Codierer 100 an das Liefersystem 150 zugeführt.
  • Die LPSM, die durch den Metadaten-Generator 106 erzeugt werden und in den codierten Bitstrom durch die Stufe 107 aufgenommen werden, sind Indikativ für den Lautheits-Verarbeitungszustand von entsprechenden Audiodaten (zum Beispiel welche(r) Typ(en) einer Lautheits-Verarbeitung auf den Audiodaten durchgeführt wurde(n)) und eine Lautheit (zum Beispiel gemessene Dialoglautheit, Gate-gesteuerte und/oder nicht-Gate-gesteuerte Lautheit und/oder Dynamikregelung) der entsprechenden Audiodaten.
  • Hier bezieht sich eine „Gate-Steuerung” von Lautheit und/oder Pegelmessungen, die auf Audiodaten durchgeführt wird, auf eine spezifische Pegel- oder Lautheits-Schwelle, bei der berechnete(r) Wert(e), der/die die Schwelle übersteigt/übersteigen, in der endgültigen Messung enthalten ist/sind (zum Beispiel Ignorieren von kurzzeitigen Lautheitswerten unten –60 dBFS in den letzten gemessenen Werten). Eine Gate-Steuerung auf einem absoluten Wert bezieht sich auf einen festen Pegel oder eine Lautheit, während sich eine Gate-Steuerung auf einem relativen Wert auf einen Wert bezieht, der abhängig ist von einem aktuellen „nicht-Gate-gesteuerten” Messwert.
  • In einigen Implementierungen des Codierers 100 ist der codierte Bitstrom, der in dem Speicher 109 zwischengespeichert ist (und an das Liefersystem 150 ausgegeben wird), ein AC-3-Bitstrom oder ein E-AC-3-Bitstrom und weist Audiodaten-Segmente (zum Beispiel die AB0-AB5-Segmente des Rahmens, der in 4 gezeigt wird) und Metadaten-Segmenten auf, wobei die Audiodaten-Segmente indikativ sind für Audiodaten, und jedes von zumindest einigen der Metadaten-Segmente Lautheits-Verarbeitungszustands-Metadaten (LPSM) umfasst. Die Stufe 107 fügt die LPSM in den Bitstrom in dem folgenden Format ein. Jedes der Metadaten-Segmente, das LPSM umfasst, ist in einem „addbsi”-Feld des Bitstrom-Information(„BSI”)-Segments eines Rahmens des Bitstroms oder in einem auxdata-Feld (zum Beispiel das AUX-Segment, das in 4 gezeigt wird) an dem Ende eines Rahmens des Bitstroms enthalten. Ein Rahmen des Bitstroms kann ein oder zwei Metadaten-Segment(e) umfassen, von denen jedes LPSM umfasst, und wenn der Rahmen zwei Metadaten-Segmente umfasst, ist eines in dem addbsi-Feld des Rahmens und das andere in dem AUX-Feld des Rahmens vorhanden. Jedes Metadaten-Segment mit LPSM umfasst ein LPSM-Nutzlast(oder Container)-Segment mit dem folgenden Format:
    ein Header (typischerweise mit einem Synchronisierungswort, das den Beginn der LPSM-Nutzlast identifiziert, gefolgt von zumindest einem Identifikationswert, zum Beispiel die LPSM-Format-Version, Länge, Dauer, Anzahl, Teilstrom-Assoziationswerte, wie in Tabelle 2 unten angegeben); und
    nach dem Header,
    zumindest ein Dialog-Anzeigewert (zum Beispiel Parameter „Dialog-Kanal/Kanäle” in Tabelle 2), der angibt, ob entsprechende Audiodaten Dialog angeben oder nicht Dialog angeben (zum Beispiel welche Kanäle von entsprechenden Audiodaten Dialog angeben);
    zumindest ein Lautheit-Vorschrifteneinhaltungs-Wert (zum Beispiel Parameter „Lautheit-Vorschriften-Typ” in Tabelle 2), der angibt, ob entsprechende Audiodaten mit einem angezeigten Satz von Lautheits-Vorschriften übereinstimmen;
    zumindest ein Lautheits-Verarbeitungswert (zum Beispiel einer oder mehrere der Parameter „Dialog-Gate-gesteuertes Lautheit-Korrektur-Flag”, „Lautheit-Korrektur-Typ” in Tabelle 2), der zumindest einen Typ einer Lautheits-Verarbeitung angibt, die auf den entsprechenden Audiodaten durchgeführt wurde; und
    zumindest ein Lautheitswert (zum Beispiel einer oder mehrere der Parameter „ITU relative Gate-gesteuerte Lautheit”, „ITU Sprache-Gate-gesteuerte Lautheit”, „ITU (EBU 3341) Kurzzeit 3 s Lautheit” und „Wahre Spitze” von Tabelle 2), der zumindest eine Lautheit (zum Beispiel Spitzen- oder durchschnittliche Lautheit) angibt, die für die entsprechenden Audiodaten charakteristisch ist.
  • In einigen Implementierungen hat jedes der Metadaten-Segmente, das durch die Stufe 107 in ein „addbsi”-Feld oder ein auxdata-Feld eines Rahmens des Bitstroms eingefügt wird, das folgende Format:
    ein Kern-Header (der typischerweise ein Synchronisierungswort umfasst, das den Beginn eines Metadaten-Segments identifiziert, gefolgt von Identifizierungswerten, zum Beispiel die Kernelement-Version, Länge und Dauer, Anzahl erweiterte Elemente, und Teilstrom-Assoziationswerte, die in Tabelle 1 unten angegeben werden); und
    nach dem Kern-Header, zumindest ein Schutzwert (zum Beispiel HMAC-Digest und Audio-Fingerabdruck-Werte von Tabelle 1), der nützlich ist für zumindest eines aus einer Entschlüsselung, Authentifizierung oder Validierung von zumindest einem aus Lautheits-Verarbeitungszustands-Metadaten oder den entsprechenden Audiodaten; und
    ebenfalls nach dem Kern-Header, wenn das Metadaten-Segment LPSM umfasst, eine LPSM-Nutzlast-Identifikation („ID”) und LPSM-Nutzlastgrößenwerte, die nachfolgende Metadaten als eine LPSM-Nutzlast identifizieren und eine Größe der LPSM-Nutzlast anzeigen.
  • Das LPSM-Nutzlast(oder Container)-Segment (vorzugsweise mit dem oben spezifizierten Format) folgt der LPSM-Nutzlast-ID und den LPSM-Nutzlastgrößenwerten.
  • In einigen Ausführungsbeispielen hat jedes der Metadaten-Segmente in dem auxdata-Feld (oder „addbsi”-Feld) eines Rahmens drei Strukturebenen:
    eine Struktur auf hoher Ebene, einschließlich eines Flags, das anzeigt, ob das auxdata(oder addbsi)-Feld Metadaten umfasst, zumindest einen ID-Wert, der anzeigt, welche(r) Typ(en) von Metadaten vorhanden ist/sind, und typischerweise auch einen Wert, der angibt, wie viele Bits von Metadaten (zum Beispiel von jedem Typ) vorhanden sind (wenn Metadaten vorhanden sind). Ein Typ von Metadaten, die vorhanden sein können, ist LSPM, und ein anderer Typ von Metadaten, die vorhanden sein können, sind Medienforschungs-Metadaten (zum Beispiel „Nielsen Media Research”-Metadaten);
    eine Struktur einer mittleren Ebene, die ein Kernelement für jeden identifizierten Typ von Metadaten aufweist (zum Beispiel Kern-Header, Schutzwerte und LPSM-Nutzlast-ID und LPSM-Nutzlastgrößenwerte, wie oben angeführt, für jeden identifizierten Typ von Metadaten); und
    eine Struktur einer unteren Ebene, die Nutzlast für ein Kernelement aufweist (zum Beispiel eine LPSM-Nutzlast, wenn eine durch das Kernelement als vorhanden identifiziert wird, und/oder eine Metadaten-Nutzlast eines anderen Typs, wenn eine durch das Kernelement als vorhanden identifiziert wird).
  • Die Datenwerte in einer derartigen Struktur mit drei Ebenen können verschachtelt sein. Zum Beispiel kann/können der/die Schutzwert(e) für eine LPSM-Nutzlast und/oder eine andere Metadaten-Nutzlast, identifiziert von einem Kernelement, enthalten sein nach jeder Nutzlast, die von dem Kernelement identifiziert wird (und somit nach dem Kern-Header des Kernelements). In einem Beispiel kann ein Kern-Header eine LPSM-Nutzlast identifizieren und eine weitere Metadaten-Nutzlast, eine Nutzlast-ID und Nutzlastgrößenwerte für die erste Nutzlast (zum Beispiel die LPSM-Nutzlast) können dem Kern-Header folgen, die erste Nutzlast selbst kann der ID und den Größenwerten folgen, die Nutzlast-ID und der Nutzlastgrößenwert für die zweite Nutzlast können der ersten Nutzlast folgen, die zweite Nutzlast selbst kann dieser ID und den Größenwerten folgen, und Schutzbits für beide Nutzlasten (oder für Kernelementwerte und beide Nutzlasten) können der letzten Nutzlast folgen.
  • In einigen Ausführungsbeispiele, wenn der Decodierer 101 einen Audiobitstrom empfängt, der in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung mit einem kryptographischen Hash erzeugt wird, ist der Decodierer konfiguriert, den kryptographischen Hash aus einem Datenblock zu analysieren bzw. zu parsen und abzurufen, der aus dem Bitstrom bestimmt wird, wobei der Block Lautheits-Verarbeitungszustands-Metadaten (LPSM) aufweist. Der Validierer 102 kann den kryptographischen Hash verwenden, um den empfangenen Bitstrom und/oder assoziierte Metadaten zu validieren. Zum Beispiel stellt der Validierer 102 fest, dass die LPSM gültig sind, basierend auf einer Übereinstimmung zwischen einem kryptographischen Referenz-Hash und dem kryptographischen Hash, der aus dem Datenblock abgerufen wird, dann kann er einen Betrieb des Prozessors 103 auf den entsprechenden Audiodaten deaktivieren und die Auswahlstufe 104 veranlassen, die Audiodaten (unverändert) durchzulassen. Zusätzlich, optional oder alternativ können andere Typen von kryptographischen Techniken anstelle eines Verfahrens basierend auf einem kryptographischen Hash verwendet werden.
  • Der Codierer 100 von 2 kann bestimmen (in Reaktion auf LPSM, die durch den Decodierer 101 extrahiert werden), dass eine Nach/Vorverarbeitungseinheit einen Typ einer Lautheits-Verarbeitung auf den zu codierenden Audiodaten (in den Elementen 105, 106 und 107) durchgeführt hat und kann somit (in dem Generator 106) Lautheits-Verarbeitungszustands-Metadaten erzeugen, die die spezifischen Parameter umfassen, die in der zuvor durchgeführten Lautheits-Verarbeitung verwendet werden und/oder daraus abgeleitet werden. In einigen Implementierungen kann der Codierer 100 Verarbeitungszustands-Metadaten erzeugen (und in den codierten Bitstrom aufnehmen, der daraus ausgegeben wird), die indikativ sind für eine Verarbeitungshistorie auf dem Audioinhalt, solange der Codierer die Typen einer Verarbeitung kennt, die auf dem Audioinhalt durchgeführt wurden.
  • 3 ist ein Blockdiagramm eines Decodierers 200, der ein Ausführungsbeispiel der erfindungsgemäßen Audioverarbeitungseinheit ist, und eines Postprozessors 300, der damit gekoppelt ist. Der Postprozessor 300 ist auch ein Ausführungsbeispiel der erfindungsgemäßen Audioverarbeitungseinheit. Die Komponenten oder Elemente des Decodierers 200 und des Postprozessors 300 können als ein oder mehrere Prozess(e) und/oder eine oder mehrere Schaltung(en) (zum Beispiel ASICs, FPGAs oder andere integrierte Schaltungen), in Hardware, Software oder einer Kombination aus Hardware und Software implementiert werden. Der Decodierer 200 weist einen Rahmenpuffer 201, einen Parser 205, einen Audio-Decodierer 202, eine Audiozustands-Validierungsstufe (Validierer) 203 und eine Steuerungsbit-Erzeugungsstufe 204 auf, verbunden wie gezeigt. Typischerweise umfasst der Decodierer 200 auch andere Verarbeitungselemente (nicht gezeigt).
  • Der Rahmenpuffer 201 (ein Pufferspeicher) speichert (zum Beispiel auf eine nicht-transitorische Weise) zumindest einen Rahmen des codierten Audiobitstroms, der durch den Decodierer 200 empfangen wird. Eine Sequenz der Rahmen des codierten Audiobitstroms wird von dem Puffer 201 an den Parser 205 zugeführt.
  • Der Parser 205 ist gekoppelt und konfiguriert, um Lautheits-Verarbeitungszustands-Metadaten (LPSM) und andere Metadaten aus jedem Rahmen des codierten Eingangsaudios zu extrahieren, um zumindest die LPSM an den Audio-Zustandsvalidierer 203 und die Stufe 204 zuzuführen, die LPSM als Ausgabe (zum Beispiel an den Postprozessor 300) zuzuführen, um Audiodaten aus dem codierten Eingangsaudio zu extrahieren und um die extrahierten Audiodaten an den Decodierer 202 zuzuführen.
  • Der codierte Audiobitstrom, der in den Decodierer 200 eingegeben wird, kann einer aus einem AC-3-Bitstrom, einem E-AC-3-Bitstrom oder einem Dolby-E-Bitstrom sein.
  • Das System von 3 umfasst auch einen Postprozessor 300. Der Postprozessor 300 weist einen Rahmenpuffer 301 und andere Verarbeitungselemente (nicht gezeigt) auf, einschließlich zumindest eines Verarbeitungselements, das mit dem Puffer 301 gekoppelt ist. Der Rahmenpuffer 301 speichert (zum Beispiel auf eine nicht-transitorische Weise) zumindest einen Rahmen des decodierten Audiobitstroms, der durch den Postprozessor 300 von dem Decodierer 200 empfangen wird. Verarbeitungselemente des Postprozessors 300 sind gekoppelt und konfiguriert zum Empfangen und adaptiven Verarbeiten einer Sequenz der Rahmen des decodierten Audiobitstroms, der von dem Puffer 301 ausgegeben wird, unter Verwendung von Metadaten (einschließlich LPSM-Werte), die von dem Decodierer 202 ausgegeben werden, und/oder Steuerungsbits, die von der Stufe 204 des Decodierers 200 ausgegeben werden. Typischerweise ist der Postprozessor 300 konfiguriert, eine adaptive Lautheits-Verarbeitung auf den decodierten Audiodaten unter Verwendung der LPSM-Werte durchzuführen (zum Beispiel basierend auf einem Lautheits-Verarbeitungszustand und/oder einer oder mehreren Audiodaten-Charakteristik(en), angegeben durch LPSM).
  • Verschiedene Implementierungen des Decodierers 200 und des Postprozessors 300 sind konfiguriert, um verschiedene Ausführungsbeispiele der Erfindung durchzuführen.
  • Der Audio-Decodierer 202 des Decodierers 200 ist konfiguriert, die Audiodaten zu decodieren, die von dem Parser 205 extrahiert werden, um decodierte Audiodaten zu erzeugen und um die decodierten Audiodaten als Ausgabe (zum Beispiel an den Postprozessor 300) zuzuführen.
  • Der Zustands-Validierer 203 ist konfiguriert, die zugeführten LPSM (und optional andere Metadaten) zu authentifizieren und zu validieren. In einigen Ausführungsbeispielen sind die LPSM ein Datenblock (oder sind darin enthalten), der in dem Eingangsbitstrom aufgenommen wurde (zum Beispiel in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung). Der Block kann einen kryptographischen Hash (einen Hash-basierten Nachrichtenauthentifizierungscode (HMAC – Hash-Based Message Authentication Code)) zum Verarbeiten der LPSM (und optional auch anderer Metadaten) und/oder der zugrundeliegenden Audiodaten (vorgesehen von dem Parser 205 und/oder dem Decodierer 202 an den Validierer 203) aufweisen. Der Datenblock kann in diesen Ausführungsbeispielen digital signiert sein, so dass eine stromabwärtige Audioverarbeitungseinheit relativ einfach die Verarbeitungszustands-Metadaten authentifizieren und validieren kann.
  • Andere kryptographische Verfahren umfassen, sind aber nicht auf eines oder mehrere kryptographische nicht-HMAC-Verfahren beschränkt, können zur Validierung von LPSM verwendet werden (zum Beispiel in dem Validierer 203), um eine sichere Übertragung und Empfang der LPSM und/oder der zugrundeliegenden Audiodaten sicherzustellen. Zum Beispiel kann eine Validierung (unter Verwendung eines solchen kryptographischen Verfahrens) in jeder Audioverarbeitungseinheit durchgeführt werden, die ein Ausführungsbeispiel des erfindungsgemäßen Audiobitstroms empfängt, um zu bestimmen, ob die Lautheits-Verarbeitungszustands-Metadaten und entsprechende Audiodaten, die in dem Bitstrom enthalten sind, einer spezifischen Lautheits-Verarbeitung (wie durch die Metadaten angegeben) unterzogen wurden (und/oder daraus resultieren) und nach der Durchführung einer derartigen spezifischen Lautheits-Verarbeitung nicht modifiziert wurden.
  • Der Zustandsvalidierer 203 führt Steuerungsdaten dem Steuerungsbit-Generator 204 zu und/oder führt die Steuerungsdaten als Ausgabe (zum Beispiel dem Postprozessor 300) zu, um die Ergebnisse der Validierungsoperation anzuzeigen. In Reaktion auf die Steuerungsdaten (und optional auch andere Metadaten, die aus dem Eingangsbitstrom extrahiert werden), kann die Stufe 204 eines erzeugen (und an den Postprozessor 300 zuführen) aus:
    Steuerungsbits, die angeben, dass decodierte Audiodaten, die von dem Decodierer 202 ausgegeben werden, einem spezifischen Typ von Lautheits-Verarbeitung unterzogen wurden (wenn die LPSM angeben, dass die Audiodaten, die von dem Decodierer 202 ausgegeben werden, dem spezifischen Typ von Lautheits-Verarbeitung unterzogen wurden, und die Steuerungsbits von dem Validierer 203 angeben, dass die LPSM gültig sind); oder
    Steuerungsbits, die angeben, dass decodierte Audiodaten, die von dem Decodierer 202 ausgegeben werden, einem spezifischen Typ von Lautheits-Verarbeitung unterzogen werden sollen (zum Beispiel, wenn die LPSM angeben, dass die Audiodaten, die von dem Decodierer 202 ausgegeben werden, nicht dem spezifischen Typ von Lautheits-Verarbeitung unterzogen wurden, oder wenn die LPSM angeben, dass die Audiodaten, die von dem Decodierer 202 ausgegeben werden, dem spezifischen Typ von Lautheits-Verarbeitung unterzogen wurden, aber die Steuerungsbits von dem Validierer 203 angeben, dass die LPSM nicht gültig sind).
  • Alternativ führt der Decodierer 200 die LPSM (und alle anderen Metadaten), die von dem Decodierer 202 aus dem Eingangsbitstrom extrahiert werden, dem Postprozessor 300 zu, und der Postprozessor 300 führt eine Lautheits-Verarbeitung auf den decodierten Audiodaten durch unter Verwendung der LPSM oder führt eine Validierung der LPSM durch und führt dann eine Lautheits-Verarbeitung auf den decodierten Audiodaten durch unter Verwendung der LPSM, wenn die Validierung anzeigt, dass die LPSM gültig sind.
  • Wenn in einigen Ausführungsbeispielen der Decodierer 201 einen Audiobitstrom empfängt, der in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung mit einem kryptographischen Hash erzeugt wird, ist der Decodierer konfiguriert, den kryptographischen Hash aus einem Datenblock zu analysieren (zu parsen) und abzurufen, der aus dem Bitstrom bestimmt wird, wobei der Block Lautheits-Verarbeitungszustands-Metadaten (LPSM) aufweist. Der Validierer 203 kann den kryptographischen Hash verwenden, um den empfangenen Bitstrom und/oder assoziierte Metadaten zu validieren. Wenn zum Beispiel der Validierer 203 feststellt, dass die LPSM gültig sind, basierend auf einer Übereinstimmung zwischen einem kryptographischen Referenz-Hash und dem kryptographischen Hash, der aus dem Datenblock abgerufen wird, dann kann er an eine stromabwärtige Audioverarbeitungseinheit (zum Beispiel der Postprozessor 300, der eine Lautstärkeabgleichungseinheit sein kann oder umfassen kann) signalisieren, die Audiodaten des Bitstroms (unverändert) durchzulassen. Zusätzlich, optional oder alternativ können andere Typen von kryptographischen Techniken anstelle eines Verfahrens basierend auf einem kryptographischen Hash verwendet werden.
  • In einigen Implementierungen des Decodierers 100 ist der empfangene (und in dem Speicher 201 gepufferte) codierte Bitstrom ein AC-3-Bitstrom oder ein E-AC-3-Bitstrom und weist Audiodaten-Segmente (zum Beispiel die AB0-AB5-Segmente des Rahmens, der in 4 gezeigt wird) und Metadaten-Segmente auf, wobei die Audiodaten-Segmente indikativ sind für Audiodaten, und jedes von zumindest einigen der Metadaten-Segmente Lautheits-Verarbeitungszustands-Metadaten (LPSM) umfasst. Die Decodierer-Stufe 202 ist konfiguriert, aus dem Bitstrom LPSM mit dem folgenden Format zu extrahieren. Jedes der Metadaten-Segmente, das LPSM umfasst, ist in einem „addbsi”-Feld des Bitstrom-Information(„BSI”)-Segments eines Rahmens des Bitstroms oder in einem auxdata-Feld (zum Beispiel das AUX-Segment, das in 4 gezeigt wird) an dem Ende eines Rahmens des Bitstroms enthalten. Ein Rahmen des Bitstroms kann ein oder zwei Metadaten-Segment(e) umfassen, von denen jedes LPSM umfasst, und wenn der Rahmen zwei Metadaten-Segmente umfasst, ist eines in dem addbsi-Feld des Rahmens und das andere in dem AUX-Feld des Rahmens vorhanden. Jedes Metadaten-Segment mit LPSM umfasst ein LPSM-Nutzlast(oder Container)-Feld mit dem folgenden Format:
    ein Header (typischerweise mit einem Synchronisierungswort, das den Beginn der LPSM-Nutzlast identifiziert, gefolgt von Identifikationswerten, zum Beispiel die LPSM-Format-Version, Länge, Dauer., Anzahl und Teilstrom-Assoziationswerte, wie in Tabelle 2 unten angegeben); und
    nach dem Header,
    zumindest ein Dialog-Anzeigewert (zum Beispiel Parameter „Dialog-Kanal/Kanäle” in Tabelle 2), der angibt, ob entsprechende Audiodaten Dialog angeben oder nicht Dialog angeben (zum Beispiel welche Kanäle von entsprechenden Audiodaten Dialog angeben);
    zumindest ein Lautheit-Vorschrifteneinhaltungs-Wert (zum Beispiel Parameter „Lautheit-Vorschriften-Typ” in Tabelle 2), der angibt, ob entsprechende Audiodaten mit einem angezeigten Satz von Lautheits-Vorschriften übereinstimmen;
    zumindest ein Lautheits-Verarbeitungswert (zum Beispiel einer oder mehrere der Parameter „Dialog-Gate-gesteuertes Lautheit-Korrektur-Flag”, „Lautheit-Korrektur-Typ” in Tabelle 2), der zumindest einen Typ einer Lautheits-Verarbeitung angibt, die auf den entsprechenden Audiodaten durchgeführt wurde; und
    zumindest ein Lautheitswert (zum Beispiel einer oder mehrere der Parameter „ITU relative Gate-gesteuerte Lautheit”, „ITU Sprache-Gate-gesteuerte Lautheit”, „ITU (EBU 3341) Kurzzeit 3 s Lautheit” und „Wahre Spitze” von Tabelle 2), der zumindest eine Lautheit (zum Beispiel Spitzen- oder durchschnittliche Lautheit) angibt, die für die entsprechenden Audiodaten charakteristisch ist.
  • In einigen Implementierungen ist die Decodierer-Stufe 202 konfiguriert, aus dem „addbsi”-Feld und/oder einem auxdata-Feld eines Rahmens des Bitstroms zumindest ein Metadaten-Segment zu extrahieren, wobei jedes Metadaten-Segment das folgende Format hat:
    ein Kern-Header (typischerweise mit einem Synchronisierungswort, das den Beginn des Metadaten-Segments identifiziert, gefolgt von zumindest einem Identifizierungswert, zum Beispiel die Kernelement-Version, Länge und Dauer, Anzahl erweiterte Elemente, und Teilstrom-Assoziationswerte, in Tabelle 1 unten angegeben); und
    nach dem Kern-Header, zumindest ein Schutzwert (zum Beispiel der HMAC-Digest und Audio-Fingerabdruck-Werte von Tabelle 1), nützlich für zumindest eines aus einer Entschlüsselung, Authentifizierung oder Validierung von zumindest einem aus Lautheits-Verarbeitungszustands-Metadaten oder den entsprechenden Audiodaten); und
    ebenfalls nach dem Kern-Header, wenn das Metadaten-Segment LPSM umfasst, eine LPSM-Nutzlast-Identifikation („ID”) und LPSM-Nutzlastgrößenwerte, die folgende Metadaten als eine LPSM-Nutzlast identifizieren und eine Größe der LPSM-Nutzlast angeben.
  • Das LPSM-Nutzlast(oder Container)-Segment (vorzugsweise mit dem oben spezifizierten Format) folgt der LPSM-Nutzlast-ID und den LPSM-Nutzlastgrößenwerten.
  • Im Allgemeinen hat der codierte Audiobitstrom, der durch bevorzugte Ausführungsbeispiele der Erfindung erzeugt wird, eine Struktur, die einen Mechanismus bietet, um Metadaten-Elemente und Teilelemente als Kern (vorgeschrieben) oder erweitert (optionale Elemente) zu bezeichnen. Dies ermöglicht, dass die Datenrate des Bitstroms (einschließlich seiner Metadaten) über eine Vielzahl von Anwendungen skaliert wird. Die Kern(vorgeschriebenen)-Elemente der bevorzugten Bitstrom-Syntax sollten auch fähig sein für ein Signalisieren, dass erweiterte (optionale) Elemente, die mit dem Audioinhalt assoziiert sind, vorhanden sind (in-band) und/oder an einem entfernten Ort sind (out-of-band).
  • Kernelement(e) müssen in jedem Rahmen des Bitstroms vorhanden sein. Einige Teilelemente von Kernelementen sind optional und können in jeder Kombination vorhanden sein. Erweiterte Elemente müssen nicht in jedem Rahmen vorhanden sein (um einen Bitrate-Overhead zu begrenzen). Somit können erweiterte Elemente in einigen Rahmen vorhanden sein und in anderen nicht. Einige Teilelemente eines erweiterten Elements sind optional und können in jeder Kombination vorhanden sein, während einige Teilelemente eines erweiterten Elements vorgeschrieben bzw. obligatorisch sein können (d. h., wenn das erweiterte Element in einem Rahmen des Bitstroms vorhanden ist).
  • In einer Klasse von Ausführungsbeispielen wird ein codierter Audiobitstrom, der eine Sequenz von Audiodaten-Segmenten und Metadaten-Segmenten aufweist, erzeugt (zum Beispiel durch eine Audioverarbeitungseinheit, die die Erfindung verkörpert). Die Audiodaten-Segmente sind indikativ für Audiodaten, wobei jedes von zumindest einigen der Metadaten-Segmente Lautheits-Verarbeitungszustands-Metadaten (LPSM) umfasst und die Audiodaten-Segmente mit den Metadaten-Segmenten zeitgemultiplext sind. In bevorzugten Ausführungsbeispielen dieser Klasse hat jedes der Metadaten-Segmente ein bevorzugtes Format, das hier beschrieben wird.
  • In einem bevorzugten Format ist der codierte Bitstrom ein AC-3-Bitstrom oder ein E-AC-3-Bitstrom, und jedes der Metadaten-Segmente, das LPSM enthält, ist als zusätzliche Bitstrom-Information in dem „addbsi”-Feld (das in 6 gezeigt wird) des Bitstrom-Information(„BSI”)-Segments eines Rahmens des Bitstroms oder in einem auxdata-Feld eines Rahmens des Bitstroms enthalten (zum Beispiel durch Stufe 107 einer bevorzugten Implementierung des Codierers 100).
  • In dem bevorzugten Format umfasst jeder der Rahmen ein Kernelement, das das Format hat, das in Tabelle 1 unten gezeigt wird, in dem addbsi-Feld des Rahmens: Tabelle 1
    Parameter Beschreibung Verpflichtend/Optional
    SYNC [ID] V
    Kernelement-Version V
    Kernelement-Länge V
    Kernelement-Dauer (xxx) V
    Anzahl erweiterte Elemente Zeigt die Anzahl von erweiterten Metadaten-Elementen an, die mit dem Kernelement assoziiert sind. Dieser Wert kann inkrementieren/dekrementieren, wenn der Bitstrom von der Erzeugung durch eine Verteilung und endgültige Ausgabe geleitet wird. V
    Teilstromassoziation Beschreibt, mit welchem Teilstrom/welchen Teilströmen das Kernelement assoziiert ist. V
    Signatur (HMAC-Digest) 256-Bit-HMAC-Digest (unter Verwendung eines SHA-2-Algorithmus), berechnet über die Audiodaten, das Kernelement und alle erweiterten Elemente des gesamten Rahmens. V
    PGM-Grenze-Rückwärtszählen Feld erscheint nur für einige Rahmen am Anfang oder Ende einer Audioprogrammdatei/eines Audioprogrammstroms. Somit kann eine Änderung einer Kernelement-Version verwendet werden, um die Aufnahme dieses Parameters zu signalisieren. O
    Audio-Fingerabdruck Audio-Fingerabdruck genommen über einige PCM-Audioabtastwerte, die durch das Feld der Kernelement-Dauer repräsentiert werden. O
    Video-Fingerabdruck Video-Fingerabdruck genommen über einige komprimierte Videoabtastwerte (wenn vorhanden), die durch das Feld der Kernelement-Dauer repräsentiert werden. O
    URL/UUID Dieses Feld ist definiert, eine URL und/oder UUID (kann zu dem Fingerabdruck redundant sein) zu tragen, die einen externen Ort von zusätzlichem Programminhalt (Essenz) und/oder Metadaten referenziert, die mit dem Bitstrom assoziiert sind. O
  • In dem bevorzugten Format enthält jedes der addbsi(oder auxdata)-Felder, das einen LPSM enthält, einen Kern-Header (und optional auch zusätzliche Kernelemente), und nach dem Kern-Header (oder dem Kern-Header und anderen Kernelementen) die folgenden LPSM-Werte (Parameter):
    eine Nutzlast-ID (die die Metadaten als LPSM identifiziert) nach den Kernelementwerten (zum Beispiel wie in Tabelle 1 spezifiziert);
    eine Nutzlastgröße (die die Größe der LPSM-Nutzlast angibt) nach der Nutzlast-ID; und
    LPSM-Daten (nach der Nutzlast-ID und dem Nutzlastgrößenwert) mit einem Format, das in der folgenden Tabelle (Tabelle 2) angegeben wird: Tabelle 2
    LPSM-Parameter [Intelligente Lautheit] Beschreibung Anzahl von eindeutigen Zuständen Verpflichtend/Optional Einfügerate (Periode einer Aktualisierung des Parameters)
    LPSM-Version V
    LPSM-Periode (xxx) Anwendbar nur auf xxx Felder V
    LPSM-Anzahl V
    LPSM-Teilstromassoziation V
    Dialog-Kanal/Kanäle Gibt an, welche Kombination von L, C & R Audiokanälen Sprache über die vorherigen 0,5 Sekunden enthält. Wenn keine Sprache in einer L, C oder R Kombination vorhanden ist, dann soll dieser Parameter „kein Dialog” anzeigen 8 V ~ 0,5 Sekunden (typisch)
    Lautheitsvorschriftentyp Gibt an, dass der assoziierte Audiodatenstrom einen spezifischen Satz von Vorschriften einhält (z. B. ATSC A/85 oder EBU R 128) 8 V Rahmen
    Dialog-Gate-gesteuertes Lautheits-Korrektur-Flag Gibt an, ob der assoziierte Audiostrom korrigiert wurde basierend auf einer Dialog-GateSteuerung 2 O (nur vorhanden, wenn Lautheitsvorschriftentyp (Loudness_Regulation_Type) angibt, dass das entsprechende Audio NICHTKORRIGIERT ist) Rahmen
    Lautheits-Korrektur-Flag Gibt an, ob der assoziierte Audiostrom korrigiert wurde mit einem unendlichen Voraus-(Datei-basiert) oder mit einem Echtzeit(RT – realtime)-Lautheit- und Dynamikregler. 2 O (nur vorhanden, wenn Lautheitsvorschriftentyp (Loudness_Regulation_Type) angibt, dass das entsprechende Audio NICHTKORRIGIERT ist) Rahmen
    ITU relative Gate-gesteuerte Lautheit (INF) Gibt die ITU-R BS.1770-2 integrierte Lautheit des assoziierten Audiostroms ohne angewendete Metadaten an (zum Beispiel 7 Bits: –58 -> +5,5 LKFS 0,5 LKFS-Schritte) 128 O 1 Sekunde
    ITU Sprache-Gate-gesteuerte Lautheit (INF) Gibt die ITU-R BS.1770-2 integrierte Lautheit des assoziierten Audiostroms ohne angewendete Metadaten an (zum Beispiel 7 Bits: –58 -> +5,5 LKFS 0,5 LKFS-Schritte) 128 O 1 Sekunde
    ITU (EBU 3341) Kurzzeit 3 s Lautheit Gibt die 3-Sekunden nicht-Gate-gesteuerte ITU-Lautheit des assoziierten Audiostroms ohne angewendete Metadaten an (gleitendes Fenster) @ ~ 10 Hz Einfügerate (zum Beispiel 8 Bits: 116 -> +11,5 LKFS 0,5 LKFS-Schritte) 256 O 0,1 Sekunden
    „Wahre Spitze”-Wert Gibt den ITU-R BS.1770 Annex 2 „Wahre Spitze”-Wert (dB TP) des assoziierten Audiostroms ohne angewendete Metadaten an (d. h. größter Wert über Rahmenperiode signalisiert in Elementperiode-Feld) 116 -> +11,5 LKFS 0,5 LKFS-Schritte) 256 O 0,5 Sekunden
  • In einem anderen bevorzugten Format eines codierten Bitstroms, der in Übereinstimmung mit der Erfindung erzeugt wird, ist der Bitstrom ein AC-3-Bitstrom oder ein E-AC-3-Bitstrom und jedes der Metadaten-Segmente, das LPSM umfasst, ist in entweder: einem „addbsi”-Feld (das in 6 gezeigt wird) des Bitstrom-Information(„BSI”)-Segments eines Rahmens des Bitstroms; oder einem auxdata-Feld (zum Beispiel das in 4 gezeigte AUX-Segment) am Ende eines Rahmens des Bitstroms enthalten (zum Beispiel durch die Stufe 107 einer bevorzugten Implementierung des Codierers 100). Ein Rahmen kann ein oder zwei Metadaten-Segment(e) umfassen, von denen jedes LPSM umfasst, und wenn der Rahmen zwei Metadaten-Segmente umfasst, ist eines in dem addbsi-Feld des Rahmens und das andere in dem AUX-Feld des Rahmens vorhanden. Jedes Metadaten-Segment mit LPSM hat das Format, das oben unter Bezugnahme auf die Tabellen 1 und 2 oben spezifiziert wird (d. h. es umfasst die Kernelemente, die in der Tabelle 1 spezifiziert werden, gefolgt von der Nutzlast-ID (die die Metadaten als LPSM identifiziert) und Nutzlastgrößenwerte, die oben spezifiziert werden, gefolgt von der Nutzlast (die LPSM-Daten, die ein Format wie in Tabelle 2 angegeben haben).
  • In einem anderen bevorzugten Format ist der codierte Bitstrom ein Dolby-E-Bitstrom, und jedes der Metadaten-Segmente, das LPSM umfasst, ist die Position der ersten N Abtastwerte des Dolby-E-Schutzband-Intervalls. Ein Dolby-E-Bitstrom mit einem derartigen Metadaten-Segment, das LPSM umfasst, umfasst vorzugsweise einen Wert, der für eine LPSM-Nutzlastlänge indikativ ist, die in dem Pd-Wort der SMPTE-337M-Präambel signalisiert wird (die SMPTE-337M-Pa-Wortwiederholungsrate bleibt vorzugsweise identisch zu einer assoziierten Videorahmenrate).
  • In einem bevorzugten Format, bei dem der codierte Bitstrom ein E-AC-3-Bitstrom ist, ist jedes der Metadaten-Segmente, das LPSM enthält, als zusätzliche Bitstrom-Information in dem „addbsi”-Feld des Bitstrom-Information(„BSI”)-Segments eines Rahmens des Bitstroms enthalten (zum Beispiel durch die Stufe 107 einer bevorzugten Implementierung des Codierers 100). Im Folgenden werden zusätzliche Aspekte eines Codierens eines E-AC-3-Bitstroms mit LPSM in diesem bevorzugten Format beschrieben:
    • 1. Während einer Erzeugung eines E-AC-3-Bitstroms, während der E-AC-3-Codierer (der die LPSM-Werte in dem Bitstrom einfügt) „aktiv” ist, für jeden erzeugten Rahmen (syncframe), soll der Bitstrom einen Metadaten-Block (einschließlich LPSM) umfassen, der in dem addbsi-Feld des Rahmens getragen wird. Die erforderlichen Bits, um den Metadaten-Block zu tragen, sollen die Codierer-Bitrate (Rahmenlänge) nicht erhöhen;
    • 2. Jeder Metadaten-Block (der LPSM enthält) soll die folgende Information enthalten: 1. Lautheits_Korrektur_Typ_Flag (loudness_correction_type_flag): wobei „1” anzeigt, dass die Lautheit der entsprechenden Audiodaten stromaufwärts von dem Codierer korrigiert wurde, und „0” anzeigt, dass die Lautheit von einem Lautheits-Korrektor korrigiert wurde, der in dem Codierer eingebettet ist (zum Beispiel der Lautheitsprozessor 103 des Codierers 100 von 2); 2. Sprache_Kanal (speech_channel): zeigt an, welche(r) Quell-Kanal/Kanäle Sprache (über die vorherigen 0,5 sek) enthält/enthalten. Wenn keine Sprache erfasst wird, soll dies derart angezeigt werden; 3. Sprache_Lautheit (speech_loudness): zeigt die integrierte Sprache-Lautheit jedes entsprechenden Audiokanals an, der Sprache enthält (über die vorherigen 0,5 sek); 4. ITU_Lautheit (ITU_loudness): zeigt die integrierte ITU BS.1770-2 Lautheit jedes entsprechenden Audiokanals an; 5. Verstärkung: Lautheit-Betriebsverstärkung(en) zur Umkehr in einem Decodierer (um Reversibilität zu demonstrieren);
    • 3. Während der E-AC-3-Codierer (der die LPSM-Werte in den Bitstrom einfügt) „aktiv” ist und einen AC-3-Rahmen mit einem „vertrauenswürdig”-Flag empfängt, soll die Lautheit-Steuervorrichtung in dem Codierer (zum Beispiel der Lautheitsprozessor 103 des Codierers 100 von 2) umgangen werden. Die „vertrauenswürdig”-Quelle-dialnorm- und DRC-Werte sollen an die E-AC-3-Codierer-Komponente (zum Beispiel die Stufe 107 der Codierers 100) weitergeleitet werden (zum Beispiel durch den Generator 106 des Codierers 100). Die LPSM-Block-Erzeugung geht weiter und das Lautheits_Korrektur_Typ_Flag wird auf „1” gesetzt. Die Lautheit-Steuervorrichtung-Umgehungssequenz muss mit dem Beginn des decodierten AC-3-Rahmens synchronisiert werden, wo das „vertrauenswürdig”-Flag erscheint. Die Lautheit-Steuervorrichtung-Umgehungssequenz soll wie folgt implementiert werden: die Gleichmacher_Menge(leveler_amount)-Steuerung wird von einem Wert von 9 auf einen Wert von 0 über 10 Audioblock-Perioden (d. h. 53,3 msek) dekrementiert und die Gleichmacher_zurück_Ende_Messung(leveler_back_end_meter)-Steuerung wird in einen Umgehungsmodus gesetzt (diese Operation soll zu einem nahtlosen Übergang führen). Der Begriff „vertrauenswürdige” Umgehung des Gleichmachers impliziert, dass der dialnorm-Wert des Quelle-Bitstroms auch an dem Ausgang des Codierers wiederverwendet wird (zum Beispiel, wenn der „vertrauenswürdig” Quelle-Bitstrom einen dialnorm-Wert von –30 hat, dann soll der Ausgang des Codierers –30 für den abgehenden dialnorm-Wert verwenden);
    • 4. Während der E-AC-3-Codierer (der die LPSM-Werte in den Bitstrom einfügt) „aktiv” ist und einen AC-3-Rahmen ohne das „vertrauenswürdig”-Flag empfängt, soll die Lautheit-Steuervorrichtung, die in dem Codierer (zum Beispiel der Lautheitsprozessor 103 des Codierers 100 von 2) eingebettet ist, aktiv sein. Eine LPSM-Block-Erzeugung geht weiter und das Lautheits_Korrektur_Typ_Flag wird auf „0” gesetzt. Die Lautheit-Steuervorrichtung-Aktivierungssequenz soll mit dem Beginn des decodierten AC-3-Rahmens synchronisiert werden, wo das „vertrauenswürdig”-Flag verschwindet. Die Lautheit-Steuervorrichtung-Aktivierungssequenz soll wie folgt implementiert werden: die Gleichmacher_Menge(leveler_amount)-Steuerung wird von einem Wert von 0 auf einen Wert von 9 über 1 Audioblock-Periode (d. h. 5,3 msek) inkrementiert und die Gleichmacher_zurück_Ende_Messung(leveler_back_end_meter)-Steuerung wird in einen „aktiven” Modus gesetzt (diese Operation soll zu einem nahtlosen Übergang führen und ein zurück_Ende_Messung(back_end_meter)-Integrations-Zurücksetzen umfassen); und
    • 5. während einer Codierung soll eine graphische Benutzerschnittstelle (GUI – graphical user interface) für einen Benutzer die folgenden Parameter anzeigen: „Eingangsaudioprogramm: [Vertrauenswürdig/Nicht-Vertrauenswürdig]” – der Zustand dieses Parameters basiert auf dem Vorhandensein des „vertrauenswürdig”-Flags in dem Eingangssignal; und „Echtzeit-Lautheit-Korrektur: [Aktiviert/Deaktiviert]” – der Zustand dieses Parameters basiert darauf, ob diese Lautheit-Steuervorrichtung, die in dem Codierer eingebettet ist, aktiv ist.
  • Bei einem Decodieren eines AC-3- oder E-AC-3-Bitstroms, der LPSM hat (in dem bevorzugten Format), die in dem „addbsi”-Feld des Bitstrom-Information(„BSI”)-Segments jedes Rahmens des Bitstroms enthalten sind, soll der Decodierer die LPSM-Block-Daten (in dem addbsi-Feld) parsen bzw. analysieren und alle extrahierten LPSM-Werte an eine graphische Benutzerschnittstelle (GUI – graphical user interface) leiten. Der Satz von extrahierten LPSM-Werten wird pro Rahmen aktualisiert.
  • In einem anderen bevorzugten Format eines codierten Bitstroms, der in Übereinstimmung mit der Erfindung erzeugt wird, ist der codierte Bitstrom ein AC-3-Bitstrom oder ein E-AC-3-Bitstrom, und jedes der Metadaten-Segmente, das LPSM umfasst, ist als zusätzliche Bitstrom-Information in dem „addbsi”-Feld (das in 6 gezeigt wird) des Bitstrom-Information(„BSI”)-Segments (oder in dem Aux-Segment) eines Rahmens des Bitstroms enthalten (zum Beispiel durch die Stufe 107 einer bevorzugten Implementierung des Codierers 100). In diesem Format (das eine Variation des Formats ist, das oben unter Bezugnahme auf die Tabellen 1 und 2 beschrieben wird) enthält jedes der addbsi(oder Aux)-Felder, das LPSM enthält, die folgenden LPSM-Werte:
    die Kernelemente, die in Tabelle 1 spezifiziert werden, gefolgt von der Nutzlast-ID (die die Metadaten als LPSM identifiziert) und Nutzlastgrößenwerten, gefolgt von der Nutzlast (LPSM-Daten), die das folgende Format hat (ähnlich zu den verpflichtenden Elementen, die in der Tabelle 2 oben angegeben werden):
    Version der LPSM-Nutzlast: ein 2-Bit-Feld, das die Version der LPSM-Nutzlast angibt;
    „dialchan”: ein 3-Bit-Feld, das angibt, ob die linken, rechten und/oder Center-Kanäle von entsprechenden Audiodaten einen gesprochenen Dialoge enthalten. Die Bitzuweisung des „dialchan”-Felds kann wie folgt sein: Bit 0, das das Vorhandensein von Dialog in dem linken Kanal anzeigt, wird in dem höchstwertigen Bit des „dialchan”-Felds gespeichert; und Bit 2, das das Vorhandensein von Dialog in dem Center-Kanal anzeigt, wird in dem niedrigstwertigen Bit des „dialchan”-Felds gespeichert.
  • Jedes Bit des „dialchan”-Felds wird auf „1” gesetzt, wenn der entsprechende Kanal einen gesprochenen Dialog während der vorhergehenden 0,5 Sekunden des Programms enthält;
    „loudregtyp”: ein 3-Bit-Feld, das anzeigt, welchem Lautheit-Vorschriften-Standard die Programmlautheit entspricht. Ein Setzen des „loudregtyp”-Felds auf „000” zeigt an, dass die LPSM keine Lautheit-Vorschriften-Einhaltung anzeigen. Zum Beispiel kann ein Wert dieses Felds (zum Beispiel 000) anzeigen, dass die Einhaltung eines Lautheit-Vorschriften-Standards nicht angezeigt wird, ein anderer Wert dieses Felds (zum Beispiel 001) kann anzeigen, dass die Audiodaten des Programms dem ATSC A/85 Standard entsprechen, und ein anderer Wert dieses Felds (zum Beispiel 010) kann anzeigen, dass die Audiodaten des Programms dem EBU R128 Standard entsprechen. In dem Beispiel sollen, wenn das Feld auf einen anderen Wert als „000” gesetzt ist, die „loudcorrdialgat”- und „loudcorrtyp”-Felder in der Nutzlast folgen;
    „loudcorrdialgat”: ein Ein-Bit-Feld, das anzeigt, ob eine Dialog-Gate-gesteuerte. Lautheitskorrektur angewendet wurde. Wenn die Lautheit des Programms unter Verwendung einer Dialog-Gate-Steuerung korrigiert wurde, wird der Wert des „loudcorrdialgat”-Felds auf „1” gesetzt. Ansonsten wird es auf „0” gesetzt;
    „loudcorrtyp”: ein Ein-Bit-Feld, das den Typ einer Lautheitskorrektur anzeigt, die auf das Programm angewendet wird. Wenn die Lautheit des Programms mit einem unendlichen Voraus(dateibasierten)-Lautheitskorrekturprozess korrigiert wurde, wird der Wert des „loudcorrtyp”-Felds auf „0” gesetzt. Wenn die Lautheit des Programms unter Verwendung einer Kombination aus Echtzeit-Lautheit-Messung und Dynamikregelung korrigiert wurde, wird der Wert dieses Felds auf „1” gesetzt;
    „loudrelgate”: ein Ein-Bit-Feld, das anzeigt, ob relative Gate-gesteuerte Lautheit-Daten (ITU) existieren. Wenn das „loudrelgate”-Feld auf „1” gesetzt ist, soll ein 7-Bit-„ituloudrelgat”-Feld in der Nutzlast folgen;
    „loudrelgat”: ein 7-Bit-Feld, das eine relative Gate-gesteuerte Programmlautheit (ITU) anzeigt. Dieses Feld zeigt die integrierte Lautheit des Audioprogramms, gemessen gemäß ITU-R BS.1770-2, ohne dass Verstärkungsanpassungen aufgrund von dialnorm und Dynamikbereichskomprimierung angewendet werden. Die Werte von 0 bis 127 werden als –58 LKFS bis +5,5 LKFS in 0,5 LKFS-Schritten interpretiert;
    „loudspchgate”: ein Ein-Bit-Feld, das anzeigt, ob Sprache-Gate-gesteuerte Lautheit-Daten (ITU) existieren. Wenn das „loudspchgate”-Feld auf „1” gesetzt ist, soll ein 7-Bit-„loudspchgat”-Feld in der Nutzlast folgen;
    „loudspchgat”: ein 7-Bit-Feld, das eine Sprache-Gate-gesteuerte Programmlautheit anzeigt. Dieses Feld zeigt die integrierte Lautheit des gesamten entsprechenden Audioprogramms an, gemessen gemäß der Formel (2) von ITU-R BS.1770-3 und ohne dass Verstärkungsanpassungen aufgrund von dialnorm und Dynamikbereichskomprimierung angewendet werden. Die Werte von 0 bis 127 werden als –58 bis +5,5 LKFS in 0,5 LKFS-Schritten interpretiert;
    „loudstrm3se”: ein Ein-Bit-Feld, das anzeigt, ob Kurzzeit(3 Sekunden)-Lautheit-Daten existieren. Wenn das Feld auf „1” gesetzt ist, soll ein 7-Bit-„loudstrm3s”-Feld in der Nutzlast folgen;
    „loudstrm3s”: ein 7-Bit-Feld, das die nicht-Gate-gesteuerte Lautheit der vorhergehenden 3 Sekunden des entsprechenden Audioprogramms anzeigt, gemessen gemäß ITU-R BS.1771-1 und ohne dass Verstärkungsanpassungen aufgrund von dialnorm und Dynamikbereichskomprimierung angewendet werden. Die Werte von 0 bis 127 werden als –116 LKFS bis +11,5 LKFS in 0,5 LKFS-Schritten interpretiert;
    „truepke”: ein Ein-Bit-Feld, das anzeigt, ob „wahre Spitze”-Lautheit-Daten existieren. Wenn das „truepke”-Feld auf „1” gesetzt ist, soll ein 8-Bit-„truepk”-Feld in der Nutzlast folgen; und
    „truepk”: ein 8-Bit-Feld, das den „wahre Spitze”-Abtastwert des Programms anzeigt, gemessen gemäß Annex 2 von ITU-R BS.1770-3 und ohne dass Verstärkungsanpassungen aufgrund von dialnorm und Dynamikbereichskomprimierung angewendet werden. Die Werte von 0 bis 256 werden als –116 LKFS bis +11,5 LKFS in 0,5 LKFS-Schritten interpretiert.
  • In einigen Ausführungsbeispiele weist das Kernelement eines Metadaten-Segments in einem auxdata-Feld (oder einem „addbsi”-Feld) eines Rahmens eines AC-3-Bitstroms oder eines E-AC-3-Bitstroms einen Kern-Header auf (typischerweise mit Identifizierungswerten, zum Beispiel, Kernelementversion), und nach dem Kern-Header: Werte, die anzeigen, ob Fingerabdruckdaten (oder andere Schutzwerte) für Metadaten des Metadaten-Segments enthalten sind, Werte, die anzeigen, ob externe Daten (in Bezug auf Audiodaten, die den Metadaten des Metadaten-Segments entsprechen) existieren, eine Nutzlast-ID und Nutzlastgrößenwerte für jeden Typ von Metadaten (zum Beispiel LPSM und/oder Metadaten eines anderen Typs als LPSM), identifiziert durch das Kernelement, und Schutzwerte für zumindest einen Typ von Metadaten, die durch das Kernelement identifiziert werden. Die Metadaten-Nutzlast(en) des Metadaten-Segments folgt/folgen dem Kern-Header und sind (in einigen Fällen) in Werten des Kernelements verschachtelt.
  • Ausführungsbeispiele der vorliegenden Erfindung können in Hardware, Firmware oder Software oder einer Kombination aus beiden (zum Beispiel als ein programmierbares Logik-Array) implementiert sein. Sofern nicht anders angegeben, sind die Algorithmen oder Prozesse, die als Teil der Erfindung enthalten sind, nicht inhärent auf einen bestimmten Computer oder eine andere Vorrichtung bezogen. Insbesondere können verschiedene Universalmaschinen mit Programmen verwendet werden, die gemäß den Lehren hier geschrieben werden, oder es kann einfacher sein, eine stärker spezialisierte Vorrichtung (zum Beispiel integrierte Schaltungen) zu konstruieren, um die erforderlichen Verfahrensschritte durchzuführen. Somit kann die Erfindung in einem oder mehreren Computerprogramm(en) implementiert werden, das/die auf einem oder mehreren programmierbaren Computersystem(en) ausgeführt wird/werden (zum Beispiel eine Implementierung eines der Elemente von 1 oder der Codierer 100 von 2 (oder ein Element davon), oder der Decodierer 200 von 3 (oder ein Element davon), oder der Postprozessor 300 von 3 (oder ein Element davon)), die jeweils zumindest einen Prozessor, zumindest ein Datenspeichersystem (einschließlich flüchtiger und nicht-flüchtiger Speicher und/oder Speicherelemente), zumindest eine Eingabevorrichtung oder -anschluss, und zumindest eine Ausgabevorrichtung oder -anschluss aufweisen. Der Programmcode wird auf Eingangsdaten angewendet, um die hier beschriebenen Funktionen durchzuführen und eine Ausgabeinformation zu erzeugen. Die Ausgabeinformation wird auf eine oder mehrere Ausgabevorrichtung(en) auf bekannte Weise angewendet.
  • Jedes derartige Programm kann in jeder gewünschten Computersprache (einschließlich Maschinen-, Assembler- oder höhere prozedurale, logische oder objektorientierte Programmiersprachen) implementiert werden, um mit einem Computersystem zu kommunizieren. In jedem Fall kann die Sprache eine kompilierte oder interpretierte Sprache sein.
  • Zum Beispiel, wenn durch Computersoftware-Anweisungssequenzen implementiert, können verschiedene Funktionen und Schritte von Ausführungsbeispielen der Erfindung durch Multithread-Software-Anweisungssequenzen implementiert werden, die in geeigneter digitaler Signalverarbeitungs-Hardware laufen, in diesem Fall können die verschiedenen Vorrichtungen, Schritte und Funktionen der Ausführungsbeispiele Teilen der Software-Anweisungen entsprechen.
  • Jedes derartige Computerprogramm ist vorzugsweise auf einem Speichermedium oder einer Speichervorrichtung (zum Beispiel Festspeicher oder -Media oder magnetische oder optische Media) gespeichert oder auf diese heruntergeladen, die durch einen allgemeinen oder programmierbaren Spezial-Computer lesbar sind, zum Konfigurieren und Betreiben des Computers, wenn das Speichermedium oder die Speichervorrichtung durch das Computersystem gelesen wird, um die hier beschriebenen Verfahren durchzuführen. Das erfindungsgemäße System kann auch als ein computerlesbares Speichermedium implementiert sein, das mit einem Computerprogramm konfiguriert ist (d. h. Speichern), wobei das derart konfigurierte Speichermedium ein Computersystem veranlasst, auf eine spezifische und vordefinierte Weise zu arbeiten, um die hier beschriebenen Funktionen durchzuführen.
  • Eine Anzahl von Ausführungsbeispielen der Erfindung wurden beschrieben. Dennoch ist offensichtlich, dass verschiedene Modifikationen durchgeführt werden können, ohne von dem Gedanken und dem Umfang der Erfindung abzuweichen. Zahlreiche Modifikationen und Variationen der vorliegenden Erfindung sind angesichts der obigen Lehren möglich. Es ist offensichtlich, dass in dem Umfang der beigefügten Ansprüche die Erfindung anders praktiziert werden kann, als spezifisch hier beschrieben wurde.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • WO 2012/075246 A2 [0010]
    • US 5583962 [0013]
    • US 5632005 [0013]
    • US 5633981 [0013]
    • US 5727119 [0013]
    • US 6021386 [0013]
  • Zitierte Nicht-Patentliteratur
    • ATSC Standard A52/A: Digital Audio Compression Standard (AC-3), Revision A, Advanced Television Systems Committee, 20. August 2001 [0013]
    • „Introduction to Dolby Digital Plus, an Enhancement to the Dolby Digital Coding System,” AES Convention Paper 6196, 117. AES Convention, 28. Oktober 2004 [0014]
    • „Efficient Bit Allocation, Quantization, and Coding in an Audio Distribution System”, AES Preprint 5068, 107. AES Conference, August 1999 [0014]
    • „Professional Audio Coder Optimized for Use with Video”, AES Preprint 5033, 10. AES Conference August 1999 [0014]
    • Standard ITU-R BS.1770 [0088]
    • ITU-R BS.1770-2 [0126]
    • ITU-R BS.1770-2 [0126]
    • ITU-R BS.1770 [0126]
    • ITU BS.1770-2 [0129]
    • ATSC A/85 Standard [0132]
    • EBU R128 Standard [0132]
    • ITU-R BS.1770-2 [0132]
    • ITU-R BS.1770-3 [0132]
    • ITU-R BS.1771-1 [0132]
    • ITU-R BS.1770-3 [0132]

Claims (15)

  1. Eine Audioverarbeitungsvorrichtung, die aufweist: einen Eingangspufferspeicher zum Speichern zumindest eines Rahmens eines codierten Audiobitstroms, der Lautheits-Verarbeitungszustands-Metadaten (LPSM – Loudness Processing State Metadata) und Audiodaten aufweist; einen Parser, der mit dem Eingangspufferspeicher gekoppelt ist, zum Extrahieren des codierten Audiobitstroms und/oder der LPSM; einen AC-3- oder E-AC-3-Decodierer, der mit dem Parser gekoppelt ist, zum Erzeugen eines Stroms von decodierten Audiodaten; und einen Ausgangspufferspeicher, der mit dem Decodierer gekoppelt ist, zum Speichern der decodierten Audiodaten.
  2. Die Audioverarbeitungsvorrichtung gemäß Anspruch 1, die weiter einen Lautheitsprozessor aufweist, der mit dem AC-3- oder E-AC-3-Decodierer gekoppelt ist, zum Durchführen einer adaptiven Lautheits-Verarbeitung des Stroms von decodierten Audiodaten unter Verwendung der LPSM.
  3. Die Audioverarbeitungsvorrichtung gemäß Anspruch 2, die weiter einen Audio-Zustandsvalidierer aufweist, der mit dem AC-3- oder E-AC-3-Decodierer gekoppelt ist, zum Authentifizieren und/oder Validieren der LPSM und/oder des Stroms von decodierten Audiodaten unter Verwendung der LPSM, wobei der Audio-Zustandsvalidierer weiter mit dem Lautheitsprozessor gekoppelt ist, um die adaptive Lautheits-Verarbeitung des Lautheitsprozessors zu steuern.
  4. Die Audioverarbeitungsvorrichtung gemäß Anspruch 2, die weiter einen Postprozessor aufweist, der mit dem AC-3- oder E-AC-3-Decodierer gekoppelt ist, zum Durchführen einer adaptiven Lautheits-Verarbeitung auf dem Strom von decodierten Audiodaten unter Verwendung der LPSM.
  5. Die Audioverarbeitungsvorrichtung gemäß Anspruch 4, die weiter einen Audio-Zustandsvalidierer aufweist, der mit dem AC-3- oder E-AC-3-Decodierer gekoppelt ist, zum Authentifizieren und/oder Validieren der LPSM und/oder des Stroms von decodierten Audiodaten unter Verwendung der LPSM, wobei der Audio-Zustandsvalidierer weiter mit dem Lautheitsprozessor und dem Postprozessor gekoppelt ist, um die adaptive Lautheits-Verarbeitung des Lautheitsprozessors und des Postprozessors zu steuern.
  6. Die Audioverarbeitungsvorrichtung gemäß Anspruch 1, wobei die LPSM in einem Container enthalten sind, der ein oder mehrere Lautheits-Verarbeitungszustands-Metadaten aufweist, die sich nach einem Header in dem zumindest einen Rahmen befinden.
  7. Die Audioverarbeitungsvorrichtung gemäß Anspruch 1, wobei die LPSM einen Lautheitsregulierungstyp-Schlitz aufweisen.
  8. Die Audioverarbeitungsvorrichtung gemäß Anspruch 1, wobei die LPSM einen Lautheitskorrekturtyp-Schlitz aufweisen.
  9. Die Audioverarbeitungsvorrichtung gemäß Anspruch 1, die weiter eine Kommunikationsschnittstelle aufweist, die mit dem Eingangspufferspeicher gekoppelt ist, zum Empfangen des zumindest einen Rahmens des codierten Audiobitstroms.
  10. Die Audioverarbeitungsvorrichtung gemäß Anspruch 9, wobei der zumindest eine Rahmen des codierten Audiobitstroms weiter Schutzbits aufweist, die mit einem Hash-basierten Nachrichtenauthentifizierungscode (MAC – Message Authentication Code) assoziiert sind.
  11. Die Audioverarbeitungsvorrichtung gemäß Anspruch 10, die weiter einen Audio-Zustandsvalidierer aufweist, der mit dem AC-3- oder E-AC-3-Decodierer gekoppelt ist, zum Authentifizieren der Audiodaten unter Verwendung der Schutzbits.
  12. Die Audioverarbeitungsvorrichtung gemäß Anspruch 11, wobei der Hash-basierte Nachrichtenauthentifizierungscode aus einem Verschlüsselungsalgorithmus erzeugt wird.
  13. Die Audioverarbeitungsvorrichtung gemäß Anspruch 12, wobei der Verschlüsselungsalgorithmus ein SHA-2-Algorithmus ist.
  14. Die Audioverarbeitungsvorrichtung gemäß Anspruch 13, die weiter einen Lautheitsprozessor aufweist, der mit dem AC-3- oder E-AC-3-Decodierer gekoppelt ist, zum Durchführen einer adaptiven Lautheits-Verarbeitung des Stroms von decodierten Audiodaten unter Verwendung der LPSM.
  15. Die Audioverarbeitungsvorrichtung gemäß Anspruch 14, wobei die adaptive Lautheits-Verarbeitung deaktiviert ist, wenn der Audio-Zustandsvalidierer die Schutzbits nicht authentifiziert.
DE202013001075U 2013-01-21 2013-02-01 Audio-Codierer und Decodierer mit Lautheits-Verarbeitugszustands-Metadaten Expired - Lifetime DE202013001075U1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201361754882P 2013-01-21 2013-01-21
US61/754,882 2013-01-21

Publications (1)

Publication Number Publication Date
DE202013001075U1 true DE202013001075U1 (de) 2013-04-30

Family

ID=48575982

Family Applications (1)

Application Number Title Priority Date Filing Date
DE202013001075U Expired - Lifetime DE202013001075U1 (de) 2013-01-21 2013-02-01 Audio-Codierer und Decodierer mit Lautheits-Verarbeitugszustands-Metadaten

Country Status (9)

Country Link
EP (2) EP3079257B1 (de)
JP (1) JP3183637U (de)
CN (7) CN203134365U (de)
DE (1) DE202013001075U1 (de)
FR (1) FR3001325B3 (de)
HK (4) HK1248395A1 (de)
ME (1) ME03067B (de)
PL (1) PL3082128T3 (de)
TW (1) TWM467148U (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111312266A (zh) * 2013-11-27 2020-06-19 弗劳恩霍夫应用研究促进协会 解码器及方法、编码器及编码方法、系统以及计算机程序
US11509737B2 (en) * 2014-09-12 2022-11-22 Sony Group Corporation Transmission device, transmission method, reception device, and a reception method

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016050740A1 (en) * 2014-10-01 2016-04-07 Dolby International Ab Efficient drc profile transmission
CN113963724A (zh) * 2021-09-18 2022-01-21 赛因芯微(北京)电子科技有限公司 音频内容元数据和产生方法、电子设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5583962A (en) 1991-01-08 1996-12-10 Dolby Laboratories Licensing Corporation Encoder/decoder for multidimensional sound fields
US5632005A (en) 1991-01-08 1997-05-20 Ray Milton Dolby Encoder/decoder for multidimensional sound fields
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
WO2012075246A2 (en) 2010-12-03 2012-06-07 Dolby Laboratories Licensing Corporation Adaptive processing with multiple media processing nodes

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7224819B2 (en) * 1995-05-08 2007-05-29 Digimarc Corporation Integrating digital watermarks in multimedia content
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
US8301884B2 (en) * 2002-09-16 2012-10-30 Samsung Electronics Co., Ltd. Method of managing metadata
KR100860984B1 (ko) * 2002-10-15 2008-09-30 삼성전자주식회사 메타데이터 관리 방법
US8979655B2 (en) * 2002-12-10 2015-03-17 Ol2, Inc. System and method for securely hosting applications
CN100474907C (zh) * 2003-06-18 2009-04-01 汤姆森特许公司 在电影胶片上记录数据的装置
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
US7668712B2 (en) * 2004-03-31 2010-02-23 Microsoft Corporation Audio encoding and decoding with intra frames and adaptive forward error correction
US8131134B2 (en) * 2004-04-14 2012-03-06 Microsoft Corporation Digital media universal elementary stream
US7617109B2 (en) * 2004-07-01 2009-11-10 Dolby Laboratories Licensing Corporation Method for correcting metadata affecting the playback loudness and dynamic range of audio information
US7624021B2 (en) * 2004-07-02 2009-11-24 Apple Inc. Universal container for audio data
RU2402885C2 (ru) * 2005-03-10 2010-10-27 Квэлкомм Инкорпорейтед Классификация контента для обработки мультимедийных данных
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
US7177804B2 (en) * 2005-05-31 2007-02-13 Microsoft Corporation Sub-band voice codec with multi-stage codebooks and redundant coding
CN101421781A (zh) * 2006-04-04 2009-04-29 杜比实验室特许公司 音频信号的感知响度和/或感知频谱平衡的计算和调整
US20080080722A1 (en) * 2006-09-29 2008-04-03 Carroll Tim J Loudness controller with remote and local control
US8160273B2 (en) * 2007-02-26 2012-04-17 Erik Visser Systems, methods, and apparatus for signal separation using data driven techniques
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
US8218790B2 (en) * 2008-08-26 2012-07-10 Apple Inc. Techniques for customizing control of volume level in device playback
JP5267115B2 (ja) * 2008-12-26 2013-08-21 ソニー株式会社 信号処理装置、その処理方法およびプログラム
TWI529703B (zh) * 2010-02-11 2016-04-11 杜比實驗室特許公司 用以非破壞地正常化可攜式裝置中音訊訊號響度之系統及方法
TWI525987B (zh) * 2010-03-10 2016-03-11 杜比實驗室特許公司 在單一播放模式中組合響度量測的系統
EP2367286B1 (de) * 2010-03-12 2013-02-20 Harman Becker Automotive Systems GmbH Automatische Korrektur der Lautstärke von Audiosignalen
EP2695161B1 (de) * 2011-04-08 2014-12-17 Dolby Laboratories Licensing Corporation Automatische metadateikonfiguration für das mischen von audioprogrammen aus zwei kodierten bitströmen
WO2012146757A1 (en) * 2011-04-28 2012-11-01 Dolby International Ab Efficient content classification and loudness estimation

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5583962A (en) 1991-01-08 1996-12-10 Dolby Laboratories Licensing Corporation Encoder/decoder for multidimensional sound fields
US5632005A (en) 1991-01-08 1997-05-20 Ray Milton Dolby Encoder/decoder for multidimensional sound fields
US5633981A (en) 1991-01-08 1997-05-27 Dolby Laboratories Licensing Corporation Method and apparatus for adjusting dynamic range and gain in an encoder/decoder for multidimensional sound fields
US6021386A (en) 1991-01-08 2000-02-01 Dolby Laboratories Licensing Corporation Coding method and apparatus for multiple channels of audio information representing three-dimensional sound fields
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
WO2012075246A2 (en) 2010-12-03 2012-06-07 Dolby Laboratories Licensing Corporation Adaptive processing with multiple media processing nodes

Non-Patent Citations (12)

* Cited by examiner, † Cited by third party
Title
"Efficient Bit Allocation, Quantization, and Coding in an Audio Distribution System", AES Preprint 5068, 107. AES Conference, August 1999
"Introduction to Dolby Digital Plus, an Enhancement to the Dolby Digital Coding System," AES Convention Paper 6196, 117. AES Convention, 28. Oktober 2004
"Professional Audio Coder Optimized for Use with Video", AES Preprint 5033, 10. AES Conference August 1999
ATSC A/85 Standard
ATSC Standard A52/A: Digital Audio Compression Standard (AC-3), Revision A, Advanced Television Systems Committee, 20. August 2001
EBU R128 Standard
ITU BS.1770-2
ITU-R BS.1770
ITU-R BS.1770-2
ITU-R BS.1770-3
ITU-R BS.1771-1
Standard ITU-R BS.1770

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111312266A (zh) * 2013-11-27 2020-06-19 弗劳恩霍夫应用研究促进协会 解码器及方法、编码器及编码方法、系统以及计算机程序
US11688407B2 (en) 2013-11-27 2023-06-27 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Decoder, encoder, and method for informed loudness estimation in object-based audio coding systems
CN111312266B (zh) * 2013-11-27 2023-11-10 弗劳恩霍夫应用研究促进协会 解码器及方法、编码器及编码方法、系统
US11875804B2 (en) 2013-11-27 2024-01-16 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Decoder, encoder and method for informed loudness estimation employing by-pass audio object signals in object-based audio coding systems
US11509737B2 (en) * 2014-09-12 2022-11-22 Sony Group Corporation Transmission device, transmission method, reception device, and a reception method

Also Published As

Publication number Publication date
EP3079257B1 (de) 2019-07-31
CN112652316B (zh) 2023-09-15
JP3183637U (ja) 2013-05-30
EP3082128A1 (de) 2016-10-19
FR3001325B3 (fr) 2015-07-03
CN203134365U (zh) 2013-08-14
HK1198674A1 (en) 2015-05-22
HK1244962A1 (zh) 2018-08-17
CN107257234B (zh) 2020-09-15
HK1244111A1 (zh) 2018-07-27
CN107276552B (zh) 2020-09-11
CN107578781A (zh) 2018-01-12
CN107276552A (zh) 2017-10-20
EP3079257A1 (de) 2016-10-12
CN107276551B (zh) 2020-10-02
CN103943112A (zh) 2014-07-23
FR3001325A3 (fr) 2014-07-25
CN112652316A (zh) 2021-04-13
CN103943112B (zh) 2017-10-13
PL3082128T3 (pl) 2018-07-31
TWM467148U (zh) 2013-12-01
CN107578781B (zh) 2021-01-29
CN107276551A (zh) 2017-10-20
CN107257234A (zh) 2017-10-17
HK1248395A1 (zh) 2018-10-12
EP3082128B1 (de) 2018-03-21
ME03067B (de) 2019-01-20

Similar Documents

Publication Publication Date Title
JP6929345B2 (ja) プログラム・ラウドネスおよび境界メタデータをもつオーディオ・エンコーダおよびデコーダ
JP6571062B2 (ja) プログラム情報またはサブストリーム構造メタデータをもつオーディオ・エンコーダおよびデコーダ
EP0978172B1 (de) Verfahren zum verschleiern von fehlern in einem audiodatenstrom
DE202013001075U1 (de) Audio-Codierer und Decodierer mit Lautheits-Verarbeitugszustands-Metadaten
EP1028539B1 (de) Verfahren zum Transkodieren eines Audiodatenstroms

Legal Events

Date Code Title Description
R207 Utility model specification

Effective date: 20130627

R150 Utility model maintained after payment of first maintenance fee after three years
R151 Utility model maintained after payment of second maintenance fee after six years
R152 Utility model maintained after payment of third maintenance fee after eight years
R071 Expiry of right