FLA Format

From wiki.benjaminwolsey.de

Jump to: navigation, search

This is currently unformatted information about the FLA format. There are at least two different FLA formats corresponding to different versions of the creation software. The one described here is the newer format, which differs from the older one by using different byte markers and UTF-16 strings.

The FLA format uses the Microsoft Compound Binary File format. This is a way to store several files in a single archive. To examine it, use the command 7z e file.fla with the free 7zip software. An example of the contents of an FLA file is:

 Contents
 M 1 1216485710 
 M 2 1216485711
 M 3 1216485711
 M 4 1216485711
 M 5 1216485711
 P 1 1216485710
 S 6 1216485711

The following sections deal with each element of the file.

Contents

Contents

The Contents file contains sections that are separated by the following byte marker:

 ff ff 01 00

The two bytes after this marker specify the length of the following section name, e.g.

 0d 00 CDocumentPage [b]

[b] is a byte that appears to be in the range 0x17 to 0x19. Whatever it is, the same byte seems to appear in following markers.

There follows a 1-byte string length, then a P element name. This first name probably identifies the main character.

 0f P 2 124864861

This example is followed by a subsection marker containing the text "main", suggesting that it is associated with the main timeline or similar.

After the initial P element, more P elements can follow. They appear to be marked with something like

 01 80 [b] [l]

Where [b] is the same as the byte following the section marker and [l] is the length of the P element name.

P Elements

Within P elements (and throughout the Contents file), the marker

 ff fe ff

is used as a divider. P elements apparently always have the following pattern, where the marker is labelled [m], and [l] is the length of a following text string:

[m] [l] {title} [m] 00 { 41 bytes } [m] 00 [m] 00 [m] 00 { 5 bytes } [m] 00 [m] 00 { 21 bytes } [m] 00 { 5 bytes } [m] 00 [m] 00 { 18 bytes } [m] 00 [m] 00 [m] 00 { 5 bytes } [m] 00 [m] 00 { 21 bytes } [m] 00 { 5 bytes } [m] 00 { 12 bytes } [m] 00 { 1 bytes } [m] 00 { 9 bytes } [m] 00 { 9 bytes } [m] 00 { 8 bytes } [m] 00 { 9 bytes }

After that there is some variation in different Contents files, though P elements within each Contents file appear to have the same pattern.

[m] 00 { 12 bytes } [m] 00 [m] 00 { 4 bytes } [m] 00 { At least 20 bytes }

or

[m] 00 { 16 bytes } [m] 00 { 8 bytes } [m] 00 [m] 00 { 4 bytes } [m] 00 { At least 20 bytes }

S Elements

S element descriptions follow. They are also marked with

 01 80 [b] [l]

followed by the S element description, then a marker section containing the title. The structure is identical to that of P elements in the same file, except that the 6th marker section after the title may contain a string in addition to the 21 bytes, i.e.

P element:

 [m] 00 { 21 bytes }

S element:

 [m] [l] { string } { 21 bytes }


Meaning of element fields

It is difficult to guess the meaning of all the fields without access to the programme that creates the FLA files, but there are clues in how much each field changes. Just dealing with the fields present in all Contents files:

1. [m] [l] { title } { 5 bytes } The title string is obvious, but not the rest of the bytes. They are always all zero for P elements, always have some data for S elements.

2. [m] 00 { 41 bytes } Largest field, very variable

[m] 00 [m] 00

3. [m] 00 { 5 bytes }

 00 02 00 00 00 

So far always identical.

[m] 00

4. [m] 00 { 21 bytes }

 00 00 00 00 00 00 00 00 
 01 00 00 00 00 00 00 00	
 ff ff ff ff 00			

So far always identical. Note in S section may be preceded by string.

5. [m] 00 { 5 bytes } Very variable

[m] 00

6. [m] 00 { 18 bytes }

 02 00 00 00 00 01 00 00 00 01 00 00 00 07 00 00 00 00

or

 02 00 00 00 00 00 00 00 00 01 00 00 00 07 00 00 00 00

Not very variable. The second variant only exists in S elements where field 4 has no string (only seen in one file).

[m] 00 [m] 00

7. [m] 00 { 5 bytes }

 00 02 00 00 00

Always the same (so far), identical to field 3.

[m] 00

8. [m] 00 { 21 bytes }

 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ff ff ff ff 00

So far always the same.

9. [m] 00 { 5 bytes }

 07 00 00 00 00

So far always the same.

10. [m] 00 { 12 bytes }

 00 00 00 00 01 00 00 00 00 00 00 00

So far always the same

11. [m] 00 { 1 bytes }

 03

So far always the same.

12. [m] 00 { 9 bytes } 00 00 00 00 00 00 00 00 03 So far always the same.

13. [m] 00 { 9 bytes }

 00 00 00 00 00 00 00 00 03

So far always the same.

14. [m] 00 { 8 bytes }

 00 00 00 00 00 00 00 00

So far always the same.

15. [m] 00 { 9 bytes } Minor variations:

 02 00 00 00 00 01 00 00 00
 02 00 00 00 00 00 00 00 00

[...] 16. [m] 00 { 4 bytes } 00 00 00 00 Rare variation in the first byte (02, 03).

17. [m] 00 { ? bytes }

Variable length, but the first bytes are generally always the same.

20-byte version
 00 00 00 00 00 00 00 80
 00 00 00 80 00 00 00 80
 00 00 00 80
28-byte version
 00 00 00 00 00 00 00 80
 00 00 00 80 00 00 00 80
 00 00 00 80 00 00 02 00
 01 00 02 00
29-byte version
 00 00 00 00 00 00 00 80
 00 00 00 80 00 00 00 80
 00 00 00 80 00 00 00 00
 00 00 00 00 00
37-byte version
 00 00 00 00 00 00 00 80
 00 00 00 80 00 00 00 80
 00 00 00 80 00 00 00 00
 00 00 00 00 00 00 00 21
 00 01 00 03 00

Main Sections

Apart from CDocumentPage, the other main sections present include CMediaBits and CQTAudioSettings:

 ff ff 01 00 0a 00 CMediaBits
 ff ff 01 00 10 00 CQTAudioSettings

This follows the pattern explained for CDocumentPage.

S Element Files

These are more or less parseable in the same way (there is often one ff ff 01 00 marker not followed by a string).

Symbol files can contain CPicPage, CPicLayer, CPicFrame, CPicShape, CPicText, and CPicSymbol sections.

The last field in the S file corresponds to the <DOMLayer> part of an XFL file, but the last field in P files is also the same, so it's not really clear which belongs to what.

string: "Layer 1"

data(50):

 01 00 00 ff ff ff ff
 4f ff 4f
 ff 00 00 00 00 01 00 00
 00 00 00 00 01 00 00 00
 00 00 00 00 80 00 00 00
 80 00 00 07 03 00 01 00
 00 00 00 00 00 00 00 00

where "Layer 1" is the name, and 4f ff 4f the colour #4fff4f, possibly with alpha byte (before or after).

This part of an S file has a corresponding entry in an XFL LIBRARY file:

| string: "Letter Gothic Std Bold" | | string: "LetterGothicStd-Bold" data(26): 00 00 00 40 ff ff ff ff 00 00 01 00 0 0 00 00 00 28 00 00 00 00 00 00 00 f6 ff | | data(4): 00 00 00 00 | | data(10): 02 01 00 00 00 00 00 00 00 00 | | data(40): 46 00 4f 00 52 00 20 00 44 00 4f 00 55 00 42 00 4c 00 45 00 20 00 49 00 44 00 45 00 4e 00 54 00 49 00 54 00 59 00 00 00 | | data(8): 00 00 00 00 00 00 00 00 |


<textRuns> <DOMTextRun> <characters>FOR DOUBLE IDENTITY</characters> <textAttrs> <DOMTextAttrs face="Letter Gothic Std Bold" size="8.733861923217773" bold="true" italic="false" fillColor="#FFFFFF" letterSpacing="-0.524031745062934" characterPosition="normal" autoKern="false"/> </textAttrs> </DOMTextRun> </textRuns>

The data(40) field corresponds to the characters in utf-16.

The data(26) field following a font string contains the colour (bytes 4-6, possibly with alpha in 7). Byte 11 is the "bold" flag. Text spacing may also be encoded, but it's not clear.

In some S files the marker ff ff 01 00 appears without a following string. In this case it is always preceded by another ff byte. The following byte is perhaps higher than in the genuine marker cases (where it specifies the name length) but 0x13, for instance, is in the same order. Known values in these cases are: 69, df, 5e, 3e, 13. This suggests the preceding 0xff is part of a different kind of marker, perhaps for a data section. Alternatively they are in length-limited sections, so should not be detected.

Or it is the byte following the length byte, which is 0 for name markers? For non-name markers it is one of the following:

08, 05, 07, 04, 0a, 07, 08, 0a, 03, 03, 04, 03

They are notably all low.

In one file (case6/S 7 1248641673) there are many ff ff 01 00 markers in close proximity, preceded by the byte fd or fe. Possibly this is in a length-limited section so should not be detected.

The same file also has an

 ff ff ff 01 00

(i.e. non-name) marker before

 ff ff 01 00 0a CPicSprite 

(i.e. a genuine section).

The CPicFrame section of a Symbol file can contain character data immediately after the CPicFrame bytes. It comes before any ff fe ff marker. This section evidently contains fill styles:

 cc 00 00 00 04 00 ff 99 00 ff 00 00 ff 66 00 ff 00 00 9f e8 ff ff 00 00 2b ca ff ff 00 00 00 00 d3 00
              ^    [  RGBA 1 ]       [  RGBA 2 ]       [  RGBA 3 ] 	  [  RGBA 4 ]             [ ? ...
              |
              ------ Fill style count?

The fill-style type must also be encoded somewhere.

P Element Files

These represent Pages.

They can contain CPicButton, CPicPage, CPicLayer, CPicFrame, CPicSprite, and CPicText sections.

ActionScript can appear in CPicButton sections.

These are parseable in the same way.

M Element Files

These are referenced in the CMediaBits section. The references correspond to the <media> entries near the start of an XFL file.

Personal tools