Bink Container: Difference between revisions

From MultimediaWiki
Jump to navigation Jump to search
(add bink audio flags)
(multitrack audio info)
Line 13: Line 13:
All multi-byte numbers are stored in little endian format.
All multi-byte numbers are stored in little endian format.


Bink files appear to start with a 56-byte header which is laid out as follows:
Bink files commence with a 44-byte header which is laid out as follows. Audio information follows the main header. If there are zero audio tracks, then the headers are omitted.


   bytes 0-2    file signature ('BIK')
   bytes 0-2    file signature ('BIK')
   byte 3        possibly a file version number (0x62, 0x66, 0x67, 0x68, 0x69 b,f,g,h,i respectivly)
   byte 3        file format version number (0x62, 0x66, 0x67, 0x68, 0x69 b,f,g,h,i respectivly)
   bytes 4-7    file size not including the first 8 bytes
   bytes 4-7    file size not including the first 8 bytes
   bytes 8-11    number of frames
   bytes 8-11    number of frames
Line 26: Line 26:
   bytes 32-35  video frames per second divider
   bytes 32-35  video frames per second divider
   bytes 36-39  unknown
   bytes 36-39  unknown
   bytes 40-43  audio flag: if 0, header ends; if 1, header continues;
   bytes 40-43  number of audio tracks
    bytes 44-45   unknown
 
    bytes 46-47   audio channels (1 or 2)
  for each audio track
    bytes 48-49   audio sample rate (Hz)
    two bytes  unknown
    bytes 50-51   flags. When bit 12 is set, use Bink Audio MDCT, otherwise use Bink Audio FFT.
    two bytes  audio channels (1 or 2)
    bytes 52-55  unknown
 
  for each audio track
    two bytes  audio sample rate (Hz)
    two bytes  flags. When bit 12 is set, use Bink Audio MDCT, otherwise use Bink Audio FFT.
 
  for each audio track
    four bytes unknown


Following the header is a sample offset table. The number of entries in the table is equal to the number of samples specified in the header. Each entry consists of a 32-bit absolute offset for that sample. There is no length information, so the length of a sample is implicitly the difference between sample offsets. One frame contains both audio and video data (if both are present it the file). Bytes 12-15 (largest frame size) probably exist to provide the playback application with the largest single buffer it will have to allocate.
Following the header is a frame index table. The number of entries in the table is equal to the number of frames specified in the header. Each entry consists of a 32-bit absolute offset for that frame. There is no length information provided in the table, so the length of a sample is implicitly the difference between frame offsets, and the size of the file (for the very last frame).
 
Each frame contains (optional) audio and video data. Bytes 12-15 (largest frame size) probably exist to provide the playback application with the largest single buffer it will have to allocate. The layout of each frame is as follows:
 
  for each audio track
      four bytes        length of audio packet (bytes) plus four
      four bytes        number of samples in packet
      variable length  [[Bink Audio]] packet
 
  variable length      [[Bink Video]] packet


== Exe files ==
== Exe files ==

Revision as of 04:45, 6 April 2008

This page is based on the document 'Description of the Bink File Format' by Mike Melanson at http://multimedia.cx/bink-format.txt.

Bink files are multimedia files used in a variety of video games, both on personal computers platforms and video game consoles. The files act as containers for data compressed with the proprietary Bink video and audio codecs. Bink multimedia files are known to bear the .bik extension.

File Format

This description is known to be incomplete.

All multi-byte numbers are stored in little endian format.

Bink files commence with a 44-byte header which is laid out as follows. Audio information follows the main header. If there are zero audio tracks, then the headers are omitted.

 bytes 0-2     file signature ('BIK')
 byte 3        file format version number (0x62, 0x66, 0x67, 0x68, 0x69 b,f,g,h,i respectivly)
 bytes 4-7     file size not including the first 8 bytes
 bytes 8-11    number of frames
 bytes 12-15   largest frame size in bytes
 bytes 16-19   number of frames again?
 bytes 20-23   video width
 bytes 24-27   video height
 bytes 28-31   video frames per second dividend
 bytes 32-35   video frames per second divider
 bytes 36-39   unknown
 bytes 40-43   number of audio tracks
 
 for each audio track
    two bytes   unknown
    two bytes   audio channels (1 or 2)
 
 for each audio track
    two bytes   audio sample rate (Hz)
    two bytes   flags. When bit 12 is set, use Bink Audio MDCT, otherwise use Bink Audio FFT.
 
 for each audio track
    four bytes  unknown

Following the header is a frame index table. The number of entries in the table is equal to the number of frames specified in the header. Each entry consists of a 32-bit absolute offset for that frame. There is no length information provided in the table, so the length of a sample is implicitly the difference between frame offsets, and the size of the file (for the very last frame).

Each frame contains (optional) audio and video data. Bytes 12-15 (largest frame size) probably exist to provide the playback application with the largest single buffer it will have to allocate. The layout of each frame is as follows:

 for each audio track
     four bytes        length of audio packet (bytes) plus four
     four bytes        number of samples in packet
     variable length   Bink Audio packet
 
 variable length       Bink Video packet

Exe files

Bink data can be contained in exe files. To find where to start decoding search in the file for one of 4 id's:

'fKIB'
'gKIB'
'hKIB'
'iKIB'

Note that this is BIK value is in machine order (therefore appears backwards for x86 binaries).

Revision b is found in Heroes of Might and Magic 3.