ES2277954T3

ES2277954T3 - Codificacion de señales de audio.

Info

Publication number: ES2277954T3
Application number: ES01983700T
Authority: ES
Inventors: Anthony Richard Leaning; Richard James Whiting
Original assignee: British Telecommunications PLC
Current assignee: British Telecommunications PLC
Priority date: 2000-12-15
Filing date: 2001-11-19
Publication date: 2007-08-01
Anticipated expiration: 2021-11-19
Also published as: JP4270868B2; ATE347729T1; AU2002215122B2; KR100838052B1; EP1215663A1; US7222068B2; CN1481547A; KR20030060984A; DE60125061T2; EP1342231B1; EP1342231A1; JP2004516505A; DE60125061D1; CA2429735C; WO2002049008A1; CA2429735A1; US20040030547A1; CN1217317C; AU1512202A

Abstract

Procedimiento para codificar señales de audio de entrada que comprende: la codificación, con un primer algoritmo de codificación que presenta una primera longitud de trama, de cada una de las primeras partes temporales consecutivas de la señal de entrada, cuyas partes corresponden a un número entero de dichas primeras longitudes de trama y son contiguas o se superponen, para generar una primera secuencia codificada; la codificación, con un segundo algoritmo de codificación que presenta una segunda longitud de trama, de cada una de las segundas partes temporales consecutivas de la señal de entrada, cuyas partes corresponden a un número entero de dichas segundas longitudes de trama y no corresponden a un número entero de dichas primeras longitudes de trama y están superpuestas, para generar una segunda secuencia codificada, de tal forma que cada zona superpuesta de la segunda secuencia codificada abarca, por lo menos, una parte de un límite la primera secuencia codificada; e incluye asimismola aplicación de una secuencia codificada a una salida y, en respuesta a un mandato de cambio, el cambio de la salida que va a ser suministrada por la otra secuencia codificada, realizándose dicho cambio en el límite entre una parte temporal codificada y la siguiente.

Description

Codificación de señales de audio.

La presente invención se refiere al suministro, a través de un enlace de telecomunicaciones, de material codificado digitalmente para su presentación al usuario.

Más particularmente, la presente invención se refiere a la codificación de audio mediante algoritmos de codificación alternativos y a la conmutación entre éstos. La utilización de tamaños de trama diferentes por los algoritmos puede llevar a problemas.

En el documento EP 0926903, se da a conocer la utilización de tamaños de trama diferentes para audio y vídeo y la separación de una trama de audio entre dos tramas de vídeo.splicing.

La patente US nº 6124895 trata sobre los problemas acarreados por el empalme de vídeos cuando la longitud de la trama de audio no coincide con la de la trama de vídeo.

Según la presente invención, según la reivindicación 1 se proporciona un procedimiento para codificar señales de audio de entrada, que comprende la codificación, con un primer algoritmo de codificación que presenta una primera longitud de trama, de cada una de las primeras partes temporales consecutivas de la señal de entrada, en la que dichas partes corresponden a un número entero de dicha primera longitud de trama y son contiguas o se superponen, para generar una primera secuencia codificada; la codificación, con un segundo algoritmo de codificación que presenta una segunda longitud de trama, de cada una de las segundas partes temporales consecutivas de la señal de entrada, en la que dichas partes corresponden a un número entero de dicha segunda longitud de trama y no corresponden a un número entero de dicha primera longitud de trama y se superponen, para generar una segunda secuencia codificada, de tal forma que cada zona superpuesta de la segunda secuencia codificada abarca, al menos una parte límite de la primera secuencia codificada que corresponden a partes temporales consecutivas de la señal de
entrada.

Otros aspectos opcionales de la presente invención se exponen en las reivindicaciones subordinadas.

Debe tenerse en cuenta que la descripción y los dibujos siguientes son idénticos a los contenidos en la solicitud de patente internacional en trámite nº WO 02/49343.

A continuación, se describirán algunas formas de realización de la presente invención haciendo referencia a los dibujos adjuntos, en los que:

la Figura 1 es un diagrama que ilustra la arquitectura global de los sistemas que se van a describir;

la Figura 2 es un diagrama de bloques de un terminal para utilizar en uno de dichos sistemas;

la Figura 3 representa el contenido de un archivo de índices habitual;

la Figura 4 es un diagrama de tiempos que ilustra un procedimiento modificado de generación de subarchivos; y

la Figura 5 es un diagrama que ilustra una arquitectura modificada.

El sistema representado en la Figura 1 tiene como objetivo suministrar al usuario señales de audio codificadas digitalmente (por ejemplo, de música o voz registrada), por medio de una red de telecomunicaciones que las transmite hasta el terminal del usuario, en el que se reproducirán los correspondientes sonidos. Sin embargo, como se indicará en mayor detalle más adelante, el sistema puede ser utilizado para transmitir señales de vídeo en lugar, o además, de señales de audio. En este ejemplo, la red es Internet u otra red de paquetes que cumple el protocolo de transferencia de hipertexto (pueden consultarse los RFC 1945/2068 para obtener más información sobre esta cuestión), aunque en principio es posible utilizar otros enlaces o redes digitales. Se supone también que las señales de audio se han registrado en formato comprimido según la norma ISO MPEG-1 Layer III (la "norma MP3"), aunque no es obligatorio utilizar este formato particular. En realidad, tampoco es necesario realizar la compresión, aunque por supuesto es muy deseable, en particular cuando la velocidad binaria y el espacio de memoria son limitados. En la Figura 1, el servidor 1 está conectado por medio de Internet 2 a los terminales de usuario 3, de los cuales sólo se representa uno. La función del servidor 1 consiste en almacenar archivos de datos, recibir, desde un terminal de usuario, una petición de suministro de un archivo de datos deseado y, en respuesta a dicha petición, transmitir el archivo al terminal de usuario por medio de la red. Habitualmente, dicha petición adopta la forma de una primera parte que indica el mecanismo de suministro de la red (p.ej., http:// o file:// para el protocolo de transferencia de hipertexto o el protocolo de transferencia de archivos, respectivamente), seguida de la dirección de red del servidor (p.ej., www.servidor1.com) a la que se añade como sufijo el nombre del archivo que se ha solicitado. Debe observarse que, en los ejemplos proporcionados, los nombres contienen una doble barra inclinada "\\" en lugar de "//" por motivos tipográficos.

En estos ejemplos, se supone que se utiliza el protocolo de transferencia de hipertexto. Aunque la utilización de dicho protocolo no es imprescindible, resulta beneficiosa, porque permite sacar provecho de las características de autenticación y seguridad (por ejemplo, la capa de conexión segura, Secure Sockets Layer) proporcionadas por dicho protocolo.

Convencionalmente, los servidores de suministro de archivos MP3 adoptan la forma de los denominados "streamers" que incluyen disposiciones de procesamiento para el control dinámico de la velocidad a la que se transmiten los datos según los requisitos de reproducción del terminal del usuario, el enmascaramiento de los errores debidos a la pérdida de paquetes y, si es posible interactuar con el usuario, el control del flujo de datos entre el servidor y el cliente. No obstante, en este caso, el servidor 1 no presenta dichas capacidades, sino que es un "servidor web" corriente.

A continuación, se describirá cómo se almacenan los archivos de datos en el servidor 1. Supongamos que se ha creado un archivo de formato MP3 y que éste va a almacenarse en el servidor. Supongamos que el archivo es una grabación de la Tocata y Fuga en D menor de J. S. Bach (BWV565), cuyo tiempo de reproducción suele ser de 9 minutos. Originalmente, esta grabación se hubiera creado como un solo archivo de datos y, en un streamer convencional, se hubiera almacenado como un solo archivo. Sin embargo, en este caso, el archivo se divide en archivos más pequeños antes de ser almacenado en el servidor 1. Es preferible que el tamaño de cada uno de estos archivos más pequeños corresponda a un tiempo de reproducción fijo, tal vez de cuatro segundos. Con un formato comprimido tal como el MP3 esto puede significar que los archivos sean de tamaños diferentes en términos del número de bits que realmente contienen. Por lo tanto, el archivo de Bach de 9 minutos de duración se dividirá en 135 archivos más pequeños, cada uno de los cuales representará un tiempo de reproducción de cuatro segundos. En el presente ejemplo, a estos archivos, se les asignan nombres que incluyen un número de serie que indica su secuencia en el archivo original, por ejemplo:

000000.bin

000001.bin

000002.bin

000003.bin

-

000134.bin

\vskip1.000000\baselineskip

La división del archivo en subarchivos más pequeños puede ser realizada habitualmente por la persona que prepara el archivo para cargarlo en el servidor web 1. (En la presente memoria, la expresión "subarchivos" se utiliza para diferenciar los subarchivos del archivo original que contiene toda la grabación; no obstante, debe hacerse hincapié en que, por lo que al servidor respecta, cada "subarchivo" es simplemente un archivo como cualquier otro.) La forma precisa de crear los subarchivos se describirá de forma más detallada más adelante. Una vez creados, los subarchivos se cargan de forma convencional en el servidor, de la misma manera en que se carga cualquier otro archivo en un servidor web. Aunque, como es obvio, el nombre de archivo puede contener también caracteres que identifican la grabación particular (el subarchivo también puede estar "marcado" con información adicional; p.ej., cuando se reproduce un archivo MP3, se obtiene información sobre el autor, los derechos de autor, etc.), en este ejemplo, los subarchivos se almacenan en el servidor en un directorio o carpeta específica para la grabación particular (p.ej., mp3_bwv565) del servidor. Por lo tanto, cuando sea necesario, podrá solicitarse un subarchivo de la siguiente forma:

http:\\www.server1.com/mp3_bwv565/000003.bin

siendo "www.server1.com" la URL del servidor 1.

También es conveniente que la persona que prepara los subarchivos para cargarlos en el servidor, cree una página de enlace para cada grabación (habitualmente en formato html) que también se almacenará en el servidor (tal vez con el nombre de archivo mp3_bwv565/link.htm), cuya estructura y finalidad se describirán más adelante.

También es conveniente almacenar en el servidor web una o más páginas de menú (html) (por ejemplo, menu.htm) que contengan una lista de las grabaciones disponibles, con hiperenlaces con las correspondientes páginas de enlace.

Haciendo referencia al terminal, habitualmente éste puede adoptar la forma de un ordenador de escritorio convencional, aunque incluirá, sin embargo, software adicional para hacerse cargo de la recepción de los archivos de audio descritos. Si se desea, el terminal puede adoptar la forma de un ordenador de bolsillo, o incluso incorporarse en un teléfono móvil. Por lo tanto, la Figura 2 representa dicho terminal con un procesador central 30, una memoria 31, una memoria de disco 32, un teclado 33, una pantalla de vídeo 34, una interfaz de comunicaciones 35 y una interfaz de audio ("tarjeta de sonido") 36. Para el suministro de vídeo, se instalará una tarjeta de vídeo en lugar o además de la tarjeta 36. La memoria de disco contiene programas que pueden recuperarse y pasarse a la memoria 31 para ser ejecutados por el procesador 30, de la forma habitual. Estos programas incluyen un programa de comunicaciones 37 para invocar y presentar visualmente páginas html, es decir, un programa de "navegación" tal como el Netscape Navigator o el Microsoft Explorer, y otro programa 38 (denominado "programa reproductor" en la presente memoria) que proporciona las funciones necesarias para reproducir los archivos de audio según esta forma de realización de la presente invención. Asimismo, se representa una zona 39 de la memoria 31 que se utiliza como memoria tampón para el audio decodificado, que contiene datos en espera de ser reproducidos (habitualmente, el tiempo de reproducción de la memoria tampón es de 10 segundos). La interfaz de audio o la tarjeta de sonido 36 puede ser una tarjeta convencional que simplemente sirve para recibir audio PCM y convertirlo en una señal de audio analógica (por ejemplo, para ser reproducida a través de un altavoz). A continuación, se proporcionará en primer lugar una visión global breve del funcionamiento del terminal para la recuperación y reproducción de la grabación deseada, cuando se utiliza el protocolo HTTP y un cliente incorporado o cliente "plugin":

1.: El usuario utiliza el navegador para recuperar y presentar visualmente la página de menú, menu.htm, del servidor 1.

2.: El usuario selecciona uno de los hiperenlaces de la página de menú, con lo cual el navegador recupera del servidor, y presenta visualmente, la página de enlace para la grabación deseada (en este ejemplo, el archivo mp3_bwv565_link.htm). La presentación de esta página en realidad no es una cuestión importante (excepto porque tal vez contenga un mensaje que confirma al usuario que el sistema está funcionando correctamente). Lo que realmente importa acerca de esta página es que contiene un mandato (o "etiqueta embed") para invocar, en el procesador 30, un procedimiento secundario en el que se ejecuta el programa reproductor 37. La invocación de un procedimiento secundario de esta manera es una tarea muy conocida (dicho procedimiento se conoce en los sistemas Netscape como "plug-in" y en los sistemas Microsoft, como "ActiveX". Dichos mandatos pueden contener también parámetros que se pasarán al procedimiento secundario y, en el sistema de la Figura 1, el mandato contiene la URL del servidor de la grabación, que será http:\\www.server1/mp3_bwv565 para la pieza de Bach.

3.: El programa reproductor 37 incluye un decodificador MP3, cuyo funcionamiento es de por sí convencional. Dentro del presente contexto, son de mayor interés las funciones de control del programa que se describen a continuación.

4.: Una vez que el programa reproductor ha recibido la URL, añade ésta al nombre de archivo del primer subarchivo, para obtener la dirección completa del subarchivo (p.ej., www.server1/mp3_bwv565/000000.bin. Como se observará, dicho sistema se organiza partiendo de la base de que los subarchivos se nombran de la forma indicada anteriormente, con lo cual el terminal no necesita ser informado acerca de los nombres de los archivos. El programa crea un mensaje de petición para el archivo que posee esta URL y lo transmite al servidor 1 por medio de la interfaz de comunicaciones 35 e Internet 2. (Los procedimientos para convertir la URL en una dirección IP y para comunicar los errores de URL incorrectas, incompletas o no disponibles son convencionales y, por consiguiente, no serán descritos). Se contempla la posibilidad de que el programa reproductor envíe las peticiones directamente a la interfaz de comunicaciones, en lugar de hacerlo a través del navegador. El servidor reacciona transmitiendo el subarchivo deseado.

5.: A partir del archivo, el programa reproductor determina la decodificación de audio utilizada en este subarchivo y decodifica el archivo para proporcionar nuevamente los valores PCM iniciales de conformidad con la norma correspondiente (MP3, en este ejemplo), realizando una inscripción de la hora de reproducción de este subarchivo. Por lo general, un archivo de audio contiene en el principio del archivo un identificador que especifica la codificación utilizada. A continuación, los datos de audio decodificados se almacenan en la memoria tampón de audio 38.

6.: El programa reproductor presenta un parámetro denominado "hora de reproducción" T_{p}. En este ejemplo, se establece en 10 segundos (este valor podría ser seleccionable por el usuario, si así se desea). El parámetro T_{p} determina el grado de almacenamiento en memoria tampón realizado por el terminal.

7.: El programa reproductor incrementa el nombre de archivo hasta 000001.bin y solicita, recibe, decodifica y almacena este segundo subarchivo como se describe en los puntos (4) y (5) anteriores, y repite este procedimiento hasta que el contenido de la memoria tampón alcanza o sobrepasa el tiempo de reproducción T_{p}. Debe tenerse en cuenta que no es realmente imprescindible que la decodificación tenga lugar antes del almacenamiento en memoria tampón; sin embargo, de esta forma el procedimiento se simplifica, ya que al decodificarse el audio y obtenerse el audio PCM inicial, se conoce de manera explícita la duración del material en la memoria tampón. El control de la memoria tampón de audio se simplifica cuando cada uno de los subarchivos tiene el mismo tamaño de reproducción de audio.

8.: Una vez que se ha alcanzado el umbral de reproducción T_{p}, los datos decodificados son enviados desde la memoria tampón hasta la interfaz de audio 36 que reproduce el sonido a través de un altavoz (no representado).

9.: Mientras se reproducen los sonidos de la forma indicada en el punto (8), el programa reproductor supervisa continuamente el estado de ocupación de la memoria tampón y, siempre que éste se halla por debajo de T_{p}, incrementa de nuevo el nombre de archivo y obtiene otro subarchivo del servidor. Este procedimiento se repite hasta que se recibe el mensaje de error "archivo no encontrado".

10.: Si durante este procedimiento la memoria tampón se vacía, el programa reproductor simplemente deja de reproducir hasta que llegan más datos.

La convención de nomenclatura de subarchivos de la presente memoria, en la que se utiliza una secuencia de longitud fija y simple de números que empiezan por cero, es la preferida porque se implementa con facilidad. No obstante, es posible utilizar una convención de nomenclatura cualquiera, siempre y cuando el programa reproductor contenga (o reciba) el nombre del primer subarchivo y un algoritmo que le permita calcular los nombres de los subsiguientes subarchivos (o reciba una lista de los nombres de los archivos).

Como se habrá deducido ya, el sistema descrito anteriormente no ofrece al usuario ninguna oportunidad de intervenir en el procedimiento de reproducción, ni tampoco ofrece ningún remedio en caso de que se produzca una insuficiencia de memoria tampón (debido, por ejemplo, a la congestión de la red). Por consiguiente, en una segunda forma de realización más perfeccionada de la presente invención, descrita a continuación, se ofrecen las características adicionales siguientes:

a): el servidor almacena dos o más versiones de la grabación, registradas con índices de compresión diferentes (por ejemplo, con compresiones correspondientes a las velocidades de transmisión de datos (continua) de 8, 16, 24 y 32 kbit/s, respectivamente), y el programa reproductor es capaz de cambiar automáticamente entre éstas.

b): el programa reproductor presenta al usuario un panel de control, por medio del cual el usuario puede empezar a reproducir, hacer una pausa, volver a empezar a reproducir (desde el principio, o desde el punto en que se hizo la pausa) o saltar hasta un punto diferente de la grabación (hacia atrás o hacia delante).

Debe tenerse en cuenta que estas características no son interdependientes, en la medida en que el control del usuario puede proporcionarse sin cambio de velocidades o viceversa.

Para tener en cuenta el cambio entre velocidades, la persona que prepara el archivo que se va a cargar en el servidor prepara varios archivos fuente, codificando el mismo archivo PCM varias veces a diferentes velocidades. Cada archivo fuente se divide en subarchivos, como se ha indicado anteriormente. En el servidor, los subarchivos pueden cargarse en directorios separados correspondientes a las diferentes velocidades, como se indica en el ejemplo de estructura proporcionado a continuación, en el que los valores "008k" y "024k" del nombre de directorio indica la velocidad de 8 kbit/s o 24 kbit/s, y así sucesivamente.

Dicha persona crea también un archivo de índices (p.ej., index.htm), cuya finalidad principal es proporcionar una lista de las velocidades de transmisión de datos que están disponibles.

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

(Tabla pasa a página siguiente)

1

Debe tenerse en cuenta que, debido a que la longitud de un subarchivo corresponde, como se ha indicado anteriormente, a una longitud de tiempo fija, el número de subarchivos de cada directorio es el mismo. Los nombres de subdirectorios comprenden la velocidad de transmisión de datos en kbit/s (tres dígitos) más la letra "k". En este ejemplo, se adjuntan indicaciones de la frecuencia de muestreo de audio (11,025 kHz) y una etiqueta mono-estéreo, para finalidades de verificación.

El archivo de índices contendrá, por lo tanto, una sentencia de la forma:

<! Audio = "024k_11_s

\hskip0.5cm

032k_11_s

\hskip0.5cm

018k_11_s

\hskip0.5cm

016k_11_m

\hskip0.5cm

008_11_m" - ->

(la notación <!-...-> indica simplemente que la sentencia está insertada como un comentario en un archivo html (también podría utilizarse un archivo de texto simple)). En la Figura 3, se representa un archivo de índices común, en el que se incluye otro tipo de información: LFI es el número de subarchivo más alto (es decir, hay 45 subarchivos) y SL es el tiempo de reproducción total (178 segundos). La entrada "Modalidad" indica "grabado" (como en el presente caso) o "en directo" (descrito más adelante). Las otras entradas son autoexplicativas o mandatos html estándar.

\newpage

Al principio, el programa reproductor solicita el archivo de índices, a partir del directorio indicado en el archivo de enlace, y almacena localmente una lista de las velocidades de transmisión de datos disponibles para una futura consulta. (La petición de archivo puede ser explícita o puede indicar sólo el directorio y, entonces, la mayoría de servidores toman como valor por omisión index.htm si no se especifica ningún nombre de archivo). A continuación, se empiezan a solicitar los subarchivos de audio, tal como se ha indicado anteriormente, a partir del directorio de "velocidad" indicado en primer lugar en el archivo de índices, es decir, 024k_11_s (o el terminal puede anularlo, modificándolo y convirtiéndolo en una velocidad por omisión establecida localmente para ese terminal). A continuación, el programa reproductor mide la velocidad de transmisión de datos real recibida desde el servidor, calculando el valor medio de ésta con respecto a un período de tiempo (por ejemplo, 30 segundos). Esta acción se realiza estableciendo los tiempos de cada petición de URL. Entonces, se determina la velocidad de transferencia alcanzada (número de bits por segundo) entre el cliente y el servidor. La precisión de esta cantidad mejora a medida que el número de peticiones se incrementa. El reproductor mantiene dos parámetros almacenados que indican, respectivamente, la velocidad actual y la velocidad medida.

Se inicia un cambio de velocidad en las situaciones siguientes:

a): Si en alguna ocasión la memoria tampón queda vacía Y la velocidad medida es inferior a la velocidad actual Y el porcentaje bajo de la memoria tampón sobrepasa el umbral de reducción (que se describirá más adelante). Entonces, la velocidad actual se reduce (realizar el cambio cuando la memoria tampón ya está vacía resulta ventajoso, puesto que la tarjeta de sonido no está reproduciendo nada y tal vez sea necesario reconfigurarla si la frecuencia de muestreo de audio, la etiqueta estéreo-mono o el ancho de bits (número de bits por muestra) han cambiado).

b): Si la velocidad medida sobrepasa no sólo la velocidad actual sino también la siguiente velocidad más alta durante un período de tiempo dado (p.ej., 120 segundos, aunque, si se desea, este valor puede ser ajustable por el usuario). Entonces se incrementa la velocidad actual.

La expresión "el porcentaje bajo de la memoria tampón" se refiere al porcentaje de tiempo que el contenido de la memoria tampón representa menos del 25% del tiempo de reproducción (es decir, que la memoria tampón está a punto de quedar vacía). Si el "umbral de reducción" se establece en el 0%, cuando la memoria tampón queda vacía el sistema siempre efectúa una reducción progresiva de la velocidad cuando se cumplen las otras condiciones. Si el umbral de reducción se establece en el 5% (el valor por omisión preferido), cuando la memoria tampón queda vacía pero el porcentaje bajo de la memoria tampón medido es superior al 5%, el sistema no efectúa ninguna reducción progresiva de la velocidad. Otros vaciados de la memoria tampón determinarán, obviamente, que la velocidad medida se incremente y en última instancia que la memoria tampón vuelva a quedar vacía cuando el valor de porcentaje bajo de la memoria tampón sobrepase el 5% si la velocidad no se puede mantener. Si se establece el valor en el 100%, el cliente nunca realizará una reducción progresiva de la velocidad.

El cambio de velocidad es efectuado de forma sencilla por el programa reproductor, cambiando la parte correspondiente de la dirección de subarchivo (por ejemplo, cambiando "008k" por "024k" para incrementar la velocidad de transmisión de datos de 8 a 24 kbit/s) y cambiando el parámetro de velocidad actual para que coincida con la dirección. Por consiguiente, la siguiente petición para el servidor es una petición de velocidad más alta (o más baja), y el subarchivo del nuevo directorio es recibido, decodificado e introducido en la memoria tampón. El procedimiento que se acaba de describir se resume en el siguiente diagrama de flujo:

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

(Tabla pasa a página siguiente)

2

3

4

El control del usuario se implementa ofreciendo al usuario las siguientes opciones de pantalla, que éste puede seleccionar utilizando el teclado u otro dispositivo de entrada, tal como un ratón:

a): Inicio: implementa las etapas numeradas indicadas más arriba, a partir de la etapa 4. Cuando se selecciona por primera vez una grabación, es opcional que ésta empiece a reproducirse de forma automática o que se reproduzca después de que el usuario haya proporcionado una instrucción de inicio. En realidad, si así se desea, la elección puede llevarse a cabo por medio de un parámetro de "autorreproducción" adicional en el archivo de enlace.

b): Pausa: se implementa con una instrucción para que el decodificador MP3 suspenda la lectura de datos de la memoria tampón;

c): Reanudación: se implementa con una instrucción para que el decodificador MP3 reanude la lectura de datos de la memoria tampón;

d): Salto: se implementa cuando el usuario indica a qué parte de la grabación desea saltar, desplazando por ejemplo el cursor hasta un punto deseado de una barra de la pantalla que representa la duración total de la grabación. El reproductor determina entonces que este punto se halla en el x% de la longitud de la barra y calcula el número del siguiente subarchivo necesario, que se utiliza a continuación para la siguiente petición. En el ejemplo de la pieza de Bach con 125 subarchivos, una petición de reproducción desde el punto que representa el 20% de la grabación dará por resultado una petición del 26º subarchivo, es decir, 000025.bin. Como es evidente, este cálculo se simplifica considerablemente si cada subarchivo corresponde a la misma duración fija. En el caso del salto, es preferible suspender la decodificación y borrar la memoria tampón para que, de ese modo, la nueva petición sea enviada de inmediato, aunque esto no es imprescindible.

Es interesante profundizar en el procedimiento de división del archivo original en subarchivos. En primer lugar, debe tenerse en cuenta que (como en la primera versión descrita anteriormente) no se espera que un subarchivo venga seguido de otro subarchivo que no sea el inmediatamente siguiente en la secuencia original. Por consiguiente, poco interés tendrá saber dónde se localizan los límites entre los subarchivos. En tal caso, el tamaño del subarchivo puede ser un número de bits fijo o una duración de tiempo de reproducción fija (o ninguna de estas cosas), siendo el tamaño que deben tener los subarchivos la única decisión real que debe tomarse. Cuando se prevén saltos (en el tiempo o entre diferentes velocidades de transmisión de datos) entran en juego otras consideraciones. Cuando la señal se codifica en tramas (como sucede en muchos tipos de codificación de voz o de audio, incluido el formato MP3), el subarchivo deberá contener un conjunto completo de tramas. En el caso del cambio de velocidades, es muy deseable, aunque en realidad no es imprescindible, que los límites de los subarchivos sean iguales para cada velocidad, de tal forma que el primer subarchivo recibido para una nueva velocidad continúe a partir del mismo punto de la grabación en el que ha terminado el último subarchivo de la velocidad anterior. Ésta no es la única forma de conseguir que cada subarchivo represente el mismo período de tiempo fijo (p.ej., los 4 segundos mencionados anteriormente), aunque desde luego sí la más conveniente. Sin embargo, debe observarse que, dependiendo del sistema de codificación que se esté utilizando, el requisito de que cada subarchivo debe contener un conjunto completo de tramas puede significar que la duración de la reproducción de los subarchivos varíe ligeramente. Debe tenerse en cuenta que aunque en esta forma de realización de la presente invención las velocidades de transmisión de datos disponibles utilizan diferentes grados de cuantificación y codifican en mono o en estéreo, todas ellas utilizan la misma frecuencia de muestreo de audio y, en consecuencia, el mismo tamaño de trama. A continuación, se indican las cuestiones que deben ser tratadas cuando se utilizan tamaños de tramas diferentes.

En cuanto a la longitud real del subarchivo, deberán evitarse preferentemente los subarchivos demasiado cortos, porque: (a) crean un tráfico de red adicional en forma de más peticiones y (b) en ciertos tipos de redes de paquetes, incluidas las redes IP, resultan antieconómicos en la medida en que deben ser transmitidos en paquetes más pequeños y, por lo tanto, la sobrecarga representada por el procedimiento de petición y la cabecera del paquete es proporcionalmente mayor. Por otra parte, los subarchivos demasiado grandes resultan desventajosos porque requieren una memoria tampón de mayor tamaño y porque provocan un retardo adicional cuando se inicia la reproducción o cuando se invocan saltos o cambios de velocidad. Se consideran satisfactorios los subarchivos de un tamaño entre el 30% y el 130% del tiempo de reproducción o, preferentemente, aproximadamente la mitad del tiempo de reproducción (como en los ejemplos proporcionados anteriormente).

El procedimiento concreto de conversión de los subarchivos puede implementarse por medio de un ordenador programado según los criterios descritos. Probablemente, resultará conveniente realizar esta tarea en un ordenador separado, desde el cual se pueden cargar los subarchivos en el servidor.

Otra modificación que puede añadirse es la utilización de una convención de nomenclatura de subarchivos más compleja para incrementar la seguridad y dificultar la copia de los subarchivos por personas no autorizadas y la oferta de éstos en otro servidor. En un ejemplo, los nombres de archivos se generan utilizando un generador de secuencias pseudoaleatorias que crea nombres de archivos de la siguiente forma:

: 01302546134643677534543134.bin

: 94543452345434533452134565.bin

: ...

En este caso, el programa reproductor incluye un generador de secuencias pseudoaleatorias idéntico. El servidor envía el primer nombre de archivo, o un "valor inicial o semilla" que puede ser de cuatro dígitos, y el generador del reproductor puede entonces sincronizar su generador y generar los nombres de los subarchivos necesarios en la secuencia correcta.

En el ejemplo anterior de cambio de velocidades, todas las velocidades de transmisión de datos utilizadas presentan el mismo tamaño de trama; en particular, se utiliza la codificación MP3 de audio PCM sometido a muestreo con una frecuencia de 11,025 KHz y un tamaño de trama (PCM) de 1.152 muestras. Cuando se desea realizar un cambio de velocidades entre grabaciones MP3 (o de otro tipo) que presentan tamaños de trama diferentes, se plantean problemas debido al requisito que obliga a los subarchivos a contener un conjunto completo de tramas, puesto que los límites de las tramas no coinciden. Este problema puede resolverse mediante el procedimiento indicado a continuación, modificado para crear los subarchivos. Debe tenerse en cuenta, en particular, que este procedimiento puede utilizarse en cualquier situación en la que se necesite cambiar de velocidades, y que no se limita al procedimiento de suministro concreto descrito anteriormente.

En la Figura 4, se representa en forma de diagrama una secuencia de muestras de audio, sobre las cuales se trazan segmentos consecutivos de cuatro segundos identificados mediante marcas de límite (en la figura, B1, B2, etc.). A 11,025 KHz, existen 44.100 muestras en cada segmento.

El procedimiento consta de las etapas siguientes:

1.: Empezando por el límite B1, codificación del audio de trama en trama para crear un subarchivo MP3, y continuación hasta que se haya codificado un conjunto completo de tramas que tenga una duración total de por lo menos cuatro segundos. Con un tamaño de trama de 1.152 muestras, cuatro segundos corresponden a 38,3 tramas. Por lo tanto, lo que se codificará en realidad es un subarchivo S1 que representa 39 tramas y una duración total de 4,075 segundos.

2.: Empezando por el límite B2, codificación del audio de la manera indicada.

3.: Repetición, empezando cada vez por un límite de 4 segundos, para generar de ese modo un conjunto de subarchivos superpuestos para la secuencia de audio completa que se desea codificar. El último segmento (que también puede ser inferior a cuatro segundos) como tal no tiene ningún segmento que le siga y se rellena con ceros (es decir, con silencio).

La codificación de las otras velocidades de transmisión de datos utilizando tamaños de tramas diferentes se realiza de la misma manera.

En el terminal, los mecanismos de control son los mismos, pero el procedimiento de decodificación y almacenamiento en memoria tampón se modifica:

1.: Recepción de subarchivo S1;

2.: Decodificación de subarchivo S1;

3.: Escritura en la memoria tampón de sólo los cuatro primeros segundos de las muestras de audio decodificadas (rechazar los restantes);

4.: Recepción de subarchivo S2;

5.: Decodificación de subarchivo S2;

6.: Escritura en la memoria tampón de sólo los cuatro primeros segundos de las muestras de audio decodificadas;

7.: Continuación con el subarchivo S3, etc.

De esta forma, se asegura que los conjuntos de subarchivos de todas las velocidades presenten límites de subarchivos que correspondan a los mismos puntos de la secuencia de muestras PCM original.

Por lo tanto, cada período de cuatro segundos excepto el último se "rellena", antes de la codificación, con muestras de audio del siguiente período de cuatro segundos, para que el tamaño del subarchivo abarque un conjunto completo de tramas MP3. Si se desea, las muestras de relleno pueden obtenerse del final del período de cuatro segundos anterior, en lugar (o además) del principio del siguiente período de cuatro segundos.

Debe tenerse en cuenta que la norma MP3 permite transferir (mediante un sistema denominado "reserva de bits") cierto tipo de información de una trama de audio a otra. En el presente contexto, aunque esta acción es aceptable dentro de un subarchivo, no es aceptable entre subarchivos. No obstante, la norma evidentemente no permite dicha transferencia al final o al principio de una grabación y, entonces, este problema se resuelve fácilmente codificando por separado cada subarchivo, como si se tratara de una sola grabación.

Los cambios de frecuencia de muestreo (y de hecho del cambio entre funcionamiento mono y estéreo) presentan algunas implicaciones prácticas para el funcionamiento de la interfaz de audio 36. Muchas tarjetas de sonido convencionales, aunque son capaces de trabajar con un rango de valores diferentes, deben ser reajustadas para cambiar la frecuencia de muestreo, lo cual provoca necesariamente una interrupción en la salida de audio. Por lo tanto, en otra modificación, se propone ejecutar de forma continua la tarjeta de sonido a la frecuencia de muestreo más alta prevista. Cuando el programa reproductor está suministrando datos a la memoria tampón a una frecuencia de muestreo baja, estos datos se sobremuestrean hasta esta frecuencia más alta antes o después de la memoria tampón. Análogamente, si la tarjeta es utilizada siempre en modalidad estéreo, pueden aplicarse en paralelo señales mono decodificadas para introducirlas de ese modo por el canal izquierdo y el derecho de la entrada de la tarjeta de sonido. También en este caso, si el número de bits por muestra de la señal decodificada es inferior al que espera la tarjeta, el número de bits puede incrementarse mediante relleno con ceros.

Como se recordará, el criterio descrito anteriormente para el cambio automático descendente de la velocidad de transmisión de datos contempla la posibilidad de reducir la velocidad sólo en los casos de insuficiencia de memoria tampón (lo cual conlleva interrupciones en la salida). Téngase en cuenta, pues, que con esta modificación dicha interrupción puede evitarse y, por consiguiente, se aplica un criterio que prevé la insuficiencia y la evita en la mayoría de casos. En este caso, la primera de las tres condiciones "Y" mencionadas anteriormente (es decir, que la memoria tampón está vacía) se omitirá.

El mismo principio puede aplicarse al suministro de grabaciones de vídeo o, por supuesto, grabaciones de vídeo con una banda sonora acompañante. En la versión más simple, en la que sólo se dispone de una grabación, el sistema difiere de la versión de audio sólo en que el archivo es un archivo de vídeo (p.ej., en formato H.261 o MPEG) y en que el programa reproductor incorpora un decodificador de vídeo. La forma de dividir el archivo en subarchivos no cambia.

Como en el caso del audio, puede haber dos o más grabaciones correspondientes a diferentes velocidades de transmisión de datos, seleccionadas mediante el mecanismo de control que ya se ha descrito. Asimismo, se pueden proporcionar grabaciones adicionales correspondientes a diferentes modalidades de reproducción, tales como "avance rápido" o "retroceso rápido", que pueden seleccionarse mediante una ampliación de las funciones de control del usuario ya descritas. También puede seguirse una convención sistemática para la nomenclatura de archivos y directorios, de tal forma que el programa reproductor pueda responder, por ejemplo, a un mandato de avance rápido, enmendando la dirección del subarchivo.

El suministro de grabaciones de vídeo tiene, sin embargo, otras repercusiones en la división de los archivos cuando se van a permitir los cambios o los saltos. En los casos en que cada una de las tramas de una imagen de una grabación se codifica independientemente, basta con que los subarchivos contengan un conjunto completo de tramas de la imagen. No obstante, si se utiliza el tipo de compresión que incluye técnicas intertrama, la situación es más compleja. Algunos de dichos sistemas (por ejemplo, los que cumplen las normas MPEG) generan una mezcla de tramas codificadas independientemente ("intratramas") y de tramas sometidas a codificación predictiva. En este caso, cada subarchivo deberá empezar, preferentemente, con una intratrama.

En el caso de los sistemas de codificación intertrama, tales como los sistemas según la norma ITU H.261, que no prevén la inclusión frecuente y regular de intratramas, esto no es posible. Esta imposibilidad se debe a que, tomando como ejemplo el cambio de velocidades, si se solicita el subarchivo n de una grabación de velocidad binaria superior seguido del subarchivo n+1 de una grabación de velocidad binaria inferior, la primera trama del subarchivo de velocidad binaria inferior habrá sido sometida a codificación intertrama utilizando la última trama decodificada del subarchivo n de la grabación de velocidad inferior, trama que por supuesto el terminal no tiene a su disposición, sino que dispone de la última trama decodificada del subarchivo n de la grabación de velocidad superior. Entonces, se produciría un grave error de pista.

En el caso del cambio entre una modalidad de reproducción normal y una modalidad de reproducción rápida, la situación es ligeramente diferente en la práctica. En la reproducción de avance rápido (a 5 veces la velocidad normal, por ejemplo), se codifica sólo cada 5ª trama. En consecuencia, la correlación intertrama es mucho más reducida y la codificación intertrama no resulta atractiva. Por este motivo, generalmente se preferirá codificar una secuencia de reproducción rápida en intratramas. Entonces, el cambio de la modalidad normal a la rápida no planteará ningún problema, puesto que las intratramas pueden codificarse sin dificultad. No obstante, cuando se vuelva a la modalidad de reproducción normal, también se producirá el error de pista, ya que el terminal recibirá una trama sometida a codificación predictiva para la cual no dispone de la trama precedente.

En cualquier caso, el problema puede resolverse utilizando el principio descrito en la solicitud de patente internacional nº WO98/26604 (publicada en USA como patente nº 6.002.440). Esto implica la codificación de una secuencia intermedia de tramas que salva la distancia entre la última trama de la secuencia precedente y la primera trama de la nueva secuencia.

A continuación, se describirá este procedimiento en el contexto del funcionamiento de avance rápido (considérese que el retroceso rápido es similar pero a la inversa). En este ejemplo, se supone que se ha codificado una secuencia de vídeo de 9 minutos de conformidad con la norma H.261 a 96 kbit/s y luego a 5 veces la velocidad normal en intratramas H.261, y que cada uno de los archivos resultantes se ha dividido en subarchivos de cuatro segundos. En este ejemplo, la cantidad de cuatro segundos hace referencia a la duración de la señal de vídeo original, no al tiempo de reproducción de avance rápido. Siguiendo una convención de nomenclatura similar a la empleada anteriormente, los subarchivos pueden ser:

5

siendo "nombre" un nombre para identificar la grabación particular, "x1" la velocidad normal y "x5" cinco veces la velocidad normal, o sea, la velocidad de avance rápido.

Para cambiar de reproducción normal a avance rápido, basta con que el programa reproductor modifique la dirección del subarchivo para que indique la secuencia de avance rápido, por ejemplo:

: Request nombre_mpg/096k_x1/000055.bin

viene seguida de la petición

: Request nombre_mpg/096k_x5/000056.bin.

Para construir las secuencias puente y volver a cambiar a la reproducción normal es necesario construir un subarchivo puente para cada transición posible. Como se describe en la solicitud de patente internacional mencionada anteriormente, una secuencia de tres o cuatro tramas generalmente es suficiente para salvar la distancia. Entonces, un procedimiento simple de implementación consistirá en construir subarchivos puente de sólo 4 tramas de duración, tales como:

Directorio	Subdirectorio	Nombre de archivo

nombre_mpg	096K_5>1	0000001.bin
		...
		000133.bin

\vskip1.000000\baselineskip

Por consiguiente, el cambio se realiza mediante una serie de peticiones, tales como:

: Request nombre_mpg/096k_x5/000099.bin

: Request nombre_mpg/096k_5>1/000099.bin

: Request nombre_mpg/096k_x1/000100.bin

El subarchivo puente se genera de la forma siguiente:

\bullet: Se decodifica la secuencia de avance rápido para obtener una versión decodificada de la última trama del subarchivo 99 (a 25 tramas por segundo, esta trama será la número 100.000 de la señal de vídeo original).

\bullet: Se decodifica la secuencia normal para obtener una versión decodificada de la primera trama del subarchivo 100 (es decir, la trama 100.001). Se recodifica esta trama cuatro veces mediante codificación intertrama H.261 basada en la trama decodificada 100.000 como trama inicial de referencia.

\bullet: Por lo tanto, una vez que el decodificador haya decodificado el subarchivo de avance rápido seguido del subarchivo puente, habrá reconstruido correctamente la trama100.000 y estará preparado para decodificar las tramas normales (x1). Debe observarse que el motivo por el cual en este procedimiento se codifica varias veces la misma trama es que, si sólo se codificara una vez, se obtendría una calidad de imagen deficiente debido a las características de cuantificación del formato H.261.

Podría utilizarse exactamente el mismo procedimiento para el cambio de velocidades (si bien es cierto que entonces se necesitarían subarchivos puente en ambas direcciones). No obstante, se observará que, como se ha descrito, el archivo puente da por resultado la congelación de la imagen durante un período de cuatro tramas (es decir, a 25 tramas por segundos, un período de 160 ms). Cuando se cambia de reproducción rápida a normal, esto es aceptable (en realidad, probablemente se decida borrar la memoria tampón en ese momento). Esto puede ser o no subjetivamente aceptable cuando se cambian las velocidades. Otra posibilidad sería, por consiguiente, construir una secuencia puente de cuatro segundos. Entonces la serie de peticiones tendría el siguiente aspecto:

: nombre_mpg/096k_x1/000099.bin

: nombre_mpg/096/128_x1/000100.bin

: nombre_mpg/128k_x1/000101.bin

El subarchivo puente en este caso se construirá o bien recodificando cuatro veces la quinta trama decodificada de la secuencia de 128 kbit/s decodificada empezando por la trama de 96 kbit/s decodificada 100.000 que se toma como trama de referencia, o bien codificando las cuatro primeras tramas de la secuencia de 128 kbit/s decodificada empezando por la trama de 96 kbit/s decodificada 100.000 que se toma como trama de referencia. En ambos casos, las 96 tramas restantes del subarchivo puente serán una copia del subarchivo de 128 kbit/s.

Los archivos que se van a suministrar se han denominado "grabaciones". No obstante, no es necesario codificar (o incluso que exista) toda la secuencia de audio o vídeo antes de iniciar el suministro. Por lo tanto, puede proporcionarse un ordenador que reciba una emisión en directo y la codifique mediante el sistema de codificación elegido, y que genere "sobre la marcha" los subarchivos y los cargue en el servidor, de tal forma que, una vez que los subarchivos están presentes en el servidor, pueda iniciarse el suministro.

Una de las aplicaciones de este sistema de suministro puede hallarse en un sistema de mensajes de voz, como el ilustrado en la Figura 5 en la que se representan otra vez el servidor 1, la red 2 y el terminal 3. Se utiliza una interfaz de mensajes de voz 4 para recibir llamadas telefónicas (por ejemplo, por medio de la red telefónica pública conmutada o PSTN 5), grabar un mensaje, codificarlo, dividirlo en subarchivos y cargar los subarchivos en el servidor 1, donde podrá accederse a éstos de la manera descrita anteriormente. Como alternativa, puede proporcionarse una segunda interfaz 6 que funciona de forma similar al terminal 3 pero es controlada remotamente, a través de la PSTN, por un teléfono remoto 5 al que se envían las señales de audio reproducidas.

Puede utilizarse el mismo sistema para una emisión de audio (o vídeo) en directo. En cierto sentido, lo que se suministra sigue siendo "grabado", siendo la diferencia fundamental que el suministro y la reproducción empiezan antes de que la grabación haya terminado, aunque, por supuesto, exista un retardo intrínseco por la necesidad de esperar a que por lo menos uno de los subarchivos haya sido grabado y cargado en el servidor 1.

El sistema puede continuar de la forma descrita anteriormente y resultará bastante satisfactorio, excepto por el hecho de que la reproducción se iniciará en el principio, mientras que muy probablemente el usuario desee que se inicie en el momento actual, es decir, con el último subarchivo creado.

Con una secuencia de audio prolongada, se puede tomar la decisión de suprimir los subarchivos antiguos para liberar memoria. Con una emisión continua (es decir, de 24 horas al día) esto resultará inevitable y, además, será necesario reutilizar los nombres de los subarchivos (en el sistema prototipo, se utilizan los nombres 000000.bin a 009768.bin y luego se empieza otra vez por 000000.bin), de tal forma que los subarchivos antiguos son sobrescritos constantemente con los nuevos. Un procedimiento simple para asegurar que el suministro empiece por el subarchivo más reciente consistirá en incluir en el archivo de índices un mandato adicional que dé la orden al programa reproductor de empezar solicitando el subarchivo adecuado. Sin embargo, esto tiene la desventaja de que es necesario modificar el archivo de índices con mucha frecuencia (lo ideal sería cada vez que se crea un nuevo subarchivo). Por consiguiente, se propone un procedimiento por medio del cual el programa reproductor explora el servidor para hallar el subarchivo inicial, de la forma indicada a continuación. En el archivo de índices, el parámetro Modalidad se establece en "en directo" para provocar la invocación de este procedimiento por el programa reproductor. El LFI se establece en un valor que indica el número máximo de subarchivos que se pueden almacenar, pongamos por caso 9768. El procedimiento incluye las etapas proporcionadas a continuación y presupone (como es habitual) que se ha determinado la última modificación de la hora y la fecha de cada subarchivo. Cuando se utiliza el protocolo HTTP, esto puede llevarse a cabo utilizando una petición HEAD que no da por resultado el suministro del subarchivo solicitado, sino sólo el suministro de la información de cabecera que indica la hora a la que se ha registrado el subarchivo en el servidor, o el valor cero si el subarchivo no existe. El procedimiento se representa esta vez como una función GetURL(LiveIndex), siendo LiveIndex el número de secuencia del subarchivo en cuestión. Los comentarios van precedidos del símbolo "//".

100

Una vez que se ha hallado LiveIndex resultará prudente retroceder el Tp (tiempo de reproducción) y empezar a realizar las peticiones para rellenar la memoria tampón de audio desde allí. La reproducción podrá comenzar de la forma normal.

Una vez que la grabación ha terminado, el archivo de índices puede modificarse, si así se desea, para cambiar el parámetro Modalidad a "grabado" y establecer cualquier parámetro de duración.

Si se desea, el programa reproductor puede verificar periódicamente si el archivo de índices ha pasado de la
modalidad "en directo" a la modalidad "grabado" para cambiar, en tal caso, a la reproducción en modalidad
"grabado".

A continuación, se describirá un procedimiento más simple y mucho más rápido de identificación del subarchivo más "reciente", suponiendo, antes que nada, que se dispone de una sola secuencia de numeración de subarchivos continua.

1.: El terminal emite una petición HEAD para el primer subarchivo (p.ej., 000000.bin).

2.: El servidor responde enviando la cabecera de este archivo e incluye la fecha y la hora a la que se ha realizado la última modificación del archivo (MODTIME), y la fecha y la hora a la que se ha enviado esta respuesta (REPLYTIME) (ambos campos son de tipo http estándar).

3.: El terminal calcula el tiempo transcurrido (ELTIME) restando ambos campos (ELTIME = REPLYTIME - MODTIME), y divide el resultado por la duración de reproducción de un subarchivo (4 segundos, en estos ejemplos) para obtener LIVEINDEX = ELTIME/4.

4.: El terminal calcula el nombre de archivo del subarchivo que presenta este índice.

\newpage

5.: El terminal emite una petición HEAD con este nombre de archivo y, si es necesario, cada nombre de archivo subsiguiente hasta que recibe el valor cero (archivo no encontrado), momento en el cual se considera que el último subarchivo que se ha hallado es el "subarchivo actual".

6.: El terminal empieza a solicitar archivos, empezando en el punto J1: del diagrama de flujo proporcionado antes.

Este procedimiento es considerablemente más rápido que el descrito anteriormente para los subarchivos numerados cíclicamente. Debe tenerse en cuenta que los subarchivos antiguos también pueden suprimirse para reducir los requisitos de memoria, siempre y cuando se mantenga el subarchivo inicial. Sin embargo, el procedimiento puede modificarse para que tenga capacidad para reutilizar los nombres de los archivos (direcciones cíclicas), aunque será necesario:

(i): que el nombre del subarchivo inicial (p.ej., 000000.bin) no sea reutilizado y que, por consiguiente, siempre esté disponible para suministrar la información de cabecera en la etapa 2. Por lo tanto, si el punto de reutilización de los nombres de los subarchivos se halla en 009768.bin, el subarchivo 009768.bin irá seguido del subarchivo 000001.bin.

(ii): calcular el Módulo 9768 del número LIVEINDEX calculado en la etapa 3 (es decir, el resto cuando ELTIME/4 se divide por 9768).

(iii): que la supresión de subarchivos siempre lleve a la creación de nuevos subarchivos, para que de ese modo no exista ningún nombre de archivo entre el subarchivo recién creado y el subarchivo antiguo no suprimido, y para que la respuesta "archivo no encontrado" esperada se reciba en la etapa 5.

Existe el riesgo de que la operación de reproducción se ejecute a una velocidad ligeramente más rápida o más lenta que la operación de registro. Para prevenir este riesgo, puede disponerse que el programa reproductor compruebe si cada subarchivo que recibe está marcado con una hora posterior a la anterior. De no ser así, el subarchivo se rechaza y se realizan repetidas peticiones (por ejemplo, tres veces) seguidas de una comprobación del archivo de índices si dichas peticiones resultan infructuosas.

El programa reproductor puede determinar si la reproducción va por detrás del procedimiento de registro, comprobando de vez en cuando si existe en el servidor un número significativo de subarchivos más recientes que los que se solicitan actualmente y, si dichos subarchivos existen, iniciar un procedimiento de "recuperación" (p.ej., rechazando con regularidad una pequeña cantidad de datos).

Claims

1. Procedimiento para codificar señales de audio de entrada que comprende: la codificación, con un primer algoritmo de codificación que presenta una primera longitud de trama, de cada una de las primeras partes temporales consecutivas de la señal de entrada, cuyas partes corresponden a un número entero de dichas primeras longitudes de trama y son contiguas o se superponen, para generar una primera secuencia codificada; la codificación, con un segundo algoritmo de codificación que presenta una segunda longitud de trama, de cada una de las segundas partes temporales consecutivas de la señal de entrada, cuyas partes corresponden a un número entero de dichas segundas longitudes de trama y no corresponden a un número entero de dichas primeras longitudes de trama y están superpuestas, para generar una segunda secuencia codificada, de tal forma que cada zona superpuesta de la segunda secuencia codificada abarca, por lo menos, una parte de un límite la primera secuencia codificada; e incluye asimismo la aplicación de una secuencia codificada a una salida y, en respuesta a un mandato de cambio, el cambio de la salida que va a ser suministrada por la otra secuencia codificada, realizándose dicho cambio en el límite entre una parte temporal codificada y la siguiente.

2. Procedimiento según la reivindicación 1, en el que el primer y el segundo algoritmos de codificación corresponden a unas respectivas velocidades de transmisión de datos de salida diferentes.

3. Procedimiento para transmitir señales de audio que comprende:

codificar las señales utilizando el procedimiento según la reivindicación 1 ó 2;

decodificar las partes discretas; y

rechazar la parte de la señal decodificada que corresponde a dicho final y/o principio.