and its primary medium, tape, Harte wanted a fine-grained and technically optimal representation of media, compared to existing ad hoc formats; and to package the multiple media elements of a software release into a single file, so that downloading a UEF is "more like obtaining the original product". He went on to observe that it was the tools in use, and "user need", that determined the actual uses to which the UEF had been put. Structure A UEF file consists of a fixed length header that identifies itself, followed by a linked list of chunks containing the data of interest. The header comprises the magic string UEF File!, a terminating null character, and the two-byte version number of the UEF specification in use. A reading application needs to pay attention to the version number, as the unit of measurement in some chunks differs according to the specification version, and one chunk has been redefined between versions. Each chunk consists of a two-byte ID which determines its meaning, the length of the body in four bytes, and the body itself. An application can readily skip the bodies of chunks it does not need to process. After the last chunk the file simply ends. Currently, UEF chunks do not nest. The whole UEF file, including the header, may optionally be compressed in gzip format. By examining the start of the file for a gzip or UEF header, a decompression library can be invoked as appropriate. Content The Unified Emulator Format models software on cassette as a contiguous sequence of segments, which may be carrier tones, the modulated asynchronous signals of ordinary data blocks, security cycles (modulated synchronous signals, said to be an "identification feature") or gaps where no recognised signal is present. Tape UEF chunks are concatenated in the order they appear, to build up the representation of a whole recording. When generated from a real source tape, each waveform on the tape corresponds directly to a tape chunk, such that the source can be accurately reconstructed (with any non-encodable signals replaced by gaps of equal length.) Standard Acorn streams (chunk ID: 0x0100) are encoded so that their bytes reappear in the UEF chunk body. From version 0.10, direct support is extended to all asynchronous formats (0x0104) including the 8,N,2 format of BASICODE. Otherwise there is a generic chunk (0x0102) to accommodate any arbitrary sequence of bits. Security wave chunks (0x0114) also