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