BRPI0412889B1

BRPI0412889B1 - métodos para a conversão, combinação e decodificação, aparelhos para conversão e para a decodificação, e meio legível por computador

Info

Publication number: BRPI0412889B1
Application number: BRPI0412889A
Authority: BR
Inventors: Grill Bernhard; Gernhardt Harald; Popp Harald; Hilpert Johann; Lutzky Manfred; Weishart Martin; Haertl Michael; Geyersberger Stefan
Original assignee: Fraunhofer Ges Forschung
Priority date: 2003-07-21
Filing date: 2004-07-13
Publication date: 2019-09-10
Also published as: US20060259168A1; BRPI0412889A; EP1647010B1; PL1647010T3; MXPA06000750A; NO20060814L; WO2005013491A2; AU2004301746B2; JP4405510B2; US7769477B2; KR100717600B1; CA2533056C; CA2533056A1; AU2004301746A1; RU2006105203A; RU2335022C2; NO334901B1; JP2006528368A; WO2005013491A3; EP1647010A2

Abstract

"conversão de formato de arquivo de áudio". de acordo com a invenção, a manipulação de dados de áudio pode ser simplificada, tal como, por exemplo, com relação à combinação de canais de áudio individuais para se proporcionarem fluxos de dados de áudio de múltiplos canais, ou para a manipulação geral de um fluxo de dados de áudio, onde um bloco de dados é modificado (56) em um fluxo de dados de áudio (10), dividido em blocos de dados (10a, 10b) com blocos de determinação (14, 16) e dados de áudio de bloco de dados (18), tal como, por exemplo, pela inclusão em, adição a ou substituição de uma parte dos mesmos, em si contendo um indicador de comprimento o qual expressa uma quantidade de dados ou um comprimento dos dados de áudio de bloco, ou uma quantidade de dados ou um comprimento dos blocos de dados, de modo a se proporcionar um segundo fluxo de dados de áudio com blocos de dados modificados. alternativamente, um fluxo de dados de áudio (10) com ponteiros nos blocos de determinação (14, 10), os quais apontam para os dados de áudio de bloco de determinação (44, 46), alocados aos blocos de determinação, mas distribuídos em vários blocos de dados, é convertido em um fluxo de áudio, onde os dados de áudio de bloco de determinação (44, 46) são combinados para proporcionarem dados de áudio de bloco de determinação coerentes (48). os dados de áudio de bloco de determinação coerentes (48) podem ser combinados com o bloco de determinação correspondente (14, 16) em um elemento de canal auto-suficiente (52a).

Description

MÉTODOS PARA A CONVERSÃO, COMBINAÇÃO E DECODIFICAÇÃO, APARELHOS PARA CONVERSÃO E PARA A DECODIFICAÇÃO, E MEIO LEGÍVEL POR COMPUTADOR

A presente invenção se refere a sinais de áudio de codificação de fluxos de dados de áudio e, mais especificamente, a uma melhor manipulação de fluxos de dados de áudio em um formato de arquivo, onde os dados de áudio associados a uma marca de tempo podem ser distribuídos dentre blocos de dados diferentes, tal como é 10 o caso no formato MP3.

A compressão de áudio de MPEG é uma forma aproximadamente efetiva de armazenamento de sinais de áudio, tal como a música ou o som de um filme, em forma digital, enquanto requer, por um lado, tão pouco espaço de 15 memória quanto possível e, por outro lado, mantendo a qualidade de áudio tão boa quanto possível. Pelos últimos anos, a compressão de áudio de MPEG provou ser uma das soluções mais bem sucedidas neste campo.

Por enquanto, existem versões diferentes de método de 20 compressão de áudio. Geralmente, o sinal de áudio é amostrado com uma certa taxa de amostragem, a seqüência resultante de amostras de áudio sendo associada a períodos de tempo sobrepostos ou a marcas de tempo, respectivamente. Estas marcas de tempo então são individualmente supridas, 25 por exemplo, para um banco de filtro híbrido consistindo em polifase e uma transformada de co-seno discreta modificada (MDCT), suprimindo os efeitos de serrilhado. A compressão de dados real ocorre durante a quantificação dos coeficientes de MDCT. Os coeficientes de MDCT quantificados 30 daquela forma então são convertidos em um código de Huffman

Petição 870190047284, de 20/05/2019, pág. 20/32

2/44 de palavras de código de Huffman, gerando uma compressão adicional pela associação de palavras de código mais curtas a coeficientes que ocorrem mais freqüentemente. Assim, em geral, as compressões de MPEG são com perdas, as perdas 5 audíveis, contudo, sendo limitadas, uma vez que um conhecimento psicoacústico foi incorporado na forma de quantificação dos coeficientes de DCT.

Um padrão MPEG amplamente usado é o assim denominado padrão MP3, como descrito na ISO/IEC 11172-3 e 13818-3.

Este padrão permite uma adaptação da perda de informação gerada pela compressão à taxa de bit pela qual a informação de áudio é para ser transmitida em tempo real. A transmissão do sinal de dados comprimido em um canal com uma taxa de bit constante também deve ser realizada em 15 outros padrões MPEG. De modo a se garantir que a qualidade de audição no decodificador de recepção permaneça suficiente, mesmo a taxas de bit baixas, o padrão MP3 provê um codificador MP3 que tem um assim denominado reservatório de bit. Isto significa o seguinte. Normalmente, devido à 20 taxa de bit fixa, o codificador de MP3 deve codificar toda marca de tempo em um bloco de palavras de código tendo o mesmo tamanho, este bloco então pode ser transmitido com uma dada taxa de bit no período de tempo da taxa de repetição de período de tempo. Contudo, isto não acomodaria 25 o caso em que algumas partes de um sinal de áudio, tais como os sons seguindo-se a um som muito alto em um pedaço de música, requerem uma quantificação menos exata com qualidade constante, se comparado com outras partes do sinal de áudio, tais como partes com uma pluralidade de 30 instrumentos diferentes. Assim, um codificador de MP3 não

Petição 870180161237, de 10/12/2018, pág. 9/63

3/44 gera um formato de fluxo de bit simples onde toda marca de tempo é codificada em um quadro com o mesmo comprimento de quadro para todos os quadros. Um quadro auto-suficiente como esse consistiria em um cabeçalho de quadro, uma informação lateral e dados principais associados à marca de tempo associada ao quadro, especificamente, os coeficientes de MDCT codificados, onde a informação lateral é uma informação para o decodificador quanto a como os coeficientes de DCT devem ser decodificados, tal como quantos coeficientes de DCT subseqüentes são 0, para indicar quais coeficientes de DCT são sucessivamente incluídos nos dados principais. Ao invés disso, um ponteiro reverso (backpointer) é incluído na informação lateral ou no cabeçalho, apontando para uma posição nos dados principais em um dos quadros prévios. Esta posição é o começo dos dados principais pertencentes à marca de tempo à qual o quadro está associado, onde o ponteiro reverso (backpointer) correspondente está incluído. O ponteiro reverso (backpointer) indica, por exemplo, o número de bits pelo qual o começo dos dados principais é deslocado no fluxo de bit. O fim destes dados principais pode ser em qualquer quadro, dependendo de quão alta for a taxa de compressão para esta marca de tempo. O comprimento dos dados principais das marcas de tempo individuais não é mais constante. Assim, o número de bits pelos quais um bloco é codificado pode ser adaptado às propriedades do sinal. Ao mesmo tempo, uma taxa de bit constante pode ser obtida. Esta técnica é denominada reservatório de bit” . Geralmente, o reservatório de bit é um buffer de bits, o qual pode ser usado para a provisão de mais bits para

Petição 870180161237, de 10/12/2018, pág. 10/63

4/44 codificação de um bloco de amostras de tempo que geralmente seria permitida pela taxa de dados de saída constante. A técnica de reservatório de bit acomoda o fato de que alguns blocos de amostras de áudio podem ser codificados com menos bits do que especificado pela taxa de transmissão constante, de modo que estes blocos preencham o reservatório de bit, enquanto outros blocos de amostras de áudio têm propriedades psicoacústicas que não permitem uma compressão tão alta, de modo que os bits disponíveis realmente não sejam suficientes para uma decodificação de interferência baixa ou sem interferência, respectivamente, destes blocos. Os bits excessivos requeridos são tomados do reservatório de bit, de modo que o reservatório de bit se esvazie durante esses blocos. A técnica do reservatório de bit também é descrita na camada 3 de MPEG de padrão indicada acima.

Embora o formato MP3 tenha vantagens no lado de codificador pela provisão dos ponteiros reversos (backpointers), há desvantagens inegáveis no lado de decodificador. Se, por exemplo, um decodificador receber um fluxo de bit de MP3 não do começo, mas começando a partir de um certo quadro no meio, o sinal de áudio codificado na marca de tempo associada a este quadro pode ser tocado apenas instantaneamente quando o ponteiro reverso (backpointer) for incidentalmente 0, o que indicaria que o começo dos dados principais deste quadro está incidentalmente imediatamente após o cabeçalho ou a informação lateral, respectivamente. Contudo, normalmente este não é o caso. Assim, tocar o sinal de áudio nesta marca de tempo não é possível quando o ponteiro reverso

Petição 870180161237, de 10/12/2018, pág. 11/63

5/44 (backpointer) do quadro que foi recebido primeiramente apontar para um quadro prévio o qual, contudo, ainda não foi recebido. Nesse caso, (em primeiro lugar), apenas o próximo quadro pode ser tocado.

Outros problemas ocorrem no lado de receptor quando se lida com os quadros em geral, os quais são interconectados pelos ponteiros reversos (backpointers) e, assim, não são auto-suficientes. Um outro problema de fluxos de bit com endereços de retorno para um reservatório de bit é que, quando canais diferentes de um sinal de áudio são individualmente codificados em MP3, os dados principais pertencentes a cada outro nos dois fluxos de bit, uma vez que eles estão associados à mesma marca de tempo, poderiam ser deslocados para cada outro, e com um deslocamento variável através da seqüência de quadros, de modo que aqui novamente a combinação destes fluxos de MP3 individuais em um fluxo de dados de áudio de canal múltiplo é impedido.

Adicionalmente, há uma necessidade de uma possibilidade simples para a geração de fluxos de dados de áudio de canal múltiplo em conformidade com MP3 facilmente gerenciáveis. Os fluxos de dados de áudio de MP3 de canal múltiplo de acordo com a norma 13818-3 da ISO/IEC requerem operações de matriz para a recuperação dos canais de entrada a partir dos canais transmitidos no lado de decodificador e o uso de vários ponteiros reversos

(backpointers) e,	assim,	são	complicados de	se	manipular.
Os fluxos de	dados	de	áudio de camada	2	de MPEG 1/2
correspondem aos	fluxos	de	dados de áudio	de	MP3 na sua

composição de quadros subseqüentes e na estrutura e no arranjo dos quadros, especificamente, a estrutura de

Petição 870180161237, de 10/12/2018, pág. 12/63

6/44 cabeçalho, informação lateral e parte de dados principal, e no arranjo com uma distância de quadro quase estática dependendo da taxa de amostra e da taxa de bit variáveis de quadro a quadro, contudo, eles diferindo dos mesmos pela falta de ponteiros reversos (backpointers) ou reservatório de bit, respectivamente, durante uma codificação. Os períodos de tempo dispendiosos e não dispendiosos de codificação do sinal de áudio são codificados com o mesmo comprimento de quadro. Os dados principais referentes a uma marca de tempo estão no respectivo quadro em conjunto com o respectivo cabeçalho.

É o objetivo da presente invenção prover um esquema para a conversão de um fluxo de dados de áudio em um outro fluxo de dados de áudio ou vice-versa, de modo que a manipulação com os dados de áudio seja tornada mais fácil, tal como com respeito à combinação de fluxos de dados de áudio individuais em fluxos de dados de áudio de canal múltiplo ou a manipulação de um fluxo de dados de áudio em geral.

Este objetivo é obtido pelo método de acordo com a reivindicação 1, 10, 13, 14 ou 15 e com o aparelho de acordo com a reivindicação 16, 18, 19, 20 ou 21.

A manipulação de dados de áudio pode ser simplificada, tal como, por exemplo, com respeito à combinação de fluxos de dados de áudio em fluxos de dados de áudio de canal múltiplo ou a manipulação geral de um fluxo de dados de áudio, pela modificação de um bloco de dados em um fluxo de dados de áudio dividido em blocos de dados com a determinação de bloco e dados de dados de bloco, tal como pela completação ou adição ou substituição de parte dos

Petição 870180161237, de 10/12/2018, pág. 13/63

7/44 mesmos, de modo que os mesmos incluam um indicador de comprimento indicando uma quantidade ou um comprimento de dados, respectivamente, dos dados de áudio de bloco de dados ou uma quantidade ou um comprimento de dados, respectivamente, do bloco de dados, para a obtenção de um segundo fluxo de dados de áudio com blocos de dados modificados. Alternativamente, um fluxo de dados de áudio com ponteiros em blocos de determinação, os quais apontam para os dados de áudio de bloco de determinação associados àqueles blocos de determinação, mas distribuídos dentre blocos de dados diferentes, é convertido em um fluxo de dados de áudio, onde os dados de áudio de bloco de determinação são combinados com dados de áudio de bloco de determinação contíguos. Os dados de áudio de bloco de determinação contíguos, então, podem ser incluídos em um elemento de canal auto-suficiente em conjunto com seu bloco de determinação.

É uma descoberta da presente invenção que um fluxo de dados de áudio baseado em ponteiro, onde um ponteiro aponta para o começo dos dados de áudio de bloco de determinação do respectivo bloco de dados, é mais fácil de manipular quando este fluxo de dados de áudio é manipulado, de modo que todos os dados de áudio de bloco de determinação, isto é os dados de áudio concernentes à mesma marca de tempo ou à codificação dos valores de áudio para a mesma marca de áudio, são combinados em um bloco contíguo de dados de áudio de bloco de determinação contíguos, e que o respectivo bloco de determinação ao qual os dados de áudio de bloco de determinação contíguos estão associados é adicionado aos mesmos. Após a disposição ou o alinhamento

Petição 870180161237, de 10/12/2018, pág. 14/63

8/44 dos mesmos, respectivamente, os elementos de canal obtidos daquela forma resultam no novo fluxo de dados de áudio, onde todos os dados de áudio referentes a uma marca de tempo ou à codificação de valores de áudio ou amostras, 5 respectivamente, para esta marca de tempo, também são combinados em um elemento de canal, de modo que o novo fluxo de dados de áudio seja mais fácil de manipular.

De acordo com uma modalidade da presente invenção, todo bloco de determinação ou todo elemento de canal é 10 modificado no novo fluxo de dados de áudio, tal como pela adição ou substituição de uma parte para a obtenção de uma indicação de comprimento indicando o comprimento ou a quantidade de dados, respectivamente, do elemento de canal dos dados de áudio contíguos incluídos ali, para facilitar 15 a decodificação do novo fluxo de dados de áudio com elementos de canal de comprimento variável. Vantajosamente, uma modificação é realizada pela substituição de uma parte redundante destes blocos de determinação idênticos para todos os blocos de determinação do fluxo de dados de áudio 20 de entrada pela respectiva indicação de comprimento. Esta medida pode obter que a taxa de bit de dados do fluxo de dados de áudio resultante seja igual a uma do fluxo de dados de áudio original, apesar da indicação de comprimento adicional, se comparado com o fluxo de dados de áudio 25 baseado em ponteiro original, e que, desse modo, adicionalmente o ponteiro realmente desnecessário no novo fluxo de dados de áudio possa ser obtido de modo a se ser capaz de reconstruir o fluxo de dados de áudio original a partir do fluxo de dados de áudio novo.

A parte redundante idêntica destes blocos de

Petição 870180161237, de 10/12/2018, pág. 15/63

9/44 determinação pode ser posicionada antes do novo fluxo de dados de áudio resultante em um bloco de determinação geral. No lado de receptor, o segundo fluxo de dados de áudio resultante assim pode ser reconvertido no fluxo de 5 dados de áudio original, de modo a se usarem os decodificadores existentes que apenas podem decodificar fluxos de dados de áudio do formato de arquivo original para a decodificação do fluxo de dados de áudio resultante no formato sem ponteiro.

De acordo com uma outra modalidade da presente invenção, uma conversão de um primeiro fluxo de dados de áudio em um segundo fluxo de dados de áudio de um outro formato de arquivo é usado para a formação de um fluxo de dados de áudio de canal múltiplo de vários fluxos de dados de áudio do primeiro formato de arquivo. Uma capacidade de gerenciamento de lado de receptor é melhorada, se comparado com a mera combinação dos fluxos de dados de áudio originais com ponteiro, uma vez que no fluxo de dados de áudio de canal múltiplo todos os elementos de canal 2 0 referentes a uma marca de tempo ou contendo os dados de áudio de bloco de determinação contíguos, respectivamente, foram obtidos pela codificação de um período de tempo simultâneo de um canal de um sinal de áudio de canal múltiplo, isto é, pela codificação de períodos de tempo de canais diferentes referentes à marca de tempo, podem ser combinados para unidades de acesso. Isto não é possível com os fluxos de dados de áudio baseados em ponteiro, uma vez que ali os dados de áudio para uma marca de tempo podem ser distribuídos dentre blocos de dados diferentes. A provisão 30 dos blocos de dados em vários fluxos de dados de áudio para

Petição 870180161237, de 10/12/2018, pág. 16/63

10/44 canais diferentes com uma indicação de comprimento permite uma melhor análise gramatical pelas unidades de acesso, durante uma combinação dos fluxos de dados de áudio para um fluxo de dados de canal múltiplo com unidades de acesso.

Ainda, a presente invenção resultou da descoberta que é muito fácil reconverter os fluxos de dados de áudio resultantes descritos acima no sinal de áudio pelos decodificadores existentes. Embora os elementos de canal resultantes tenham um comprimento diferente e, assim, sejam 10 às vezes mais longos e às vezes mais curtos do que o comprimento disponível no bloco de dados do fluxo de dados de áudio original, não é requerido deslocar ou combinar os dados principais de acordo com ponteiros reversos (backpointers) obtidos eventualmente de forma desnecessária 15 para se tocar o fluxo de dados de áudio em um novo formato de arquivo, mas é suficiente aumentar uma indicação de taxa de bit nos blocos de determinação do fluxo de dados de áudio do formato de arquivo original a ser gerado. O efeito disto é que de acordo com esta indicação de taxa de bit 20 mesmo o mais longo dos elementos de canal no fluxo de dados de áudio a ser decodificado é menor ou o mesmo que o comprimento de bloco de dados o qual os blocos de dados têm em um fluxo de dados de áudio do primeiro formato de arquivo. Os ponteiros reversos (backpointers) são regulados 25 para zero e os elementos de canal são aumentados para o comprimento correspondente à indicação de taxa de bit aumentada pela adição de bits de valores sem importância. Assim, os blocos de dados de um fluxo de dados de áudio em um formato de arquivo original são gerados, onde os dados 30 principais referentes são meramente incluídos no bloco de

Petição 870180161237, de 10/12/2018, pág. 17/63

11/44 dados em si e não em qualquer outro. Um fluxo de dados de áudio do primeiro formato de arquivo reconvertido daquela forma então pode ser suprido para um decodificador existente para fluxos de dados de áudio do primeiro formato de arquivo pelo uso da taxa de bit aumentada de acordo com a indicação de bit aumentada. Assim, operações de deslocamento dispendiosas para reconversão são omitidas, bem como a exigência de substituição de decodificadores existentes por novos.

Por outro lado, de acordo com uma outra modalidade, é possível recuperar o fluxo de dados de áudio original a partir do fluxo de dados de áudio resultante pelo uso da informação incluída no bloco de determinação geral do fluxo de dados de áudio resultante através da parte redundante idêntica dos blocos de determinação para a recuperação da parte sobrescrita pela indicação de comprimento.

As modalidades preferidas da presente invenção serão discutidas abaixo com referência aos desenhos em anexo. Eles mostram:

Fig. 1: um desenho esquemático para ilustração do formato de arquivo MP3 com ponteiros reversos (backpointers) ;

Fig. 2: um diagrama de blocos para ilustração de uma estrutura para conversão de um fluxo de dados de áudioem

MP3 em um fluxo de dados de áudio em MPEG-4;

Fig. 3: um fluxograma de um método para conversãode um fluxo de dados de áudio em MP3 em um fluxo de dadosde áudio em MPEG-4, de acordo com uma modalidade da presente invenção;

Fig. 4: um desenho esquemático para ilustração da

Petição 870180161237, de 10/12/2018, pág. 18/63

12/44 etapa de combinação de dados de áudio associados pela adição dos blocos de determinação e a etapa de modificação dos blocos de determinação no método da Fig. 3;

Fig. 5: um desenho esquemático para ilustração de um método para conversão de vários fluxos de dados de áudio em MP3 em um fluxo de dados de áudio de canal múltiplo em MPEG-4, de acordo com uma outra modalidade da presente invenção;

Fig. 6: um diagrama de blocos de um arranjo para conversão de um fluxo de dados de áudio em MPEG-4 obtido de acordo com a Fig. 3 de volta em um fluxo de dados de áudio em MP3 para ser capaz de decodificar os mesmos pelos decodificadores de MP3 existentes;

Fig. 7: um fluxograma de um método para a reconversão do fluxo de dados de áudio em MPEG-4 obtido de acordo com a Fig. 3 em um ou vários fluxos de dados de áudio em formato MP3;

Fig. 8: um fluxograma de um método para reconversão do fluxo de dados de áudio em MPEG-4 obtido de acordo com a Fig. 3 em um ou vários fluxos de dados de áudio em formato MP3, de acordo com uma outra modalidade da presente invenção; e

Fig. 9: um fluxograma de um método para reconversão de um fluxo de dados de áudio em MP3 em um fluxo de dados de áudio em MPEG-4, de acordo com uma outra modalidade da presente invenção.

A presente invenção será discutida abaixo com referência aos desenhos, com base em modalidades em que o fluxo de dados de áudio original em um formato de arquivo em que ponteiros reversos (backpointers) são usados nos

Petição 870180161237, de 10/12/2018, pág. 19/63

13/44 blocos de determinação dos blocos de dados para apontarem para o começo de dados principais referentes ao bloco de determinação é meramente um exemplo de um fluxo de dados de áudio em MP3, enquanto o fluxo de dados de áudio resultante consistindo em elementos de canal auto-suficientes em que os dados de áudio referentes à respectiva marca de tempo são combinados, cada um, também é meramente um exemplo de um fluxo de dados de áudio de MPEG-4. O formato MP3 é descrito nas normas ISO/IEC 11172-3 e 13818-3 citadas no período de antecedentes, enquanto o formato de arquivo MPEG-4 é descrito na norma ISO/IEC 14496-3.

Em primeiro lugar, o formato MP3 será brevemente discutido com referência à Fig. 1. A Fig. 1 mostra uma porção de um fluxo de dados de áudio em MP3 10. O fluxo de dados de áudio 10 consiste em uma seqüência de quadros ou blocos de dados, respectivamente, dos quais apenas três podem ser plenamente vistos na Fig. 1, especificamente, 10a, 10b e 10c. O fluxo de dados de áudio em MP3 10 foi gerado por um codificador de MP3 a partir de um sinal de áudio ou de som, respectivamente. O sinal de áudio codificado pelo fluxo de dados 10, por exemplo, é música, ruído, uma mistura dos mesmos e similares. Os blocos de dados 10a, 10b e 10c são associados, cada um, a um de sucessivos períodos de tempo possivelmente sobrepostos nos quais o sinal de áudio foi dividido pelo codificador de MP3. Todo período de tempo corresponde a uma marca de tempo do sinal de áudio e, assim, na descrição, o termo marca de tempo freqüentemente é usado para o período de tempo. Todo período de tempo foi codificado nos filmes permeáveis (main_data) pelo codificador de MP3 individualmente, por

Petição 870180161237, de 10/12/2018, pág. 20/63

14/44 exemplo, por um banco de filtro híbrido consistindo em um banco de filtro de polifase e uma transformada de co-seno discreta modificada com entropia subseqüente, tal como uma codificação de Huffman. Os dados principais referentes às três marcas de tempo sucessivas, às quais os blocos de dados 10a a 10c são associados, são ilustradas na Fig. 1 por 12a, 12b e 12c como blocos contíguos ao lado do fluxo de dados de áudio real 10.

Os blocos de dados 10a a 10c do fluxo de dados de áudio 10 são dispostos de forma eqüidistante no fluxo de dados de áudio 10. Isto significa que cada bloco de dados 10a a 10c tem o mesmo comprimento de bloco de dados ou comprimento de quadro, respectivamente. O comprimento de quadro, novamente, depende da taxa de bit na qual o fluxo de dados de áudio 10 é para ser pelo menos tocado em tempo real, e da taxa de amostragem a qual o codificador de MP3 usou para a amostragem do sinal de áudio antes da codificação real. A conexão é que a taxa de amostragem indica em relação ao número fixo de amostras por marca de tempo quão longa é uma marca de tempo, e que ela pode ser calculada a partir da taxa de bit e o período de marca de tempo em que quantos bits podem ser transmitidos neste período de tempo.

Ambos os parâmetros, isto é, a taxa de bit e a taxa de amostragem, são indicados em cabeçalhos de quadro 14 nos blocos de dados 10a a 10c. Assim, todo bloco de dados 10a a 10c tem seu próprio cabeçalho de quadro 14. Geralmente, toda informação importante para a decodificação do fluxo de dados de áudio é armazenada em cada quadro 10a a 10c em si, de modo que um decodificador pode começar a decodificação

Petição 870180161237, de 10/12/2018, pág. 21/63

15/44 na metade de um fluxo de dados de áudio em MP3 10.

À parte do cabeçalho de quadro 14, o qual está no começo, cada bloco de dados 10a a 10c tem uma parte de informação lateral 16 e uma parte de dados principais 18 contendo os dados de áudio de bloco de dados. A mesma inclui uma informação essencial para o decodificador do fluxo de dados de áudio 10 para encontrar os dados principais ou os dados de áudio de bloco de determinação, respectivamente, associados ao respectivo bloco de dados, os quais são principalmente palavras de código de Huffman dispostas linearmente em série e para a decodificação das mesmas de uma forma corrente para os coeficientes de DCT ou MDCT, respectivamente. A parte de dados principais 18 forma o final de todo bloco de dados.

Como mencionado na seção antecedente da descrição, o padrão MP3 suporta uma função de reservatório. Isto é permitido pelos ponteiros reversos (backpointers) incluídos na informação lateral na parte de informação lateral 16 indicada na Fig. 1 por 20. Se um ponteiro reverso (backpointer) for regulado para 9, os dados principais para esta informação lateral começam imediatamente após a parte de informação lateral 16. Caso contrário, o ponteiro 20 (main_data_begin) indica o começo da codificação de dados principais da marca de tempo à qual o bloco de dados está associado, onde a informação lateral 16 contendo o ponteiro reverso (backpointer) 2 0 é incluída em um bloco de dados prévio. Na Fig. 1, por exemplo, o bloco de dados 10a está associado a uma marca de tempo codificada pelos dados principais 12a. O ponteiro reverso (backpointer) 20 na informação lateral 16 deste bloco de dados 10a aponta, por

Petição 870180161237, de 10/12/2018, pág. 22/63

16/44 exemplo, para o começo dos dados principais 12a, o qual está em um bloco de dados antes do bloco de dados 10a na direção de fluxo 22 pela indicação de um deslocamento de bit ou byte medido a partir do começo do cabeçalho 14 do bloco de dados 16a. Isso significa que ao mesmo tempo, durante uma codificação do sinal de áudio, o reservatório de bit do codificador de MP3 gerado o fluxo de dados de áudio em MP3 10 não estava cheio, mas poderia ser completado até a altura do ponteiro reverso (backpointer) . A partir da posição, para a qual o ponteiro reverso (backpointer) 20 do bloco de dados 10a aponta, em diante, os dados principais 12a são inseridos no fluxo de dados de áudio 10 com pares dispostos de forma eqüidistante de cabeçalhos e informação lateral 14, 16. No presente exemplo, os dados principais 12a se estendem até ligeiramente além da metade da parte de dados principais 18 do bloco de dados 10a. O ponteiro reverso (backpointer) 20 na parte de informação lateral 16 do 10b subseqüente aponta para uma posição imediatamente após os dados principais 12a no bloco de dados 10a. O mesmo se aplica ao ponteiro reverso (backpointer) 20 na parte de informação lateral 16 do bloco de dados 10c.

Como pode ser visto, é bem uma exceção no fluxo de dados de áudio em MP3 10 quando os dados principais referentes a uma marca de tempo estão na realidade exclusivamente em um bloco de dados associado a esta marca de tempo. Ao invés disso, os blocos de dados são principalmente distribuídos dentre um ou vários blocos de dados, os quais poderiam nem mesmo incluir o bloco de dados correspondente em si, dependendo do tamanho do reservatório

Petição 870180161237, de 10/12/2018, pág. 23/63

17/44 de bit. A altura do valor de ponteiro reverso (backpointer) é limitada pelo tamanho do reservatório de bit.

Após a estrutura de um fluxo de dados de áudio em MP3 ter sido descrita com respeito à Fig. 1, um arranjo será descrito com referência à Fig. 2, a qual é adequada para converter um fluxo de dados de áudio em MP3 em um fluxo de dados de áudio em MPEG-4, ou obter um fluxo de dados de áudio em MPEG-4 a partir de um sinal de áudio, o qual pode ser facilmente convertido em um formato MP3.

A Fig. 2 mostra um codificador de MP3 30 e um conversor de MP3-MPEG-4 32. O codificador de MP3 30 compreende uma entrada em que o mesmo recebe um sinal de áudio a ser codificado, e uma saída em que o mesmo extrai um fluxo de dados de áudio em MP3 codificando o sinal de áudio na entrada. O codificador de MP3 30 opera de acordo com o padrão MP3 mencionado acima.

O fluxo de dados de áudio em MP3 cuja estrutura foi discutida com referência à Fig. 1 consiste, como mencionado, em quadros com um comprimento de quadro fixo, o qual depende de uma taxa de bit regulada e da taxa de amostragem subjacente, bem como um byte de enchimento, o qual é regulado ou não regulado. O conversor de MP3-MPEG-4 32 recebe o fluxo de dados de áudio em MP3 em uma entrada e extrai um fluxo de dados de áudio em MPEG-4 em uma saída, cuja estrutura resulta da descrição subseqüente do modo de operação do conversor de MP3-MPEG-4 32. A finalidade do conversor 32 é converter o fluxo de dados de áudio em MP3 em um formato MPEG-4. O formato de dados MPEG-4 tem a vantagem de todos os dados principais referentes a uma certa marca de tempo serem incluídos em uma unidade de

Petição 870180161237, de 10/12/2018, pág. 24/63

18/44 acesso contíguo ou um elemento de canal, de modo que a manipulação do último é facilitada significativamente.

A Fig. 3 mostra as etapas de método individuais durante uma conversão do fluxo de dados de áudio em MP3 no fluxo de dados de áudio em MPEG-4 realizadas pelo conversor 32. Em primeiro lugar, o fluxo de dados de áudio em MP3 é recebido em uma etapa 40. O recebimento compreende o armazenamento do fluxo de dados de áudio pleno ou meramente uma parte atual do mesmo em um circuito registrador (latch) . Correspondentemente, as etapas subseqüentes durante a conversão podem ser realizadas durante a recepção 40 em tempo real ou apenas seguindo-se àquilo.

Então, em uma etapa 42, todos os dados de áudio ou os dados principais, respectivamente, referentes a uma marca de tempo são combinados em um bloco contíguo, e isto é realizado para todas as marcas de tempo. A etapa 42 é ilustrada em maiores detalhes esquematicamente na Fig. 4, onde nesta os elementos de um fluxo de dados de áudio em MP3 similares aos elementos ilustrados na Fig. 1 são providos com os mesmos números de referência ou similares e uma descrição repetida destes elementos é omitida.

Como pode ser visto a partir da direção de fluxo de dados 22, estas partes do fluxo de dados de áudio em MP3 10 ilustradas mais distantes para a esquerda na Fig. 4 atingem o conversor 32 mais cedo do que as partes à direita do mesmo. Dois blocos de dados 10a e 10b são ilustrados plenamente na Fig. 4. A marca de tempo referente ao bloco de dados 10a é codificado pelos dados principais MD1 incluídos na Fig. 4 de modo exemplar parcialmente em um bloco de dados antes do bloco de dados 10 e parcialmente no

Petição 870180161237, de 10/12/2018, pág. 25/63

		19/44
bloco de dados 10a,	e	aqui particularmente na	parte de
dados principais 18	do	mesmo. Aqueles dados	principais
codificando a marca	de	tempo à qual o bloco	de dados

subseqüente 10b é associado são exclusivamente incluídos na parte de dados principais 18 do bloco de dados 10a e indicados por MD2. Os dados principais MD3 referentes ao bloco de dados seguindo-se ao bloco de dados 10b são distribuídos dentre as partes de dados principais 18 dos blocos de dados 10a e 10b.

Na etapa 42, o conversor 42 combina todos os dados principais referentes, isto é, todos os dados principais codificando uma e a mesma marca de tempo, em blocos contíguos. Dessa forma, a porção 44 antes do bloco de dados 10a da porção 46 no bloco de dados 10a nos dados principais MD1 resulta no bloco contíguo 48 pela combinação após a etapa 42. O mesmo é realizado para os outros dados principais MD2, MD3...

Para a realização da etapa 42, o conversor 32 lê o ponteiro na informação lateral 16 de um bloco de dados 10a e, então, com base neste ponteiro, a respectiva primeira parte 44 dos dados de áudio de bloco de determinação 12a para este bloco de dados 10a incluído no campo 18 de um bloco de dados prévio, começando na posição determinada pelo ponteiro até o cabeçalho do bloco de dados atual 10a. Então, ele lê a segunda parte 46 dos dados de áudio de bloco de determinação incluída na parte 18 do bloco de dados atual 10a e compreendendo o fim dos dados de áudio de bloco de determinação para este bloco de dados 10a começando a partir do fim da informação lateral 16 do bloco de dados de áudio atual 10a até o começo dos próximos dados

Petição 870180161237, de 10/12/2018, pág. 26/63

20/44 de áudio, aqui indicado por MD2, até o próximo bloco de dados 10b, para o qual o ponteiro na informação lateral 16 do bloco de dados subseqüente 10b aponta, o que o conversor 32 lê também. Combinar as duas partes 44 e 46 resulta, como descrito, no bloco 48.

Em uma etapa 50, o conversor 32 lê o cabeçalho associado 14 incluindo a informação lateral associada 16 aos blocos contíguos para finalmente formar os elementos de canal de MP3 52a, 52b e 52c. Assim, todo elemento de canal de MP3 52a a 52c consiste no cabeçalho 14 de um bloco de dados de MP3 correspondente, uma parte de informação lateral subseqüente 16 do mesmo bloco de dados de MP3, e o bloco contíguo 48 de dados principais codificando a marca de tempo à qual o bloco de dados está associado, a partir do que o cabeçalho e a informação lateral se originam.

Os elementos de canal de MP3 resultantes das etapas 42 e 50 têm comprimentos diferentes de elemento de canal, como indicado pelas setas duplas 54a a 54c. Deve ser notado que os blocos de dados 10a, 10b no fluxo de dados de áudio de

MP3 10 tinham um comprimento de quadro fixo 56, mas que o número de dados principais para as marcas de tempo individuais varia em torno de um valor médio, devido à função de reservatório de bit.

Para facilidade de decodificação e particularmente de análise gramatical dos elementos de canal de MP3 individuais 52a a 52c no lado de decodificador, os cabeçalhos 14 H1 a H3 são modificados para a obtenção do comprimento do respectivo elemento de canal 52a a 52c, isto é, 54a a 54c. Isto é realizado em uma etapa 56. A entrada de comprimento é escrita em uma parte idêntica ou

Petição 870180161237, de 10/12/2018, pág. 27/63

21/44 redundante, respectivamente, para todos os cabeçalhos 14 do fluxo de dados de áudio 10. No formato MP3, todo cabeçalho 14 recebe no começo uma palavra de sincronização fixa (syncword) consistindo em 12 bits. Na etapa 56, esta syncword é ocupada pelo comprimento do respectivo elemento de canal. Os 12 bits da syncword são suficientes para a representação do comprimento do respectivo elemento de canal em forma binária, de modo que o comprimento dos elementos de canal de MP3 resultantes 58a a 58c com o cabeçalho modificado h1-h3 permaneça o mesmo, apesar da etapa 56, isto é, igual a 54a a 54c. Dessa forma, a informação de áudio também pode ser transmitida com a mesma taxa de bit em tempo real ou ser tocada como o fluxo de dados de áudio em MP3 original 10, após a combinação dos elementos de canal de MP3 58a a 58c de acordo com a ordem da marca de tempo codificada pelos mesmos, apesar da adição da indicação de comprimento, desde que nenhuma informação adicional seja adicionada pelos cabeçalhos adicionais.

Em uma etapa 58, um cabeçalho de arquivo, ou para o caso em que o fluxo de dados a ser gerado não é um arquivo, mas um streaming, um cabeçalho de fluxo de dados é gerado para o fluxo de dados de áudio de MPEG-4 desejado (etapa 60). Uma vez que, de acordo com a presente modalidade, um fluxo de dados de áudio em conformidade com MPEG-4 é para ser gerado, um cabeçalho de arquivo é gerado de acordo com o padrão MPEG-4, onde nesse caso o cabeçalho de arquivo tem uma estrutura fixa devido à função AudioSpecificConfig, a qual é definida na norma MPEG-4 mencionada acima. A interface para o sistema MPEG-4 é provida pelo elemento ObjectTypeIndication regulado com o valor 0x40, bem como

Petição 870180161237, de 10/12/2018, pág. 28/63

22/44 pela indicação de um audioObjectType com o número 29. O AudioSpecificConfig específico de MPEG-4 é estendido como se segue correspondente a sua definição original na ISO/IEC 14496-3, onde no exemplo a seguir apenas o conteúdo de AudioSpecificConfig significativo para a presente descrição, e não todo ele, é considerado:

AudioSpecificConfig() { audioObjectType;

samplingFrequencyIndex;

if(samplingFrequencyIndex==0xf) samplingFrequency;

channelConfiguration;

if(audioObjectType==29){

MPEG_1_2_SpecificConfig();

} }

A lista acima de AudioSpecificConfig é uma representação em notação comum para a função AudioSpecificConfig, a qual serve para a análise gramatical ou a leitura dos parâmetros de chamada no cabeçalho de arquivo no decodificador, especificamente, o samplingFrequencyIndex, o channelConfiguration e o audioObjectType, ou indica as instruções sobre como o cabeçalho de arquivo é para ser decodificado ou para ser analisado gramaticalmente.

Como pode ser visto, o cabeçalho de arquivo gerado na etapa 60 começa com a indicação do audioObjectType, o qual é regulado para 29 (linha 2), como mencionado acima. O parâmetro audioObjectType indica para o decodificador de que forma os dados foram codificados e, particularmente, de

Petição 870180161237, de 10/12/2018, pág. 29/63

23/44 que forma uma informação adicional para a codificação do cabeçalho de arquivo pode ser extraída, como será descrito abaixo.

Então, o parâmetro de chamada samplingFrequencyIndex se segue, o qual aponta para uma certa posição em uma tabela normalizada para as freqüências de amostra (linha 3). Se o índice for 0 (linha 4), a indicação da freqüência de amostra seguirá sem apontar para uma tabela normalizada (linha 5).

Então, a indicação de uma configuração de canal e segue (linha 6), a qual indica de uma forma que será discutida abaixo em maiores detalhes, quantos canais são incluídos no fluxo de dados de áudio em MPEG-4 gerado, onde também é possível, em contraste com a presente modalidade, combinar mais de um fluxo de dados de áudio em memória persistente em um fluxo de dados de áudio em MPEG-4, como será descrito abaixo com referência à Fig. 5.

Então, se o audioObjectType for 29, o qual é o caso aqui, uma parte do cabeçalho de arquivo AudioSpecificConfig contendo uma parte redundante de cabeçalho de quadro de MP3 no fluxo de dados de áudio 10 se segue, isto é, aquela parte remanescente do mesmo dentre os cabeçalhos de quadro 14 (linha 8). Esta parte é indicada aqui por MPEG_1_2_SpecificConfig(), novamente uma função que define a estrutura desta parte.

Embora a estrutura de MPEG_1_2_SpecificConfig também possa ser tomada a partir da norma de MP3, uma vez que ela corresponde à parte fixa de um cabeçalho de quadro de MP3 que não muda de quadro para quadro, a estrutura do mesmo é listada abaixo como um exemplo:

Petição 870180161237, de 10/12/2018, pág. 30/63

24/44

MPEG_1_2_SpecificConfig(channelConfiguration){ syncword

ID layer reserved sampling_frequency reserved reserved reserved if(channelConfiguration==0){ channel configuration description;

} }

Na parte MPEG_1_2_SpecificConfig, todos os bits diferindo de cabeçalho de quadro para cabeçalho de quadro 14 no fluxo de dados de áudio de MP3 são regulados para 0. Em qualquer caso, o primeiro parâmetro

MPEG_1_2_SpecificConfig, especificamente a palavra de

sincronização	de	12	bits syncword	servindo	para a
sincronização	de	um	codificador de	MP3 quando do
recebimento de	um	fluxo	de dados de áudio	em MP3	(linha 2),
é o mesmo para	todo	cabeçalho de quadro. O	parâmetro
subseqüente ID	(linha 3)	indica a versão	de MPEG,	isto é, 1

ou 2, pela norma correspondente ISO/IEC 13818-3 para a versão 2 e a norma correspondente ISO/IEC 11172-3 para a versão 1. A camada de parâmetro (linha 4) dá uma indicação para a camada 3, a qual corresponde ao padrão MP3. O bit seguinte é reservado (linha 5), uma vez que seu valor pode mudar de quadro para quadro e é transmitido pelos elementos de canal de MP3. Este bit mostra possivelmente que o

Petição 870180161237, de 10/12/2018, pág. 31/63

25/44 cabeçalho é seguido por uma variável de CRC. A próxima variável sampling_frequency (linha 6) aponta para uma tabela com taxas de amostragem definidas no padrão MP3 e, assim, indica a taxa de amostragem subjacente aos 5 coeficientes de MP3-DCT. Então, na linha 7, a indicação de um bit para aplicações específicas (reservado) se segue, bem como nas linhas 8 e 9. Então, (nas linhas 11, 12), a definição exata da configuração de canal se segue, quando o parâmetro indicado na linha 6 do AudioSpecificConfig não 10 aponta para uma configuração de canal pré-definida, mas tem o valor 0. Caso contrário, a configuração de canal da tabela 1.11 subparte da 14496-3 se aplica.

Pela etapa 60 e, particularmente, pela provisão do elemento MPEG_1_2_SpecificConfig no cabeçalho de arquivo, o 15 qual inclui toda a informação redundante nos cabeçalhos de quadro 14 do fluxo de dados de áudio em MP3 original 10, é assegurado que esta parte redundante nos cabeçalhos de quadro não leva a uma perda irrecuperável desta informação no arquivo em MPEG-4 a ser gerado durante a inserção de 20 dados facilitando a decodificação, tal como na etapa 56 pela inserção do comprimento de elemento de canal, mas que esta parte modificada pode ser reconstruída com base no cabeçalho de arquivo em MPEG-4.

Então, na etapa 62, o fluxo de dados de áudio em MPEG25 4 é extraído na ordem do cabeçalho de arquivo em MPEG-4 gerado na etapa 60, e os elementos de canal na ordem de suas marcas de tempo associadas, onde o fluxo de dados de áudio em MPEG-4 pleno resulta em um arquivo em MPEG-4 ou é transmitido por sistemas de MPEG-4.

A descrição acima está relacionada à conversão de um

Petição 870180161237, de 10/12/2018, pág. 32/63

26/44 fluxo de dados de áudio em MP3 em um fluxo de dados de áudio em MPEG-4. Contudo, como pode ser visto com linhas pontilhadas na Fig. 2, também é possível converter dois ou mais fluxos de dados de áudio em MP3 a partir de dois codificadores de MP3, especificamente 30 e 30' em um fluxo de dados de áudio de canal múltiplo em MPEG-4. Nesse caso, o conversor de MP3-MPEG-4 32 recebe o fluxo de dados de áudio em MP3 de todos os codificadores 30 e 30' e extrai o fluxo de dados de áudio de canal múltiplo no formato MPEG-

4.

Na metade superior, a Fig. 5 ilustra em relação à representação da Fig. 4 de que forma o fluxo de dados de áudio de canal múltiplo de acordo com MPEG-4 pode ser obtido, onde a conversão é novamente realizada pelo conversor 32. Três seqüências de elemento de canal 70, 72 e 74 são ilustradas, as quais foram geradas de acordo com as etapas 40 a 56 a partir de um sinal de áudio cada por um codificador de MP3 30 ou 30' (Fig. 2). A partir de cada seqüência de elementos de canal 70, 72 e 74, dois respectivos elementos de canal são mostrados, especificamente, 70a, 70b, 72a, 72b ou 74a, 74b, respectivamente. Na Fig. 5, os elementos de canal dispostos uns acima dos outros, aqui 70a a 74a ou 70b a 74b, respectivamente, são associados, cada um, à mesma marca de tempo. Os elementos de canal de segurança 70, por exemplo, codificam o sinal de áudio que foi gravado de acordo com uma normalização adequada na esquerda, direita de frente (frente), enquanto as seqüências 72 e 82 codificam sinais de áudio representando uma gravação da mesma fonte de áudio a partir de outras direções ou com um outro espectro de

Petição 870180161237, de 10/12/2018, pág. 33/63

27/44 freqüência, tal como o alto-falante dianteiro central (centro) e a partir da esquerda e direita traseira (surround).

Como indicado pelas setas 76, estes elementos de canal agora são combinados em unidades durante a saída (como feito na etapa 62 na Fig. 3) no fluxo de dados de áudio em MPEG-4, referidas abaixo como unidades de acesso 78. Assim, no fluxo de dados de áudio em MPEG-4, os dados em uma unidade de acesso 78 sempre se referem a uma marca de tempo. O arranjo de elementos de canal de MP3 80a, 72a e

74a na unidade de acesso 78, aqui na ordem de canal de frente, centro e surround, é considerado no cabeçalho de arquivo como gerado para o fluxo de dados de áudio em MPEG4 a ser gerado (como feito na etapa 60 na Fig. 3) pela regulagem respectivamente da configuração de canal de parâmetro de chamada no AudioSpecificConfig, sendo feita referência, de novo, à subparte 1 na ISO/IEC 14496-3. As unidades de acesso 78 de novo são sucessivamente dispostas no fluxo em MPEG-4 de acordo com a ordem de suas marcas de tempo, e elas são precedidas pelo cabeçalho de arquivo em MPEG-4. O parâmetro channelConfiguration é regulado apropriadamente no cabeçalho de arquivo em

MPEG-4 para indicar a ordem de elementos de canal nas unidades de acesso ou sua significância no lado de decodificador, respectivamente.

Como mostrou a descrição acima da Fig. 5, é muito fácil combinar fluxos de dados de áudio em MP3 em um fluxo de dados de áudio de canal múltiplo quando, como proposto de acordo com a presente invenção, os fluxos de dados de áudio em MP3 são manipulados para a obtenção de elementos

Petição 870180161237, de 10/12/2018, pág. 34/63

28/44 de canal auto-suficientes a partir dos blocos de dados, onde todos os dados de uma marca de tempo são incluídos em um elemento de canal, onde estes elementos de canal dos canais individuais então podem facilmente ser combinados em unidades de acesso.

A presente descrição está relacionada à conversão de um ou vários fluxos de dados de áudio em MP3 em um fluxo de dados de áudio em MPEG-4. Contudo, é uma descoberta significativa da presente invenção que todas as vantagens do fluxo de dados de áudio em MPEG-4 resultante, tal como a capacidade de gerenciamento melhorada de elementos de canal de MP3 auto-suficientes individuais com taxa de transmissão igual e a possibilidade de transmissão de canal múltiplo poder ser utilizada sem se ter de substituir os codificadores de MP3 plenamente por novos decodificadores, mas que a reconversão também pode ser realizada de forma não problemática, de modo que a mesma possa ser usada durante uma decodificação do fluxo de dados de áudio em

MPEG-4 descrito acima.

Na FIG.	6,	isto é ilustrado	em	um	arranjo de um
reconstrutor	de	MP3 100, cujo modo	de	operação será
discutido em	maiores detalhes abaixo,	e	dos	decodificadores
de MP3 102,	102'.	... Um reconstrutor	de MP3 recebe em sua

dados de áudio em entrada um fluxo de gerado de

MPEG-4 como acordo com uma das modalidades prévias, e extrai um ou, no caso de um fluxo de dados de áudio de canal múltiplo, vários fluxos de dados de áudio em MP3 para um ou vários decodificadores de MP3

102,

102'..., os quais em si decodificam o fluxo de dados de áudio em MP3 respectivamente recebido para um respectivo sinal de áudio

Petição 870180161237, de 10/12/2018, pág. 35/63

29/44 e o passam para respectivos alto-falantes dispostos de acordo com a configuração de canal.

Uma forma particularmente simples de reconstrução dos fluxos de dados de áudio em MP3 originais de um fluxo de 5 dados de áudio em MPEG-4 gerado de acordo com a Fig. 5 será descrita com referência à Fig. 5 abaixo e à Fig. 7, onde estas etapas são realizadas pelo reconstrutor de MP3 da Fig. 6.

Em primeiro lugar, o reconstrutor de MP3 100 verifica 10 em uma etapa 110 que o fluxo de dados de áudio em MPEG-4 recebido na entrada é um fluxo de dados de áudio em MP3 reformatado, ao verificar o parâmetro de chamada audioObjectType no cabeçalho de arquivo de acordo com a AudioSpecificConfig, onde o mesmo inclui o valor 29. Se 15 este é o caso (linha 7 na AudioSpecificConfig), o reconstrutor de MP3 100 prossegue com a análise gramatical do cabeçalho de arquivo do fluxo de dados de áudio em MPEG4 e lê a parte redundante de todos os cabeçalhos de quadro do fluxo de dados de áudio em MP3 original a partir da 20 parte MPEG_1_2_SpecificConfig a partir da qual o fluxo de dados de áudio em MPEG-4 foi obtido (etapa 112).

Após a avaliação de MPEG_1_2_SpecificConfig, o reconstrutor de MP3 100 substitui na etapa 114 em todo elemento de canal 74a a 74c no respectivo cabeçalho hF, hC, 25 hS uma ou várias partes dos elementos de canal por componentes de MPEG_1_2_SpecificConfig, particularmente a indicação de comprimento de elemento de canal pela palavra de sincronização de MPEG_1_2_SpecificConfig para a obtenção dos cabeçalhos de quadro de fluxo de dados de áudio em MP3 30 originais HF, HC, HS novamente, como indicado pelas setas

Petição 870180161237, de 10/12/2018, pág. 36/63

30/44

116. Em uma etapa 118, o reconstrutor de MP3 100 modifica a informação lateral Sf, Sc e Ss no fluxo de dados de áudio em MPEG-4 em todo elemento de canal. Particularmente, o ponteiro reverso (backpointer) é regulado para 0 para a obtenção da nova informação lateral S'f, S'c e S's. A manipulação de acordo com a etapa 118 é indicada na Fig. 5 pelas setas 120. Então, em uma etapa 122, o reconstrutor de MP3 100 regula o índice de taxa de bit em cada reator catalítico 74a a 74c no cabeçalho de quadro Hf, Hc, Hs provido na etapa 114 com a palavra de sincronização ao invés da indicação de comprimento de elemento de canal para o valor mais alto admissível. No final, os cabeçalhos resultantes diferem dos originais, o que é indicado na Fig. 5 por um apóstrofo, isto é, H'f, H'c e H's. A manipulação dos elementos de canal de acordo com a etapa 122 também é indicada pela seta 116.

Para ilustração das mudanças das etapas 114 a 122 de novo, os parâmetros individuais são listados na Fig. 5 para o cabeçalho H'f e a parte de índice lateral S'f. O cabeçalho de quadro H'f começa com o parâmetro syncword. Syncword é regulado para o valor original (Etapa 114), como é o caso em todo fluxo de dados de áudio em MP3, especificamente, para o valor 0xFFF. Geralmente, um cabeçalho de quadro H'f como resultante após as etapas 114 a 122 difere do cabeçalho de quadro de MP3 original como incluído no fluxo de dados de áudio em MP3 original 10 apenas pelo fato de o índice de taxa de bit ser regulado para o valor mais alto admissível, o qual é 0xE, de acordo com o padrão MP3.

A finalidade de mudança do índice de taxa de bit é

Petição 870180161237, de 10/12/2018, pág. 37/63

31/44 obter um novo comprimento de quadro ou um comprimento de bloco de dados, respectivamente, para o recém fluxo de dados de áudio em MP3 a ser gerado, o qual é maior do que aquele do fluxo de dados de áudio em MP3 original, a partir do qual o fluxo de dados de áudio em MPEG-4 com a unidade de acesso 7 8 foi gerado. O truque desse modo é que o comprimento de quadro em bytes no formato MP3 sempre depende da taxa de bit, de acordo com a equação a seguir:

Para a camada 3 de MPEG 1:

Comprimento de	quadro [Bit]	= 1152 *	taxa	de	bit
[Bits/s] / taxa de	amostragem	[Bits/s] +	8 *	bit	de
enchimento [Bit]
Para a camada 3	de MPEG 2:
Comprimento de	quadro [Bit]	= 576 *	taxa	de	bit
[Bits/s] / taxa de	amostragem	[Bits/s] +	8 *	bit	de
enchimento [Bit]
Em outras palavras, o comprimento de	quadro	de	um

fluxo de dados de áudio em MP3 de acordo com a norma é diretamente proporcional à taxa de bit e inversamente proporcional à taxa de amostragem. Como um valor adicional, o valor dos bits de enchimento é adicional, o qual é indicado nos cabeçalhos de quadro de MP3 hF, hC e hS e pode ser usado para a regulagem da taxa de bit exatamente. A taxa de amostragem é fixa, uma vez que ela determina com que velocidade o sinal de áudio decodificado é tocado. A conversão da taxa de bit comparada à regulagem original permite acomodar tais elementos de canal de MP3 74a a 74c em um comprimento de bloco de dados do recém fluxo de dados de áudio em MP3 a ser gerado, os quais são mais longos do que o original, uma vez que para a geração do fluxo de

Petição 870180161237, de 10/12/2018, pág. 38/63

32/44 dados de áudio original os dados principais foram gerados pela tomada de bits do reservatório de bit.

Assim, embora na presente modalidade o índice de taxa de bit seja sempre regulado para o valor mais alto 5 admissível, seria possível ainda aumentar o índice de taxa de bit apenas para um valor suficiente para resultar em um comprimento de bloco de dados de acordo com o padrão MP3, de modo que mesmo os elementos de canal de MP3 mais longos 74a a 74c se adaptassem a partir do seu comprimento.

Em 126, é ilustrado que o ponteiro reverso (backpointer) main_data_begin é regulado para 0 na informação lateral resultante. Isto apenas significa que no fluxo de dados de áudio em MP3 gerado de acordo com o método da Fig. 7 os blocos de dados são sempre auto15 suficientes, de modo que os dados principais para um certo cabeçalho de quadro e a informação lateral sempre comecem diretamente após a informação lateral e terminem no mesmo bloco de dados.

As etapas 114, 118, 122 são realizadas em todo elemento de canal, pela extração de cada um dos mesmos de suas unidades de acesso, onde as indicações de comprimento de elemento de canal são úteis durante a extração.

Então, em uma etapa 128, aquela quantidade de dados de preenchimento ou bits sem valor são adicionados a todo 25 elemento de canal 74a a 74c para aumento do comprimento de todos os elementos de canal de MP3 de forma unitária para o comprimento de bloco de dados de MP3, como regulado pelo novo índice de taxa de bit 0xE. Estes dados de preenchimento são indicados em 128 na Fig. 5. A quantidade 30 de dados de preenchimento pode ser calculada para todo

Petição 870180161237, de 10/12/2018, pág. 39/63

33/44 elemento de canal, por exemplo, pela avaliação da indicação de comprimento de elemento de canal e do bit de enchimento.

Então, em uma etapa 130, os elementos de canal mostrados na Fig. 5 em 74a' a 74c' modificados de acordo com as etapas prévias, são passados para um respectivo decodificador de MP3 ou uma entidade de decodificador de MP3 134a a 134c como blocos de dados de um fluxo de dados de áudio em MP3 na ordem das marcas de tempo codificadas. O cabeçalho de arquivo em MP3 é omitido. Os fluxos de dados de áudio em MP3 resultantes são indicados na Fig. 5 geralmente por 132a, 132b e 132c. As entidades de decodificador de MP3 134a a 134c foram inicializadas antes, por exemplo, o mesmo número de elementos de canal sendo incluídos nas unidades de acesso individuais.

O reconstrutor de MP3 100 sabe quais elementos de canal 74a a 74c em uma unidade de acesso 78 do fluxo de dados de áudio em MPEG-4 se referem a quais dos fluxos de dados de áudio em MP3 a serem gerados 132a a 132c a partir de uma avaliação do parâmetro de chamada channelConfiguration na AudioSpecificConfig do fluxo de dados de áudio em MPEG-4. Assim, a entidade de decodificador de MP3 134a conectada ao alto-falante frontal recebe o fluxo de dados de áudio 132a correspondente ao canal frontal e, correspondentemente, as entidades de decodificador de MP3 134b e 134c recebem os fluxos de dados de áudio 132b e 132c associados ao canal de centro e surround e extraem os sinais de áudio resultantes para alto-falantes dispostos respectivamente, por exemplo, para um subwoofer ou para alto-falantes dispostos no esquerda traseira ou direita traseira, respectivamente.

Petição 870180161237, de 10/12/2018, pág. 40/63

34/44

Obviamente, para uma codificação em tempo real do fluxo de dados de áudio em MPEG-4 pelo arranjo da Fig. 6 com as entidades de decodificador 102, 102' ou 134a a 134c, é requerido transmitir os fluxos de dados de áudio em MP3 recém gerados 132a a 132c com a taxa de bit aumentada na etapa 122, a qual é mais alta do que no fluxo de dados de áudio original 10, o que, contudo, não é problema, uma vez que o arranjo entre o reconstrutor de MP3 100 e os decodificadores de MP3 102, 102' ou 134a a 134c é fixo, de modo que aqui os percursos de transmissão são correspondentemente curtos e podem ser projetados com uma taxa de dados correspondentemente alta com baixo custo e esforço.

De acordo com a modalidade descrita com referência à Fig. 7, um fluxo de dados de áudio de canal múltiplo em MPEG-4 obtido de acordo com a Fig. 5 a partir dos fluxos de dados de áudio originais 10 não foi reconvertido exatamente para os fluxos de dados de áudio em MP3 originais, mas outros fluxos de dados de áudio em MP3 foram gerados a partir dos mesmos, onde em contraste com os fluxos de dados de áudio originais, todos os ponteiros reversos (backpointers) são regulados para 0 e o índice de taxa de bit é regulado para o valor mais alto. Os blocos de dados destes fluxos de dados de áudio em MP3 recém gerados assim também são auto-suficientes, à medida que todos os dados associados a uma certa marca de tempo são incluídos no mesmo bloco de dados 74'a a 74'c, e os dados de preenchimento foram usados para aumento do comprimento de bloco de dados para um valor unitário.

A Fig. 8 mostra uma modalidade para um método de

Petição 870180161237, de 10/12/2018, pág. 41/63

35/44 acordo com o qual é possível reconverter o fluxo de dados de áudio em MPEG-4 gerado de acordo com as modalidades das Fig. 1 a 5 nos fluxos de áudio em MP3 originais ou no fluxo de dados de áudio em MP3 original, respectivamente.

Nesse caso, o reconstrutor de MP3 100 testa de novo em uma etapa 150, exatamente como na etapa 110, se o fluxo de dados de áudio em MPEG-4 é um fluxo de dados de áudio em MP3 reformatado. As etapas subseqüentes 152 e 154 também correspondem às etapas 112 e 114 do procedimento da Fig. 7.

Ao invés de mudar os ponteiros reversos (backpointers) na informação lateral e o índice de taxa de bit nos cabeçalhos de quadro, o reconstrutor de MP3 100 reconstrói, de acordo com o método da Fig. 8, na etapa 156, o comprimento de bloco de dados original nos fluxos de dados de áudio em MP3 originais convertidos para o fluxo de dados de áudio em MPEG-4, com base na taxa de amostragem, na taxa de bit e no bit de enchimento. A taxa de amostragem e a indicação de enchimento são indicadas em

MPEG_1_2_SpecificConfig, e a taxa de bit em todo elemento de canal, se a última for diferente de quadro para quadro.

Para a camada 3 de MPEG 1:

Comprimento	de	quadro	[Bit]	= 1152	* taxa	de	bit
[Bits/s] / taxa	de	amostragem	[Bits/s]	+	8 *	bit	de
enchimento [Bit]
Para a camada 3	de MPEG	2 :
Comprimento	de	quadro	[Bit]	= 576	*	taxa	de	bit
[Bits/s] / taxa	de	amostragem	[Bits/s]	+	8 *	bit	de

enchimento [Bit]

Então, o fluxo de dados de áudio em MP3 ou os fluxos de dados de áudio em MP3, respectivamente, são gerados pela

Petição 870180161237, de 10/12/2018, pág. 42/63

36/44 disposição dos respectivos cabeçalhos de quadro a partir do respectivo canal em um intervalo do comprimento de bloco de dados calculado e os espaços são preenchidos pela inserção dos dados de áudio ou dos dados principais, 5 respectivamente, nas posições indicadas pelos ponteiros na informação lateral. Diferentemente das modalidades da Fig.

ou 5, respectivamente, os dados principais associados ao respectivo cabeçalho ou à respectiva informação lateral, respectivamente, são inseridos no fluxo de dados de áudio 10 em MP3 no começo da posição indicada pelo ponteiro reverso (backpointer) . Ou, em outras palavras, o começo dos dados principais dinâmicos é deslocado correspondendo ao valor de main_data_begin. O cabeçalho de arquivo de MPEG-4 é omitido. O fluxo de dados de áudio em MP3 resultante ou os 15 fluxos de dados de áudio em MP3 resultantes, respectivamente, correspondem aos fluxos de dados de áudio em MP3 originais nos quais o fluxo de dados de áudio em MPEG-4 foi baseado. Estes fluxos de dados de áudio em MP3 assim poderiam ser decodificados por decodificadores de MP3 20 convencionais em sinais de áudio, como os fluxos de dados de áudio da Fig. 7.

Com respeito à descrição prévia, deve ser notado que os fluxos de dados de áudio em MP3 descritos como fluxos de dados de áudio em MP3 de canal único em algumas posições 25 realmente já eram fluxos de dados de áudio em MP3 de dois canais, de acordo com a norma ISO/IEC 13818-3, onde, contudo, a descrição não entrou em detalhes quanto a isso, uma vez que isso não muda nada com respeito à compreensão da presente invenção. Operações de matriz a partir dos 30 canais transmitidos para a recuperação do canal de entrada

Petição 870180161237, de 10/12/2018, pág. 43/63

37/44 no lado de decodificador e o uso de vários ponteiros reversos (backpointers) nestes sinais de canal múltiplo não foi discutida, mas uma referência é feita à respectiva norma.

As modalidades acima tornaram possível armazenar blocos de dados em MP3 na forma alterada em um formato de arquivo em MPEG-4. Os formatos de MPEG-1/2-camada de áudio 3, MP3 curto ou proprietários como MPEG2.5 ou mp3PRO derivados dali podem ser empacotados em um arquivo MPEG-4 com base nestes procedimentos, de modo que esta nova representação represente uma representação de canal múltiplo de um número arbitrário de canais de uma forma simples.Usar o método complicado e dificilmente usado da norma ISO/IEC 13818-3 não é requerido. Particularmente, os blocos de dados em MP3 são empacotados de modo que cada bloco - elemento de canal de unidade de acesso - se refira a uma marca de tempo definida.

Nas modalidades acima para mudança do formato da representação de sinal digital, partes da representação foram sobrescritas com dados diferentes. Em outras palavras, a informação requerida ou útil para o decodificador é escrita através da parte do bloco de dados em MP3 que é constante para blocos diferentes em um fluxo de dados.

Pelo empacotamento de vários blocos de dados mono ou estéreo em uma unidade de acesso do formato de arquivo MPEG-4, uma representação de canal múltiplo poderia ser obtida, a qual é significativamente mais fácil de manipular, se comparado com a representação a partir da norma ISO/IEC 13818-3.

Petição 870180161237, de 10/12/2018, pág. 44/63

38/44

Nas modalidades prévias, a representação de um bloco de dados em MP3 foi formatada de uma forma diferente tal que todos os dados referentes a uma certa marca de tempo também fossem incluídos em uma unidade de acesso. Isto geralmente não é o caso em blocos de dados em MP3, uma vez que o elemento main_data_begin ou o ponteiro reverso (backpointer) no bloco de dados em MP3 original, respectivamente, pode apontar para blocos de dados anteriores.

A reconstrução do fluxo de dados original também poderia ser realizada (Fig. 8). Isso significa, como mostrado, que os fluxos de dados recuperados podem ser processados por todo decodificador em conformidade.

Acima de tudo, as modalidades acima permitem a codificação ou a decodificação de mais de dois canais. Ainda, nas modalidades acima, os dados em MP3 prontos codificados apenas têm de ser reformatados por operações simples para a obtenção de um formato de canal múltiplo. Por outro lado, no lado de codificador, apenas esta operação ou estas operações, respectivamente, teriam de ser revertidas.

Embora o fluxo de dados em MP3 usualmente inclua blocos de dados de comprimentos diferentes, uma vez que os dados dinâmicos referentes a um bloco podem ser empacotados em blocos prévios, as modalidades prévias agrupavam os dados dinâmicos diretamente atrás da informação lateral. O fluxo de dados de áudio em MPEG-4 resultante tinha uma taxa de bit média constante, mas blocos de dados de comprimentos diferentes. O elemento main_data_begin ou o ponteiro reverso (backpointer), respectivamente, é transmitido de

Petição 870180161237, de 10/12/2018, pág. 45/63

39/44 uma forma não alterada para se garantir a reprodução do fluxo de dados original.

Ainda, com referência à Fig. 5, uma extensão da sintaxe de MPEG-4 foi descrita para o empacotamento de vários blocos de dados em MP3 em um formato de canal múltiplo em um arquivo em MPEG-4. Todas as entradas de elemento de canal de MP3 referentes a um ponto de tempo foram empacotadas em uma unidade de acesso. Correspondentemente ao padrão MPEG-4, a informação adequada para a configuração no lado de codificador pode ser tomada do assim denominado AudioSpecificConfig. À parte do audioObjectType, a taxa de amostragem e a configuração de canal etc., o mesmo inclui um descritor relevante para o respectivo audioObjectType. Este descritor foi descrito acima com respeito ao MPEG_1_2_SpecificConfig.

De acordo com as modalidades prévias, a syncword de MPEG-1/2 de 12 bits no cabeçalho foi substituída pelo comprimento do respectivo elemento de canal de MP3. DE acordo com a ISO/IEC 13818-3, 12 bits são suficientes, portanto. O cabeçalho remanescente não foi modificado misturas, o que pode acontecer, contudo, para encurtamento, por exemplo, do cabeçalho de quadro e da parte redundante residual, exceto pela syncword, para a redução da quantidade de informação a ser transmitida.

Variações diferentes das modalidades acima podem ser facilmente realizadas. Assim, a seqüência nas etapas nas Fig. 3, 7, 8 pode ser alterada, particularmente, as etapas 42, 50, 56, 60 na Fig. 3, 11, 114, 118, 122 e 128 e na Fig. 7 e 152, 154, 156 na Fig. 8.

Ainda, com respeito às Fig. 3, 7, 8, deve ser notado

Petição 870180161237, de 10/12/2018, pág. 46/63

40/44 que as etapas mostradas ali são realizadas pelos respectivos recursos no conversor ou reconstrutor, respectivamente, das Fig. 2 ou 6, respectivamente, o qual pode ser, por exemplo, concretizado como um computador ou um circuito com fio.

Na modalidade da Fig. 7, a manipulação dos cabeçalhos da informação lateral, respectivamente (etapas 118, 122), foi realizada para os decodificadores de MP3 no receptor ou lado de decodificador, respectivamente, no fluxo de dados em MP3 ligeiramente modificado, se comparado com o fluxo de dados em MP3 original. Em muitos casos de aplicação, pode ser vantajoso realizar estas etapas no lado de codificador ou transmissor, respectivamente, uma vez que os dispositivos receptores freqüentemente são dispositivos produzidos em massa, de modo que economias na eletrônica no lado de receptor permitem ganhos significativamente mais altos. De acordo com uma modalidade alternativa, assim, pode ser provido que estas etapas já sejam realizadas durante a conversão de formato de dados de MP3-MPEG-4. As etapas de acordo com este método de conversão de formato alternativo são mostradas na Fig. 9, onde etapas idênticas àquelas na Fig. 3 são providas com os mesmos números de referência e não são descritas de novo, para se evitarem repetições.

Em primeiro lugar, o fluxo de dados de áudio em MP3 a ser convertido é recebido na etapa 40, e na etapa 42 os dados de áudio referentes a uma marca de tempo ou representando uma codificação de um período de tempo do sinal de áudio a ser codificado pelo fluxo de dados de áudio em MP3 referente à respectiva marca de tempo,

Petição 870180161237, de 10/12/2018, pág. 47/63

41/44 respectivamente, são combinados em um bloco contíguo, e isto para todas as marcas de tempo. Os cabeçalhos são adicionados de novo aos blocos contíguos para a obtenção dos elementos de canal (etapa 50). Contudo, os cabeçalhos não são apenas modificados pela substituição da palavra de sincronização pelo comprimento do respectivo elemento de canal, como na etapa 56. Ao invés disso, nas etapas 180 e 182 correspondentes às etapas 118 e 122 da Fig. 7, outras modificações se seguem. Na etapa 180, o ponteiro na informação lateral de cada elemento de canal é regulado para zero, e na etapa 182, o índice de taxa de bit no cabeçalho de todo elemento de canal é modificado, de modo que como descrito acima o comprimento de bloco de dados em MP3 dependendo da taxa de bit seja suficiente para incluir todos os dados de áudio deste elemento de canal ou referentes a uma marca de tempo, respectivamente, em conjunto com o tamanho do cabeçalho e a informação lateral. A etapa 182 também poderia compreender a conversão dos bits de enchimento nos cabeçalhos dos elementos de canal sucessivos para a produção de uma taxa de bit exata mais tarde quando do suprimento do fluxo de dados de áudio em MPEG-4 formado pelo método da Fig. 9 para um decodificador operando de acordo com o método da Fig. 7, mas sem as etapas 118 e 122. O enchimento também pode ser realizado, obviamente, no lado de decodificador na etapa 128.

Na etapa 182, pode ser útil regular o índice de taxa de bit não para o valor mais alto possível, como descrito com respeito à etapa 122. O valor também pode ser regulado para o valor mínimo, o qual é suficiente para se assumirem todos os dados de áudio, o cabeçalho e a informação lateral

Petição 870180161237, de 10/12/2018, pág. 48/63

42/44 de um elemento de canal em um comprimento de quadro de MP3 calculado, o que também pode significar que no caso de passagens do pedaço de áudio codificado que pode ser codificado com uma quantidade menor de coeficientes, o índice de taxa de bit é reduzido.

Após estas modificações, nas etapas 60 e 62, meramente o cabeçalho de arquivo (AudioSpecificConfig) é gerado, e o mesmo é extraído em conjunto com os elementos de canal de MP3 como o fluxo de dados de áudio em MPEG-4. O mesmo pode ser tocado, como já foi mencionado, de acordo com o método da Fig. 7, onde, contudo, as etapas 118 e 122 podem ser omitidas, o que facilita a implementação no lado de decodificador. Contudo, as etapas 42, 50, 56, 180, 182 e 60 podem ser realizadas em qualquer ordem.

A descrição prévia está relacionada meramente em forma de exemplo a fluxos de dados em MP3 com um comprimento de bit de bloco de dados fixo. Obviamente, os fluxos de dados em MP3 Com carinho, de bloco de dados variável podem ser processados de acordo com as modalidades prévias, onde o índice de taxa de bit e, assim, também o comprimento de bloco de dados mudam de quadro para quadro.

A descrição prévia está relacionada a fluxos de dados de áudio em MP3. Em outros fluxos de dados de áudio não baseados em ponteiro, uma modalidade da presente invenção provê a modificação dos cabeçalhos nos blocos de dados de, por exemplo, um fluxo de dados de áudio de camada 2 de MPEG 1/2 contendo, à parte dos cabeçalhos, a informação referente e os dados de áudio referentes e, assim, já sendo auto-suficiente para a geração de um fluxo de dados de áudio em MPEG-4. A modificação provê todo cabeçalho com uma

Petição 870180161237, de 10/12/2018, pág. 49/63

43/44 indicação de comprimento indicando a quantidade de dados do respectivo bloco de dados ou dos dados de áudio no respectivo bloco de dados, de modo que o fluxo de dados em MPEG-4 possa ser decodificado mais facilmente, em particular quando o mesmo é combinado em vários fluxos de dados de áudio de camada 2 de MPEG 1/2 em um fluxo de dados de áudio de canal múltiplo, de modo similar à descrição acima com respeito à Fig. 5. Preferencialmente, a modificação é obtida de modo similar à maneira descrita acima pela substituição das syncwords ou de uma outra parte redundante das mesmas nos cabeçalhos do fluxo de dados de camada 2 de MPEG 1/2 pelas indicações de comprimento. A reformatação de ponteiro ou dissolução antes da Fig. 5 pela combinação dos dados de áudio referentes a uma marca de tempo é omitida nos fluxos de dados de camada 2, uma vez que não existem ponteiros reversos (backpointers) ali. A decodificação de um fluxo de dados de áudio em MPEG-4 combinado com dois fluxos de dados de áudio de camada de MPEG 1/2 representando dois canais de um fluxo de dados de áudio de canal múltiplo pode ser facilmente realizada pela leitura das indicações de comprimento, e pelo acesso aos elementos de canal individuais nas unidades de acesso baseada nisso. O mesmo então pode ser transmitido para decodificadores em conformidade com camada de MPEG 1/2.

Ainda, não é significativo para a presente invenção onde exatamente o ponteiro reverso (backpointer) está nos blocos de dados do fluxo de dados de áudio baseado em ponteiro. Ele poderia ainda estar diretamente nos cabeçalhos de quadro para a definição de um bloco de determinação contíguo em conjunto com o mesmo.

Petição 870180161237, de 10/12/2018, pág. 50/63

44/44

Particularmente, deve ser notado que dependendo das condições, o esquema inventivo para a conversão de formato de arquivo também poderia ser implementado em software. A implementação pode ser feita em um meio de memória digital, 5 particularmente um disco ou um CD com sinais de controle legíveis eletronicamente, os quais podem cooperar com um sistema de computador programável, de modo que o respectivo método seja realizado. Assim, geralmente, a invenção consiste também em um produto de programa de computador com 10 um código de programa armazenado em um portador que pode ser lido em máquina para a realização do método inventivo, quando o produto de programa de computador rodar em um computador. Em outras palavras, a invenção também pode ser realizada como um programa de computador com um código de 15 programa para a realização do método, quando o programa de computador rodar em um computador.

Claims

REIVINDICAÇÕES

1. Método para a conversão de um primeiro fluxo de dados de áudio representando um sinal de áudio codificado compreendendo períodos de tempo e tendo um primeiro formato de arquivo em um segundo fluxo de dados de áudio representando sinal de áudio codificado e tendo um segundo formato de arquivo, onde um período de tempo compreende um número de valores de áudio, e onde de acordo com o primeiro formato de arquivo o primeiro fluxo de dados de áudio é dividido em blocos de dados subsequentes, onde um bloco de dados compreende um cabeçalho e dados de áudio de bloco de dados, em que todos os cabeçalhos compreendem uma parte idêntica redundante para todos os cabeçalhos, o método caracterizado por compreender as etapas de:

modificação dos blocos de dados, de modo que os mesmos incluam uma indicação de comprimento indicando a quantidade de dados dos blocos de dados ou uma quantidade de dados dos dados de áudio de bloco de dados para a obtenção de elementos de canal que formam o segundo fluxo de dados de áudio a partir dos blocos de dados, onde a etapa de modificação inclui a substituição de uma parte redundante idêntica para todos os cabeçalhos pela indicação de comprimento, em que o método compreende ainda posicionar (60, 62) um cabeçalho geral na frente do segundo fluxo de dados e o cabeçalho geral possui a parte idêntica redundante para todos os cabeçalhos, ou a parte idêntica redundante para todos os cabeçalhos é uma palavra de sincronização.
2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de os dados de áudio de cabeçalho

Petição 870190047284, de 20/05/2019, pág. 21/32

2/11 serem associados ao cabeçalho (14, 16), que são obtidos por codificação de um período de tempo, em que o cabeçalho compreende um ponteiro apontando para o começo dos dados de áudio de cabeçalho (12a, 12b, 12c), e em que um fim dos

5 dados de áudio de cabeçalho (12a, 12b, 12c) está antes de um começo dos dados de áudio de cabeçalho (12b, 12c) no fluxo de dados de áudio associado a um bloco de dados próximo, compreendendo as etapas de:

combinar (42) os dados de áudio de cabeçalho (44, 46)

10 associados ao cabeçalho dos pelo menos dois blocos de dados para obter dados de áudio de cabeçalho contíguo (48) formando parte do segundo fluxo dos dados de áudio;

adicionar (50) o cabeçalho (14, 16) com o qual os dados de áudio de cabeçalho (44, 46) são associados, a

15 partir do qual os dados de áudio de cabeçalho contíguos são obtidos, aos dados de áudio de cabeçalho contíguos (48) para obter um elemento de canal (52a);

dispor os elementos de canal para obter o segundo fluxo de dados de áudio; e

20 modificar (56) o elemento de canal (54a, 54b, 54c), de modo que o mesmo inclua uma indicação de comprimento indicando a quantidade de dados do elemento de canal (54a,

54b, 54c) ou uma quantidade de dados dos dados de áudio de cabeçalho contíguos, em que a etapa de modificar compreende

25 substituir (56) uma parte idêntica redundante para todos os cabeçalhos pela indicação de comprimento.
3. Método, de acordo com a reivindicação 1 ou 2, caracterizado pelo fato da etapa de combinação compreender as subetapas de:

30 leitura do ponteiro em um cabeçalho;

Petição 870190047284, de 20/05/2019, pág. 22/32

3/11 leitura de uma primeira parte dos dados de áudio de cabeçalho incluídos nos dados de áudio de bloco de dados de um de pelo menos dois blocos de dados e compreendendo o começo dos dados de áudio de cabeçalho para o qual o

5 ponteiro do cabeaçalho aponta;

leitura de uma segunda parte dos dados de áudio de cabeçalho incluídos nos dados de áudio de bloco de dados do outro dos pelo menos dois blocos de dados e compreendendo o fim dos dados de áudio de cabeçalho; e

10 combinação das primeira e segunda partes.
4. Método para combinação de um primeiro fluxo de dados de áudio que representa um primeiro sinal de áudio codificado e um segundo fluxo de dados de áudio representando um segundo sinal de áudio codificado em um 15 fluxo de dados de áudio de múltiplos canais, caracterizado por compreender as etapas de:

conversão do primeiro fluxo de dados de áudio em um primeiro fluxo de dados de subáudio conforme definido no método de qualquer uma das reivindicações 1 a 3; e

20 conversão do segundo fluxo de dados de áudio em um segundo fluxo de dados de subáudio conforme definido no método de qualquer uma das reivindicações 1 a 3, em que as etapas de disposição são realizadas de modo que os dois fluxos de dados de subáudio em conjunto formem 25 o fluxo de dados de áudio de múltiplos canais, e que no fluxo de dados de áudio de múltiplos canais os elementos de canal (7 0a) do primeiro fluxo de dados de subáudio e os elementos de canal (72a) do segundo fluxo de dados de subáudio contendo dados de áudio de cabeçalho contíguos 30 obtidos pela codificação de períodos de tempo iguais no

Petição 870190047284, de 20/05/2019, pág. 23/32

4/11 tempo sejam dispostos sucessivamente em uma unidade de acesso contígua (78).
5. Método, de acordo com a reivindicação 4, caracterizado por ainda compreender a etapa de:

5 posicionamento de um cabeçalho geral na frente do segundo fluxo de dados de áudio, o cabeçalho geral incluindo uma indicação de formato indicando em qual ordem os elementos de canal (70a) do primeiro fluxo de dados de subáudio e do segundo fluxo de dados de subáudio (70b) são 10 dispostos nas unidades de acesso (78).
6. Método, de acordo com qualquer uma das reivindicações 1 a 5, caracterizado pelo fato dos blocos de dados serem blocos de dados de tamanho igual ou variável predeterminado, dependendo de uma indicação de taxa de

15 amostragem e de uma indicação de taxa de bit no cabeçalho dos mesmos.
7. Método, de acordo com qualquer uma das reivindicações 1 a 3, caracterizado por ainda compreender as etapas de:

20 reinicialização (180) dos ponteiros nos cabeçalhos, de modo que os mesmos indiquem como um começo dos dados de áudio de cabeçalho que os dados de áudio de cabeçalho começam imediatamente após o respectivo cabeçalho; e mudança (182) das indicações de taxa de bit nos

25 cabeçalhos, de modo que um comprimento de bloco de dados dependendo de uma indicação de taxa de bit de acordo com o primeiro formato de arquivo de áudio seja suficiente para assumir o respectivo cabeçalho e os dados de áudio de cabeçalho associados.

30 8. Método para a decodificação de um segundo fluxo de

Petição 870190047284, de 20/05/2019, pág. 24/32

5/11 dados de áudio que representa um sinal de áudio codificado compreendendo períodos de tempo e tendo um segundo formato de arquivo, com base em um decodificador, o qual é capaz de decodificar um primeiro fluxo de dados de áudio representando o sinal codificado e tendo um primeiro formato de arquivo, em um sinal de áudio, onde um período de tempo compreende um número de valores de áudio, e onde de acordo com o primeiro formato de arquivo, o primeiro fluxo de dados de áudio é dividido em blocos de dados sucessivos (10a a 10c) com uma função de reservatório de bit, onde um bloco de dados tem um cabeçalho (14, 16) e dados de áudio de bloco de dados (18), onde os dados de áudio de cabeçalho, os quais são obtidos pela codificação de um período de tempo, são associados ao cabeçalho (14, 16), onde o cabeçalho inclui um ponteiro que aponta para um começo dos dados de áudio de cabeçalho (12a a 12c), e onde um fim dos dados de áudio de cabeçalho (12a a 12c) ocorre antes de um começo de dados de áudio de cabeçalho (12a a 12c) no fluxo de dados de áudio associado a um próximo bloco de dados, e onde o segundo fluxo de dados de áudio é dividido em elementos de canal de acordo com o segundo formato de arquivo, onde um elemento de canal compreende dados de áudio de cabeçalho contíguos (44, 46) obtidos pela combinação dos dados de áudio de cabeçalho associados a um cabeçalho de dois blocos de dados, e o cabeçalho associado, em uma forma onde a parte previamente redundante, a qual é idêntica para todos os cabeçalho, é modificada para ser substituída por uma indicação de comprimento indicando a quantidade de dados do respectivo elemento de canal ou uma quantidade de dados dos respectivos dados de cabeçalho

Petição 870190047284, de 20/05/2019, pág. 25/32

6/11 contíguos, em que um cabeçalho geral compreendendo uma parte idêntica redundante para todos os cabeçalhos é posicionado em frente do segundo fluxo de dados de áudio, o método caracterizado por compreender as etapas de:

formação de um fluxo de dados de entrada que representa o sinal de áudio codificado e tendo um primeiro formato de arquivo, a partir do segundo fluxo de dados de áudio pela:

análise de que o segundo fluxo de dados de áudio é um fluxo de dados reformatado a partir do primeiro formato de dados;

leitura da parte idêntica previamente redundante do cabeçalho geral;

substituição da indicação de comprimento nos cabeçalhos pela parte previamente redundante idêntica;

reinicialização dos ponteiros nos cabeçalho dos elementos de canal do segundo fluxo de dados de áudio, de modo que os mesmos indiquem como um começo dos dados de áudio de cabeçalho que os dados de áudio de cabeçalho começam imediatamente depois do respectivo cabeçalho para a obtenção de cabeçalho de reinicialização;

mudança de uma indicação de taxa de bit nos cabeçalho dos elementos de canal do segundo fluxo de dados de áudio, de modo que um comprimento de bloco de dados dependendo da indicação de taxa de bit de acordo com o primeiro formato de arquivo de áudio em todos os cabeçalhos seja suficiente para assumir o respectivo cabeçalho e os dados de áudio de cabeçalho associados para a obtenção de cabeçalho de taxa de bit mudada e reinicialização; e inserção de bits entre cada elemento de canal e o

Petição 870190047284, de 20/05/2019, pág. 26/32

7/11 elemento de canal subseqüente, de modo que o comprimento de cada elemento de canal mais os bits inseridos seja adaptado à indicação de taxa de bit mudada; e suprimento do fluxo de dados de entrada para o decodificador, de acordo com a indicação de taxa de bit mudada, para a obtenção do sinal de áudio.

9. Aparelho para a conversão de um primeiro fluxo de dados de áudio que representa um sinal de áudio codificado compreendendo períodos de tempo e tendo um primeiro formato de arquivo em um segundo fluxo de dados de áudio representando sinal de áudio codificado e tendo um segundo formato de arquivo, onde um período de tempo compreende um número de valores de áudio, e onde de acordo com o primeiro formato de arquivo, o primeiro fluxo de dados de áudio é dividido em blocos de dados subseqüentes, onde um bloco de dados compreende um cabeçalho e dados de áudio de bloco de dados, em que todos os cabeçalhos compreendem uma parte idêntica redundante para todos os cabeçalhos, o método caracterizado por compreender:

um meio para a modificação dos blocos de dados, de modo que os mesmos incluam uma indicação de comprimento indicando a quantidade de dados dos blocos de dados ou uma quantidade de dados dos dados de áudio de bloco de dados para a obtenção de elementos de canal que formam o segundo fluxo de dados de áudio a partir dos blocos de dados, onde a etapa de modificação inclui a substituição de uma parte idêntica redundante para todos os cabeçalhos pela indicação de comprimento, em que o aparelho compreende ainda meio para posicionamento (60, 62) de um cabeçalho geral na frente do

Petição 870190047284, de 20/05/2019, pág. 27/32
8/11 segundo fluxo de dados de áudio e o cabeçalho geral possui a parte redundante idêntica para todos os cabeçalhos, ou a

parte redundante idêntica para todos os cabeçalhos é uma palavra de sincronização. 10. Aparelho, de acordo com a reivindicação 9, caracterizado pelo fato de que os dados de áudio de cabeçalho são associados ao cabeçalho (14, 16), que são obtidos por codificação de um período de tempo, onde o

cabeçalho compreende um ponteiro que aponta para um começo dos dados de áudio de cabeçalho (12a, 12b, 12c), onde um fim dos dados de áudio de cabeçalho (12a, 12b, 12c) fica antes de um começo dos dados de áudio de cabeçalho (12a, 12b, 12c) no fluxo de dados de áudio associado a um próximo bloco de dados, compreendendo:

meio para combinar (42) os dados de áudio de cabeçalho (44, 46) associados a um cabeçalho de pelo menos dois blocos de dados para obter dados de áudio de cabeçalho contíguos (48) formando parte do segundo fluxo de dados de áudio;

meio para adicionar (50) o cabeçalho (14, 16) aos quais os dados de áudio de cabeçalho (44, 46) são associados, a partir do qual os dados de áudio de cabeçalho contíguos são obtidos, aos dados de áudio de cabeçalho contíguos (48) para obter um elemento de canal (52a); e meio para dispor os elementos de canal para obter o segundo fluxo de dados de áudio; e meio para modificar (56) os elementos de canal (54a, 54b, 54c) de modo que os mesmos incluam uma indicação de comprimento indicando a quantidade de dados de elementos de canal (54a, 54b, 54c) ou uma quantidade de dados de dados

Petição 870190047284, de 20/05/2019, pág. 28/32
9/11 de áudio de cabeçalho contíguos, onde o meio para modificar (56) são configurados para substituir uma parte redundante idêntica para todos os cabeçalhos para a indicação de comprimento.

5 11. Aparelho para a decodificação de um segundo fluxo de dados de áudio que representa um sinal de áudio codificado compreendendo períodos de tempo e tendo um segundo formato de arquivo, com base em um decodificador, o qual é capaz de decodificar um primeiro fluxo de dados de 10 áudio representando o sinal codificado e tendo um primeiro formato de arquivo, em um sinal de áudio, onde um período de tempo compreende um número de valores de áudio, e onde de acordo com o primeiro formato de arquivo, o primeiro fluxo de dados de áudio é dividido em blocos de dados 15 sucessivos (10a, 10b, 10c) com um reservatório de bits, onde um bloco de dados tem um cabeçalho (14, 16) e dados de áudio de bloco de dados (18), onde os dados de áudio de cabeçalho, os quais são obtidos pela codificação de um período de tempo, são associados ao cabeçalho (14, 16),

2 0 onde o cabeçalho inclui um ponteiro que aponta para um começo dos dados de áudio de cabeçalho (12a, 12b, 12c), e onde um fim dos dados de áudio de bloco de determinação (12a, 12b, 12c) ocorre antes de um começo de dados de áudio de cabeçalho (12a, 12b, 12c) no fluxo de dados de áudio 25 associado a um próximo bloco de dados, e onde o segundo fluxo de dados de áudio é dividido em elementos de canal de acordo com o segundo formato de arquivo, onde um elemento de canal compreende dados de áudio de cabeçalho contíguos (44, 46) obtidos pela combinação dos dados de áudio de

30 cabeçalho associados a um cabeçalho de dois blocos de

Petição 870190047284, de 20/05/2019, pág. 29/32
10/11 dados, e o cabeçalho associado em uma forma onde a parte previamente redundante idêntica para todos os cabeçalhos, é modificada para ser substituída por uma indicação de comprimento indicando a quantidade de dados do respectivo elemento de canal ou uma quantidade de dados dos respectivos dados de cabeçalho contíguos, em que um cabeçalho geral compreendendo uma parte redundante idêntica para todos os cabeçalhos é localizada em frente do segundo fluxo de dados de áudio, o aparelho caracterizado por compreender:

um meio para a formação de um fluxo de dados de entrada que representa o sinal de áudio codificado e tendo

um primeiro formato de arquivo, a partir do segundo fluxo de dados de áudio análise pela: de que o segundo fluxo de dados de áudio é um fluxo de dados reformatado a partir do primeiro

formato de dados;

leitura da parte previamente redundante idêntica a partir do cabeçalho geral;

substituição da indicação de comprimento nos cabeçalhos pela parte previamente redundante idêntica;

reinicialização dos ponteiros nos cabeçalhos dos elementos de canal do segundo fluxo de dados de áudio, de modo que os mesmos indiquem como um começo dos dados de áudio de cabeçalho que os dados de áudio de cabeçalho começam imediatamente depois do respectivo cabeçalho para a obtenção de cabeçalhos de reinicialização;

mudança de uma indicação de taxa de bit nos cabeçalhos dos elementos de canal do segundo fluxo de dados de áudio, de modo que um comprimento de bloco de dados

Petição 870190047284, de 20/05/2019, pág. 30/32
11/11 dependendo da indicação de taxa de bit de acordo com o primeiro formato de arquivo de áudio em todos os cabeçalhos seja suficiente para assumir o respectivo cabeçalho e os dados de áudio de cabeçalho associados para a obtenção de

5 cabeçalhos de taxa de bit mudada e reinicialização; e inserção de bits entre cada elemento de canal e o elemento de canal subseqüente, de modo que o comprimento de cada elemento de canal mais os bits inseridos seja adaptado à indicação de taxa de bit mudada; e

10 um meio para o suprimento do fluxo de dados de entrada para o decodificador, de acordo com a indicação de taxa de bit mudada, para a obtenção do sinal de áudio.
12. Aparelho, de acordo com a reivindicação 11, caracterizado pelo fato de que a parte redundante idêntica

15 para todos os cabeçalhos é uma palavra de sincronização.
13. Aparelho, de acordo com a reivindicação 11 ou 12, caracterizado pelo fato de que o meio de formação do fluxo de dados de entrada é configurado para, quando mudar a taxa de indicação de bit, configurar o mesmo para um valor mais

20 alto permitido.
14. Meio legível por computador caracterizado pelo fato de compreender instruções que, quando executadas por um computador, realizam as etapas do método conforme definido nas reivindicações 1 a 8.