El formato de archivo de intercambio de recursos ( RIFF ) es un formato de contenedor de archivos genérico para almacenar datos en fragmentos etiquetados . [2] Se utiliza principalmente para audio y video, aunque se puede utilizar 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 los archivos multimedia de Windows 3.1 . Se basa en el formato de archivo de intercambio introducido por Electronic Arts en 1985 en el Amiga . IFF utiliza la convención big-endian de la CPU Motorola 68000 del Amiga , pero en RIFF los números enteros de varios bytes se almacenan en el orden little-endian de los procesadores x86 utilizados en los IBM PC compatibles . 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 están compuestos en su totalidad por " fragmentos ". El formato general es idéntico al de IFF , excepto por el orden de bits indicado 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 con el formato correcto formateará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 tamaños de archivo superiores a 4 gigabytes . Para ello, proporciona un fragmento "ds64" con un tamaño de 64 bits (8 bytes).
El fragmento opcional INFO permite que los archivos RIFF se "etiqueten" con información que pertenece a una serie de categorías predefinidas, como copyright ("ICOP"), comentarios ("ICMT"), artista ("IART"), de forma estandarizada. Estos detalles se pueden leer desde un archivo RIFF incluso si el resto del formato del archivo no se reconoce. El estándar también permite el uso de campos definidos por el usuario. Los programadores que tengan intención de utilizar campos no estándar deben tener en cuenta que el mismo ID de subfragmento no estándar puede ser utilizado por diferentes aplicaciones de formas diferentes (y potencialmente incompatibles).
En línea 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 que se utilizaba para almacenar información de canciones que se iban a reproducir en instrumentos musicales electrónicos. El formato de archivo MIDI de Microsoft consistía en un archivo MIDI estándar incluido 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" incrustada, esto causaba la desventaja de tener que lidiar con dos formatos de archivo para el mismo tipo de información.
Desde entonces, la Asociación de Fabricantes MIDI ha adoptado el formato de archivo MIDI basado en RIFF y lo ha utilizado como base de un "archivo midi extendido" que también incluye datos de instrumentos en formato " DLS ", integrados dentro del mismo archivo .RMI.
Para fines de catalogación, la posición óptima para el fragmento INFO es cerca del comienzo del archivo. Sin embargo, dado que el fragmento INFO es opcional, a menudo se omite en las especificaciones detalladas de los formatos de archivo individuales, lo que genera cierta confusión sobre la posición correcta para este fragmento dentro de un archivo.
Cuando se trabaja con archivos multimedia de gran tamaño, 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 deba 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 puede consumir mucho espacio en el disco. Una solución alternativa es "rellenar" el fragmento INFO inicial con datos ficticios (utilizando 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 programa escrito de forma inteligente puede sobrescribir solo el encabezado del archivo cuando se modifican los datos de etiquetado, sin modificar ni mover el cuerpo principal del 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 dado lugar a dos convenciones diferentes para la colocación de fragmentos, con el riesgo asociado de que algunas combinaciones de software puedan hacer que los datos INFO de un archivo se ignoren o se sobrescriban de forma permanente durante la edición. Los programas más sofisticados tendrán en cuenta la posibilidad de una colocación "inesperada" de fragmentos 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 guardarlos, reubicará el fragmento INFO de nuevo en el encabezado del archivo.
Aunque CorelDRAW 10 utiliza nominalmente una estructura de archivo 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 mostrara en el administrador de archivos de Windows de manera predeterminada. Una utilidad de "parche" que se incluye con el programa soluciona este problema.
Las etiquetas de información RIFF se encuentran en archivos de audio WAV y de vídeo AVI.
El campo consta de dos valores (v[0] y v[1]) separados por un espacio (0x20). Código de ejemplo:
// tiempo en segundos - "concatena" 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 Unix del 1 de enero de 1970 (369 años y días bisiestos) UnixTimeStamp = TimeInSeconds - 134774 * 24 * 3600 ;