El formato de archivo de intercambio de recursos ( RIFF ) es un formato contenedor de archivos genérico para almacenar datos en fragmentos etiquetados . [2] Se utiliza principalmente para audio y vídeo, aunque puede utilizarse para datos arbitrarios. [3]
La implementación de Microsoft se conoce principalmente a través de formatos contenedores como AVI , ANI y WAV , que utilizan RIFF como base. [4]
RIFF fue introducido en 1991 por Microsoft e IBM y utilizado como formato predeterminado para archivos multimedia de Windows 3.1 . Está basado en el formato de archivo de intercambio introducido por Electronic Arts en 1985 en Amiga . IFF utiliza la convención big-endian de la CPU Motorola 68000 de Amiga , pero en RIFF los enteros multibyte se almacenan en el orden little-endian de los procesadores x86 utilizados en PC compatibles con IBM . También se introdujo un formato RIFX, que es big-endian.
En 2010, Google introdujo el formato de imagen WebP , que utiliza RIFF como contenedor. [5]
Los archivos RIFF constan enteramente de " fragmentos ". El formato general es idéntico a IFF , excepto por el endianismo como se indicó anteriormente y el significado diferente de los nombres de los fragmentos.
Todos los fragmentos tienen el siguiente formato:
Dos identificadores de fragmentos, "RIFF" y "LIST", introducen un fragmento que puede contener subfragmentos. Los datos de los fragmentos RIFF y LIST (que aparecen después del identificador y la longitud) tienen el siguiente formato:
El archivo en sí consta de un fragmento RIFF, que luego puede contener más subfragmentos: por lo tanto, los primeros cuatro bytes de un archivo RIFF formateado correctamente deletrearán "RIFF".
Puede encontrar más información sobre el formato RIFF en el artículo Formato de archivo de intercambio .
RF64 es un formato de archivo multicanal basado en la especificación RIFF, desarrollado por la Unión Europea de Radiodifusión . Es compatible con BWF y permite que el tamaño de los archivos supere los 4 gigabytes . Lo hace proporcionando un fragmento "ds64" con un tamaño de 64 bits (8 bytes).
El fragmento INFO opcional permite "etiquetar" archivos RIFF con información que se clasifica en una serie de categorías predefinidas, como derechos de autor ("ICOP"), comentarios ("ICMT"), artista ("IART"), de forma estandarizada. Estos detalles se pueden leer desde un archivo RIFF incluso si no se reconoce el resto del formato del archivo. El estándar también permite el uso de campos definidos por el usuario. Los programadores que deseen utilizar campos no estándar deben tener en cuenta que diferentes aplicaciones pueden utilizar el mismo ID de subfragmento no estándar de formas diferentes (y potencialmente incompatibles).
De acuerdo con su política de utilizar .RIFF para todos los archivos "multimedia" de Windows 3.1, Microsoft introdujo una nueva variante del formato de archivo MIDI existente utilizado para almacenar información de canciones que se reproducirán en instrumentos musicales electrónicos. El formato de archivo MIDI de Microsoft consistía en un archivo MIDI estándar encerrado en un contenedor RIFF y tenía la extensión de archivo .RMI . Dado que el formato de archivo MIDI existente ya admitía información de "etiquetado" incorporada, esto provocaba la desventaja de tener que tratar con dos formatos de archivo para el mismo tipo de información.
Desde entonces, la Asociación de Fabricantes MIDI adoptó el formato de archivo MIDI basado en RIFF y lo utilizó como base de un "archivo midi extendido" que también incluye datos de instrumentos en formato " DLS ", incrustados dentro del mismo archivo .RMI.
Para fines de catalogación, la posición óptima para el fragmento INFO es cerca del principio del archivo. Sin embargo, dado que el fragmento INFO es opcional, a menudo se omite en las especificaciones detalladas de los formatos de archivos individuales, lo que genera cierta confusión sobre la posición correcta de este fragmento dentro de un archivo.
Cuando se trata de archivos multimedia grandes, la expansión o contracción del fragmento INFO durante la edición de etiquetas puede provocar que la siguiente sección de "datos" del archivo tenga que leerse y reescribirse en el disco para adaptarse al nuevo tamaño del encabezado. Dado que los archivos multimedia pueden tener un tamaño de gigabytes, este es un proceso que potencialmente consume mucho disco. Una solución alternativa es "rellenar" el fragmento de INFORMACIÓN inicial utilizando datos ficticios (usando un "fragmento ficticio" o "fragmento de relleno") cuando se crea el archivo. La edición posterior puede expandir o contraer el campo "ficticio" para mantener constante el tamaño total del encabezado del archivo: un software escrito de forma inteligente puede sobrescribir sólo el encabezado del archivo cuando se cambian los datos de etiquetado, sin modificar ni mover el cuerpo principal del archivo. el archivo.
Algunos programas han intentado solucionar el problema colocando el fragmento INFO al final de un archivo multimedia, después del cuerpo principal del archivo. Esto ha resultado en dos convenciones diferentes para la colocación de fragmentos, con el consiguiente riesgo de que algunas combinaciones de software puedan hacer que los datos INFO de un archivo sean ignorados o sobrescritos permanentemente durante la edición. Los programas más sofisticados tendrán en cuenta la posibilidad de que se coloquen fragmentos "inesperados" en los archivos y responderán en consecuencia. Por ejemplo, cuando el programa de edición de audio Audacity encuentra un archivo .WAV con datos INFO colocados al final, identificará y leerá correctamente los datos, pero al guardar, reubicará el fragmento INFO nuevamente en el encabezado del archivo.
Aunque CorelDRAW 10 nominalmente usa una estructura de archivos RIFF, la versión inicial del programa colocó el fragmento INFO al final, de modo que cualquier mapa de bits de vista previa incrustado no se mostraría en el administrador de archivos de Windows de forma predeterminada. Una utilidad de "parche" suministrada con el programa soluciona este problema.
Las etiquetas de información RIFF se encuentran en archivos de audio WAV y vídeo AVI.
El campo consta de dos valores (v[0] y v[1]) separados por un espacio (0x20). Código de muestra:
// tiempo en segundos - "concatenar" elementos de fecha y hora con un delimitador de punto decimal TimeInSeconds = ( v [ 0 ] * ( 2 ^ 32 ) + v [ 1 ]) * 10 ^ ( -7 ); // cambia la base del 1 de enero de 1601 a la época de Unix el 1 de enero de 1970 (369 años y días bisiestos) UnixTimeStamp = TimeInSeconds - 134774 * 24 * 3600 ;