ES2277954T3 - Codificacion de señales de audio. - Google Patents
Codificacion de señales de audio. Download PDFInfo
- Publication number
- ES2277954T3 ES2277954T3 ES01983700T ES01983700T ES2277954T3 ES 2277954 T3 ES2277954 T3 ES 2277954T3 ES 01983700 T ES01983700 T ES 01983700T ES 01983700 T ES01983700 T ES 01983700T ES 2277954 T3 ES2277954 T3 ES 2277954T3
- Authority
- ES
- Spain
- Prior art keywords
- subfile
- file
- coding
- audio
- subfiles
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
- 238000000034 method Methods 0.000 claims abstract description 41
- 230000008859 change Effects 0.000 claims abstract description 23
- 230000004044 response Effects 0.000 claims abstract description 4
- 230000005236 sound signal Effects 0.000 abstract description 8
- 230000005540 biological transmission Effects 0.000 description 10
- 238000005070 sampling Methods 0.000 description 7
- 238000012546 transfer Methods 0.000 description 7
- 230000009467 reduction Effects 0.000 description 6
- 238000010586 diagram Methods 0.000 description 5
- 230000004048 modification Effects 0.000 description 5
- 238000012986 modification Methods 0.000 description 5
- 238000004891 communication Methods 0.000 description 4
- 230000006835 compression Effects 0.000 description 4
- 238000007906 compression Methods 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- IJJWOSAXNHWBPR-HUBLWGQQSA-N 5-[(3as,4s,6ar)-2-oxo-1,3,3a,4,6,6a-hexahydrothieno[3,4-d]imidazol-4-yl]-n-(6-hydrazinyl-6-oxohexyl)pentanamide Chemical compound N1C(=O)N[C@@H]2[C@H](CCCCC(=O)NCCCCCC(=O)NN)SC[C@@H]21 IJJWOSAXNHWBPR-HUBLWGQQSA-N 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 230000000750 progressive effect Effects 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 238000011002 quantification Methods 0.000 description 2
- 238000011084 recovery Methods 0.000 description 2
- 230000002441 reversible effect Effects 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 230000002950 deficient Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000008014 freezing Effects 0.000 description 1
- 238000007710 freezing Methods 0.000 description 1
- 230000000873 masking effect Effects 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 230000005055 memory storage Effects 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000002035 prolonged effect Effects 0.000 description 1
- 230000001850 reproductive effect Effects 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 230000009897 systematic effect Effects 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L27/00—Modulated-carrier systems
-
- G—PHYSICS
- G10—MUSICAL INSTRUMENTS; ACOUSTICS
- G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
- G10L19/00—Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis
- G10L19/04—Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis using predictive techniques
- G10L19/16—Vocoder architecture
- G10L19/18—Vocoders using multiple modes
- G10L19/24—Variable rate codecs, e.g. for generating different qualities using a scalable representation such as hierarchical encoding or layered encoding
-
- G—PHYSICS
- G10—MUSICAL INSTRUMENTS; ACOUSTICS
- G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
- G10L19/00—Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis
- G10L19/04—Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis using predictive techniques
- G10L19/16—Vocoder architecture
- G10L19/167—Audio streaming, i.e. formatting and decoding of an encoded audio signal representation into a data stream for transmission or storage purposes
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Health & Medical Sciences (AREA)
- Audiology, Speech & Language Pathology (AREA)
- Human Computer Interaction (AREA)
- Physics & Mathematics (AREA)
- Acoustics & Sound (AREA)
- Computational Linguistics (AREA)
- Quality & Reliability (AREA)
- Computer Networks & Wireless Communication (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Signal Processing For Digital Recording And Reproducing (AREA)
- Compression, Expansion, Code Conversion, And Decoders (AREA)
- Reduction Or Emphasis Of Bandwidth Of Signals (AREA)
- Transmission Systems Not Characterized By The Medium Used For Transmission (AREA)
- Amplifiers (AREA)
- Signal Processing Not Specific To The Method Of Recording And Reproducing (AREA)
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.
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)
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.5cm032k_11_s
\hskip0.5cm018k_11_s
\hskip0.5cm016k_11_m
\hskip0.5cm008_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)
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:
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 "//".
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".
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 (3)
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.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP00311275A EP1215663A1 (en) | 2000-12-15 | 2000-12-15 | Encoding audio signals |
EP00311275 | 2000-12-15 |
Publications (1)
Publication Number | Publication Date |
---|---|
ES2277954T3 true ES2277954T3 (es) | 2007-08-01 |
Family
ID=8173454
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES01983700T Expired - Lifetime ES2277954T3 (es) | 2000-12-15 | 2001-11-19 | Codificacion de señales de audio. |
Country Status (11)
Country | Link |
---|---|
US (1) | US7222068B2 (es) |
EP (2) | EP1215663A1 (es) |
JP (1) | JP4270868B2 (es) |
KR (1) | KR100838052B1 (es) |
CN (1) | CN1217317C (es) |
AT (1) | ATE347729T1 (es) |
AU (2) | AU1512202A (es) |
CA (1) | CA2429735C (es) |
DE (1) | DE60125061T2 (es) |
ES (1) | ES2277954T3 (es) |
WO (1) | WO2002049008A1 (es) |
Families Citing this family (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
ATE396588T1 (de) | 2002-01-18 | 2008-06-15 | Koninkl Philips Electronics Nv | Audio-kodierung |
US9323571B2 (en) * | 2004-02-06 | 2016-04-26 | Intel Corporation | Methods for reducing energy consumption of buffered applications using simultaneous multi-threading processor |
US20050185541A1 (en) * | 2004-02-23 | 2005-08-25 | Darren Neuman | Method and system for memory usage in real-time audio systems |
US7594254B2 (en) * | 2004-03-22 | 2009-09-22 | Cox Communications, Inc | System and method for transmitting files from a sender to a receiver in a television distribution network |
WO2005099243A1 (ja) * | 2004-04-09 | 2005-10-20 | Nec Corporation | 音声通信方法及び装置 |
US8868772B2 (en) | 2004-04-30 | 2014-10-21 | Echostar Technologies L.L.C. | Apparatus, system, and method for adaptive-rate shifting of streaming content |
US7818444B2 (en) | 2004-04-30 | 2010-10-19 | Move Networks, Inc. | Apparatus, system, and method for multi-bitrate content streaming |
DE102004047069A1 (de) * | 2004-09-28 | 2006-04-06 | Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. | Vorrichtung und Verfahren zum Ändern einer Segmentierung eines Audiostücks |
DE102004047032A1 (de) * | 2004-09-28 | 2006-04-06 | Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. | Vorrichtung und Verfahren zum Bezeichnen von verschiedenen Segmentklassen |
US8683066B2 (en) | 2007-08-06 | 2014-03-25 | DISH Digital L.L.C. | Apparatus, system, and method for multi-bitrate content streaming |
US8370514B2 (en) * | 2005-04-28 | 2013-02-05 | DISH Digital L.L.C. | System and method of minimizing network bandwidth retrieved from an external network |
JP4639966B2 (ja) * | 2005-05-31 | 2011-02-23 | ヤマハ株式会社 | オーディオデータ圧縮方法およびオーディオデータ圧縮回路並びにオーディオデータ伸張回路 |
CN101231850B (zh) * | 2007-01-23 | 2012-02-29 | 华为技术有限公司 | 编解码方法及装置 |
EP2112653A4 (en) * | 2007-05-24 | 2013-09-11 | Panasonic Corp | AUDIO DEODICATION DEVICE, AUDIO CODING METHOD, PROGRAM AND INTEGRATED CIRCUIT |
EP2131590A1 (en) * | 2008-06-02 | 2009-12-09 | Deutsche Thomson OHG | Method and apparatus for generating or cutting or changing a frame based bit stream format file including at least one header section, and a corresponding data structure |
JP2009294603A (ja) * | 2008-06-09 | 2009-12-17 | Panasonic Corp | データ再生方法、データ再生装置及びデータ再生プログラム |
US8321401B2 (en) | 2008-10-17 | 2012-11-27 | Echostar Advanced Technologies L.L.C. | User interface with available multimedia content from multiple multimedia websites |
US9510029B2 (en) | 2010-02-11 | 2016-11-29 | Echostar Advanced Technologies L.L.C. | Systems and methods to provide trick play during streaming playback |
US9942593B2 (en) * | 2011-02-10 | 2018-04-10 | Intel Corporation | Producing decoded audio at graphics engine of host processing platform |
CN103117958B (zh) * | 2013-01-08 | 2015-11-25 | 北京百度网讯科技有限公司 | 网络数据包聚集方法、系统及装置 |
CN105409230A (zh) * | 2014-05-27 | 2016-03-16 | 华为技术有限公司 | 媒体文件处理方法及装置 |
CN105429983B (zh) * | 2015-11-27 | 2018-09-14 | 刘军 | 采集媒体数据的方法、媒体终端及音乐教学系统 |
CN115497487A (zh) * | 2022-09-09 | 2022-12-20 | 维沃移动通信有限公司 | 音频信号处理方法、装置、电子设备及可读存储介质 |
Family Cites Families (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CA2140850C (en) * | 1994-02-24 | 1999-09-21 | Howard Paul Katseff | Networked system for display of multimedia presentations |
US5835495A (en) * | 1995-10-11 | 1998-11-10 | Microsoft Corporation | System and method for scaleable streamed audio transmission over a network |
US6118790A (en) * | 1996-06-19 | 2000-09-12 | Microsoft Corporation | Audio server system for an unreliable network |
US5903872A (en) * | 1997-10-17 | 1999-05-11 | Dolby Laboratories Licensing Corporation | Frame-based audio coding with additional filterbank to attenuate spectral splatter at frame boundaries |
US6124895A (en) * | 1997-10-17 | 2000-09-26 | Dolby Laboratories Licensing Corporation | Frame-based audio coding with video/audio data synchronization by dynamic audio frame alignment |
WO1999031888A1 (en) * | 1997-12-15 | 1999-06-24 | Matsushita Electric Industrial Co., Ltd. | Optical disc and computer-readable storage medium, and recording method and apparatus therefor |
US6061655A (en) * | 1998-06-26 | 2000-05-09 | Lsi Logic Corporation | Method and apparatus for dual output interface control of audio decoder |
US6366888B1 (en) * | 1999-03-29 | 2002-04-02 | Lucent Technologies Inc. | Technique for multi-rate coding of a signal containing information |
-
2000
- 2000-12-15 EP EP00311275A patent/EP1215663A1/en not_active Withdrawn
-
2001
- 2001-11-19 AU AU1512202A patent/AU1512202A/xx active Pending
- 2001-11-19 AT AT01983700T patent/ATE347729T1/de not_active IP Right Cessation
- 2001-11-19 CA CA002429735A patent/CA2429735C/en not_active Expired - Lifetime
- 2001-11-19 JP JP2002550638A patent/JP4270868B2/ja not_active Expired - Lifetime
- 2001-11-19 CN CN018205879A patent/CN1217317C/zh not_active Expired - Lifetime
- 2001-11-19 EP EP01983700A patent/EP1342231B1/en not_active Expired - Lifetime
- 2001-11-19 AU AU2002215122A patent/AU2002215122B2/en not_active Ceased
- 2001-11-19 DE DE60125061T patent/DE60125061T2/de not_active Expired - Lifetime
- 2001-11-19 ES ES01983700T patent/ES2277954T3/es not_active Expired - Lifetime
- 2001-11-19 WO PCT/GB2001/005082 patent/WO2002049008A1/en active IP Right Grant
- 2001-11-19 US US10/433,054 patent/US7222068B2/en not_active Expired - Lifetime
- 2001-11-19 KR KR1020037007741A patent/KR100838052B1/ko active IP Right Grant
Also Published As
Publication number | Publication date |
---|---|
CA2429735C (en) | 2008-08-26 |
WO2002049008A1 (en) | 2002-06-20 |
CN1481547A (zh) | 2004-03-10 |
DE60125061D1 (de) | 2007-01-18 |
AU2002215122B2 (en) | 2007-10-25 |
US7222068B2 (en) | 2007-05-22 |
US20040030547A1 (en) | 2004-02-12 |
CA2429735A1 (en) | 2002-06-20 |
JP4270868B2 (ja) | 2009-06-03 |
EP1215663A1 (en) | 2002-06-19 |
CN1217317C (zh) | 2005-08-31 |
EP1342231A1 (en) | 2003-09-10 |
AU1512202A (en) | 2002-06-24 |
EP1342231B1 (en) | 2006-12-06 |
ATE347729T1 (de) | 2006-12-15 |
KR20030060984A (ko) | 2003-07-16 |
KR100838052B1 (ko) | 2008-06-12 |
JP2004516505A (ja) | 2004-06-03 |
DE60125061T2 (de) | 2007-06-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
ES2277954T3 (es) | Codificacion de señales de audio. | |
ES2342357T3 (es) | Transmision y recepcion de material de audio y/o video. | |
JP4087706B2 (ja) | オーディオおよび、またはビデオマテリアルの送信および受信 | |
CN104253999B (zh) | 用于发送内容的设备和方法 | |
CN101204015B (zh) | 一起提供运动信号和声音信号的方法和装置 | |
AU2002215122A1 (en) | Encoding audio signals | |
TWI513238B (zh) | 同步內容廣播傳輸系統 | |
JP2011505107A (ja) | 部分的に利用可能なマルチメディアコンテンツの再生のためのシステム及び方法 | |
CN102577307A (zh) | 使用url模板和构造规则的增强型块请求流送 | |
US20080195695A1 (en) | Contents Distributing System, Client, Server, Contents Distributing Method, and Contents Reproducing Method | |
KR20040102091A (ko) | 데이터 처리 시스템, 데이터 처리 방법 및 데이터 처리장치와 데이터 처리 프로그램 | |
US20070270986A1 (en) | Audio Reproduction Device | |
CN101430910B (zh) | 数据记录方法和数据解码方法 | |
KR100456110B1 (ko) | 무선통신을 이용한 엠피3 플레이어 및 그 재생방법 | |
KR20090041219A (ko) | 메타데이터를 포함하는 ucc 파일 생성/변환 시스템 및ucc 파일 관리방법 | |
TW200820781A (en) | Image encoding/decoding apparatus and method thereof | |
JP3599207B2 (ja) | データ記録方法及び装置、データ再生方法及び装置、記録媒体、データ伝送方法及び装置 | |
JP2004343167A (ja) | ファイル記録装置及びファイル記録方法 | |
JP2003173622A (ja) | 符号化音声データ復号化装置及び符号化音声データ復号化方法 | |
JPH11213639A (ja) | 配信システム、配信方法、受信装置及び受信方法 | |
JPH03262222A (ja) | Fm多重信号送出装置 | |
JP2001345709A (ja) | 符号化器と復号器、及び、符号化方法と復号方法 | |
JPH11331771A (ja) | 符号化データの連続再生判定装置及び符号化データ復号装置並びにそれらの方法 | |
JP2006139535A (ja) | 移動通信端末装置 |