Ressursutvekslingsfilformat - Resource Interchange File Format

RIFF
Første utgivelse August 1991 ; 29 år siden  ( 1991-08 )
Type format Container
Utvidet fra Utveksle filformat
Utvidet til AVI , ANI , PAL, RDIB, RMIDI, RMMP, WAV

Den Resource filutvekslingsformat ( riff ) er en generisk fil container format for lagring av data i kodet biter . Det brukes primært til å lagre multimedia som lyd og video, men det kan også brukes til å lagre vilkårlige data.

Microsoft-implementeringen er mest kjent gjennom containerformater som AVI , ANI og WAV , som bruker RIFF som grunnlag.

Historie

RIFF ble introdusert i 1991 av Microsoft og IBM , og ble presentert av Microsoft som standardformat for Windows 3.1 multimediefiler. Den er basert på Electronic Arts ' Interchange File Format , introdusert i 1985 på Commodore Amiga , den eneste forskjellen er at flerbyte heltall er i lite endian- format, innfødt i 80x86- prosessorserien som brukes i IBM-PCer, i stedet for de store. -endian- format innfødt i 68k- prosessorserien som brukes i Amiga- og Apple Macintosh- datamaskiner, der IFF-filer ble mye brukt. Et RIFX-format, som bruker big-endian-format, ble også introdusert.

I 2010 introduserte Google WebP- bildeformatet, som bruker RIFF som en container.

Forklaring

RIFF-filer består utelukkende av " biter ". Det generelle formatet er identisk med IFF , bortsett fra endigheten som tidligere nevnt, og den forskjellige betydningen av klossnavnene.

Alle biter har følgende format:

  • 4 byte: en ASCII- identifikator for denne delen (eksemplene er "fmt" og "data"; merk mellomrom i "fmt").
  • 4 byte: et usignert, lite endian 32- biters heltall med lengden på denne klumpen (unntatt selve feltet og klumpidentifikatoren).
  • felt med variabel størrelse: selve klumpdataene, av størrelsen gitt i forrige felt.
  • en padbyte, hvis bunklengden ikke er jevn.

To klumpidentifikatorer, "RIFF" og "LIST", introduserer en klump som kan inneholde underbiter. RIFF- og LIST-klumpdataene (vises etter identifikatoren og lengden) har følgende format:

  • 4 byte: en ASCII-identifikator for denne spesielle RIFF- eller LIST-klumpen (for RIFF i det typiske tilfellet beskriver disse 4 byte innholdet i hele filen, for eksempel "AVI" eller "WAVE").
  • resten av data: subchunks.

Filen i seg selv består av en RIFF-del, som deretter kan inneholde ytterligere underbunker: Derfor vil de første fire bytene i en riktig formatert RIFF-fil stave "R", "I", "F", "F".

Mer informasjon om RIFF-formatet finner du i artikkelen Interchange File Format .

RF64 er et flerkanals filformat basert på RIFF-spesifikasjon, utviklet av European Broadcasting Union . Det er BWF- kompatibelt og lar filstørrelser overstige 4 gigabyte . Den gjør det ved å tilby en "ds64" -bit med en 64-biters (8-byte) størrelse.

Bruk av INFO-delen

Det valgfrie INFO-stykket lar RIFF-filer "merkes" med informasjon som faller inn i en rekke forhåndsdefinerte kategorier, for eksempel copyright ("ICOP"), kommentarer ("ICMT"), artist ("IART"), på en standardisert måte. Disse detaljene kan leses fra en RIFF-fil, selv om resten av filformatet ikke gjenkjennes. Standarden tillater også bruk av brukerdefinerte felt. Programmerere som har tenkt å bruke ikke-standardfelt, bør huske at den samme ikke-standardiserte subchunk ID-en kan brukes av forskjellige applikasjoner på forskjellige (og potensielt inkompatible) måter.

Kompatibilitetsproblemer

Innledende problemer med MIDI-filer

I tråd med deres policy om å bruke .RIFF for alle Windows 3.1 "multimedia" -filer, introduserte Microsoft en ny variant på det eksisterende MIDI-filformatet som brukes til å lagre sanginformasjon som skal spilles på elektroniske musikkinstrumenter. Microsofts "nye" MIDI-filformat besto av en standard MIDI-fil innelukket i en RIFF "wrapper", og hadde filtypen .RMI . Siden det eksisterende MIDI-filformatet allerede støttet innebygd "tagging" -informasjon, var ikke fordelene for brukeren av å ha et nytt format åpenbare.

MIDI Manufacturers Association har siden tatt imot det RIFF-baserte MIDI-filformatet, og brukt det som grunnlag for en "utvidet midifile" som også inkluderer instrumentdata i " DLS " -format, innebygd i samme .RMI-fil.

INFO problemer med plassering av klumper

For katalogiseringsformål er den optimale posisjonen for INFO-delen nær begynnelsen av filen. Imidlertid, siden INFO-delen er valgfri, blir den ofte utelatt fra de detaljerte spesifikasjonene for individuelle filformater, noe som fører til en viss forvirring over riktig posisjon for denne delen i en fil.

Når du arbeider med store mediefiler, kan utvidelsen eller sammentrekningen av INFO-delen under tag-redigering resultere i at den følgende "data" -delen av filen må leses og skrives om til disk for å imøtekomme den nye toppstørrelsen. Siden mediefiler kan ha gigabyte, er dette en potensielt diskintensiv prosess. En løsning er å "pute ut" den ledende INFO-delen ved hjelp av dummy-data (ved hjelp av en "dummy chunk" eller "pad chunk") når filen er opprettet. Senere redigering kan deretter utvide eller trekke sammen "dummy" -feltet for å holde den totale størrelsen på filoverskriften konstant: et intelligent skrevet programvare kan deretter overskrive bare filoverskriften når merking av data endres uten å endre eller flytte hoveddelen av filen.

Noen programmer har forsøkt å løse problemet ved å plassere INFO-delen på slutten av en mediefil, etter hoveddelen av filen. Dette har resultert i to forskjellige konvensjoner for plassering av klumper, med tilhørende risiko for at noen kombinasjoner av programvare kan føre til at en fils INFO-data blir ignorert eller permanent overskrevet under redigering. Mer sofistikerte programmer vil ta hensyn til muligheten for "uventet" plassering av klumper i filer og svare deretter. For eksempel når lydredigeringsprogrammet Audacity møter en .WAV-fil med sluttplasserte INFO-data, vil den identifisere og lese dataene riktig, men når den lagres, flytter den INFO-delen tilbake til filoverskriften.

Selv om CorelDRAW 10 nominelt bruker en RIFF-filstruktur, plasserte programmets første utgivelse INFO-delen på slutten, slik at en hvilken som helst innebygd forhåndsvisning bitmap ikke ble vist under Windows filbehandling som standard. Et "patch" -verktøy som følger med programmet løser dette problemet.

RIFF-info-koder

RIFF-informasjonskoder finnes i WAV-lyd- og AVI-videofiler. Tagger som er en del av Exif 2.2-spesifikasjonen (Tag ID begynner med "I") har et understreket tagnavn i HTML-versjonen av denne dokumentasjonen. Andre koder finnes i AVI-filer generert av Sony Vegas videoredigeringsprogramvare.

Tag-ID Merkens navn Skrivbar Verdier / notater
DTIM DateTimeOriginal N ICC-profil "dtim" -formatverdier
TEIP Båndnavn N

Konvertering av DTIM-tid til normal tid

Feltet består av to verdier (v [0] og v [1]) atskilt med et mellomrom (0x20). Eksempelkode: 

// time in seconds - "concatenate" date & time elements with a decimal point delimiter
TimeInSeconds = (v[0] * (2^32) + v[1]) * 10^(-7);

// shift basis from Jan 1, 1601 to Unix epoch Jan 1, 1970 (369 years & leap days)
UnixTimeStamp = TimeInSeconds - 134774 * 24 * 3600;

Noen vanlige RIFF-filtyper

Se også

Referanser

Eksterne linker