Some notes about the current implementation of the movtar format:

.) The first file needed in the stream is an INFO file (now dynamic size).

.) Sound is supported now (see below) !

.) Structure of the INFO file:
Each tag has a number, defined in "movtar.c". The human description of the tag is completely ignored. The colon ":" denotes the begin of the data section of a line. Semicolons or hashes can be used for comments (NOT tested yet !). Unparsable lines generate warnings (e.g. in buz_play).

.) The number description of each JPEG from buz_rec output denotes

(not parsed when reading):

{framenumber}-[{timeseconds}:{timemicrosec}].jpeg

.) The datatype of a file is recognized on its extension

(of course, of course, I could analyse the file, too - but why should I, the content of a movtar is just generated by smart programs, am I right ? ;P )

.) Nothing is guaranteed to be working - I can't yet guarantee that recorded

files from this version will work with future versions - sorry.

.) There are nearly no movtar manipulating tools, but have a look at "tar":

It is your friend, and has become the buz_tools', too :-)

.) If a JPEG contains two fields, the even lines field must come first.

.) Please use movtar_datatype to determine the type of data stored in a data

block in the movtar .... ".raw" would be otherwise hard to guess (it contains raw sound)

Some remarks to the sound support

Audio files are saved as raw audio, the format is defined in the INFO file. (this saves me from saving e.g. .WAV-headers in every single audio snippet I generate and write into the file).

The sound sample formats are:
8 bit: Unsigned 8-bit samples (most common 8-bit format) 16 bit: Signed 16-bit Little Endian samples (most common 16-bit format)

The audio information should always be written after the frame it belongs to. Some preliminary rules for the audio file size: It should be 8192 (recommended) or 2048 or 4096 (will lower performance and efficiency). The last file can of course be smaller. The accepted extension is ".raw".

To the 2 Gigabyte filesize problem:
I am already thinking about some possible solutions (integrating a symlink file at the end, writing link information after the final two empty tarblocks), but yet movtar can't handle this problem.... but we will provide you with a clean solution in some time ! :-)

Anyways: Have fun (as Rainer uses to say :-) ) /gz