RIFF

RIFF(, 리소스 교환 파일 형식)는 태그가 붙은 청크 단위로 데이터를 저장하는 범용 파일 컨테이너 포맷이다. 주로 오디오와 비디오에 사용되지만, 임의의 데이터를 저장하는 데에도 사용될 수 있다.

마이크로소프트의 구현체는 주로 RIFF를 기반으로 하는 AVI, ANI, WAV 등의 컨테이너 포맷을 통해 잘 알려져 있다.

 역사 
RIFF는 1991년에 마이크로소프트와 IBM에 의해 도입되었으며 윈도우 3.1 멀티미디어 파일의 기본 형식으로 사용되었다. 이는 1985년 일렉트로닉 아츠가 아미가에서 도입한 인터체인지 파일 포맷(IFF)을 기반으로 한다. IFF는 아미가의 모토로라 68000 CPU의 빅 엔디언 관례를 사용하지만, RIFF에서는 다중 바이트 정수가 IBM PC 호환기종에 사용되는 X86 프로세서의 리틀 엔디언 순서로 저장된다. 빅 엔디언 방식인 RIFX 포맷도 도입되었다.

2010년 구글은 RIFF를 컨테이너로 사용하는 WebP 이미지 포맷을 도입했다.

 설명 
RIFF 파일은 전적으로 "청크"들로 구성된다. 전체적인 포맷은 앞서 언급한 엔디언 방식과 청크 이름의 다른 의미를 제외하면 IFF와 동일하다.

모든 청크는 다음과 같은 형식을 갖는다:
 4 바이트: 이 청크를 식별하는 ASCII 식별자 (예: "fmt " 및 "data"; "fmt "의 공백에 주의).
 4 바이트: 이 청크의 길이(이 필드 자체와 청크 식별자 제외)를 나타내는 부호 없는 리틀 엔디언 32비트 정수.
 가변 크기 필드: 이전 필드에서 주어진 크기의 청크 데이터 자체.
 청크의 길이가 짝수가 아닌 경우 패딩 바이트 하나.

두 개의 청크 식별자인 "RIFF"와 "LIST"는 하위 청크를 포함할 수 있는 청크를 도입한다. RIFF 및 LIST 청크 데이터(식별자와 길이 다음에 나타남)는 다음과 같은 형식을 갖는다:
 4 바이트: 해당 RIFF 또는 LIST 청크의 특정 ASCII 식별자 (RIFF의 경우 일반적인 경우 "AVI " 또는 "WAVE"와 같이 전체 파일의 내용을 설명함).
 나머지 데이터: 하위 청크들.

파일 자체는 하나의 RIFF 청크로 구성되며, 이 청크는 다시 추가 하위 청크를 포함할 수 있다. 따라서 올바른 형식의 RIFF 파일의 처음 4바이트는 "RIFF"가 된다.

RIFF 포맷에 대한 더 자세한 정보는 인터체인지 파일 포맷 문서에서 찾을 수 있다.

RF64는 유럽 방송 연맹에서 개발한 RIFF 사양을 기반으로 하는 다채널 파일 포맷이다. 이는 BWF와 호환되며 파일 크기가 4 기가바이트를 초과할 수 있도록 허용한다. 이는 64비트(8바이트) 크기를 가진 "ds64" 청크를 제공함으로써 이루어진다.

 INFO 청크의 사용 
선택 사항인 INFO 청크를 사용하면 RIFF 파일에 저작권("ICOP"), 주석("ICMT"), 아티스트("IART")와 같이 미리 정의된 여러 카테고리에 속하는 정보를 표준화된 방식으로 "태그"할 수 있다. 이러한 세부 정보는 파일 포맷의 나머지 부분을 인식하지 못하더라도 RIFF 파일에서 읽을 수 있다. 표준은 또한 사용자 정의 필드의 사용을 허용한다. 비표준 필드를 사용하려는 프로그래머는 동일한 비표준 하위 청크 ID가 서로 다른 응용 프로그램에서 서로 다른(잠재적으로 호환되지 않는) 방식으로 사용될 수 있음을 유념해야 한다.

 호환성 문제 
 MIDI 파일의 초기 문제 
모든 윈도우 3.1 "멀티미디어" 파일에 .RIFF를 사용하려는 정책에 따라, 마이크로소프트는 전자 악기에서 재생될 곡 정보를 저장하는 데 사용되는 기존 MIDI 파일 포맷에 새로운 변형을 도입했다. 마이크로소프트의 MIDI 파일 포맷은 RIFF 래퍼로 둘러싸인 표준 MIDI 파일로 구성되었으며, .RMI라는 파일 확장자를 가졌다. 기존 MIDI 파일 포맷이 이미 내장된 "태그" 정보를 지원했기 때문에, 이는 동일한 유형의 정보에 대해 두 가지 파일 포맷을 처리해야 하는 단점을 야기했다.

MIDI 제조업체 협회(MIDI Manufacturers Association)는 이후 RIFF 기반 MIDI 파일 포맷을 수용했으며, 이를 동일한 .RMI 파일 내에 "DLS" 포맷의 악기 데이터도 포함하는 "확장 미디파일(extended midifile)"의 기초로 사용했다.

 INFO 청크 배치 문제 
카탈로그 작성 목적으로 INFO 청크의 최적 위치는 파일의 시작 부분 근처이다. 그러나 INFO 청크는 선택 사항이므로 개별 파일 포맷의 세부 사양에서 생략되는 경우가 많으며, 이로 인해 파일 내에서 이 청크의 올바른 위치에 대해 혼란이 발생하기도 한다.

대용량 미디어 파일을 다룰 때 태그 편집 중에 INFO 청크가 확장되거나 축소되면, 새로운 헤더 크기를 수용하기 위해 파일의 이어지는 "data" 섹션을 읽고 다시 디스크에 써야 할 수도 있다. 미디어 파일의 크기가 기가바이트 단위일 수 있으므로 이는 잠재적으로 디스크 집약적인 프로세스이다. 한 가지 해결책은 파일을 생성할 때 더미 데이터("더미 청크" 또는 "패드 청크" 사용)를 사용하여 선행 INFO 청크를 "채우는(pad out)" 것이다. 나중에 편집할 때 이 "더미" 필드를 확장하거나 축소하여 파일 헤더의 총 크기를 일정하게 유지할 수 있다. 지능적으로 작성된 소프트웨어는 태그 데이터가 변경될 때 파일의 본체를 수정하거나 이동하지 않고 파일 헤더만 덮어쓸 수 있다.

일부 프로그램은 INFO 청크를 파일 본체 뒤인 미디어 파일 끝에 배치하여 이 문제를 해결하려고 시도했다. 이로 인해 청크 배치에 대한 두 가지 서로 다른 관례가 생겨났으며, 일부 소프트웨어 조합에서는 편집 중에 파일의 INFO 데이터가 무시되거나 영구적으로 덮어씌워질 위험이 따르게 되었다. 보다 정교한 프로그램은 파일에서 "예기치 않은" 청크 배치의 가능성을 고려하고 그에 따라 대응한다. 예를 들어, 오디오 편집 프로그램인 오다시티는 끝에 INFO 데이터가 배치된 .WAV 파일을 만나면 데이터를 정확하게 식별하고 읽지만, 저장할 때는 INFO 청크를 다시 파일 헤더로 재배치한다.

코렐드로 10은 명목상 RIFF 파일 구조를 사용하지만, 프로그램의 초기 릴리스에서는 INFO 청크를 끝에 배치하여 윈도우의 파일 관리자에서 내장된 미리보기 비트맵이 기본적으로 표시되지 않았다. 프로그램과 함께 제공된 "패치" 유틸리티가 이 문제를 해결한다.

 RIFF 정보 태그 

RIFF 정보 태그는 WAV 오디오 및 AVI 비디오 파일에서 발견된다.

 태그 ID 태그 이름 쓰기 가능 값 / 참고 DTIM DateTimeOriginal N ICC 프로필 "dtim" 포맷 값 TAPE TapeName N

 DTIM 시간을 일반 시간으로 변환 
이 필드는 공백(0x20)으로 구분된 두 개의 값(v[0] 및 v[1])으로 구성된다. 샘플 코드:
// 초 단위 시간 - 소수점 구분 기호를 사용하여 날짜 및 시간 요소를 "연결"
TimeInSeconds = (v[0] * (2^32) + v[1]) * 10^(-7);

// 기준을 1601년 1월 1일에서 유닉스 에포크인 1970년 1월 1일로 변경 (369년 및 윤일)
UnixTimeStamp = TimeInSeconds - 134774 * 24 * 3600;

 주요 RIFF 파일 유형 
 WAV (윈도우 오디오)
 AVI (윈도우 시청각)
 RMI (윈도우 "RIFF MIDI파일")
 CDR (코렐드로 벡터 그래픽 파일)
 ANI (애니메이션 윈도우 커서)
 PAL (팔레트)
 DLS (다운로드 가능한 사운드)
 WebP (구글에서 개발한 이미지 포맷)
 XMA (WMA Pro 기반의 마이크로소프트 엑스박스 360 콘솔 오디오 포맷)
 SF(1/2/3) (악기 샘플 저장을 위해 만들어진 사운드폰트 버전 1, 2, 3)

 같이 보기 
 FourCC

 각주 

분류:파일 포맷