Ascorn animation

This is an animation format used by Ascorn (later Ascaron) in some of its games like Elisabeth I (aka Gloriana) or Das Hexagon Kartell. Unlike many other formats it decodes YUV picture with 5 or 6 bits per component.

File is organised into a series of chunks, each with 4-byte type and size. First chunk should be AN15, last one should be ENDE

Header chunk

 4 bytes - "AN15"
 4 bytes - size (usually 64)
 4 bytes - zero
 4 bytes - header size again
 4 bytes - "V0.9"
 4 bytes - number of video frames
 4 bytes - number of audio frames
 4 bytes - unknown, usually zero
 4 bytes - offset to video frame index
 4 bytes - offset to audio frame index
 12 bytes - always zero?
 3 bytes - unknown
 4 bytes - unknown
 1 byte  - unknown
 4 bytes - frames per one hundredth of second (e.g. 1250 for 12.5 fps)
 4 bytes - unknown

Audio chunk

 4 bytes - "SAMP"
 4 bytes - size
 4 bytes - CRC
 4 bytes - header size (usually 15, starting from CRC field)
 3 bytes - sample rate
 1 byte  - number of channels
 1 byte  - bits per sample
 2 bytes - usually zero

Audio data is unpacked PCM

Palette chunk

 4 bytes - "PALT"
 4 bytes - size
 4 bytes - usually zero
 4 bytes - unknown
 768 bytes - VGA palette
 rest - LUT

This chunk provides look-up table for mapping YUV data into indexed colours.

Picture chunk

 4 bytes - "BILD"
 4 bytes - size
 4 bytes - usually zero
 4 bytes - header size
 2 bytes - width
 2 bytes - height
 2 bytes - compression mode
 4 bytes - luma size
 4 bytes - first chroma component size
 4 bytes - second chroma component size
 8 bytes - unknown
 if header size > 34 {
   11 bytes - unknown
   1 byte - bits per luma sample (0 or 5 - 5 bits, 6 - 6 bits)
 }

There are several compression methods known:

• 2 - raw YUV data packed in bits (5 or 6 bits for luma, signed 8 bits for chroma), luma plane first, chroma planes afterwards
• 3 - differences to the previous YUV frame
• 4 - same as method 3 but data is motion compensated with MV data sent before the change data (each 8x8 luma block having MV source consisting of 9-bit vertical offset and 10-bit horizontal offset)
• 16 - RGB compression

Method 3 codes data almost in the same way as method 2 except that zero component value means skip with the next 8- or 16-bit value (top bit set means 16-bit value, 8 bits otherwise) being the number of values to leave unchanged.

Method 16 is LZ77-like compression performed on RGB24 data. Flags are grouped in bytes and sent before the rest of the data. Flag 1 means raw RGB triplet, flag 0 means reading 16-bit offset plus 8-bit length (plus three) and copying that number of pixels from that offsets.

Image data is stored in wrapped 128000-pixel buffer which fits two images, so the previous image may be referenced while decoding the current one.

Index chunks

 4 bytes - "SPTR" (audio) / "BPTR" (video)
 4 bytes - usually 4
 4 bytes - usually 12
 4 bytes - number of entries
 N*4 bytes - offsets to the audio/video frame chunks