BR112015007723B1 - Unidade de processamento de áudio e método para decodificar um fluxo de bits contínuo de áudio codificado. - Google Patents

Abstract

codificador e decodificador de áudio com sonoridade de programa e metadados de limite. a presente invenção refere-se a aparelho e métodos para gerar um fluxo de bits contínuo de áudio codificado, incluindo pela inclusão de metadados de sonoridade do programa e dados de áudio no fluxo de bits contínuo, e opcionalmente ainda metadados de limite do programa em pelo menos um segmento (por exemplo, quadro) do fluxo de bits contínuo. outros aspectos são aparelhos e métodos para decodificar tal fluxo de bits contínuo, por exemplo, incluindo pela realização do processamento de sonoridade adaptativo dos dados de áudio de um programa de áudio indicado pelo fluxo de bits contínuo, ou autenticação e/ou validação de metadados e/ou dados de áudio de tal programa de áudio. outro aspecto é uma unidade de processamento de áudio (por exemplo, um codificador, decodificador, ou pós-processador) configurada (por exemplo, programada) para realizar qualquer modalidade do método ou que inclui uma memória buffer que armazena pelo menos um quadro de um fluxo de bits contínuo de áudio gerado de acordo com qualquer modalidade do método.

Description

[001] Esse pedido reivindica a prioridade ao Pedido de PatenteProvisório Norte-americano n° 61/754.882, depositado no dia 21 de Janeiro de 2013 e Pedido de Patente Provisório Norte-americano n° 61/824.010, depositado no dia 16 de Maio de 2013, os quais são incorporados aqui a título de referência em sua totalidade.

CAMPO TÉCNICO

[002] A invenção pertence ao processamento de sinal de áudio e,mais especificamente, à codificação e decodificação do fluxo de bits de dados de áudio com metadados indicativos do estado de processamento de sonoridade ("loudness") de conteúdo de áudio e a localização de fronteiras de programa de áudio indicados pelos fluxos de bits. Algumas modalidades da invenção geram ou decodificam dados de áudio em um dos formatos conhecidos como AC-3, AC-3 Avançado ou E-AC-3, ou Dolby E.

ANTECEDENTES DA INVENÇÃO

[003] Dolby, Dolby Digital, Dolby Digital Plus, e Dolby E são marcas registradas da Dolby Laboratories Licensing Corporation. A Dolby Laboratories fornece implementações proprietárias de AC-3 e E-AC-3 conhecidas como Dolby Digital e Dolby Digital Plus, respectivamente.

[004] As unidades de processamento de dados de áudio normalmente operam em uma maneira cega e não prestam atenção ao histórico de processamento de dados de áudio que ocorre antes dos dados serem recebidos. Isso pode funcionar em uma estrutura de processamento na qual uma única entidade faz todo o processamento e codificação de dados de áudio para uma variedade de dispositivos de interpretação de mídias-alvo enquanto um dispositivo de interpretação de mídias-alvo faz toda a decodificação e interpretação dos dados de áudio codificados. Entretanto, esse processamento cego não funciona bem (ou de modo algum) em situações onde uma pluralidade de unidades de processamento de áudio é dispersa por uma rede diversa ou é colocada em tandem (por exemplo, corrente) e espera-se que realize otimamente seus respectivos tipos de processamento de dados. Por exemplo, alguns dados de áudio podem ser codificados por sistemas de mídia de alto desempenho e podem ter que ser convertidos a uma forma reduzida adequada para um dispositivo móvel ao longo de uma cadeia de processamento de mídia. Em conformidade, uma unidade de processamento de áudio pode realizar desnecessariamente um tipo de processamento sobre os dados de áudio que já tenha sido realizado. Por exemplo, uma unidade de nivelamento de volume pode realizar processamento sobre um clip de áudio de entrada, independentemente de o mesmo nivelamento de volume ou similar ter sido previamente realizado sobre o clip de áudio de entrada ou não. Como resultado, a unidade de nivelamento de volume pode realizar nivelamento mesmo quando não é necessário. Esse processamento desnecessário pode também causar degradação e/ou remoção de características específicas enquanto interpretando o conteúdo dos dados de áudio.

[005] Um típico fluxo de bits de áudio inclui ambos os conteúdosde dados (por exemplo, um ou mais canais do conteúdo de áudio) e metadados indicativos de pelo menos uma característica do conteúdo de dados. Por exemplo, em um fluxo de bits AC-3 há vários parâmetros de metadados de áudio que são especificamente destinados para o uso na alteração de sons do programa entregue a um ambiente sonoro. Um dos parâmetros de metadados é o parâmetro DIALNORM, que é destinado a indicar o nível de mídia de diálogo ocorrendo em um programa de áudio, e é utilizado para determinar o nível de sinal de reprodução de áudio.

[006] Durante a reprodução de um fluxo de bits que compreendeuma sequência de segmentos de programa de áudio diferentes (cada um tendo um parâmetro DIALNORM diferente), um decodificador AC-3 utiliza o parâmetro DIALNORM de cada segmento para realizar um tipo de processamento de sonoridade no qual ele modifica o nível ou sonoridade de reprodução de tal modo que a sonoridade percebida do diálogo da sequência de segmentos está em um nível consistente. Cada segmento de áudio codificado (item) em uma sequência de itens de áudio codificados teria (em geral) um parâmetro DIALNORM diferente, e o decodificador escalaria o nível de cada um dos itens de modo que o nível ou a sonoridade de reprodução do diálogo para cada item é o mesmo ou muito similar, embora isso possa exigir a aplicação de diferentes quantidades de aumento aos diferentes itens durante a reprodução.

[007] O DIALNORM é normalmente estabelecido por um usuário,e não é gerado automaticamente, embora haja um valor de DIALNORM padrão, caso nenhum valor seja estabelecido pelo usuário. Por exemplo, um criador de conteúdo pode fazer medições de sonoridade com um dispositivo externo a um codificador AC-3 e então transferir o resultado (indicativo de sonoridade do dito diálogo falado de um programa de áudio) para um codificador para estabelecer o valor de DIALNORM. Assim, há confiança no criador de conteúdo para estabelecer o parâmetro DIALNORM corretamente.

[008] Há várias razões diferentes pelas quais o parâmetro DIALNORM em um fluxo de bits AC-3 pode estar incorreto. Primeiro, cada codificador AC-3 tem um valor de DIALNORM padrão que é utilizado durante a geração do fluxo de bits se um valor de DIALNORM não for estabelecido pelo criador de conteúdo. Esse valor-padrão pode ser substancialmente diferente do nível de sonoridade do diálogo real do áudio. Segundo, mesmo se um criador de conteúdo medir a sonorida- de e estabelecer o valor de DIALNORM em conformidade, um algoritmo ou aparelho de medição de sonoridade pode ter sido utilizado não em conformidade com o método de medição de sonoridade AC-3 recomendado, resultando em um valor de DIALNORM incorreto. Terceiro, mesmo se um fluxo de bits AC-3 foi criado com o valor de DIALNORM medido e estabelecido corretamente pelo criador de conteúdo, ele pode ser alterado para um valor incorreto durante a transmissão e/ou armazenamento do fluxo de bits. Por exemplo, não é incomum em aplicações de transmissão de televisão que fluxos de bits AC-3 sejam codificados, modificados e então recodificados utilizando informações de metadados de DIALNORM incorretas. Assim, um valor de DIALNORM incluso em um fluxo de bits AC-3 pode ser incorreto ou impreciso e, portanto, pode ter um impacto negativo sobre a qualidade da experiência sonora.

[009] Além disso, o parâmetro DIALNORM não indica o estadodo processamento de sonoridade de dados de áudio correspondentes (por exemplo, que tipo(s) de processamento de sonoridade foi(foram) realizado(s) sobre os dados de áudio). Até a presente invenção, um fluxo de bits de áudio não teve metadados inclusos, indicativos de estado de processamento de sonoridade (por exemplo, tipo(s) de processamento de sonoridade aplicado(s) a) o conteúdo de áudio do fluxo de bits de áudio ou o estado de processamento de sonoridade e sono-ridade do conteúdo de áudio do fluxo de bits, em um formato de um tipo descrito na presente descrição. Os metadados de estado de processamento de sonoridade em tal formato são úteis para facilitar o processamento de sonoridade adaptativo de um fluxo de bits de áudio e/ou da verificação de validade do estado e sonoridade de processamento de sonoridade do conteúdo de áudio, de uma maneira particularmente eficiente.

[0010] Embora a presente invenção não esteja limitada ao uso com um fluxo de bits AC-3, um fluxo de bits E-AC-3, ou um fluxo de bits Dolby E, por conveniência ela será descrita nas modalidades nas quais ela gera, decodifica, ou senão processa tal fluxo de bits que inclui metadados de estado de processamento de sonoridade.

[0011] Um fluxo de bits codificado AC-3 compreende metadados eum a seis canais de conteúdo de áudio. O conteúdo de áudio consiste de dados de áudio que foram comprimidos utilizando codificação de áudio perceptiva. Os metadados incluem vários parâmetros de metadados de áudio que são destinados para uso na alteração de sons de um programa entregue a um ambiente sonoro.

[0012] Detalhes da codificação AC-3 (também conhecido comoDolby Digital) são bem conhecidos e são apresentadas muitas referências publicadas, incluindo as seguintes:

[0013] ATSC Standard A52/A: Digital Audio Compression Standard(AC-3), Revision A, Advanced Television Systems Comittee, 20 Aug. 2001; e Patentes Norte-americanas 5.583.962, 5.632.005, 5.633.981, 5.727.119, e 6.021.386, todas as quais são aqui incorporadas a título de referência em sua totalidade.

[0014] Detalhes da codificação Dolby Digital Plus (E-AC-3) sãoapresentados em "Introduction to Dolby Digital Plus, na Enhancement to the Dolby Digital Coding System," AES Convention Paper 6196, 117th AES Convention, October 28, 2004.

[0015] Detalhes da codificação de Dolby E são apresentadas em"Efficient Bit Allocation, Quantization, and Coding in an Audio Distribution System", AES Preprint 5068, 107th AES Conference, August 1999 e "Professional Audio Coder Optimized for Use with Video", AES Preprint 5033, 107th AES Conference August 1999.

[0016] Cada quadro de um fluxo de bits AC-3 contínuo de áudiocodificado contém conteúdo de áudio e metadados para 1536 amostras de áudio digital. Para uma variação de amostra de 48 kHz, isso representa 32 milissegundos de áudio digital ou uma variação de 31,25 quadros por segundo de áudio.

[0017] Cada quadro de um fluxo de bits E-AC-3 contínuo de áudiocodificado contém conteúdo de áudio e metadados para 256, 512, 768 ou 1536 amostras de áudio digital, dependendo se o quadro contém um, dois, três ou seis blocos de dados de áudio, respectivamente. Para uma variação de amostra de 48 kHz, isso representa 5,333, 10,667, 16 ou 32 milissegundos de áudio digital, respectivamente, ou uma variação de 189,9, 93,75, 62,5 ou 31,5 quadros por segundo de áudio, respectivamente.

[0018] Conforme indicado na Figura 4, cada quadro AC-3 está dividido em seções (segmentos), incluindo: uma seção de Informações de Sincronização (SI) que contém (conforme mostrado na Figura 5) uma palavra de sincronização (SW) e a primeira de duas palavras de correção de erro (CRC1); uma seção de Informações de Fluxo de Bits (BSI) que contém a maioria dos metadados; seis Blocos de Áudio (ABO a AB5) que contêm dados de conteúdo de áudio comprimidos (e podem também incluir metadados); segmentos de perda de bits (W) que contêm quaisquer bits não utilizados deixados para trás após o conteúdo de áudio ser comprimido; uma seção de informações Auxiliares (AUX) que pode conter mais metadados; e a segunda de duas palavras de correção de erro (CRC2). O segmento de perda de bits (W) pode também ser referido como um "campo omitido".

[0019] Conforme indicado na Figura 7, cada quadro E-AC-3 é dividido em seções (segmentos), incluindo: uma seção de Informações de Sincronização (SI) que contém (conforme mostrado na Figura 5) uma palavra de sincronização (SW); uma seção de Informações de Fluxo de Bits (BSI) que contém a maioria dos metadados; entre um e seis Blocos de Áudio (ABO a AB5) que contêm dados de conteúdo de áudio comprimidos (e podem também incluir metadados); segmentos de perda de bits (W) que contêm quaisquer bits não utilizados deixados para trás após o conteúdo de áudio ser comprimido (embora somente um segmento de perda de bits seja mostrado, um diferente segmento de perda de bits seguiria normalmente cada bloco de áudio); uma seção de informações Auxiliares (AUX) que pode conter mais metadados; e uma palavra de correção de erro (CRC). O segmento de perda de bits (W) pode também ser referido como um "campo omitido." Em um fluxo de bits AC-3 (ou E-AC-3) há vários parâmetros de metadados de áudio que são especificamente destinados para uso na alteração de som do programa entregue a um ambiente sonoro. Um dos parâmetros de metadados é o parâmetro DIALNORM, que está incluso no segmento BSI.

[0020] Conforme mostrado na Figura 6, o segmento BSI de umquadro AC-3 inclui um parâmetro de cinco bits ("DIALNORM") indicando o valor de DIALNORM para o programa. Um parâmetro de cinco bits ("DIALNORM2") indicando o valor de DIALNORM para um segundo programa de áudio carregado no mesmo quadro AC-3 é incluso se o modo de codificação de áudio ("acmod") do quadro AC-3 for "0", indicando que um canal de configuração dual-mono ou "1+1" está em uso.

[0021] O segmento BSI inclui também um indicador ("addbsie")indicando a presença (ou ausência) de informações de fluxo de bits adicionais seguindo o bit "addbsie", um parâmetro ("addbsil") indicando o comprimento de qualquer informação de fluxo de bits adicional seguindo o valor de "addbsil", e até 64 bits de informação de fluxo de bits adicional ("addbsi") seguindo o valor de "addbsil".

[0022] O segmento BSI inclui outros valores de metadados nãomostrados especificamente na Figura 6.

BREVE DESCRIÇÃO DA INVENÇÃO

[0023] Em uma classe de modalidades, a invenção é uma unidade de processamento de áudio que inclui uma memória buffer, um decodi- ficador de áudio, e um interpretador. A memória buffer armazena pelo menos um quadro de um fluxo de bits contínuo de áudio codificado. O fluxo de bits contínuo de áudio codificado inclui dados de áudio e um segmento de metadados (por exemplo, um recipiente de metadados). O segmento de metadados inclui um cabeçalho, uma ou mais cargas úteis de metadados, e dados de proteção. O cabeçalho inclui uma pa-lavra de sincronização que identifica o início do recipiente. Uma ou mais cargas úteis de metadados descrevem um programa de áudio associado com os dados de áudio. Os dados de proteção estão localizados após uma ou mais cargas úteis de metadados. Os dados de proteção também são capazes de ser utilizados para verificar a integridade do segmento de metadados e uma ou mais cargas úteis dentro do segmento de metadados. O decodificador de áudio é acoplado à memória buffer e pode decodificar os dados de áudio. O interpretador é acoplado ou integrado com o decodificador de áudio e capaz de interpretar o segmento de metadados.

[0024] Nas modalidades típicas, o método inclui receber um fluxode bits contínuo de áudio codificado onde o fluxo de bits contínuo de áudio codificado é segmentado em um ou mais quadros. Os dados de áudio são extraídos do fluxo de bits contínuo de áudio codificado, com um recipiente de metadados. O recipiente de metadados inclui um cabeçalho seguido por uma ou mais cargas úteis de metadados seguidas por dados de proteção. Finalmente, a integridade do recipiente e uma ou mais cargas úteis de metadados é verificada através do uso dos dados de proteção. Uma ou mais cargas úteis de metadados pode incluir uma carga útil da sonoridade do programa que contém dados indicativos da sonoridade medida de um programa de áudio associado com os dados de áudio.

[0025] Uma carga útil de metadados da sonoridade do programa, referida como metadados do estado do processamento de sonoridade ("LPSM"), embutida em um fluxo de bits contínuo de áudio de acordo com as modalidades típicas da invenção pode ser autenticada e validada, por exemplo, para permitir que as entidades regulatórias de sonoridade verifiquem se uma sonoridade de programa particular já está dentro de uma faixa especificada e que os próprios dados de áudio correspondentes não foram modificados (assim garantindo a conformidade com as regulagens aplicáveis). Um valor de sonoridade incluído em um bloco de dados que compreende os metadados do estado do processamento de sonoridade pode ser lido para verificar isso, ao invés de computar a sonoridade novamente. Em resposta aos LPSM, uma agência regulatória pode determinar que o conteúdo de áudio cor-respondente está em conformidade (conforme indicado pelos LPSM) com exigências estatutárias e/ou regulatórias de sonoridade (por exemplo, as regulagens promulgadas em Commercial Advertisement Loudness Mitigation Act, também conhecidas como "CALM" Act) sem a necessidade de computar a sonoridade do conteúdo de áudio.

[0026] As medições de sonoridade que são necessárias para conformidade com algumas exigências estatutárias e/ou regulatórias de sonoridade (por exemplo, as regulagens promulgadas sob o Ato CALM) são baseadas na sonoridade integrada do programa. A sonoridade integrada do programa exige que uma medição do sonoridade, tanto do nível do diálogo quanto nível de mistura total, seja feita sobre todo um programa de áudio. Assim, a fim de fazer medições da sono-ridade do programa (por exemplo, em vários estágios na cadeia de transmissão) para verificar a conformidade com as típicas exigências legais, é essencial que as medições sejam feitas com o conhecimento de quais dados de áudio (e metadados) determinam um programa de áudio total, e isso tipicamente exige o conhecimento da localização do começo e final do programa (por exemplo, durante o processamento de um fluxo de bits contínuo indicativo de uma sequência de programas de áudio).

[0027] De acordo com as modalidades típicas da presente invenção, um fluxo de bits contínuo de áudio codificado é indicativo de pelo menos um programa de áudio (por exemplo, uma sequência de programas de áudio), e metadados de limite do programa e LPSM incluídos no fluxo de bits contínuo permitem redefinir a medição da sonoridade do programa no final de um programa e assim fornece uma forma automatizada de medir a sonoridade integrada do programa. Modalidades típicas da invenção incluem metadados de limite do programa em um fluxo de bits contínuo de áudio codificado em uma forma eficiente, o que permite a determinação precisa e robusta de pelo menos um limite entre programas de áudio consecutivos indicados pelo fluxo de bits contínuo. Modalidades típicas permitem a determinação precisa e robusta de um limite do programa no sentido que permitem a determinação precisa do limite do programa mesmo nos casos em que os fluxos de dados contínuos indicativo de diferentes programas são ligados (para gerar o fluxo de bits contínuo inventivo) em uma forma que trunca um ou ambos os fluxos de dados contínuos ligados (e assim descarta os metadados de limite do programa que foram incluídos pelo menos em um dos fluxos de dados contínuos pré-ligados).

[0028] Nas modalidades típicas, os metadados de limite do programa em um quadro do fluxo de bits contínuo inventivo é um indicador do limite do programa indicativo de uma conta do quadro. Tipicamente, o indicador é indicativo do número de quadros entre o quadro atual (o quadro que inclui o indicador) e um limite do programa (o começo ou o fim do programa de áudio atual). Em algumas modalidades preferidas, os indicadores do limite do programa são inseridos em uma forma simétrica, eficiente no começo e final de cada segmento do fluxo de bits contínuo que é indicativo de um único programa (ou seja, em quadros que ocorrem dentro de um número predeterminado de quadros após o começo do segmento, e em quadros que ocorrem dentro de algum número predeterminado de quadros antes do final do segmento), de modo que quando estes segmentos do fluxo de bits contínuo são concatenados (para serem indicativos de uma sequência de dois programas), os metadados de limite do programa podem estar presentes (por exemplo, simetricamente) em ambos os lados do limite entre os dois programas.

[0029] Para limitar o aumento da taxa de dados que resulta da inclusão de metadados de limite do programa em um fluxo de bits contínuo de áudio codificado (que pode ser indicativo de um programa de áudio ou de uma sequência de programas de áudio), em modalidades típicas, indicadores limite do programa são inseridos somente em um subconjunto dos quadros do fluxo de bits contínuo. Tipicamente, a taxa de inserção do indicador limite é uma função de não aumento de crescente separação de cada um dos quadros de fluxos de dados contí-nuos (nos quais um indicador é inserido) a partir do limite do programa que é o mais próximo de cada um dos ditos quadros, onde "taxa de inserção do indicador limite" indica a relação média do número de quadros (indicativos de um programa) que inclui um indicador do limite do programa ao número de quadros (indicativos de um programa) que não inclui um indicador do limite do programa, onde a média é uma média corrida sobre um número (por exemplo, número relativamente pequeno) de quadros consecutivos do fluxo de bits contínuo de áudio codificado. Em uma classe de modalidades, a taxa de inserção do indicador limite é uma função algoritmicamente decrescente da distância crescente (de cada local de inserção do indicador) a partir do limite do programa mais próximo, e para cada quadro contendo indicadores que inclui um dos indicadores, o tamanho do indicador no dito quadro contendo indicadores é igual ou maior que o tamanho de cada indicador em um quadro localizado mais próximo ao limite do programa mais próximo do que é o dito quadro contendo indicadores (ou seja, o tamanho do indicador do limite do programa em cada quadro contendo indicadores é uma função não decrescente da separação crescente do dito quadro contendo indicadores a partir do limite do programa mais próximo).

[0030] Outro aspecto da invenção é uma unidade de processamento de áudio (APU) configurada para realizar qualquer modalidade do método inventivo. Em outra classe de modalidades, a invenção é uma APU incluindo a memória buffer (buffer) que armazena (por exemplo, de uma maneira não transitória) pelo menos um quadro de um fluxo de bits contínuo de áudio codificado que foi gerado por qualquer modalidade do método inventivo. Exemplos das APUs incluem, mas não estão limitados a, codificadores (por exemplo, transcodifica- dores), decodificadores, codificadores-decodificadores, sistemas de pré-processamento (pré-processadores), sistemas pós-processamento (pós-processadores), sistemas de processamento de fluxo de bits contínuo de áudio, e combinações de tais elementos.

[0031] Em outra classe de modalidades, a invenção é uma unidade de processamento de áudio (APU) configurada para gerar um fluxo de bits contínuo de áudio codificado que compreende segmentos de dados de áudio e segmentos de metadados, onde os segmentos de dados de áudio são indicativos de dados de áudio, e cada um de pelo menos alguns dos segmentos de metadados inclui metadados do estado do processamento de sonoridade (LPSM) e opcionalmente também metadados de limite do programa. Tipicamente, pelo menos um desses segmentos de metadados em um quadro do fluxo de bits contínuo inclui pelo menos um segmento de LPSM indicativo de se um primeiro tipo de processamento de sonoridade foi realizado sobre os dados de áudio do quadro (ou seja, dados de áudio em pelo menos um dos segmentos de dados de áudio do quadro), e pelo menos outro segmento de LPSM indicativo de sonoridade de pelo menos alguns dos dados de áudio do quadro (por exemplo, sonoridade de diálogo de pelo menos alguns dos dados de áudio do quadro que são indicativos de diálogo). Em uma modalidade nessa classe, a APU é um codificador configurado para codificar áudio de entrada para gerar áudio codificado, e os segmentos de dados de áudio incluem o áudio codificado. Em modalidades típicas nessa classe, cada um dos segmentos de metadados tem um formato preferido a ser descrito aqui.

[0032] Em algumas modalidades, cada um dos segmentos de metadados do fluxo de bits contínuo codificado (um fluxo de bits contínuo AC-3 ou um fluxo de bits contínuo E-AC-3 em algumas modalidades) que inclui LPSM (por exemplo, LPSM e metadados de limite do programa) está incluído em uma perda de bit do segmento de campo de salto de um quadro do fluxo de bits contínuo (por exemplo, um segmento de perda de bit W do tipo mostrado na Figura 4 ou Figura 7). Em outras modalidades, cada um dos segmentos de metadados do fluxo de bits contínuo codificado (um fluxo de bits contínuo AC-3 ou um fluxo de bits contínuo E-AC-3 em algumas modalidades) que inclui LPSM (por exemplo, LPSM e metadados de limite do programa) está incluído como informações de fluxo de bits adicionais no campo "add- bsi" do segmento de Informações do fluxo de bits contínuo ("BSI") de um quadro do fluxo de bits contínuo ou em um campo de dados auxiliares (por exemplo, um segmento AUX do tipo mostrado na Figura 4 ou Figura 7) na extremidade de um quadro do fluxo de bits contínuo. Cada segmento de metadados incluindo LPSM pode ter o formado especificado aqui com relação às Tabelas 1 e 2 abaixo (ou seja, inclui os elementos centrais especificados na Tabela 1 ou uma variação dos mesmos, seguido pela ID da carga útil (identificando os metadados como LPSM) e pelos valores do tamanho da carga útil, seguido pela carga útil (dados LPSM que têm o formato conforme indicado na Tabela 2, ou o formato conforme indicado em uma variação da Tabela 2 descrita aqui). Em algumas modalidades, um quadro pode incluir um ou dois segmentos metadados, cada um inclui LPSM, e se o quadro inclui dois segmentos metadados, um pode estar presente no campo "addbsi" do quadro e o outro no campo AUX do quadro.

[0033] Em uma classe de modalidades, a invenção é um métodoincluindo as etapas de codificação dos dados de áudio para gerar um fluxo de bits contínuo de áudio codificado AC-3 ou E-AC-3, incluindo incluir em um segmento de metadados (de pelo menos um quadro do fluxo de bits contínuo) LPSM e metadados de limite do programa e opcionalmente também outros metadados para o programa de áudio ao qual o quadro pertence. Em algumas modalidades, cada um desses segmentos de metadados está incluído em um campo "addbsi" do quadro, ou em um campo de dados auxiliares do quadro. Em outras modalidades, cada um desses segmentos de metadados está incluído em um segmento de perda de bit do quadro. Em algumas modalidades, cada um desses segmentos de metadados que contêm LPSM e metadados de limite do programa contém um cabeçalho central (e opcionalmente também elementos centrais adicionais), e após o cabeçalho central (ou o cabeçalho central e outros elementos centrais), um segmento da carga útil LPSM (ou recipiente) tendo o seguinte formato: um cabeçalho, tipicamente incluindo pelo menos um valor de identificação (por exemplo, valores de associação de fluxo de bits, conta, período, comprimento, versão de formato LPSM, conforme indicado na Tabela 2 apresentada aqui), edepois o cabeçalho, o LPSM e os metadados de limite do programa. Os metadados de limite do programa podem incluir uma conta do quadro do limite do programa, e um valor central (por exemplo, um valor "offset_exist") indicativo de se o quadro inclui somente uma conta do quadro do limite do programa ou ambos, uma conta do quadro do limite do programa e um valor compensado, e (em alguns casos) um valor compensado. O LPSM pode incluir:pelo menos um valor de indicação de diálogo indicando se dados de áudio correspondentes indicam diálogo ou não indicam diálogo (por exemplo, quais canais de dados de áudio correspondentes indicam diálogo). O(s) valor(es) de indicação de diálogo pode(m) indicar se o diálogo está presente em qualquer combinação dos, ou todos os canais dos dados de áudio correspondentes;pelo menos um valor de conformidade de regulagem de sonoridade indicando se dados de áudio correspondentes estão em conformidade com um conjunto de regulagens de sonoridade indicado;pelo menos um valor de processamento de sonoridade indicando pelo menos um tipo de processamento de sonoridade que foi realizado sobre os dados de áudio correspondentes; epelo menos um valor de sonoridade indicando pelo menos uma característica de sonoridade (por exemplo, sonoridade máxima ou média) dos dados de áudio correspondentes.

[0034] Em outras modalidades, o fluxo de bits contínuo codificadoé um fluxo de bits contínuo que não é um fluxo de bits contínuo AC-3 ou um fluxo de bits contínuo E-AC-3, e cada um dos segmentos de metadados que inclui LPSM (e opcionalmente também metadados de limite do programa) está incluído em um segmento (ou campo ou entalhe) do fluxo de bits contínuo reservado para armazenamento de dados adicionais. Cada um dos segmentos de metadados incluindo LPSM pode ter formato similar ou idêntico àquele especificado aqui com relação às Tabelas 1 e 2 abaixo (ou seja, inclui elementos centrais similares ou idênticos àqueles especificados na Tabela 1, seguido pela ID da carga útil (identificando os metadados como LPSM) e valores do tamanho da carga útil, seguido pela carga útil (dados de LPSM que tem formato similar ou idêntico ao formato indicado na Tabela 2 ou uma variação sobre a Tabela 2 descrita aqui).

[0035] Em algumas modalidades, o fluxo de bits contínuo codificado compreende uma sequência de quadros, cada um dos quadros inclui um segmento de informações do fluxo de bits contínuo ("BSI") incluindo um campo "addbsi" (às vezes referido como segmento ou entalhe), e um campo ou entalhe de dados auxiliares (por exemplo, o fluxo de bits contínuo codificado é um fluxo de bits contínuo AC-3 ou um fluxo de bits contínuo E-AC-3), e compreende segmentos de dados de áudio (por exemplo, os segmentos AB0-AB5 do quadro mostrado na Figura 4) e segmentos de metadados, onde os segmentos de dados de áudio são indicativos de dados de áudio, e cada um de pelo menos alguns dos segmentos de metadados inclui metadados do estado do processamento de sonoridade (LPSM) e opcionalmente também metadados de limite do programa. Os LPSM estão presentes no fluxo de bits contínuo no seguinte formato. Cada um dos segmentos de metadados que inclui LPSM está incluído em um campo "addbsi" do segmento BSI de um quadro do fluxo de bits contínuo, ou em um campo de dados auxiliares de um quadro do fluxo de bits contínuo, ou em um segmento de perda de bit de um quadro do fluxo de bits contínuo. Cada um dos segmentos de metadados incluindo LPSM inclui um segmento da carga útil LPSM (ou recipiente) tendo o seguinte formato:um cabeçalho (tipicamente incluindo pelo menos um valor de identificação, por exemplo, os valores de associação de fluxo de bits, conta, período, comprimento e versão de formato LPSM indicados na Tabela 2 abaixo); edepois do cabeçalho, o LPSM e opcionalmente também os metadados de limite do programa. Os metadados de limite do programa podem incluir uma conta do quadro do limite do programa, e um valor de código (por exemplo, um valor "offset_exist") indicativo de se o quadro inclui somente uma conta do quadro do limite do programa ou ambos, uma conta do quadro do limite do programa e um valor compensado, e (em alguns casos) um valor compensado. O LPSM pode incluir:pelo menos um valor de indicação de diálogo indicando se dados de áudio correspondentes indicam diálogo ou não indicam diálogo (por exemplo, quais canais de dados de áudio correspondentes indicam diálogo). O(s) valor(es) de indicação de diálogo pode(m) indicar se o diálogo está presente em qualquer combinação dos, ou todos os canais dos dados de áudio correspondentes;pelo menos um valor de conformidade da regulagem de sonoridade (por exemplo, parâmetro "Loudness Regulation Type" da Tabela 2) indicando se dados de áudio correspondentes estão em conformidade com um conjunto de regulagens de sonoridade indicado;pelo menos um valor de processamento de sonoridade (por exemplo, um ou mais dos parâmetros "Dialog gated Loudness Correction flag", "Loudness Correction Type," da Tabela 2) indicando pelo menos um tipo de processamento de sonoridade que foi realizado sobre os dados de áudio correspondentes; epelo menos um valor de sonoridade (por exemplo, um ou mais dos parâmetros "ITU Relative Gated Loudness," "ITU Speech Gated Loudness," "ITU (EBU 3341) Short-term 3s Loudness," e "True Peak" da Tabela 2) indicando pelo menos uma característica de sonoridade (por exemplo, sonoridade máxima ou média) dos dados de áudio correspondentes.

[0036] Em qualquer modalidade da invenção que contempla, utiliza ou gera pelo menos um valor de sonoridade indicativo dos dados de áudio correspondentes, o(s) valor(es) de sonoridade pode(m) indicar pelo menos uma característica de medição da sonoridade utilizada para processar a sonoridade e/ou variação dinâmica dos dados de áu- dio.

[0037] Em algumas implementações, cada um dos segmentos demetadados em um campo "addbsi", ou em um campo de dados auxiliares, ou em um segmento de perda de bit, de um quadro do fluxo de bits contínuo tem o seguinte formato:um cabeçalho central (tipicamente incluindo uma palavra de sincronização identificando o início do segmento de metadados, seguido pelos valores de identificação, por exemplo, o período, comprimento e versão do elemento central, e os valores de associação de fluxo de bits, conta do elemento estendido indicados na Tabela 1 abaixo); edepois do cabeçalho central, pelo menos um valor de proteção (por exemplo, uma compilação HMAC e valores de Impressão Digital de Áudio, onde a compilação HMAC pode ser uma compilação HMAC de 256-bits (utilizando algoritmo SHA-2) computada sobre os dados de áudio, o elemento central, e todos os elementos estendidos, de um quadro inteiro, como indicado na Tabela 1) útil para pelo menos um de decriptação, autenticação, ou validação de pelo menos um dos metadados do estado do processamento de sonoridade ou dos dados de áudio correspondentes); etambém depois do cabeçalho central, se o segmento de metadados inclui LPSM, identificação da carga útil LPSM ("ID") e valores do tamanho da carga útil LPSM que identifica os seguintes metadados como uma carga útil LPSM e indica o tamanho da carga útil LPSM. O segmento da carga útil LPSM (preferivelmente tendo o formato especificado acima) segue a ID da carga útil LPSM e os valores de tamanho da carga útil LPSM.

[0038] Em algumas modalidades do tipo descrito no parágrafo anterior, cada um dos segmentos de metadados no campo de dados auxiliares (ou campo "addbsi" ou segmento de perda de bit) do quadro tem três níveis de estrutura:uma estrutura de nível alto, incluindo um indicador indicando se o campo de dados auxiliares (ou addbsi) inclui metadados, pelo menos um valor de ID indicando que tipo(s) de metadados está presentes, e tipicamente também um valor indicando quantos bits de metadados (por exemplo, de cada tipo) está presente (se metadados estiverem presentes). Um tipo de metadados que poderia estar presente é LSPM, outro tipo de metadados que poderia estar presente são os metadados de limite do programa, e outro tipo de metadados que poderia estar presente são os metadados de pesquisa de mídia;uma estrutura de nível intermediário, que compreende um elemento central para cada tipo de metadados identificado (por exemplo, cabeçalho central, valores de proteção, e ID da carga útil e valores de tamanho da carga útil, por exemplo, do tipo mencionado acima, para cada tipo de metadados identificado); euma estrutura de nível baixo, que compreende cada carga útil para um elemento central (por exemplo, uma carga útil LPSM, se uma for identificada pelo elemento central como estando presente, e/ou uma carga útil de metadados de outro tipo, se uma for identificada pelo elemento central como estando presente).

[0039] Os valores de dados nas tais três estruturas de nível podemser agrupados. Por exemplo, o(s) valor(es) de proteção para uma carga útil LPSM e/ou outra carga útil de metadados identificada por um elemento central pode(m) ser incluído(s) depois de cada carga útil identificada pelo elemento central (e, assim, depois o cabeçalho central do elemento central). Em um exemplo, um cabeçalho central poderia identificar uma carga útil LPSM e outra carga útil de metadados, ID da carga útil e valores de tamanho da carga útil para a primeira carga útil (por exemplo, a carga útil LPSM) poderia seguir o cabeçalho central, a primeira carga útil em si poderia seguir a ID e os valores de ta- manho, a ID da carga útil e os valores de tamanho da carga útil para a segunda carga útil poderiam seguir a primeira carga útil, e a segunda carga útil em si poderia seguir essas ID e valores de tamanho, e va- lor(es) de proteção para uma ou ambas as cargas úteis (ou para os valores do elemento central e uma ou ambas as cargas úteis) poderiam seguir a última carga útil.

[0040] Em algumas modalidades, o elemento central de um segmento de metadados em um campo de dados auxiliares (ou campo "addbsi" ou segmento de perda de bit) de um quadro compreende um cabeçalho central (tipicamente incluindo valores de identificação, por exemplo, versão de elemento central), e depois o cabeçalho central: valores indicativos de se os dados de impressão digital estão incluídos para metadados do segmento de metadados, valores indicativos de se dados externos (relacionados aos dados de áudio correspondentes aos metadados do segmento de metadados) existem, carga útil ID e valores de tamanho da carga útil para cada tipo de metadados (por exemplo, LPSM, e/ou metadados de um tipo que não LPSM) identificados por um elemento central, e valores de proteção para pelo menos um tipo de metadados identificado pelo elemento central. A carga útil de metadados(s) do segmento de metadados segue o cabeçalho central, e é (em alguns casos) agrupada dentro de valores do elemento central.

[0041] Em outro formato preferido, o fluxo de bits contínuo codificado é um fluxo de bits contínuo Dolby E, e cada um dos segmentos de metadados que inclui LPSM (e opcionalmente também metadados de limite do programa) está incluído em uma primeira localização de amostras N do intervalo de banda de guarda Dolby E.

[0042] Em outra classe de modalidades, a invenção é uma APU(por exemplo, um decodificador) acoplada e configurada para receber um fluxo de bits contínuo de áudio codificado que compreende seg- mentos de dados de áudio e segmentos de metadados, onde os segmentos de dados de áudio são indicativos de dados de áudio, e cada um de pelo menos alguns dos segmentos de metadados inclui metadados do estado do processamento de sonoridade (LPSM) e opcionalmente também metadados de limite do programa, e para extrair o LPSM do fluxo de bits contínuo, para gerar dados de áudio decodificados em resposta aos dados de áudio e para realizar pelo menos uma operação de processamento de sonoridade adaptativo sobre os dados de áudio utilizando o LPSM. Algumas modalidades nessa classe também incluem um pós-processador acoplado à APU, em que o pós- processador está acoplado e configurado para realizar pelo menos uma operação de processamento de sonoridade adaptativa sobre os dados de áudio utilizando o LPSM.

[0043] Em outra classe da modalidade, a invenção é uma unidadede processamento de áudio (APU) incluindo uma memória buffer (buffer) e um subsistema de processamento acoplado ao buffer, em que a APU é acoplada para receber um fluxo de bits contínuo de áudio codificado que compreende segmentos de dados de áudio e segmentos de metadados, onde os segmentos dados de áudio são indicativos de dados de áudio, e cada um de pelo menos alguns dos segmentos de metadados inclui metadados do estado do processamento de sonoridade (LPSM) e opcionalmente também metadados de limite do programa, o buffer armazena (por exemplo, de uma maneira não transitória) pelo menos um quadro do fluxo de bits contínuo de áudio codificado, e o subsistema de processamento está configurado para extrair o LPSM do fluxo de bits contínuo e para realizar pelo menos uma operação de processamento de sonoridade adaptativa sobre os dados de áudio utilizando o LPSM. Em modalidades típicas nessa classe, a APU é uma de um codificador, um decodificador, e um pós-processador.

[0044] Em algumas implementações do método inventivo, o fluxo de bits de áudio contínuo gerado é um de um fluxo de bits contínuo codificado AC-3, um fluxo de bits contínuo E-AC-3, ou um fluxo de bits contínuo Dolby E, incluindo metadados do estado do processamento de sonoridade, bem como outros metadados (por exemplo, um parâmetro de metadados DIALNORM, parâmetros de metadados de controle de variação dinâmica, e outros parâmetros metadados). Em algumas outras implementações do método, o fluxo de bits contínuo de áudio gerado é um fluxo de bits contínuo codificado de outro tipo.

[0045] Aspectos da invenção incluem um sistema ou dispositivoconfigurado (por exemplo, programado) para realizar qualquer modalidade do método inventivo, e um meio legível por computador (por exemplo, um disco) que armazena códigos (por exemplo, de uma maneira não transitória) para implementar qualquer modalidade do método ou etapas inventivas do mesmo. Por exemplo, o sistema inventivo pode ser ou incluir um processador de finalidade geral programável, processador de sinal digital, ou microprocessador, programado com software ou firmware e/ou senão configurado para realizar qualquer uma de uma variedade de operações sobre dados, incluindo uma modalidade do método ou etapas inventivas do mesmo. Tal processador de finalidade geral programável pode ser ou incluir um sistema de computador incluindo um dispositivo de entrada, uma memória, e circuitos de processamento programados (e/ou senão configurados) para realizar uma modalidade do método inventivo (ou etapas do mesmo) em resposta aos dados afirmados ao mesmo.

BREVE DESCRIÇÃO DOS DESENHOS

[0046] A figura 1 é um diagrama em blocos de uma modalidade deum sistema que pode ser configurado para realizar uma modalidade do método inventivo.

[0047] A figura 2 é um diagrama em blocos de um codificador queé uma modalidade da unidade de processamento de áudio inventiva.

[0048] A figura 3 é um diagrama em blocos de um decodificadorque é uma modalidade da unidade de processamento de áudio inventiva, e um pós-processador acoplado a ela que é outra modalidade da unidade de processamento de áudio inventiva.

[0049] A figura 4 é um diagrama de um quadro AC-3, incluindo ossegmentos nos quais é dividido.

[0050] A figura 5 é um diagrama do segmento da Informação deSincronização (SI) de um quadro AC-3, incluindo segmentos nos quais é dividido.

[0051] A figura 6 é um diagrama do segmento da Informação dofluxo de bits contínuo (BSI) de um quadro AC-3, incluindo segmentos nos quais é dividido.

[0052] A figura 7 é um diagrama de um quadro E-AC-3, incluindosegmentos nos quais é dividido.

[0053] A figura 8 é um diagrama de quadros de um fluxo de bitscontínuo de áudio codificado que inclui metadados de limite do programa cujo formato é de acordo com uma modalidade da invenção.

[0054] A figura 9 é um diagrama de outros quadros do fluxo de bitscontínuo de áudio codificado da figura 9. Alguns desses quadros incluem metadados de limite do programa tendo formato de acordo com uma modalidade da invenção.

[0055] A figura 10 é um diagrama de dois fluxos de bits contínuosde áudio codificado: um fluxo de bits contínuo (IEB) no qual um limite do programa (identificado "Limite") é alinhado com uma transição entre dois quadros do fluxo de bits contínuo, e outro fluxo de bits contínuo (TB) no qual um limite do programa (identificado "Limite Verdadeiro") é compensado por 512 amostras de uma transição entre dois quadros do fluxo de bits contínuo.

[0056] A figura 11 é um conjunto de diagramas que mostram quatro fluxos de bits contínuos de áudio codificados. O fluxo de bits contí- nuo no topo da figura 11 (identificado "Cenário 1") é indicativo de um primeiro programa de áudio (P1) incluindo metadados de limite do programa seguido por um segundo programa de áudio (P2) que ainda inclui metadados de limite do programa; o segundo fluxo de bits contínuo (identificado "Cenário 2") é indicativo de um primeiro programa de áudio (P1) que inclui metadados de limite do programa seguido por um segundo programa de áudio (P2) que não inclui metadados de limite do programa; o terceiro fluxo de bits contínuo (identificado "Cenário 3") é indicativo de um primeiro programa de áudio truncado (P1) que inclui metadados de limite do programa, e que foi ligado com todo um segundo programa de áudio (P2) que inclui metadados de limite do programa; e o quarto fluxo de bits contínuo (identificado "Cenário 4") é indicativo de um primeiro programa de áudio truncado (P1) que inclui metadados de limite do programa, e um segundo programa de áudio truncado (P2) que inclui metadados de limite do programa e que foi ligado com uma parte do primeiro programa de áudio.

Notação e Nomenclatura

[0057] Em toda esta descrição, incluindo nas concretizações, aexpressão realizar uma operação "em" um sinal ou dados (por exemplo, filtragem, escala, transformação, ou aplicação novamente, ao sinal ou dados) é utilizado em um sentido amplo para denotar a realização da operação diretamente no sinal ou dados, ou em uma versão processada de sinal ou dados (por exemplo, em uma versão do sinal que passou pela filtragem preliminar ou pré-processamento antes da realização da operação nele).

[0058] Em toda esta descrição incluindo nas concretizações, a expressão "sistema" é utilizada em um amplo sentido para denotar um dispositivo, sistema, ou subsistema. Por exemplo, um subsistema que implementa um decodificador pode ser referido como um sistema de decodificador, e um sistema incluindo tal subsistema (por exemplo, um sistema que gera X sinais de saída em resposta às várias entradas, nas quais o subsistema gera M das entradas e saídas e outras entradas X - M são recebidas de uma fonte externa) podem ainda ser referidas como um sistema de decodificador.

[0059] Em toda esta descrição incluindo nas concretizações, otermo "processador" é utilizado em um amplo sentido para denotar um sistema ou dispositivo programável ou, em outro caso, configurável (por exemplo, com software ou firmware) para realizar as operações nos dados (por exemplo, áudio, ou vídeo ou outros dados de imagem). Exemplos de processadores incluem uma porta da matriz programável por campo (ou outro circuito integrado configurável ou conjunto de chips), um processador do sinal digital programado e/ou, caso contrário, configurado para realizar o processamento em conduta no áudio ou outros dados do som, um processador ou computador de finalidade geral programável, e um chip do microprocessador programável ou conjunto de chips.

[0060] Em toda esta descrição incluindo nas concretizações, asexpressões "processador de áudio" e "unidade de processamento de áudio" são utilizadas de forma intercambiável, e em um amplo sentido, para denotar um sistema configurado para processar os dados de áudio. Exemplos das unidades de processamento de áudio incluem, entre outros, codificadores (por exemplo, transcodificadores), decodifica- dores, codecs, sistemas de pré-processamento, sistemas de pós- processamento, e sistemas de processamento do fluxo de bits contínuo (às vezes referido como ferramentas de processamento do fluxo de bits contínuo).

[0061] Em toda esta descrição incluindo nas concretizações, a expressão "metadados do estado de processamento" (por exemplo, como na expressão "metadados do estado do processamento de sonoridade") se refere aos dados separados e diferentes dos dados de áudio correspondentes (o conteúdo de áudio de um fluxo de bits de áudio que ainda inclui metadados do estado de processamento). Os metadados do estado de processamento são associados com os dados de áudio, indicam o estado de processamento de sonoridade dos dados de áudio correspondentes (por exemplo, quais tipos de processamento já foram realizados nos dados de áudio), e tipicamente ainda indicam pelo menos uma função ou característica de dados de áudio. A associação dos metadados do estado de processamento com os dados de áudio é síncrona. Assim, os metadados presentes (os mais recentemente recebidos ou atualizados) do estado de processamento indicam que os dados de áudio correspondentes contemporaneamente com-preendem os resultados dos tipos indicados do processamento de dados de áudio. Em alguns casos, os metadados do estado de processamento podem incluir o histórico de processamento e/ou alguns ou todos os parâmetros que são utilizados e/ou derivados dos tipos indicados de processamento. Adicionalmente, metadados do estado de processamento podem incluir pelo menos uma função ou característica dos dados de áudio correspondentes, que foram computadas ou extraídas dos dados de áudio. Os metadados do estado de processamento podem ainda incluir outros metadados que não são relacionados ou derivados de qualquer processamento dos dados de áudio correspondentes. Por exemplo, dados terceiros, informação de rastrea- mento, identificadores, informação de propriedade ou padrão, dados de anotação do usuário, dados de preferência do usuário, etc. podem ser adicionados por uma unidade de processamento de áudio particular para passar para outras unidades de processamento de áudio.

[0062] Em toda esta descrição incluindo nas concretizações, a expressão "metadados do estado do processamento de sonoridade" (ou "LPSM") denota os metadados do estado de processamento indicativo do estado de processamento de sonoridade de dados de áudio cor- respondentes (por exemplo quais tipos de processamento de sonoridade foram realizados nos dados de áudio) e tipicamente ainda pelo menos uma função ou característica (por exemplo, sonoridade) dos dados de áudio correspondentes. Os metadados de sonoridade do estado de processamento podem incluir dados (por exemplo, outros metadados) que não são (ou seja, quando são considerados sozinhos) metadados do estado do processamento de sonoridade.

[0063] Em toda esta descrição incluindo nas concretizações, a expressão "canal" (ou "canal de áudio") denota um sinal de áudio mono- fônico.

[0064] Em toda esta descrição incluindo nas concretizações, a expressão "programa de áudio" denota um conjunto de um ou mais canais de áudio e opcionalmente ainda metadados associados (por exemplo, metadados que descrevem uma apresentação de áudio espacial desejada, e/ou LPSM, e/ou metadados de limite de programa).

[0065] Em toda esta descrição incluindo nas concretizações, a expressão "metadados de limite do programa" denota metadados de um fluxo de bits contínuo de áudio codificado, onde o fluxo de bits contínuo de áudio codificado é indicativo de pelo menos um programa de áudio (por exemplo, dois ou mais programas de áudio), e os metadados de limite do programa são indicativos da localização no fluxo de bits contínuo de pelo menos um limite (começo e/ou fim) de pelo menos um dito programa de áudio. Por exemplo, os metadados de limite do programa (de um fluxo de bits contínuo de áudio codificado indicativo de um programa de áudio) podem incluir metadados indicativos da localização (por exemplo, o começo do quadro "N"th do fluxo de bits contínuo, ou da localização da amostra "M"th do quadro "N"th do fluxo de bits contínuo) do começo do programa, e metadados adicionais indicativos da localização (por exemplo, o começo do "J"th quadro do fluxo de bits contínuo, ou da localização da "K"th amostra do "J"th quadro do fluxo de bits contínuo) do final do programa.

[0066] Em toda esta descrição incluindo nas concretizações, otermo "acopla" ou "acoplado" é utilizado para significar tanto uma conexão direta quanto indireta. Assim, se um primeiro dispositivo acopla em um segundo dispositivo, essa conexão pode ser através da conexão direta, ou de uma conexão indireta através de outros dispositivos e conexões.DESCRIÇÃO DETALHADA DAS MODALIDADES DA INVENÇÃO

[0067] De acordo com as modalidades típicas da invenção, umacarga útil de metadados da sonoridade do programa, referida como metadados do estado do processamento de sonoridade ("LPSM") e opcionalmente ainda metadados de limite de programa, são embutidos em um ou mais campos reservados (ou compartimentos) de segmentos de metadados de um fluxo de bits contínuo de áudio que ainda inclui dados de áudio em outros segmentos (segmentos de dados de áudio). Tipicamente, pelo menos um segmento de cada quadro do fluxo de bits contínuo inclui LPSM, e pelo menos um outro segmento do quadro inclui dados de áudio correspondentes (ou seja, dados de áudio cujo estado de processamento de sonoridade e sonoridade é indicado pela LPSM). Em algumas modalidades, o volume dos dados da LPSM pode ser suficientemente pequeno para ser carregado sem afetar a taxa de bit afetada para carregar os dados de áudio.

[0068] Comunicar os metadados do estado do processamento desonoridade em uma cadeia de processamento de dados de áudio é particularmente útil quando duas ou mais unidades de processamento de áudio precisam funcionar juntamente com outra cadeia de processamento (ou ciclo de vida do conteúdo). Sem inclusão de metadados do estado do processamento de sonoridade em um fluxo de bits contínuo de áudio, vários problemas de processamento de mídia como qualidade, nível e degradações espaciais podem ocorrer, por exemplo, quando dois ou mais codecs de áudio são utilizados na cadeia e o nivelamento de volume simples é aplicado mais do que uma vez durante a jornada do fluxo de bits contínuo a um dispositivo de consumo de mídia (ou um ponto de renderização do conteúdo de áudio do fluxo de bits contínuo).

[0069] A figura 1 é um diagrama em blocos de uma cadeia de processamento de áudio exemplar (um sistema de processamento de dados de áudio), em que um ou mais elementos do sistema podem ser configurados de acordo com uma modalidade da presente invenção. O sistema inclui os seguintes elementos, acoplados juntos conforme mostrado: uma unidade de pré-processamento, um codificador, uma análise de sinal e unidade de correção de metadados, um transcodifi- cador, um decodificador, e uma unidade de pré-processamento. Nas variações do sistema mostrado, um ou mais dos elementos são omitidos, ou unidades de processamento de dados de áudio adicionais são incluídas.

[0070] Em algumas implementações, a unidade de pré-processamento da figura 1 é configurada para aceitar amostras de PCM (domínio de tempo) que compreendem o conteúdo de áudio como entrada, e para emitir amostras de PCM processadas. O codificador pode ser configurado para aceitar as amostras de PCM como entrada e para emitir um fluxo de bits contínuo de áudio indicativo codificado (por exemplo, comprimido) do conteúdo de áudio. Os dados do fluxo de bits contínuo que são indicativos do conteúdo de áudio são, às vezes, referidos neste documento como "dados de áudio." Se o codificador é configurado de acordo com uma típica modalidade da presente invenção, o fluxo de bits contínuo de áudio emitido do codificador inclui metadados do estado do processamento de sonoridade (e tipicamente outros metadados, opcionalmente incluindo metadados de limite de programa) bem como dados de áudio.

[0071] A análise de sinal e unidade de correção de metadados dafigura 1 podem aceitar um ou mais fluxos de bits contínuo de áudio codificado como entrada e determinam (por exemplo, validam) se os metadados do estado de processamento em cada fluxo de bits contínuo de áudio codificado estão corretos, realizando uma análise de sinal (por exemplo, utilizando metadados de limite do programa em um fluxo de bits contínuo de áudio codificado). Se a análise de sinal e unidade de correção de metadados tiver metadados incluídos, ela é invá-lida, tipicamente substitui os valores incorretos com os valores corretos obtidos da análise de sinal. Assim, cada fluxo de bits contínuo de áudio codificado emitido da análise de sinal e unidade de correção de metadados pode incluir metadados do estado de processamento corrigidos (ou não corrigidos) bem como dados de áudio codificados.

[0072] O transcodificador da figura 1 pode aceitar fluxos de bitscontínuos de áudio codificado como entrada, e (por exemplo, codificados de forma diferente) fluxos de dados contínuo de áudio emitidos modificados em resposta (por exemplo, pela decodificação de um fluxo de entrada e recodificação do fluxo decodificado em um formato de codificação diferente). Se o transcodificador for configurado de acordo com uma típica modalidade da presente invenção, o fluxo de bits contínuo de áudio emitido do transcodificador inclui metadados do estado do processamento de sonoridade (e tipicamente outros metadados) bem como dados de áudio codificados. Os metadados podem ter sido incluídos no fluxo de bits contínuo.

[0073] O decodificador da figura 1 pode aceitar fluxos de dadoscontínuos de áudio codificado (por exemplo, comprimidos) como entrada, e fluxos de saída (em resposta) das amostras de áudio de PCM decodificados. Se o decodificador é configurado de acordo com uma típica modalidade da presente invenção, a saída do decodificador na típica operação é ou inclui qualquer um dos seguintes: um fluxo de amostras de áudio, e um fluxo de metadados do estado do processamento de sonoridade correspondente (e tipicamente outros metadados) extraídos de um fluxo de bits contínuo codificado de entrada; ouum fluxo de amostras de áudio, e um fluxo de bits de controle correspondente determinado dos metadados do estado do processamento de sonoridade (e tipicamente outros metadados) extraídos de um fluxo de bits contínuo codificado de entrada; ouum fluxo de amostras de áudio, sem um fluxo de metadados do estado de processamento correspondente ou bits de controle determinados dos metadados do estado de processamento. Neste último caso, o decodificador pode extrair metadados do estado do processamento de sonoridade (e/ou outros metadados) do fluxo de bits contínuo codificado de entrada e realizar pelo menos uma operação nos metadados extraídos (por exemplo, validação), embora não emita os metadados extraídos ou bits de controle determinados dela.

[0074] Pela configuração da unidade de pós-processamento dafigura 1 de acordo com uma típica modalidade da presente invenção, a unidade de pós-processamento é configurada para aceitar um fluxo de amostras de áudio de PCM decodificado, e para realizar o pós- processamento nele (por exemplo, nivelamento do volume do conteúdo de áudio) utilizando metadados do estado do processamento de sonoridade (e tipicamente outros metadados) recebidos com as amostras, ou bits de controle (determinados pelo decodificador de metada-dos do estado do processamento de sonoridade e tipicamente outros metadados) recebidos com as amostras. A unidade de pós- processamento é tipicamente ainda configurada para renderizar o conteúdo de áudio pós-processado para reproduzir por um ou mais alto- falantes.

[0075] Modalidades típicas da presente invenção fornecem uma cadeia de processamento de áudio melhorada na qual as unidades de processamento de áudio (por exemplo, codificadores, decodificadores, transcodificadores, e unidades de pré- e pós-processamento) adaptam seu respectivo processamento para ser aplicado aos dados de áudio de acordo com um estado contemporâneo dos dados da mídia conforme indicado pelos metadados do estado do processamento de sonoridade respectivamente recebidos pelas unidades de processamento de áudio.

[0076] Os dados de áudio de entrada em qualquer unidade deprocessamento de áudio do sistema da figura 1 (por exemplo, o codificador ou transcodificador da figura 1) pode incluir metadados do estado do processamento de sonoridade (e opcionalmente outros metadados) bem como dados de áudio (por exemplo, dados de áudio codificados). Estes metadados podem ter sido incluídos no áudio de entrada por outro elemento do sistema da figura 1 (ou outra fonte, não mostrada na figura 1) de acordo com uma modalidade da presente invenção. A unidade de processamento que recebe o áudio de entrada (com metadados) pode ser configurada para realizar pelo menos uma operação nos metadados (por exemplo, validação) ou em resposta aos metadados (por exemplo, processamento adaptativo do áudio de entrada), e tipicamente ainda para incluir em seu áudio de saída os metadados, uma versão processada dos metadados, ou bits de controle determi-nados dos metadados.

[0077] Uma típica modalidade da unidade de processamento deáudio inventiva (ou processador de áudio) é configurada para realizar o processamento adaptativo de dados de áudio com base no estado dos dados de áudio conforme indicado pelos metadados do estado do processamento de sonoridade correspondentes aos dados de áudio. Em algumas modalidades, o processamento adaptativo é (ou inclui) processamento de sonoridade (se os metadados indicam que o pro- cessamento de sonoridade, ou processamento semelhante a ela, não foi realizado nos dados de áudio, mas não é (e não inclui) processamento de sonoridade (se os metadados indicarem que este processamento de sonoridade, ou processamento semelhante a ele, já foi realizado nos dados de áudio). Em algumas modalidades, o processamento adaptativo é ou inclui validação de metadados (por exemplo, realizada em uma subunidade de validação de metadados) para garantir que a unidade de processamento de áudio realize outro processamento adaptativo dos dados de áudio com base no estado dos dados de áudio conforme indicado pelos metadados do estado do processamento de sonoridade. Em algumas modalidades, a validação determina a confiabilidade dos metadados do estado do processamento de sonoridade associados com (por exemplo, incluídos em um fluxo de bits contínuo com) os dados de áudio. Por exemplo, se os metadados são validados para serem confiáveis, então resultam de um tipo de processamento de áudio previamente realizado pode ser reutilizado e novo desempenho do mesmo tipo de processamento de áudio pode ser evitado. Por outro lado, se os metadados são encontrados como manipulados com (ou, caso contrário, confiável), então o tipo de processamento de mídia alegadamente previamente realizado (conforme indicado pelos metadados confiáveis) pode ser repetido pela unidade de processamento de áudio, e/ou outro processamento pode ser realizado pela unidade de processamento de áudio nos metadados e/ou nos dados de áudio. A unidade de processamento de áudio pode ainda ser configurada para sinalizar as outras unidades de processamento de áudio a jusante em uma cadeia de processamento de mídia melhorada que os metadados do estado do processamento de sonoridade (por exemplo, presentes em um fluxo de bits contínuo de mídia) são válidos, se a unidade determinar que os metadados do estado de processamento são válidos (por exemplo, com base em uma combinação de um valor criptográfico extraído e um valor criptográfico de referência).

[0078] A figura 2 é um diagrama em blocos de um codificador(100) que é uma modalidade da unidade de processamento de áudio inventiva. Qualquer um dos componentes ou elementos do codificador 100 pode ser implementado como um ou mais processos e/ou um ou mais circuitos (por exemplo, ASICs, FPGAs, ou outros circuitos integrados), em hardware, software, ou uma combinação de hardware e software. O codificador 100 compreende o buffer do quadro 110, interpretador 111, decodificador 101, validador do estado do áudio 102, estágio de processamento de sonoridade 103, estágio de seleção de fluxo de áudio 104, codificador 105, estágio do fio de enchimen- to/formatador 107, estágio de geração dos metadados 106, subsistema de medição da sonoridade do diálogo 108, e buffer do quadro 109, conectados conforme mostrado. Tipicamente, o codificador 100 inclui outros elementos de processamento (não mostrados).

[0079] O codificador 100 (que é um transcodificador) é configuradopara converter um fluxo de bits contínuo de áudio de entrada (que, por exemplo, pode ser um de um fluxo de bits contínuo AC-3, um fluxo de bits contínuo E-AC-3, ou um fluxo de bits contínuo Dolby E) em um fluxo de bits contínuo de áudio de saída codificado (que, por exemplo, pode ser outro de um fluxo de bits contínuo AC-3, um fluxo de bits contínuo E-AC-3, ou um fluxo de bits contínuo Dolby E) incluindo a realização do processamento de sonoridade adaptativo e automatizado utilizando metadados do estado do processamento de sonoridade incluídos no fluxo de bits contínuo de entrada. Por exemplo, o codificador 100 pode ser configurado para converter um fluxo de bits contínuo de entrada Dolby E (um formato tipicamente utilizado nas facilidades de produção e transmissão, mas não em dispositivos de consumidor que recebem programas de áudio que foram transmitidos a ele) em um fluxo de bits contínuo de áudio de saída codificado (adequado para transmitir aos dispositivos do consumidor) no formato AC-3 ou E-AC-3.

[0080] O sistema da figura 2 ainda inclui subsistema de entrega deáudio codificado 150 (que armazena e/ou entrega os fluxos de dados contínuos codificados emitidos do codificador 100) e decodificador 152. Um fluxo de bits contínuo de áudio codificado emitido do codificador 100 pode ser armazenado pelo subsistema 150 (por exemplo, na forma de um DVD ou disco Blue-ray), ou transmitido pelo subsistema 150 (que pode implementar um link de transmissão ou rede), ou pode ser tanto armazenado quanto transmitido pelo subsistema 150. O de- codificador 152 é configurado para decodificar um fluxo de bits contínuo de áudio codificado (gerado pelo codificador 100) que recebe através do subsistema 150, incluindo extrair metadados do estado do processamento de sonoridade (LPSM) de cada quadro do fluxo de bits contínuo (e opcionalmente ainda extrair metadados de limite do programa do fluxo de bits contínuo), e gerar dados de áudio decodificado. Tipicamente, o decodificador 152 é configurado para realizar o processamento de sonoridade adaptativo nos dados de áudio decodificado utilizando o LPSM (e opcionalmente outros metadados de limite do programa), e/ou para encaminhar os dados de áudio decodificado e LPSM a um pós-processador configurado para realizar o processamento de sonoridade adaptativo nos dados de áudio decodificado utilizando o LPSM (e opcionalmente outros metadados de limite do programa). Tipicamente, o decodificador 152 inclui um buffer que armazena (por exemplo, em uma forma não transitória) o fluxo de bits contínuo de áudio codificado recebido do subsistema 150.

[0081] Várias implementações do codificador 100 e do decodifica-dor 152 são configuradas para realizar diferentes modalidades do método inventivo.

[0082] O buffer do quadro 110 é uma memória buffer acoplada para receber um fluxo de bits contínuo de áudio de entrada codificado. Na operação, o buffer 110 armazena (por exemplo, de forma não transitória) pelo menos um quadro do fluxo de bits contínuo de áudio codificado, e uma sequência dos quadros do fluxo de bits contínuo de áudio codificado é imposta do buffer 110 ao interpretador 111.

[0083] O interpretador 111 é acoplado e configurado para extrairmetadados do estado do processamento de sonoridade (LPSM), e opcionalmente outros metadados de limite do programa (e/ou outros metadados) de cada quadro do áudio de entrada codificado no qual estes metadados estão incluídos, para impor pelo menos o LPSM (e opcionalmente outros metadados de limite do programa e/ou outros metadados) ato validador do estado do áudio 102, estágio de processamento de sonoridade 103, estágio 106 e subsistema 108, para extrair da-dos de áudio do áudio de entrada codificado, e para impor os dados de áudio ao decodificador 101. O decodificador 101 do codificador 100 é configurado para decodificar os dados de áudio para gerar dados de áudio decodificado, e para impor os dados de áudio decodificado ao estágio de processamento de sonoridade 103, estágio de seleção de fluxo de áudio 104, subsistema 108, e tipicamente ainda ao validador de estado 102.

[0084] O validador de estado 102 é configurado para autenticar evalidar o LPSM (e opcionalmente outros metadados) inseridos nele. Em algumas modalidades, o LPSM é (ou está incluído em) um bloco de dados que foi incluído no fluxo de bits contínuo de entrada (por exemplo, de acordo com uma modalidade da presente invenção). O bloco pode compreender um hash criptográfico (um código de autenticação de mensagens com base no hash ou "HMAC") para processamento de LPSM (e opcionalmente outros metadados) e/ou os dados de áudio subjacentes (fornecidos do decodificador 101 ao validador 102). O bloco de dados pode ser digitalmente assinado nestas modalidades, de modo que uma unidade de processamento de áudio a ju- sante possa relativamente autenticar facilmente e validar os metadados do estado de processamento.

[0085] Por exemplo, o HMAC é utilizado para gerar uma conversão, e os valores de proteção incluídos no fluxo de bits contínuo inventivo podem incluir a conversão. A conversão pode ser gerada como segue para um quadro AC-3:1. Após dados AC-3 e LPSM serem codificados, bytes de dados do quadro (concatenado frame_data #1 e frame_data #2) e os bytes de dados de LPSM são utilizados como entrada para o HMAC da função de dispersão. Outros dados, que podem estar presentes dentro de um campo de dados auxiliares, não são considerados para calcular a conversão. Estes outros dados podem ser bytes não pertencendo aos dados AC-3 nem aos dados de LSPSM. Os bits de proteção em LPSM podem não ser considerados para calcular a conversão de HMAC.2. Após a conversão ser calculada, ela é gravada no fluxo de bits contínuo em um campo reservado para bits de proteção.3. A última etapa da geração do quadro AC-3 completo é o cálculo de CRC-check. Este é gravado em cada final do quadro e todos os dados pertencentes a este quadro são considerados, incluindo os bits de LPSM.

[0086] Outros métodos criptográficos incluindo, entre outros, qualquer um de um ou mais métodos criptográficos não HMAC podem ser utilizados para validação de LPSM (por exemplo, no validador 102) para garantir a transmissão e recepção seguras de LPSM e/ou dos dados de áudio subjacentes. Por exemplo, a validação (utilizando tal método criptográfico) pode ser realizada em cada unidade de processamento de áudio que recebe uma modalidade do fluxo de bits contínuo inventivo de áudio para determinar se os metadados do estado do processamento de sonoridade e dados de áudio correspondentes in- cluídos no fluxo de bits contínuo passaram (e/ou resultaram do) processamento de sonoridade específico (conforme indicado pelos metadados) e não foram modificados após a realização deste processamento de sonoridade específico.

[0087] O validador de estado 102 impõe dados de controle ao estágio de seleção de fluxo de áudio 104, gerador de metadados 106, e subsistema de medição da sonoridade do diálogo 108, para indicar os resultados da operação da validação. Em resposta aos dados de controle, o estágio 104 pode selecionar (e passar ao codificador 105): a saída adaptativamente processada do estágio de processamento de sonoridade 103 (por exemplo, quando o LPSM indica que os dados de áudio emitidos do decodificador 101 não passaram por um tipo específico de processamento de sonoridade, e os bits de controle do valida- dor 102 indicam que os LPSM são válidos); ou os dados de áudio emitidos do decodificador 101 (por exemplo, quando os LPSM indicam que os dados de áudio emitidos do decodificador 101 já passaram pelo tipo específico de processamento de sonoridade que seria realizado pelo estágio 103, e os bits de controle do validador 102 indicam que os LPSM são válidos).

[0088] O estágio 103 do codificador 100 é configurado para realizar o processamento de sonoridade adaptativo nos dados de áudio decodificado emitido do decodificador 101, com base em uma ou mais características dos dados de áudio indicadas pelos LPSM extraídos pelo decodificador 101. O estágio 103 pode ser uma transformada adaptativa de sonoridade no domínio de tempo real e processador de controle da faixa dinâmica. O estágio 103 pode receber a entrada do usuário (por exemplo, valores da faixa dinâmica/sonoridade alvo do usuário ou valores de dialnorm), ou outra entrada de metadados (por exemplo, um ou mais tipos de dados terceiros, informação de rastrea- mento, identificadores, informação de propriedade ou padrão, dados de anotação do usuário, dados de preferência do usuário, etc.) e/ou outra entrada (por exemplo, de um processo de impressão digital), e utilizam esta entrada para processar os dados de áudio decodificado emitido do decodificador 101. O estágio 103 pode realizar o processamento de sonoridade adaptativo nos dados de áudio decodificado (emitido do decodificador 101) indicativo de um único programa de áudio (conforme indicado pelos metadados de limite de programa extraído pelo interpretador 111), e pode redefinir o processamento de sono-ridade em resposta à recepção dos dados de áudio decodificado (emitido do decodificador 101) indicativo de um diferente programa de áudio conforme indicado pelos metadados de limite de programa extraídos pelo interpretador 111.

[0089] O subsistema de medição da sonoridade do diálogo 108pode operar para determinar a sonoridade dos segmentos do áudio decodificado (do decodificador 101) que são indicativas de diálogo (ou outra fala), por exemplo, utilizando os LPSM (e/ou outros metadados) extraídos pelo decodificador 101, quando os bits de controle do valida- dor 102 indicam que os LPSM são inválidos. A operação do subsistema de medição da sonoridade do diálogo 108 pode ser desabilitada quando os LPSM indicarem os segmentos da sonoridade do diálogo previamente determinados (ou outra fala) do áudio decodificado (do decodificador 101) quando os bits de controle do validador 102 indicam que os LPSM são válidos. O subsistema 108 pode realizar uma medição da sonoridade nos dados de áudio decodificado indicativo de um único programa de áudio (conforme indicado pelos metadados de limite de programa extraídos pelo interpretador 111), e pode redefinir a medição em resposta à recepção de dados de áudio decodificado indicativo de um diferente programa de áudio conforme indicado por tais metadados-limite do programa.

[0090] As ferramentas úteis (por exemplo, o medidor de sonorida- de Dolby LM100) existem para medir o nível de diálogo no conteúdo de áudio convenientemente e facilmente. Algumas modalidades do APU inventivo (por exemplo, estágio 108 do codificador 100) são implementadas para incluir (ou para realizar as funções de) tal ferramenta para medir a sonoridade média do diálogo do conteúdo de áudio de um fluxo de bits contínuo de áudio (por exemplo, um fluxo de bits contínuo AC-3 decodificado imposto ao estágio 108 do decodificador 101 do codificador 100).

[0091] Se o estágio 108 é implementado para medir a sonoridademédio do diálogo verdadeiro dos dados de áudio, a medição pode incluir uma etapa de isolamento dos segmentos do conteúdo de áudio que predominantemente contém fala. Os segmentos de áudio que predominantemente são fala são então processados de acordo com um algoritmo de medição da sonoridade. Para os dados de áudio decodificados de um fluxo de bits contínuo AC-3, este algoritmo pode ser uma medição de sonoridade ponderada por K padrão (de acordo com o padrão internacional ITU-R BS.1770).

[0092] De modo alternativo, outras medições da sonoridade podem ser utilizadas (por exemplo, aquelas com base nos modelos psi- coacústico de sonoridade).

[0093] O isolamento dos segmentos da fala não é essencial paramedir a sonoridade média do diálogo de dados de áudio. Entretanto, melhora a precisão da medição e tipicamente fornece resultados mais satisfatórios da perspectiva de um ouvinte. Por causa de todo o conteúdo de áudio conter diálogo (fala), a medição da sonoridade de todo o conteúdo de áudio pode fornecer uma aproximação suficiente do nível do diálogo do áudio, com a fala presente.

[0094] O gerador de metadados 106 gera (e/ou passa pelo estágio107) os metadados a serem incluídos pelo estágio 107 no fluxo de bits contínuo codificado para ser emitido do codificador 100. O gerador de metadados 106 pode passar pelo estágio 107 os LPSM (e opcionalmente outros metadados de limite de programa e/ou outros metadados) extraídos pelo codificador 101 e/ou interpretador 111 (por exemplo, quando bits de controle do validador 102 indicam que os LPSM e/ou outros metadados são válidos), ou geram novos LPSM (e opcionalmente outros metadados de limite de programa e/ou outros metadados) e impõem os novos metadados ao estágio 107 (por exemplo, quando bits de controle do validador 102 indicam que os LPSM e/ou outros metadados extraídos pelo decodificador 101 são inválidos, ou podem impor ao estágio 107 uma combinação de metadados extraídos pelo decodificador 101 e/ou interpretador 111 e metadados recentemente gerados. O gerador de metadados 106 pode incluir dados da sonoridade gerados pelo subsistema 108, e pelo menos um valor indicativo do tipo de processamento de sonoridade realizado pelo subsistema 108, nos LPSM ele impõe ao estágio 107 para inclusão no fluxo de bits contínuo codificado a ser emitido do codificador 100.

[0095] O gerador de metadados 106 pode gerar os bits de proteção (que pode consistir ou incluir um código de autenticação de mensagens com base no hash ou "HMAC") úteis para pelo menos uma da decriptação, autenticação, ou validação dos LPSM (e opcionalmente outros metadados) a serem incluídos no fluxo de bits contínuo codificado e/ou os dados de áudio subjacentes a serem incluídos no fluxo de bits contínuo codificado. O gerador de metadados 106 pode fornecer estes bits de proteção ao estágio 107 para inclusão no fluxo de bits contínuo codificado.

[0096] Na típica operação, o subsistema de medição da sonoridade do diálogo 108 processa os dados de áudio emitidos do decodifica- dor 101 para gerar em resposta a ele os valores do sonoridade (por exemplo, valores da sonoridade do diálogo em portas ou não) e valores da faixa dinâmica. Em resposta a estes valores, o gerador de me tadados 106 pode gerar metadados do estado do processamento de sonoridade (LPSM) para inclusão (por fio de enchimento/formatador 107) ao fluxo de bits contínuo codificado a ser emitido do codificador 100.

[0097] Adicionalmente, opcionalmente, ou de modo alternativo,subsistemas de 106 e/ou 108 do codificador 100 podem realizar análise adicional dos dados de áudio para gerar metadados indicativos de pelo menos uma característica dos dados de áudio para inclusão no fluxo de bits contínuo codificado a ser emitido do estágio 107.

[0098] O codificador 105 codifica (por exemplo, pela realização dacompressão nele) os dados de áudio emitido do estágio de seleção 104, e impõe o áudio codificado ao estágio 107 para inclusão no fluxo de bits contínuo codificado a ser emitido do estágio 107.

[0099] O estágio 107 multiplexa o áudio codificado do codificador105 e dos metadados (incluindo LPSM) do gerador 106 para gerar o fluxo de bits contínuo codificado a ser emitido do estágio 107, preferivelmente de modo que o fluxo de bits contínuo codificado tenha o formato conforme especificado por uma modalidade preferida da presente invenção.

[00100] O buffer do quadro 109 é uma memória buffer que armazena (por exemplo, de forma não transitória) pelo menos um quadro do fluxo de bits contínuo de áudio codificado emitido do estágio 107, e uma sequência de quadros do fluxo de bits contínuo de áudio codificado é então imposto do buffer 109 conforme emitido do codificador 100 ao sistema de entrega 150.

[00101] Os LPSM gerados pelo gerador de metadados 106 e incluídos no fluxo de bits contínuo codificado pelo estágio 107 são indicativos do estado de processamento de sonoridade dos dados de áudio correspondentes (por exemplo, quais tipos de processamento de sonoridade foram realizados nos dados de áudio) e sonoridade (por exem- plo, sonoridade do diálogo medido, sonoridade em portas e/ou não, e/ou faixa dinâmica) dos dados de áudio correspondentes.

[00102] Neste documento, "acionamento por porta" da sonoridade e/ou as medições do nível realizadas nos dados de áudio se refere a um nível específico ou limite de sonoridade onde os valores computados que excedem o limite são incluídos na medição final (por exemplo, ignorando valores da sonoridade curtos abaixo de -60 dBFS nos valores medidos finais). O acionamento por porta de um valor absoluto se refere a um nível fixo ou sonoridade, no qual o acionamento por porta em um valor relativo se refere a um valor que é dependente de um valor de medição atual "sem porta".

[00103] Em algumas implementações do codificador 100, o fluxo de bits contínuo codificado colocado na memória buffer 109 (e emitido ao sistema de entrega 150) é um fluxo de bits contínuo AC-3 ou um fluxo de bits contínuo E-AC-3, e compreende segmentos de dados de áudio (por exemplo, os segmentos de AB0-AB5 do quadro mostrado na figura 4) e segmentos de metadados, onde os segmentos de dados de áudio são indicativos dos dados de áudio, e cada um de pelo menos alguns dos segmentos de metadados inclui metadados do estado do processamento de sonoridade (LPSM). O estágio 107 insere os LPSM (e opcionalmente outros metadados de limite de programa) ao fluxo de bits contínuo no seguinte formato. Cada um dos segmentos de metadados que inclui LPSM (e opcionalmente outros metadados de limite de programa) é incluído em um segmento da perda de bit do fluxo de bits contínuo (por exemplo, um segmento da perda de bit "W" conforme mostrado na figura 4 ou figura 7), ou um campo "addbsi" do segmento da Informação do Fluxo de Bits Contínuo ("BSI") de um quadro do fluxo de bits contínuo, ou em um campo de dados auxiliares (por exemplo, o segmento AUX mostrado na figura 4 ou figura 7) no final de um quadro do fluxo de bits contínuo. Um quadro do fluxo de bits contí- nuo pode incluir um ou dois segmentos de metadados, cada um incluindo os LPSM, e se o quadro inclui dois segmentos de metadados, um pode estar presente no campo addbsi do quadro e o outro no campo AUX do quadro. Em algumas modalidades, cada segmento dos metadados incluindo LPSM inclui um segmento de carga útil de LPSM (ou recipiente) tendo o seguinte formato:um cabeçalho (tipicamente incluindo uma palavra de sincronização identificando o começo da carga útil de LPSM, seguido por pelo menos um valor de identificação, por exemplo, a versão, comprimento, período, contagem do formato LPSM, e valores da associação do subfluxo indicados na Tabela 2 abaixo); eapós o cabeçalho,pelo menos um valor de indicação do diálogo (por exemplo, parâmetro "Dialog channel(s)" da Tabela 2) indicando se dados de áudio correspondentes indicam o diálogo ou não indicam o diálogo (por exemplo, quais canais de dados de áudio correspondentes indicam o diálogo);pelo menos um valor de conformidade de regulação de sonoridade (por exemplo, parâmetro "Loudness Regulation Type" da Tabela 2) indicando se dados de áudio correspondentes estão em conformidade com um conjunto de regulagens de sonoridade indicadas;pelo menos um valor do processamento de sonoridade (por exemplo, um ou mais dos parâmetros "Dialog gated Loudness Correction indicator," "Loudness Correction Type," da Tabela 2) indicando pelo menos um tipo de processamento de sonoridade que foi realizado nos dados de áudio correspondentes; epelo menos um valor de sonoridade (por exemplo, um ou mais dos parâmetros "ITU Relative Gated Loudness," "ITU Speech Gated Loudness," "ITU (EBU 3341) Short-term 3s Loudness," e "True Peak" da Tabela 2) indicando pelo menos uma característica da sono- ridade (por exemplo, sonoridade máxima ou média) dos dados de áudio correspondentes.

[00104] Em algumas modalidades, cada segmento dos metadados que contém LPSM e metadados de limite de programa contém um cabeçalho central (e opcionalmente outros elementos centrais adicionais), e após o cabeçalho central (ou o cabeçalho central e outros elementos centrais) um segmento da carga útil de LPSM (ou recipiente) tendo o seguinte formato:um cabeçalho, tipicamente incluindo pelo menos um valor de identificação (por exemplo, versão, comprimento, período, contagem do formatos LPSM, e valores da associação do subfluxo, conforme indicado na Tabela 2 definido neste documento), eapós o cabeçalho, os LPSM e os metadados de limite de programa. Os metadados de limite de programa podem incluir uma conta do limite do programa do quadro, e um valor do código (por exemplo, um valor "offset_exist") indicativo se o quadro inclui apenas uma conta do limite do programa do quadro ou tanto uma conta do limite do programa do quadro quanto um valor de compensação, e (em alguns casos) um valor de compensação.

[00105] Em algumas implementações, cada um dos segmentos de metadados inseridos pelo estágio 107 em um segmento da perda de bit ou um campo "addbsi" ou um campo de dados auxiliares de um quadro do fluxo de bits contínuo tem o seguinte formato:um cabeçalho central (tipicamente incluindo uma palavra de sincronização identificando o começo dos segmento dos metadados, seguido pelos valores de identificação, por exemplo, a versão, comprimento e período do elemento central, contagem do elemento estendido, e valores da associação do subfluxo indicado na Tabela 1 abaixo); eapós o cabeçalho central, pelo menos um valor de proteção (por exemplo, a conversão de HMAC e valores de Audio Fingerprint da Tabela 1) úteis para pelo menos uma de decriptação, autenticação, ou validação de pelo menos um dos metadados do estado do processamento de sonoridade ou os dados de áudio correspondentes); eainda após o cabeçalho central, se os segmentos dos metadados incluírem LPSM, a identificação da carga útil de LPSM ("ID") e valores do tamanho da carga útil de LPSM que identificam os seguintes metadados como uma carga útil de LPSM e indicam o tamanho da carga útil de LPSM.

[00106] O segmento da carga útil (ou recipiente) de LPSM (preferivelmente tendo o formato especificado acima) segue o ID da carga útil de LPSM e valores do tamanho da carga útil de LPSM.

[00107] Em algumas modalidades, cada um dos segmentos de metadados no campo de dados auxiliares (ou campo "addbsi") de um quadro tem três níveis de estrutura:uma estrutura de alto nível, incluindo um indicador indicando se o campo auxdata (ou addbsi) inclui metadados, pelo menos um valor do ID indicando quais tipos de metadados estão presentes, e tipicamente ainda um valor indicando quantos bits de metadados (por exemplo, de cada tipo) estão presentes (se metadados estão presentes). Um tipo de metadados que poderia estar presente são os LSPM, outro tipo de metadados que poderia estar presente são os metadados de limite de programa, e outro tipo de metadados que poderiam estar presentes são os metadados de pesquisa de mídia (por exemplo, metadados de Nielsen Media Research);uma estrutura de nível intermediário, que compreende um elemento central para cada tipo identificado de metadados (por exemplo, cabeçalho central, valores de proteção, e ID da carga útil de LPSM e valores do tamanho da carga útil de LPSM, conforme mencionado acima, para cada tipo identificado de metadados); e uma estrutura de baixo nível, que compreende cada carga útil para um elemento central (por exemplo, uma carga útil de LPSM, se um for identificado pelo elemento central como sendo presente, e/ou uma carga útil de metadados de outro tipo, se um for identificado pelo elemento central como sendo presente).

[00108] Os valores de dados nesta estrutura de três níveis podem ser agrupados. Por exemplo, os valores de proteção para uma carga útil de LPSM e/ou outra carga útil de metadados identificados por um elemento central podem ser incluídos após cada carga útil identificada pelo elemento central (e, assim, após o cabeçalho central do elemento central). Em um exemplo, um cabeçalho central poderia identificar uma carga útil de LPSM e outra carga útil de metadados, ID da carga útil e valores do tamanho da carga útil para a primeira carga útil (por exemplo, a carga útil de LPSM) poderia seguir o cabeçalho central, a própria primeira carga útil poderia seguir os valores de ID e tamanho, o ID da carga útil e o valor do tamanho da carga útil para a segunda carga útil poderia seguir a primeira carga útil, a própria segunda carga útil poderia seguir estes valores de ID e tamanho, e bits de proteção para ambas as cargas úteis (ou para os valores do elemento central e ambas as cargas úteis) poderiam seguir a última carga útil.

[00109] Em algumas modalidades, se o decodificador 101 receber um fluxo de bits contínuo de áudio gerado de acordo com uma modalidade da invenção com hash criptográfico, o decodificador é configurado para analisar e recuperar o hash criptográfico de um bloco de dados determinado do fluxo de bits contínuo, o dito bloco que compreende metadados do estado do processamento de sonoridade (LPSM) e opcionalmente outros metadados do limite do programa. O validador 102 pode usar o hash criptográfico para validar o fluxo de bits contínuo recebido e/ou metadados associados. Por exemplo, se o validador 102 acha que os LPSM são válidos com base em uma correspondência entre um hash criptográfico de referência e o hash criptográfico recuperado do bloco de dados, então pode desabilitar a operação do processador 103 nos dados de áudio correspondentes e fazer com que o estágio de seleção 104 passe (de modo não modificado) pelos dados de áudio. Adicionalmente, opcionalmente, ou de modo alternativo, outros tipos de técnicas criptográficas podem ser utilizados no lugar de um método com base em um hash criptográfico.

[00110] O codificador 100 da figura 2 pode determinar (em resposta aos LPSM, e opcionalmente outros metadados do limite do programa, extraídos pelo decodificador 101) que uma unidade de pós/pré- processamento realizou um tipo de processamento de sonoridade nos dados de áudio a ser codificado (nos elementos 105, 106, e 107) e, assim, pode criar (no gerador 106) metadados do estado do processamento de sonoridade que incluem os parâmetros específicos utilizados e/ou derivados do processamento de sonoridade previamente realizado. Em algumas implementações, o codificador 100 pode criar (e incluir no fluxo de bits contínuo codificado emitido dele) os metadados do estado de processamento indicativo do histórico de processamento no conteúdo de áudio desde que o codificador esteja ciente sobre os tipos de processamento que foram realizados no conteúdo de áudio.

[00111] A figura 3 é um diagrama em blocos de um decodificador 200 que é uma modalidade da unidade de processamento de áudio inventiva, e de um pós-processador 300 acoplado a ela. O pós- processador 300 é ainda uma modalidade da unidade de processamento de áudio inventiva. Qualquer um dos componentes ou elementos do decodificador 200 e pós-processador 300 pode ser implementado como um ou mais processos e/ou um ou mais circuitos (por exemplo, ASICs, FPGAs, ou outros circuitos integrados), em hardware, software, ou uma combinação de hardware e software. O decodificador 200 compreende buffer do quadro 201, interpretador 205, decodifica- dor de áudio 202, estágio de validação do estado de áudio (validador) 203, e estágio de geração de bit de controle 204, conectado conforme mostrado. Tipicamente ainda, o decodificador 200 inclui outros elementos de processamento (não mostrados).

[00112] O buffer do quadro 201 (uma memória buffer) armazena(por exemplo, de forma não transitória) pelo menos um quadro do fluxo de bits contínuo de áudio codificado recebido pelo decodificador 200. Uma sequência de quadros do fluxo de bits contínuo de áudio codificado é imposto do buffer 201 ao interpretador 205.

[00113] O interpretador 205 é acoplado e configurado para extrair metadados de estado do processamento de sonoridade (LPSM) e opcionalmente outros metadados de limite de programa, e outros metadados de cada quadro do áudio de entrada codificado, para impor pelo menos os LPSM (e metadados de limite de programa se qualquer um for extraído) ao validador do estado de áudio 203 e estágio 204, para impor os LPSM (e opcionalmente outros metadados de limite de pro-grama) como saída (por exemplo, ao pós-processador 300), para extrair dados de áudio do áudio de entrada codificado, e para impor os dados de áudio extraídos ao decodificador 202.

[00114] O fluxo de bits contínuo de áudio codificado entrada ao de- codificador 200 pode ser um de um fluxo de bits contínuo AC-3, um fluxo de bits contínuo E-AC-3, ou um fluxo de bits contínuo Dolby E.

[00115] O sistema da figura 3 ainda inclui pós-processador 300. O pós-processador 300 compreende buffer do quadro 301 e outros elementos de processamento (não mostrados) incluindo pelo menos um elemento de processamento acoplado ao buffer 301. O buffer do quadro 301 armazena (por exemplo, de forma não transitória) pelo menos um quadro do fluxo de bits contínuo de áudio decodificado recebido pelo pós-processador 300 do decodificador 200. Os elementos de processamento do pós-processador 300 são acoplados e configurados para receber e de forma adaptativa processar uma sequência de quadros do fluxo de bits contínuo de áudio decodificado emitido do buffer 301, utilizando metadados (incluindo os valores de LPSM) emitidos do decodificador 202 e/ou bits de controle emitidos do estágio 204 do de- codificador 200. Tipicamente, o pós-processador 300 é configurado para realizar o processamento de sonoridade adaptativo nos dados de áudio decodificado utilizando os valores de LPSM e opcionalmente outros metadados de limite de programa (por exemplo, com base no estado de processamento de sonoridade, e/ou uma ou mais características dos dados de áudio, indicadas pelos LPSM para os dados de áudio indicativo de um único programa de áudio).

[00116] As várias implementações do decodificador 200 e pós- processador 300 são configuradas para realizar diferentes modalidades do método inventivo.

[00117] O decodificador de áudio 202 do decodificador 200 é configurado para decodificar os dados de áudio extraídos pelo interpretador 205 para gerar dados de áudio decodificado, e para impor os dados de áudio decodificados como saída (por exemplo, ao pós-processador 300).

[00118] O validador de estado 203 é configurado para autenticar e validar os LPSM (e opcionalmente outros metadados) impostos nele. Em algumas modalidades, os LPSM são (ou são incluídos em) um bloco de dados que foi incluído no fluxo de bits contínuo de entrada (por exemplo, de acordo com uma modalidade da presente invenção). O bloco pode compreender um hash criptográfico (um código de autenticação de mensagens com base no hash ou "HMAC") para proces-samento dos LPSM (e opcionalmente outros metadados) e/ou os dados de áudio subjacentes (fornecidos do interpretador 205 e/ou deco- dificador 202 ao validador 203). O bloco de dados pode ser digitalmente assinado nestas modalidades, de modo que uma unidade de pro- cessamento de áudio a jusante possa autenticar relativamente de forma fácil e validar os metadados do estado de processamento.

[00119] Outros métodos criptográficos incluindo, mas não limitados a qualquer um de um ou mais métodos criptográficos não-HMAC pode ser utilizado para validação de LPSM (por exemplo, no validador 203) para garantir a transmissão e recebimento seguros dos LPSM e/ou dos dados de áudio subjacentes. Por exemplo, a validação (utilizando tal método criptográfico) pode ser realizada em cada unidade de pro-cessamento de áudio que recebe uma modalidade do fluxo de bits contínuo inventivo de áudio para determinar se os metadados do estado do processamento de sonoridade e dados de áudio correspondentes incluídos no fluxo de bits contínuo passaram por (e/ou resultaram do) processamento de sonoridade específico (conforme indicado pelos metadados) e não foram modificados após a realização deste processamento de sonoridade específico.

[00120] O validador de estado 203 impõe dados de controle para controlar o gerador de bit 204, e/ou impõe os dados de controle como saída (por exemplo, ao pós-processador 300), para indicar os resultados da operação da validação. Em resposta aos dados de controle (e opcionalmente outros metadados extraídos do fluxo de bits contínuo de entrada), o estágio 204 pode gerar (e impor ao pós-processador 300):os bits de controle indicando que os dados de áudio decodificado emitido do decodificador 202 passaram por um tipo específico de processamento de sonoridade (quando os LPSM indicam que os dados de áudio emitido do decodificador 202 passaram pelo tipo específico de processamento de sonoridade, e os bits de controle do vali- dador 203 indicam que os LPSM são válidos); ouos bits de controle indicando que os dados de áudio decodificado emitido do decodificador 202 devem passar por um tipo especí- fico de processamento de sonoridade (por exemplo, quando os LPSM indicam que os dados de áudio emitido do decodificador 202 não passaram pelo tipo específico de processamento de sonoridade, ou quando os LPSM indicam que os dados de áudio emitido do decodificador 202 passaram pelo tipo específico de processamento de sonoridade, mas os bits de controle do validador 203 indicam que os LPSM não são válidos).

[00121] De modo alternativo, o decodificador 200 impõe os metadados extraídos pelo decodificador 202 do fluxo de bits contínuo de entrada, e os LPSM (e opcionalmente outros metadados de limite de programa) extraídos pelo interpretador 205 do fluxo de bits contínuo de entrada ao pós-processador 300, e o pós-processador 300 realiza o processamento de sonoridade nos dados de áudio decodificado utilizando os LPSM (e opcionalmente ainda os metadados de limite de programa), ou realiza a validação dos LPSM e então realiza o processamento de sonoridade nos dados de áudio decodificado utilizando os LPSM (e opcionalmente outros metadados de limite de programa) se a validação indicar que os LPSM são válidos.

[00122] Em algumas modalidades, se o decodificador 200 receber um fluxo de bits contínuo de áudio gerado de acordo com uma modalidade da invenção com hash criptográfico, o decodificador é configurado para analisar e recuperar o hash criptográfico de um bloco de dados determinado do fluxo de bits contínuo, o dito bloco que compreende metadados do estado do processamento de sonoridade (LPSM). O validador 203 pode usar o hash criptográfico para validar o fluxo de bits contínuo recebido e/ou metadados associados. Por exemplo, se o validador 203 acha que os LPSM são válidos com base em uma correspondência entre um hash criptográfico de referência e o hash criptográfico recuperado do bloco de dados, então ele pode sinalizar a uma unidade de processamento de áudio a jusante (por exemplo, pós- processador 300, que pode ser ou incluir uma unidade de nivelamento do volume) para passar (de forma não alternada) pelos dados de áudio do fluxo de bits contínuo. Adicionalmente, opcionalmente, ou de modo alternativo, outros tipos de técnicas criptográficas podem ser utilizados no lugar de um método com base em um hash criptográfico.

[00123] Em algumas implementações do decodificador 200, o fluxo de bits contínuo codificado recebido (e colocado na memória buffer 201) é um fluxo de bits contínuo AC-3 ou um fluxo de bits contínuo E- AC-3, e compreende segmentos de dados de áudio (por exemplo, os segmentos de AB0-AB5 do quadro mostrado na figura 4) e segmentos de metadados, onde os segmentos de dados de áudio são indicativos dos dados de áudio, e cada um de pelo menos alguns dos segmentos de metadados inclui metadados do estado do processamento de sonoridade (LPSM) e opcionalmente outros metadados de limite de programa. O estágio do decodificador 202 (e/ou interpretador 205) é configurado para extrair do fluxo de bits contínuo LPSM (e opcionalmente outros metadados de limite de programa) tendo o seguinte formato. Cada um dos segmentos de metadados que inclui LPSM (e opcionalmente outros metadados de limite de programa) é incluído em um segmento da perda de bit de um quadro do fluxo de bits contínuo, ou um campo "addbsi" do segmento da Informação do Fluxo de Bits Contínuo ("BSI") de um quadro do fluxo de bits contínuo, ou em um campo de dados auxiliares (por exemplo, o segmento AUX mostrado na figura 4) no final de um quadro do fluxo de bits contínuo. Um quadro do fluxo de bits contínuo pode incluir um ou dois segmentos de metadados, cada um podendo incluir LPSM, e se o quadro inclui dois segmentos de metadados, um pode estar presente no campo addbsi do quadro e o outro no campo AUX do quadro. Em algumas modalidades, cada seg-mento dos metadados incluindo LPSM inclui um segmento da carga útil de LPSM (ou recipiente) tendo o seguinte formato: um cabeçalho (tipicamente incluindo uma palavra de sincronização identificando o começo da carga útil de LPSM, seguido pelos valores de identificação, por exemplo, a versão, comprimento, período, contagem do formato LPSM, e valores da associação do subflu- xo indicados na Tabela 2 abaixo); eapós o cabeçalho,pelo menos um valor de indicação do diálogo (por exemplo, parâmetro "Dialog channel(s)" da Tabela 2) indicando se os dados de áudio correspondentes indicam diálogo ou não indicam diálogo (por exemplo, quais canais de dados de áudio correspondentes indicam diálogo);pelo menos um valor de conformidade de regulação de sonoridade (por exemplo, parâmetro "Loudness Regulation Type" da Tabela 2) indicando se os dados de áudio correspondentes estão conformes com as regulagens do conjunto de sonoridade;pelo menos um valor do processamento de sonoridade (por exemplo, um ou mais dos parâmetros "Dialog gated Loudness Correction indicator", "Loudness Correction Type," da Tabela 2) indicando pelo menos um tipo de processamento de sonoridade que foi realizado nos dados de áudio correspondentes; epelo menos um valor de sonoridade (por exemplo, um ou mais dos parâmetros "ITU Relative Gated Loudness," "ITU Speech Gated Loudness," "ITU (EBU 3341) Short-term 3s Loudness," e "True Peak" da Tabela 2) indicando pelo menos uma característica do sonoridade (por exemplo, sonoridade máximo ou médio) dos dados de áudio correspondentes.

[00124] Em algumas modalidades, cada segmento dos metadados que contém LPSM e metadados de limite de programa contém um cabeçalho central (e opcionalmente outros elementos centrais adicionais), e após o cabeçalho central (ou o cabeçalho central e outros elementos centrais) um segmento de carga útil de LPSM (ou recipiente) tendo o seguinte formato:um cabeçalho, tipicamente incluindo pelo menos um valor de identificação (por exemplo, versão, comprimento, período, contagem do formato LPSM, e valores da associação do subfluxo, conforme indicado na Tabela 2 abaixo), eapós o cabeçalho, o LPSM e os metadados de limite de programa. Os metadados de limite de programa podem incluir uma contagem de quadro limite de programa, e um valor de código (por exemplo, um valor "offset_exist") indicativo de se o quadro inclui apenas uma contagem de quadro de limite de programa ou tanto uma contagem de limite de quadro de programa quanto um valor de compensação, e (em alguns casos) um valor de compensação.

[00125] Em algumas implementações, o interpretador 205 (e/ou estágio do decodificador 202) é configurado para extrair, de um segmento da perda de bit, ou um campo "addbsi", ou um campo de dados auxiliares, de um quadro do fluxo de bits contínuo, cada segmento dos metadados tendo o seguinte formato:um cabeçalho central (tipicamente incluindo uma palavra de sincronização identificando o começo do segmento dos metadados, seguido por pelo menos um valor de identificação, por exemplo, a versão, comprimento e período do elemento central, contagem do elemento estendido, e valores da associação do subfluxo indicados na Tabela 1 abaixo); eapós o cabeçalho central, pelo menos um valor de proteção (por exemplo, a conversão de HMAC e valores de Audio Fingerprint da Tabela 1) úteis para pelo menos um de decriptação, autenticação, ou validação de pelo menos um dos metadados do estado do processamento de sonoridade ou dos dados de áudio correspondentes; eainda após o cabeçalho central, se os segmentos dos me tadados incluem LPSM, identificação da carga útil de LPSM ("ID") e valores do tamanho da carga útil de LPSM que identificam os seguintes metadados como uma carga útil de LPSM e indicam o tamanho da carga útil de LPSM.

[00126] O segmento da carga útil (ou recipiente) de LPSM (preferivelmente tendo o formato especificado acima) segue a ID da carga útil de LPSM e valores do tamanho da carga útil de LPSM.

[00127] De forma mais geral, o fluxo de bits contínuo de áudio codificado gerado pelas modalidades preferidas da invenção tem uma estrutura que fornece um mecanismo para identificar os elementos dos metadados e sub-elementos como centrais (obrigatórios) ou expandidos (elementos opcionais). Isso permite que a taxa de dados do fluxo de bits contínuo (incluindo seus metadados) escale pelas várias aplicações. Os elementos centrais (obrigatórios) da sintaxe preferida do fluxo de bits contínuo ainda devem ser capazes de sinalizar que os elementos expandidos (opcionais) associados com o conteúdo de áudio estão presentes (na banda) e/ou em uma localização remota (fora da banda).

[00128] Os elementos centrais são necessários para estar presentes em cada quadro do fluxo de bits contínuo. Alguns sub-elementos dos elementos centrais são opcionais e podem estar presentes em qualquer combinação. Elementos expandidos não necessitam estar presentes em cada quadro (para limitar a suspensão da taxa de bit). Assim, os elementos expandidos podem estar presentes em alguns quadros e não em outros. Alguns sub-elementos de um elemento expandido são opcionais e podem estar presentes em qualquer combi-nação, na qual alguns sub-elementos de um elemento expandido podem ser obrigatórios (ou seja, se o elemento expandido está presente em um quadro do fluxo de bits contínuo).

[00129] Em uma classe de modalidades, um fluxo de bits contínuo de áudio codificado que compreende uma sequência de segmentos de dados de áudio e segmentos de metadados é gerado (por exemplo, por uma unidade de processamento de áudio que incorpora a invenção). Os segmentos de dados de áudio são indicativos de dados de áudio, cada um de pelo menos alguns dos segmentos de metadados inclui metadados do estado do processamento de sonoridade (LPSM) e opcionalmente outros metadados de limite de programa, e os segmentos de dados de áudio são multiplexados pela divisão de tempo com os segmentos de metadados. Nas modalidades preferidas nesta classe, cada um dos segmentos de metadados tem um formato preferido a ser descrito neste documento.

[00130] Em um formato preferido, o fluxo de bits contínuo codificado é um fluxo de bits contínuo AC-3 ou um fluxo de bits contínuo E-AC-3, e cada um dos segmentos de metadados que inclui LPSM é incluído (por exemplo, pelo estágio 107 de uma implementação preferida do codificador 100) como informação do fluxo de bit adicional no campo "addbsi" (mostrado na figura 6) do segmento da Informação do Fluxo de Bits Contínuo ("BSI") de um quadro do fluxo de bits contínuo, ou em um campo de dados auxiliares de um quadro do fluxo de bits contínuo, ou em um segmento da perda de bit de um quadro do fluxo de bits contínuo.

[00131] No formato preferido, cada um dos quadros inclui um elemento central tendo o formato mostrado na Tabela 1 abaixo, no campo addbsi (ou segmento da perda de bit) do quadro:

[00132] No formato preferido, cada um dos campos addbsi (ou aux- data) ou segmento da perda de bits que contém LPSM contém um cabeçalho central (e opcionalmente outros elementos centrais adicionais), e após o cabeçalho central (ou o cabeçalho central e outros elementos centrais), os seguintes valores de LPSM (parâmetros):um ID da carga útil (identificando os metadados como LPSM) seguindo os valores do elemento central (por exemplo, conforme especificado na Tabela 1);um tamanho da carga útil (indicando o tamanho da carga útil de LPSM) seguindo o ID da carga útil; edados de LPSM (seguindo o ID da carga útil e valor do ta-manho da carga útil) tendo o formato conforme indicado na seguinte tabela (Tabela 2):

[00133] Em outro formato preferido de um fluxo de bits contínuo co-dificado gerado de acordo com a invenção, o fluxo de bits contínuo é um fluxo de bits contínuo AC-3 ou um fluxo de bits contínuo E-AC-3, e cada um dos segmentos de metadados que inclui LPSM (e opcionalmente ainda metadados de limite do programa) é incluído (por exemplo, pelo estágio 107 de uma implementação preferida do codificador 100) em quaisquer dos: um segmento de perda de bit de um quadro do fluxo de bits contínuo; ou um campo "addbsi" (mostrado na Figura 6) do segmento de informações do fluxo de bits contínuo ("BSI") de um quadro do fluxo de bits contínuo; ou um campo de dados auxiliares (por exemplo, o segmento AUX mostrado na Figura 4) no final de um quadro do fluxo de bits contínuo. Um quadro pode incluir um ou dois segmentos de metadados, cada um dos quais inclui os LPSM, e se o quadro inclui dois segmentos de metadados, um pode estar presente no campo "addbsi" do quadro e o outro no campo AUX do quadro. Cada um dos segmentos de metadados incluindo os LPSM tem o formato especificado acima com relação às Tabelas 1 e 2 acima (ou seja, inclui os elementos centrais especificados na Tabela 1, seguido pela ID da carga útil (identificando os metadados as LPSM) e os valores do tamanho da carga útil especificados acima, seguido pela carga útil (os dados dos LPSM que tem o formato conforme indicado na Tabela 2).

[00134] Em outro formato preferido, o fluxo de bits contínuo codifi-cado é um fluxo de bits contínuo Dolby E, e cada um dos segmentos de metadados que inclui os LPSM (e opcionalmente ainda metadados de limite do programa) é a primeira localização da amostra N do intervalo da banda de guarda Dolby E. Um fluxo de bits contínuo Dolby E incluindo tais segmentos de metadados que inclui os LPSM preferivelmente inclui um valor indicativo do comprimento da carga útil dos LPSM assinalados na palavra Pd do preâmbulo SMPTE 337M (a taxa de repetição da palavra Pa do SMPTE 337M preferivelmente permanece idêntica à taxa do quadro de vídeo associado).

[00135] Em um formato preferido, em que o fluxo de bits contínuo codificado é um fluxo de bits contínuo E-AC-3, cada um dos segmentos de metadados que inclui LPSM (e opcionalmente ainda metadados de limite do programa) é incluído (por exemplo, pelo estágio 107 de uma implementação preferida de codificador 100) conforme as informações adicionais do fluxo de bits contínuo em um segmento de perda de bit, ou no campo "addbsi" do segmento de informações do fluxo de bits contínuo ("BSI"), de um quadro do fluxo de bits contínuo. Nós descrevemos a seguir aspectos adicionais da codificação de um fluxo de bits contínuo E-AC-3 com LPSM no formato preferido:1. Durante a geração de um fluxo de bits contínuo E-AC-3, enquanto o codificador E-AC-3 (que insere os valores dos LPSM no fluxo de bits contínuo) está "ativo," para todos os quadros ("syncfra-me") gerados, o fluxo de bits contínuo deve incluir um bloco de metadados (incluindo LPSM) carregado no campo "addbsi" (ou segmento de perda de bit) do quadro. Os bits exigidos para carregar o bloco de metadados não deve aumentar a taxa de bits do codificador (comprimento do quadro);2. Cada bloco de metadados (contendo LPSM) deve conter as seguintes informações: loudness_correction_type_flag: onde ‘1’ indica que a sono-ridade dos dados de áudio correspondentes foi corrigida a jusante a partir do codificador, e '0' indica que a sonoridade foi corrigida por um corretor de sonoridade incorporado no codificador (por exemplo, processador de sonoridade 103 do codificador 100 da Figura 2);speech_channel: indica que o(s) canal(is) de fonte contém discurso (sobre o 0,5 segundo anterior). Se nenhum discurso for de-tectado, isso deve ser indicado como tal;speech_loudness: indica a sonoridade de discurso integrado de cada canal de áudio correspondente que contém discurso (sobre o 0,5 segundo anterior);ITU_loudness: indica a sonoridade ITU BS.1770-3 integra-da de cada canal de áudio correspondente; egain: ganho(s) composto de sonoridade para inversão em um decodificador (para demonstrar reversibilidade);3. Enquanto o codificador E-AC-3 (que insere os valores dos LPSM no fluxo de bits contínuo) estiver "ativo" e estiver recebendo um quadro AC-3 com um indicador de "confiança", o controlador de sonoridade no codificador (por exemplo, processador de sonoridade 103 do codificador 100 da Figura 2) deve ser contornado. Os valores de DRC e "dialnorm" de fonte confiada devem ser atravessados (por exemplo, pelo gerador 106 de codificador 100) ao componente do codificador E-AC-3 (por exemplo, estágio 107 do codificador 100). A geração do bloco de LPSM continua e o "loudness_correction_type_flag" é estabelecido a ‘1’. A sequência bypass do controlador da sonoridade deve ser sincronizada no começo do quadro decodificado AC-3 onde o indicador de "confiança" aparece. A sequência bypass do controlador de sonoridade deve ser implementada como se segue: o controle "le- veler_amount" é decrescido a partir de um valor de 9 até um valor de 0 acima de períodos de bloco de áudio 10 (ou seja, 53,3 milissegundos) e o controle "leveler_back_end_meter" é colocado no modo bypass (essa operação deve resultar em uma transição contínua). O termo bypass "confiado" do nivelador implica que o valor do "dialnorm" do fluxo de bits contínuo da fonte é ainda reutilizado na saída do codificador, (por exemplo, se o fluxo de bits contínuo da fonte "confiada" tem um valor de "dialnorm" de -30 então a saída do codificador deve utilizar -30 para o valor do "dialnorm" de saída);

[00136] Enquanto o codificador E-AC-3 (que insere os valores de LPSM no fluxo de bits contínuo) estiver "ativo" e estiver recebendo um quadro AC-3 sem o indicador de "confiança", o controlador de incorporado ao codificador (por exemplo, processador de sonoridade 103 do codificador 100 da Figura 2) deve estar ativo. A geração do bloco de LPSM continua e o "loudness_correction_type_flag" é estabelecido a 'O'. A sequência de ativação do controlador de sonoridade deve estar sincronizada ao começo do quadro decodificado AC-3 onde o indicador de "confiança" desaparece. A sequência de ativação do controlador de sonoridade deve ser implementada como se segue: o controle "leveler_amount" é incrementado a partir do valor de 0 a um valor de 9 acima do período de bloco de áudio 1, (ou seja, 5,3 milissegundos) e o controle "leveler_back_end_meter" é colocado no modo "ativo" (essa operação deve resultar em uma transição contínua e inclui uma reini- cialização de integração "back_end_meter"); e durante a codificação, uma interface do usuário de gráfico (GUI) deve indicar a um usuário os seguintes parâmetros: "Programa de áudio de entrada:

[00137] [Confiado/Não Confiado]" - o estado desse parâmetro é baseado na presença do indicador de "confiança" dentro do sinal de entrada; e "Correção de Sonoridade em Tempo Real: [Ati- va/Desativada]" - o estado desse parâmetro é baseado em se esse controlador de sonoridade incorporado no codificador está ativo.

[00138] Quando decodificando um AC-3 ou fluxo de bits contínuo E- AC-3 que tem LPSM (no formato preferido) incluídos em um segmento de perda de bit, ou o campo "addbsi" do segmento de informação do fluxo de bits contínuo ("BSI"), de cada quadro do fluxo de bits contínuo, o decodificador deve analisar os dados de bloco dos LPSM (no segmento de perda de bit ou no campo "addbsi") e passar todos os valores de LPSM extraídos para uma interface do usuário de gráfico (GUI). O conjunto de valores de LPSM extraídos é atualizado a cada quadro.

[00139] Em outro formato preferido de um fluxo de bits contínuo codificado gerado de acordo com a invenção, o fluxo de bits contínuo codificado é um fluxo de bits contínuo AC-3 ou um fluxo de bits contínuo E-AC-3, e cada um dos segmentos de metadados que inclui os LPSM é incluído (por exemplo, pelo estágio 107 de uma implementação preferida de codificador 100) em um segmento de perda de bit, ou em um segmento auxiliar, ou como informações de fluxo de bits adicionais no campo "addbsi" (mostrado na Figura 6) do segmento de informações do fluxo de bits contínuo ("BSI"), de um quadro do fluxo de bits contínuo. Nesse formato (que é uma variação sobre o formato descrito acima com relação às Tabelas 1 e 2), cada um dos campos "addbsi" (ou auxiliar ou de perda de bit) que contém LPSM contém os seguintes valores de LPSM:os elementos centrais especificados na Tabela 1, seguidos pela ID da carga útil (identificando os metadados como LPSM) e os valores de tamanho da carga útil, seguidos pela carga útil (dados de LPSM) que tem o seguinte formato (similar aos elementos obrigatórios indicados na Tabela 2 acima):versão da carga útil dos LPSM: um campo de 2-bits que in-dica a versão da carga útil dos LPSM;"dialchan": um campo de 3-bits que indica se os canais es-querdo, direto e/ou central de dados de áudio correspondentes contêm diálogo falado. A alocação de bits do campo dialchan pode ser como se segue: bit 0, que indica a presença de diálogo no canal esquerdo, é armazenado no bit mais significante do campo "dialchan"; e bit 2, que indica a presença de diálogo no canal central, é armazenado no bit menos significante do campo "dialchan". Cada bit do campo dialchan é estabelecido a ‘1’ se o canal correspondente contém diálogo falado durante o 0,5 segundo precedente do programa; "loudregtyp": um campo de 4-bits que indica com qual padrão de regulagem de sonoridade a sonoridade do programa está em conformidade. Estabelecendo o campo "loudregtyp" a "000" indica que os LPSM não indicam conformidade de regulagem de sonoridade. Por exemplo, um valor desse campo (por exemplo, 0000) pode indicar que a conformidade com um padrão de regulagem de sonoridade não é indicada, outro valor desse campo (por exemplo, 0001) pode indicar que os dados de áudio do programa estão em conformidade com o padrão de ATSC A/85, e ou-tro valor desse campo (por exemplo, 0010) pode indicar que os dados de áudio do programa estão em conformidade com o padrão de EBU R128. No exemplo, se o campo é estabelecido para qualquer valor que não "OOO", os campos "loudcorrdialgat" e "loudcorrtyp" devem seguir na carga útil;"loudcorrdialgat": um campo de 1-bit que indica se uma correção de sonoridade de diálogo fechado foi aplicada. Se a sonoridade do programa foi corrigida utilizando fechamento de diálogo, o valor do campo "loudcorrdialgat" é estabelecido a ‘1’. Caso contrário ele é estabelecido a "0";"loudcorrtyp": um campo de 1-bit que indica o tipo de correção de sonoridade aplicada ao programa. Se a sonoridade do programa foi corrigida com um processo de correção de sonoridade de antecipação infinita (baseado em arquivo), o valor do campo "loudcorrtyp" é estabelecido a "0". Se a sonoridade do programa foi corrigida utilizando uma combinação de medição da sonoridade em tempo real e um controle de variação dinâmico, o valor desse campo é estabelecido a ‘1’; "loudrelgate": um campo de 1-bit que indica se dados da sonoridade (ITU) fechados relativos existem. Se o campo "loudrelgate" é estabelecido a ‘1’, um campo "ituloudrelgat" de 7-bits deve seguir na carga útil;"loudrelgat": um campo de 7-bit que indica sonoridade do programa (ITU) fechado relativo. Esse campo indica a sonoridade in-tegrada do programa de áudio, medida de acordo com o ITU-R BS.1770-3 sem quaisquer ajustes de ganho devido ao "dialnorm" e a compressão de faixa dinâmica sendo aplicada. Os valores de 0 a 127 são interpretados como -58L FS a +5,5L FS, nas etapas 0,5 LKFS;"loudspchgate": um campo de 1-bit que indica se dados da sonoridade (ITU) de discurso fechado existem. Se o campo "loudspchgate" é estabelecido a ’1’, um campo "loudspchgat" de 7-bits deve seguir na carga útil;"loudspchgat": um campo de 7-bits que indica sonoridade de discurso fechado do programa. Esse campo indica a sonoridade integrada do programa de áudio inteiro correspondente, medido de acordo com a fórmula (2) de ITU-R BS.1770-3 e sem quaisquer ajus-tes de ganho devido ao "dialnorm" e à compressão de faixa dinâmica sendo aplicada. Os valores de 0 a 127 são interpretados como -58 a +5.5 LKFS, nas etapas 0,5 LKFS;"loudstrm3se": um campo de 1-bit que indica se dados da sonoridade a curto-prazo (3 segundos) existem. Se o campo é estabelecido a ‘1’, um campo "loudstrm3s" de 7-bit deve seguir na carga útil;

[00140] "loudstrm3s": um campo de 7-bits que indica a sonoridade não fechado dos 3 segundos precedentes do programa de áudio correspondente, medido de acordo com ITU-R BS.1771-1 e sem quaisquer ajustes de ganho devido ao "dialnorm" e à compressão de faixa dinâmica sendo aplicada. Os valores de 0 a 256 são interpretados co- mo -116 LKFS a +11.5 LKFS nas etapas 0,5 LKFS;"truepke": um campo de 1-bit que indica se os dados da sonoridade máxima verdadeira existem. Se o campo "truepke" é estabelecido a ‘1’, um campo "truepk" 8-bit deve seguir na carga útil; e"truepk": um campo de 8-bits que indica o valor de amostra máximo verdadeiro do programa, medido de acordo com o Anexo 2 de ITU-R BS.1770-3 e sem quaisquer ajustes de ganho devido ao "dialnorm" e à compressão de faixa dinâmica sendo aplicada. Os valores de 0 a 256 são interpretados como -116 L FS a +11,5 L FS nas etapas 0,5 LKFS.

[00141] Em algumas modalidades, o elemento central de um seg-mento de metadados em um segmento de perda de bit ou em um campo de dados auxiliares (ou "addbsi") de um quadro de um fluxo de bits contínuo AC-3 ou de um fluxo de bits contínuo E-AC-3 compreende um cabeçalho central (tipicamente incluindo valores de identificação, por exemplo, versão de elemento central), e depois do cabeçalho central: valores indicativos de se dados do "fingerprint" (ou outros valores de proteção) estão incluídos para os metadados do segmento de metadados, valores indicativos de se dados externos (relacionados aos dados de áudio correspondentes aos metadados do segmento de metadados) existem, a ID da carga útil e os valores de tamanho da carga útil para cada tipo de metadados (por exemplo, LPSM, e/ou metadados de outro tipo que não LPSM) identificado pelo elemento central, e valores de proteção para pelo menos um tipo de metadados identificado pelo elemento central. A(s) carga(s) útil(úteis) de metadados do segmento de metadados segue o cabeçalho central, e é (em alguns casos) agrupada dentro dos valores do elemento central.

[00142] Modalidades típicas da invenção incluem metadados de limite do programa em um fluxo de bits contínuo de áudio codificado em uma forma eficiente que segue determinação precisa e sólida de pelo menos um limite entre programas de áudio consecutivos indicados pelo fluxo de bits contínuo. As modalidades típicas permitem determinação precisa e sólida de um limite do programa no sentido que elas permitem determinação precisa do limite do programa mesmo em casos em que os fluxos de dados contínuos indicativos de diferentes programas são ligados juntos (para gerar o fluxo de bits contínuo inventivo) de uma maneira que trunca um ou ambos os fluxos de dados contínuos ligados (e, assim, descarta metadados de limite do programa que tenham sido incluídos em pelo menos um dos fluxos de dados contínuos pré-ligados).

[00143] Nas modalidades típicas, os metadados de limite do pro-grama em um quadro do fluxo de bits contínuo inventivo são indicadores do limite do programa indicativo de uma conta do quadro. Tipicamente, o indicador é indicativo do número de quadros entre o quadro atual (o quadro que inclui o indicador) e um limite do programa (o começo ou o fim do programa de áudio atual). Em algumas modalidades preferidas, indicadores do limite do programa são inseridos de uma maneira simétrica e eficiente no começo e no final de cada segmento do fluxo de bits contínuo que é indicativo de um programa único (ou seja, em quadros ocorrendo dentro de algum número predeterminado de quadros após o começo do segmento, e em quadros ocorrendo dentro de algum número predeterminado de quadros antes do final do segmento), de modo que quando dois desses segmentos do fluxo de bits contínuo são concatenados (como para serem indicativos de uma sequência de dois programas), os metadados de limite do programa podem estar presentes (por exemplo, simetricamente) sobre ambos os lados do limite entre os dois programas.

[00144] A robustez máxima pode ser alcançada inserindo um indi-cador do limite do programa em todos os quadros de um fluxo de bits contínuo indicativo de um programa, mas isso não seria tipicamente prático devido ao aumento associado na taxa de dados. Em modalidades típicas, indicadores do limite do programa são inseridos em somente um subconjunto dos quadros de um fluxo de bits de áudio codificado contínuo (que pode ser indicativo de um programa de áudio ou uma sequência de programas de áudio), e a taxa de inserção do indicador de limite é uma função de não aumento da separação crescente de cada um dos quadros dos fluxos de dados contínuos (em que um indicador é inserido) a partir do limite do programa que está mais próximo a cada um dos ditos quadros, onde a "taxa de inserção do indicador de limite" indica a razão média do número de quadros (indicativo de um programa) que inclui um indicador do limite do programa ao número de quadros (indicativo do programa) que não inclui um indicador do limite do programa, onde a média é uma média corrida sobre um número (por exemplo, número relativamente pequeno) de quadros consecutivos do fluxo de bits de áudio codificado contínuo.

[00145] Aumentar a taxa de inserção do indicador de limite (por exemplo, em locais no fluxo de bits contínuo mais próximo ao limite do programa) aumenta a taxa de dados exigida para entregar o fluxo de bits contínuo. Para compensar isso, o tamanho (número de bits) de cada indicador inserido é preferivelmente diminuído conforme a taxa de inserção do indicador de limite é aumentada (por exemplo, de modo que o tamanho do indicador de limite do programa no quadro "N" do fluxo de bits contínuo, onde N é um número inteiro, seja uma função de não aumento de distância (número de quadros) entre o quadro "N" e o limite do programa mais próximo). Em uma classe de modalidades, a taxa de inserção do indicador de limite é uma função decrescente algoritmicamente de distância crescente (de cada local de inserção do indicador) a partir do limite do programa mais próximo, e para cada quadro contendo indicadores que inclui um dos indicadores, o tamanho do indicador no dito quadro contendo indicadores é igual ou maior que o tamanho de cada indicador em um quadro localizado o mais próximo do limite do programa mais próximo do que está o dito quadro contendo indicadores. Tipicamente, o tamanho de cada indicador é determinado por uma função crescente do número de quadros do local de inserção do indicador ao limite do programa mais próximo.

[00146] Por exemplo, considere a modalidade das Figuras 8 e 9, em que cada coluna identificada por um número de quadro (na fileira superior) indica um quadro de um fluxo de bits contínuo de áudio codificado. O fluxo de bits contínuo é indicativo de um programa de áudio tendo um primeiro limite do programa (indicativo do começo do programa) que ocorre imediatamente à esquerda da coluna identificada pelo quadro número "17" na lateral esquerda da Figura 9, e um segundo limite do programa (indicativo do sinal do programa) que ocorre imediatamente à esquerda da coluna identificada pelo quadro número "1" na lateral direita da Figura 8. Os indicadores do limite do programa incluídos nos quadros mostrados na Figura 8 fazem contagem regressiva do número de quadros entre o quadro atual e o segundo limite do programa. Os indicadores do limite do programa incluídos nos quadros mostrados na Figura 9 contam o número de quadros entre o quadro atual e o primeiro limite do programa.

[00147] Na modalidade das Figuras 8 e 9, um indicador do limite do programa é inserido somente em cada um dos quadros "2N" dos pri-meiros X quadros do fluxo de bits contínuo codificado depois do começo do programa de áudio indicado pelo fluxo de bits contínuo, e em cada um dos quadros "2N" (dos últimos X quadros do fluxo de bits contínuo) mais próximo ao final do programa indicado pelo fluxo de bits contínuo, onde o programa compreende Y quadros, X é um número inteiro menor ou igual a Y/2, e N é um número inteiro positivo em uma variação de 1 a log2(X). Assim (conforme indicado nas Figuras 8 e 9), um indicador do limite do programa é inserido no segundo quadro (N = 1) do fluxo de bits contínuo (o quadro mais próximo do começo do programa contendo indicadores), no quarto quadro (N = 2), no oitavo quadro (N = 3), e assim por diante, e no oitavo quadro a partir do final do fluxo de bits contínuo, no quarto quadro a partir do final do fluxo de bits contínuo, e no segundo quadro a partir do final do fluxo de bits contínuo (o quadro mais próximo do final do programa contendo indicadores). Nesse exemplo, o indicador do limite do programa no quadro "2N" a partir do começo (ou final) do programa compreende bits binários de log2(2N+2), conforme indicado nas Figuras 8 e 9. Assim, o indicador do limite do programa limite no segundo quadro (N = 1) a partir do começo (ou final) do programa compreende bits binários de log2(2N+2) = log2(23) = 3, e o indicador no quarto quadro (N = 2) a partir do começo (ou final) do programa compreende bits binários de log2(2N+2) = log2(24) = 4, e assim por diante.

[00148] No exemplo das Figuras 8 e 9, o formato de cada indicador do limite do programa é como se segue. Cada indicador do limite do programa consiste de um bit "1" de condução, uma sequência de "0" bits ("0" bit ou um ou mais "0" bits consecutivos) depois do bit de condução, um código de carregamento de 2-bits. O código de carregamento é "11" para os indicadores nos últimos X quadros do fluxo de bits contínuo (os quadros mais próximos ao final do programa), conforme indicado na Figura 8. O código de carregamento é "10" para os indicadores nos primeiros X quadros do fluxo de bits contínuo (os quadros mais próximos ao começo do programa), conforme indicado na Figura 9. Assim, para ler (decodificar) cada indicador, o número de zeros entre o bit "1" de condução e o código de carregamento é contado. Se o código de carregamento é identificado para ser "11", o indicador indica que já (2Z+1-1) quadros entre o quadro atual (o quadro que inclui o indicador) e o final do programa, onde Z é o número de zeros entre o bit "1" bit e o código de carregamento do indicador. O decodifi- cador pode ser eficientemente implementado para ignorar o primeiro e o último bit de cada indicador, para determinar o inverso da sequência dos bits (intermediários) do outro indicador (por exemplo, se a sequência de bits intermediários é "0001" com o bit "1" sendo o último bit na sequência, a sequência invertida de bits intermediários é "1000" com o bit "1" sendo o primeiro bit na sequência invertida), e para identificar o valor binário da sequência invertida de bits intermediários como o índice do quadro atual (o quadro em que o indicador é incluído) em relação ao final do programa. Por exemplo, se a sequência invertida de bits intermediários é "1000", essa sequência invertida tem um valor binário de 24 = 16, e o quadro é identificado como o 16° quadro antes do final do programa (conforme indicado na coluna da Figura 8 que descreve o quadro "0").

[00149] Se o código de carregamento é identificado para ser "10", o indicador indica que há (2Z+1-1) quadros entre o começo do programa e o quadro atual (o quadro que inclui o indicador), onde Z é o número de zeros entre o bit "1" e o código de carregamento do indicador. O decodificador pode ser implementado eficientemente para ignorar o primeiro e o último bit de cada indicador, para determinar o inverso da sequência dos bits intermediários do indicador (por exemplo, se a sequência de bits intermediários é "0001" com o bit "1" sendo o último bit na sequência, a sequência invertida de bits intermediários é "1000" com o bit "1" sendo o primeiro bit na sequência invertida), e para identificar o valor binário da sequência invertida de bits intermediários como o índice do quadro atual (o quadro em que o indicador é incluído) em relação ao começo do programa. Por exemplo, se a sequência de bits intermediários é "1000", essa sequência invertida tem um valor binário de 24 = 16, e o quadro é identificado como o 16° quadro depois do começo do programa (conforme indicado na coluna da Figura 9 que descreve o quadro "32").

[00150] No exemplo das Figuras 8 e 9, um indicador do limite do programa está presente somente em cada um dos quadros "2N" dos primeiros X quadros de um fluxo de bits contínuo codificado depois do começo de um programa de áudio indicado pelo fluxo de bits contínuo, e em cada um dos quadros "2N" (dos últimos X quadros do fluxo de bits contínuo) mais próximos do programa indicado pelo fluxo de bits contínuo, onde o programa compreende Y quadros, X é um número inteiro menor ou igual a Y/2, e N é um número inteiro positivo em uma variação de 1 a log2(X). A inclusão dos indicadores do limite do programa adiciona somente uma taxa de bits média de 1,875 bits/quadro para a taxa de bits exigida para transmitir o fluxo de bits contínuo sem os indicadores.

[00151] Em uma implementação típica da modalidade de Figuras 8 e 9 em que o fluxo de bits contínuo é um fluxo de bits de áudio codifi-cado contínuo AC-3, cada quadro contém conteúdo de áudio e metadados para 1536 amostras de áudio digital. Para uma taxa de amostragem de 48 kHz, isso representa 32 milissegundos de áudio digital ou uma taxa de 31,25 quadros por segundo de áudio. Assim, em tal modalidade, um indicador do limite do programa em um quadro separado por algum número de quadros ("X" quadros) a partir de um limite do programa indica que o limite ocorre 32X milissegundos depois do começo do quadro contendo indicadores (ou 32X milissegundos antes do começo do quadro contendo indicador).

[00152] Em uma implementação típica da modalidade das Figuras 8 e 9 em que o fluxo de bits contínuo é um fluxo de bits de áudio codificado contínuo E-AC-3, cada quadro do fluxo de bits contínuo contém conteúdo de áudio e metadados para 256, 512, 768 ou 1536 amostras de áudio digital, dependendo de se o quadro contém um, dois, três ou seis blocos de dados de áudio respectivamente. Para uma taxa de amostragem de 48 kHz, isso representa 5,333, 10,667, 16 ou 32 milis- segundos de áudio digital respectivamente ou uma variação de 189,9, 93,75, 62,5 ou 31,25 quadros por segundo de áudio respectivamente. Assim, em tal modalidade (assumindo que cada quadro é indicativo de 32 milissegundos de áudio digital), um indicador do limite do programa em um quadro separado por algum número de quadros ("X" quadros) a partir de um limite do programa indica que o limite ocorre 32X milisse- gundos após o final do quadro contendo indicadores (ou 32X milisse- gundos antes do começo do quadro contendo indicadores).

[00153] Em algumas modalidades em que um limite do programa pode ocorrer dentro de um quadro de um fluxo de bits de áudio contínuo (ou seja, não em alinhamento com o começo ou final de um quadro), os metadados de limite do programa incluídos em um quadro do fluxo de bits contínuo incluem uma conta do quadro do limite do programa (ou seja, metadados indicativos do número de quadros cheios entre o começo ou o final do quadro contendo conta do quadro e um limite do programa) e um valor compensado. O valor compensado é indicativo de uma compensação (tipicamente um número de amostras) entre o começo ou final de um quadro contendo limite do programa, e a localização real do limite do programa dentro do quadro contendo limite do programa.

[00154] Um fluxo de bits contínuo de áudio codificado pode ser indi-cativo de uma sequência de programas (trilha sonora) de uma se-quência de programas de vídeo correspondente, e limites de tais programas de áudio tendem a ocorrer nas bordas de quadros de vídeo ao invés de bordas de quadros de áudio. Também, alguns codificadores- decodificadores de áudio (por exemplo, codificadores-decodificadores E-AC-3) utilizam tamanhos de quadro de áudio que não estão alinhados aos quadros de vídeo. Também, em alguns casos, um fluxo de bits de áudio contínuo codificado inicialmente passa por transcodifica- ção para gerar um fluxo de bits contínuo transcodificado, e o fluxo de bits contínuo codificado inicialmente tem um tamanho de quadro diferente do fluxo de bits contínuo transcodificado de modo que um limite do programa (determinado pelo fluxo de bits contínuo codificado inicialmente) não é garantido de ocorrer em um limite de quadro do fluxo de bits contínuo transcodificado. Por exemplo, se o fluxo de bits codificado inicialmente contínuo (por exemplo, fluxo de bits contínuo "IEB" da Figura 10) tem um tamanho de quadro de 1536 amostras por quadro, e o fluxo de bits contínuo transcodificado (por exemplo, fluxo de bits contínuo "TB" da Figura 10) tem um tamanho de quadro de 1024 amostras por quadro, o processo de transcodificação pode fazer com que o limite do programa real não ocorra em um limite de quadro do fluxo de bits contínuo transcodificado, mas em algum lugar em um quadro do mesmo (por exemplo, 512 amostras em um quadro do fluxo de bits contínuo transcodificado, conforme indicado na Figura 10), devido aos tamanhos do quadro se diferenciando de codificadores- decodificadores diferentes. As modalidades da presente invenção em que os metadados de limite do programa incluídos em um quadro de um fluxo de bits contínuo de áudio codificado incluem um valor compensado bem como uma conta do quadro do limite do programa são úteis nos três casos observados nesse parágrafo (bem como em outros casos).

[00155] A modalidade descrita acima com relação às Figuras 8 e 9 não inclui um valor compensado (por exemplo, um campo compensado) em nenhum dos quadros de fluxo de bits contínuo codificado. Em variações sobre essa modalidade, um valor compensado é incluído em cada quadro de um fluxo de bits contínuo de áudio codificado que inclui um indicador do limite do programa (por exemplo, em quadros correspondentes aos quadros numerados 0, 8, 12, e 14 na Figura 8, e os quadros numerados 18, 20, 24, e 32 na Figura 9).

[00156] Em uma classe modalidades, uma estrutura de dados (em cada quadro de um fluxo de bits contínuo codificado que contém os metadados de limite de programa inventivo) inclui um valor de código indicativo de se o quadro inclui somente uma conta do quadro do limite do programa ou ambos, uma conta do quadro do limite do programa e um valor compensado. Por exemplo, o valor de código pode ser o valor de um campo de bit único (a ser referido aqui como um campo "offset_exist"), o valor "offset_exist" = 0 pode indicar que nenhum valor compensado está incluído no quadro, e o valor "offset_exist" = 1 pode indicar que um a conta do quadro do limite do programa e um valor compensado estão incluídos no quadro.

[00157] Em algumas modalidades, pelo menos um quadro de um fluxo de bits contínuo de áudio codificado AC-3 ou E-AC-3 inclui um segmento de metadados que inclui LPSM e metadados de limite do programa (e opcionalmente outros metadados) para um programa de áudio determinado pelo fluxo de bits contínuo. Cada um desses segmentos de metadados (que pode ser incluído em um campo "addbsi", ou em um campo de dados auxiliares, ou em um segmento de perda de bit do fluxo de bits contínuo) contém um cabeçalho central (e opcionalmente ainda elementos centrais adicionais), e depois do cabeçalho central (ou o cabeçalho central e outros elementos centrais) um segmento da carga útil (ou recipiente) LPSM tendo o seguinte formato: um cabeçalho (tipicamente incluindo pelo menos um valor de identificação, por exemplo, conta, período, comprimento, versão de formato LPSM e valores de associação de fluxo de bits), edepois do cabeçalho, os metadados de limite do programa (que podem incluir uma conta do quadro do limite do programa, um valor de código (por exemplo, um valor "offset_exist") indicativo de se o quadro inclui somente uma conta do quadro do limite do programa ou ambos, uma conta do quadro do limite do programa e um valor compensado e, em alguns casos, um valor compensado, e o LPSM. O LPSM pode incluir:pelo menos um valor de indicação de diálogo indicando se dados de áudio correspondentes indicam diálogo ou não indicam diálogo (por exemplo, quais canais de dados de áudio correspondentes indicam diálogo). O(s) valor(es) de indicação de diálogo pode indicar se o diálogo está presente em qualquer combinação dos, ou todos os canais dos dados de áudio correspondentes;pelo menos um valor de conformidade de regulagem de sonoridade indicando se dados de áudio correspondentes estão em conformidade com um conjunto de regulagens de sonoridade indicado;pelo menos um valor de processamento de sonoridade in-dicando pelo menos um tipo de processamento de sonoridade que foi realizado sobre os dados de áudio correspondentes; epelo menos um valor de sonoridade indicando pelo menos uma característica de sonoridade (por exemplo, sonoridade máxima ou média) dos dados de áudio correspondentes.

[00158] Em algumas modalidades, o segmento da carga útil LPSM inclui um valor de código (um valor "offset_exist") indicativo de se o quadro inclui somente uma conta do quadro do limite do programa ou ambos, uma conta do quadro do limite do programa e um valor compensado. Por exemplo, em tal modalidade, quando tal valor de código indica (por exemplo, quando o offset_exist = 1) que o quadro inclui uma conta do quadro do limite do programa e um valor compensado, o segmento da carga útil LPSM pode incluir um valor compensado que é um número inteiro não sinalizado de 11-bits (ou seja, tendo um valor de 0 a 2048) e que indica o número de amostras de áudio adicionais entre o limite de quadro sinalizado (o limite do quadro que inclui o limite do programa) e o limite do programa real. Se a conta do quadro do limite do programa indica o número de quadros (na taxa atual de quadro) ao quadro contendo o limite do programa, a localização precisa (em unidades de número de amostras) do limite do programa (em re-lação ao começo ou final do quadro que inclui o segmento da carga útil LPSM) seria calculada como:S = (frame_counter * frame size) + offset,em que S é o número de amostras do limite do programa (do começo ao final do quadro que inclui o segmento da carga útil LPSM),"frame_counter" é a conta do quadro indicada pela conta do quadro do limite do programa, "frame size" é o número de amostras por quadro, e "offset" é o número de amostras, conforme indicado pelo valor compensado.

[00159] Algumas modalidades nas quais a taxa de inserção de indi-cadores do limite do programa aumenta próxima ao limite do programa real implementam uma regra que um valor compensado nunca está incluído em um quadro se o quadro for menor que ou igual a um número ("Y") de quadros a partir do quadro que inclui o limite do programa. Tipicamente, Y = 32. Para um codificador E-AC-3 que implementa essa regra (com Y = 32), o codificador nunca insere um valor compensado no segundo final de um programa de áudio. Nesse caso, o dispositivo de recepção é responsável por manter um temporizador e, assim, realizar seu próprio cálculo compensado (em resposta aos metadados de limite de programa, incluindo um valor compensado, em um quadro do fluxo de bits contínuo codificado que é de mais que Y quadros a partir do quadro contendo limites do programa).

[00160] Para programas cujos programas de áudio são conhecidos por serem "quadros alinhados" aos quadros de vídeo de programas de vídeo correspondentes (por exemplo, contribuição típica alimenta com áudio codificado Dolby E), seria supérfluo incluir valores compensados no fluxo de bits contínuo codificado indicativo dos programas de áudio. Assim, valores compensados não serão tipicamente incluídos em tal fluxo de bits contínuo codificado.

[00161] Com relação à Figura 11, considera-se então casos em que os fluxos de bits de áudio contínuos codificados são ligados juntos para gerar uma modalidade do fluxo de bits de áudio contínuo inventivo.

[00162] O fluxo de bits contínuo no topo da Figura 11 (identificado como "Cenário 1") é indicativo de um primeiro programa de áudio (P1) inteiro incluindo metadados de limite do programa (indicadores do limite do programa, F) seguido por um segundo programa de áudio (P2) inteiro que ainda inclui metadados de limite do programa (indicadores do limite do programa, F). Os indicadores do limite do programa na parte final do primeiro programa (alguns dos quais são mostrados na Figura 11) são idênticos ou similares àqueles descritos com relação à Figura 8, e determinam a localização do limite entre os dois programas (ou seja, o limite no começo do segundo programa). Os indicadores do limite do programa na parte inicial do segundo programa (alguns dos quais são mostrados na Figura 11) são idênticos ou similares àqueles descritos com relação à Figura 9, e eles determinam também a localização do limite. Em modalidades típicas, um codificador ou decodifi- cador implementa um temporizador (calibrado pelos indicadores no primeiro programa) que faz a contagem regressiva para o limite do programa, e o mesmo temporizador (calibrado pelos indicadores no segundo programa) conta a partir do mesmo limite do programa. Conforme indicado pelo gráfico do temporizador de limite no Cenário 1 da Figura 11, tal contagem regressiva do temporizador (calibrado pelos indicadores no primeiro programa) alcança zero no limite, e a conta-gem do temporizador (calibrado pelos indicadores no segundo pro-grama) indica aquela mesma localização do limite.

[00163] O segundo fluxo de bits contínuo do topo da Figura 11 (identificado como "Cenário 2") é indicativo de um primeiro programa de áudio (P1) inteiro incluindo metadados de limite do programa (indi- cadores do limite do programa, F) seguido por um segundo programa de áudio (P2) inteiro que não inclui metadados de limite do programa. Os indicadores do limite do programa na parte final do primeiro programa (alguns dos quais são mostrados na Figura 11) são idênticos ou similares àqueles descritos com relação à Figura 8, e determinam a localização do limite entre os dois programas (ou seja, o limite no começo do segundo programa), tal como no Cenário 1. Nas modalidades típicas, um codificador ou decodificador implementa um temporizador (calibrado pelos indicadores no primeiro programa) que faz contagem regressiva ao limite do programa, e o mesmo temporizador (sem ser posteriormente calibrado) continua a contar a partir do limite do pro-grama (conforme indicado pelo gráfico do temporizador de limite no Cenário 2 da Figura 11).

[00164] O terceiro fluxo de bits contínuo do topo da Figura 11 (iden-tificado como "Cenário 3") é indicativo de um primeiro programa de áudio truncado (P1) que inclui metadados de limite do programa (indicadores do limite do programa, F), e que foi ligado com um segundo programa de áudio (P2) inteiro que ainda inclui metadados de limite do programa (indicadores do limite do programa, F). A junção removeu os últimos "N" quadros do primeiro programa. Os indicadores do limite do programa na parte inicial do segundo programa (alguns dos quais são mostrados na Figura 11) são idênticos ou similares àqueles com relação à Figura 9, e eles determinam a localização do limite (junções) entre o primeiro programa truncado e o segundo programa inteiro. Nas modalidades típicas, um codificador ou decodificador implementa um temporizador (calibrado pelos indicadores no primeiro programa) que faz a contagem regressiva até o final do primeiro programa não truncado, e o mesmo temporizador (calibrado pelos indicadores no segundo programa) conta a partir do começo do segundo programa. O começo do segundo programa é o limite do programa no Cenário 3. Con- forme indicado pelo gráfico do temporizador de limite no Cenário 3 da Figura 11, tal contagem regressiva do temporizador (calibrado pelos metadados de limite do programa no primeiro programa) é reinicializada (em resposta aos metadados de limite do programa no segundo programa) antes de ter alcançado zero (em resposta aos metadados de limite do programa no primeiro programa). Assim, embora a truncamento do primeiro programa (pela junção) previna o temporizador de identificar o limite do programa entre o primeiro programa truncado e o começo do segundo programa em resposta aos (ou seja, sob a calibração pelos) metadados de limite do programa no primeiro programa sozinho, os metadados do programa no segundo programa reinicializam o temporizador, de modo que o temporizador reinicializado corretamente indique (conforme a localização correspondente à contagem "zero" do temporizador reinicializado) a localização do limite do programa entre o primeiro programa truncado e o começo do segundo programa.

[00165] O quarto fluxo de bits contínuo (identificado como "Cenário 4") é indicativo de um primeiro programa de áudio truncado (P1) que inclui metadados de limite do programa (indicadores do limite do programa, F), e um segundo programa de áudio truncado (P2) que inclui metadados de limite do programa (indicadores do limite do programa, F) e que foi ligado com uma parte (a parte não truncada) do primeiro programa de áudio. Os indicadores do limite do programa na parte inicial do segundo programa (pré-truncamento) inteiro (alguns dos quais são mostrados na Figura 11) são idênticos ou similares àqueles descritos com relação à Figura 9, e os indicadores do limite do programa na parte final do primeiro programa (pré-truncamento) inteiro (alguns dos quais são mostrados na Figura 11) são idênticos ou similares àqueles descritos com relação à Figura 8. A junção removeu os últimos "N" quadros do primeiro programa (e, assim, alguns dos indicadores do limite do programa que tenham sido incluídos aqui antes da junção) e os primeiros "M" quadros do segundo programa (e, assim, alguns dos indicadores do limite do programa que tenham sido incluídos aqui antes da junção). Nas modalidades típicas, um codificador ou decodifica- dor implementa um temporizador (calibrado pelos indicadores no primeiro programa truncado) que faz contagem regressiva em direção ao final do primeiro programa não truncado, e o mesmo temporizador (calibrado pelos indicadores no segundo programa truncado) conta a partir do começo do segundo programa não truncado. Conforme indicado pelo gráfico do temporizador de limite no Cenário 4 da Figura 11, tal contagem regressiva do temporizador (calibrado pelos metadados de limite do programa no primeiro programa) é reinicializada (em resposta aos metadados de limite do programa no segundo programa) antes de ter alcançado zero (em resposta aos metadados de limite do programa no primeiro programa). O truncamento do primeiro programa (pela junção) previne que o temporizador identifique o limite do programa entre o primeiro programa truncado e o começo do segundo programa trun-cado, em resposta aos (ou seja, sob a calibração pelos) metadados de limite do programa no primeiro programa sozinho. Entretanto, o temporizador reinicializado não indica corretamente a localização do limite do programa entre o final do primeiro programa truncado e o começo do segundo programa truncado. Assim, o truncamento de ambos os fluxos de dados contínuos ligados pode prevenir a determinação precisa do limite entre eles.

[00166] As modalidades da presente invenção podem ser imple-mentadas em hardware, firmware, ou software, ou uma combinação de ambos (por exemplo, como uma matriz lógica programável). A menos que especificado de outra maneira, os algoritmos ou processos incluídos como parte da invenção não estão inerentemente relacionados a qualquer computador específico ou outro aparelho. Em particular, vá- rias máquinas de objetivos gerais podem ser utilizadas com programas escritos de acordo com os ensinamentos daqui, ou podem ser mais convenientes para construir um aparelho mais especializado (por exemplo, circuitos integrados) para realizar as etapas do método exigidas. Assim, a invenção pode ser implementada em um ou mais programas de computador executando em um ou mais sistemas de computador programáveis (por exemplo, uma implementação de quaisquer dos elementos da Figura 1, ou codificador 100 da Figura 2 (ou umelemento do mesmo), ou decodificador 200 da Figura 3 (ou um elemento do mesmo), ou pós-processador 300 da Figura 3 (ou um ele-mento do mesmo) que compreendem cada um pelo menos um processador, pelo menos um sistema de armazenamento de dados (incluindo memória volátil e não volátil e/ou elementos de armazenamento), pelo menos um dispositivo ou porta de entrada, e pelo menos um dispositivo ou porta de saída). O código do programa é aplicado aos dados de entrada para realizar as funções descritas aqui e gerar informações de saída. As informações de saída são aplicadas a um ou mais dispositivos de saída, de maneira conhecida.

[00167] Cada um desses programas pode ser implementado em qualquer linguagem de computador desejada (incluindo linguagens de montagem ou máquina, de programação orientada a objeto, lógica ou processual de alto nível) para se comunicar com um sistema de computador. Em qualquer caso, a linguagem pode ser uma linguagem compilada ou interpretada.

[00168] Por exemplo, quando implementadas pelas sequências de instrução do software de computador, várias funções e etapas das modalidades da invenção podem ser implementadas por sequências de instrução de software funcionando em um hardware de processamento de sinal digital adequado, em cujo caso os vários dispositivos, etapas, e funções das modalidades podem corresponder a partes das instruções de software.

[00169] Cada um desses programas de computador é preferivel-mente armazenado ou baixado para um meio ou dispositivo de armazenamento (por exemplo, memória ou meio de estado sólido, ou meio óptico ou magnético) legível por um computador programável especial ou geral, para configurar e operar o computador quando o meio ou dispositivo de armazenamento é lido pelo sistema de computador para realizar os procedimentos descritos aqui. O sistema inventivo pode ainda ser implementado como um meio de armazenamento legível por computador, configurado com (ou seja, armazenando) um programa de computador, onde o meio de armazenamento então configurado faz com que o sistema de computador opere de uma maneira específica e predefinida para realizar as funções descritas aqui.

[00170] Um número de modalidades da invenção foi descrito. Con-tudo, deve-se observar que várias modificações podem ser feitas sem partir do escopo e do espírito da invenção. Modificações e variações numerosas da presente invenção são possíveis à luz dos ensinamentos acima. Deve ser entendido que dentro do escopo das concretizações, a invenção pode ser praticada de outro modo que não o especificamente descrito aqui.

Claims (15)

1. Unidade de processamento de áudio (100, 200) caracterizada pelo fato de que compreende:uma memória buffer (110, 201) para armazenar pelo menos um quadro de um fluxo de bits contínuo de áudio codificado, em que o fluxo de bits contínuo de áudio codificado inclui dados de áudio e um segmento de metadados, em que o segmento de metadados são dados separados e diferentes dos dados de áudio e inclui um cabeçalho, uma ou mais cargas úteis de metadados, e dados de proteção;um decodificador de áudio (101, 202) acoplado à memória buffer (110, 201) para decodificar os dados de áudio; eum interpretador (111, 205) acoplado ou integrado com o decodificador de áudio (101, 202) para interpretar o fluxo de bits contínuo de áudio codificado,em que o cabeçalho inclui uma palavra de sincronização que identifica o início do recipiente de metadados, as uma ou mais cargas úteis de metadados descrevem um programa de áudio associado com os dados de áudio, os dados de proteção são localizados após as uma ou mais cargas úteis de metadados, e os dados de proteção são capazes de ser utilizados para verificar a integridade do segmento de metadados e as uma ou mais cargas úteis dentro do segmento de metadados.

2. Unidade de processamento de áudio (100, 200), de acordo com a reivindicação 1, caracterizada pelo fato de que o segmento de metadados é armazenado em um espaço de dados reservados AC-3 ou E-AC-3 selecionado a partir do grupo que consiste em um campo de salto, um campo de dados auxiliares, um campo addbsi, e uma combinação dos mesmos.

3. Unidade de processamento de áudio (100, 200), deacordo com a reivindicação 1 ou 2, caracterizada pelo fato de que as uma ou mais cargas úteis de metadados incluem metadados indicativos de pelo menos um limite entre os programas de áudio consecutivos.

4. Unidade de processamento de áudio (100, 200), deacordo com a reivindicação 1 ou 2, caracterizada pelo fato de que as uma ou mais cargas úteis de metadados incluem uma carga útil da sonoridade do programa que contém dados indicativos de uma sonoridade medida de um programa de áudio.

5. Unidade de processamento de áudio (100, 200), deacordo com a reivindicação 4, caracterizada pelo fato de que a carga útil da sonoridade do programa inclui: um campo que indica se um canal de áudio contém diálogo falado; ou um campo que indica um método de medição de sonoridade que foi utilizado para gerar os dados da sonoridade contidos na carga útil da sonoridade do programa.

6. Unidade de processamento de áudio (100, 200), deacordo com a reivindicação 4, caracterizada pelo fato de que a carga útil da sonoridade do programa inclui: um campo que indica se uma sonoridade de um programa de áudio foi corrigida utilizando acionamento por porta de diálogo; ou um campo que indica se uma sonoridade de um programa de áudio foi corrigida utilizando um processo de correção da sonoridade com base em arquivo ou antecipação infinita.

7. Unidade de processamento de áudio (100, 200), deacordo com a reivindicação 4, caracterizada pelo fato de que a carga útil da sonoridade do programa inclui um campo que indica uma sonoridade integrada de um programa de áudio sem quaisquer ajustes de ganho atribuídos à compressão de faixa dinâmica.

8. Unidade de processamento de áudio (100, 200), deacordo com a reivindicação 4, caracterizada pelo fato de que a carga útil da sonoridade do programa inclui um campo que indica uma sonoridade integrada de um programa de áudio sem quaisquer ajustes de ganho atribuídos à normalização de diálogo.

9. Unidade de processamento de áudio (100, 200), deacordo com a reivindicação 4, caracterizada pelo fato de que a unidade de processamento de áudio (100, 200) é configurada para realizar o processamento de sonoridade adaptativo utilizando a carga útil da sonoridade do programa.

10. Unidade de processamento de áudio (100, 200), de acordo com qualquer uma das reivindicações 1 a 9, caracterizada pelo fato de que o fluxo de bits contínuo de áudio codificado é um fluxo de bits contínuo AC-3 ou um fluxo de bits contínuo E-AC-3.

11. Unidade de processamento de áudio (100, 200), de acordo com qualquer uma das reivindicações 4 a 9, caracterizada pelo fato de que a unidade de processamento de áudio (100, 200) é configurada para extrair a carga útil da sonoridade do programa do fluxo de bits contínuo de áudio codificado e autenticar ou validar a carga útil da sonoridade do programa.

12. Unidade de processamento de áudio (100, 200), de acordo com qualquer uma das reivindicações 1 a 11, caracterizada pelo fato de que uma ou mais cargas úteis de metadados cada um inclui um único identificador de carga útil, e o único identificador de carga útil é localizado no início de cada carga útil de metadados.

13. Unidade de processamento de áudio (100, 200), de acordo com qualquer uma das reivindicações 1 a 11, caracterizada pelo fato de que a palavra de sincronização é uma palavra de sincronização de 16 bits tendo um valor de 0x5838.

14. Método para decodificar um fluxo de bits contínuo de áudio codificado, o método caracterizado pelo fato de que compreende as etapas de:receber um fluxo de bits contínuo de áudio codificado, o fluxo de bits contínuo de áudio codificado segmentado em um ou mais quadros;extrair dados de áudio e um segmento de metadados do fluxo de bits contínuo de áudio codificado, o segmento de metadados sendo dados separados e diferentes dos dados de áudio e incluindo um cabeçalho seguido por uma ou mais cargas úteis de metadados seguidas por dados de proteção; everificar a integridade do recipiente e uma ou mais cargas úteis de metadados através do uso de dados de proteção,em que as uma ou mais cargas úteis de metadados incluem uma carga útil da sonoridade do programa que contém dados indicativos de uma sonoridade medida de um programa de áudio associada com os dados de áudio.

15. Método, de acordo com a reivindicação 14, caracterizado pelo fato de que o segmento de metadados é armazenado em um ou mais campos de salto ou segmentos de perda de bit de um quadro.

Images