configure.ac: Check for optional dependency on zlib for id3demux

Original commit message from CVS:
* configure.ac:
Check for optional dependency on zlib for id3demux

* gst/id3demux/Makefile.am:
* gst/id3demux/gstid3demux.c: (gst_gst_id3demux_get_type),
(gst_id3demux_base_init), (gst_id3demux_class_init),
(gst_id3demux_reset), (gst_id3demux_init), (gst_id3demux_dispose),
(gst_id3demux_add_srcpad), (gst_id3demux_remove_srcpad),
(gst_id3demux_trim_buffer), (gst_id3demux_chain),
(gst_id3demux_set_property), (gst_id3demux_get_property),
(id3demux_get_upstream_size), (gst_id3demux_srcpad_event),
(gst_id3demux_read_id3v1), (gst_id3demux_read_id3v2),
(gst_id3demux_sink_activate), (gst_id3demux_src_activate_pull),
(gst_id3demux_src_checkgetrange), (gst_id3demux_read_range),
(gst_id3demux_src_getrange), (gst_id3demux_change_state),
(gst_id3demux_pad_query), (gst_id3demux_get_query_types),
(simple_find_peek), (simple_find_suggest),
(gst_id3demux_do_typefind), (gst_id3demux_send_tag_event),
(plugin_init):
* gst/id3demux/gstid3demux.h:
* gst/id3demux/id3tags.c: (read_synch_uint),
(id3demux_read_id3v1_tag), (id3demux_read_id3v2_tag),
(id3demux_id3v2_frame_hdr_size), (convert_fid_to_v240),
(id3demux_id3v2_frames_to_tag_list):
* gst/id3demux/id3tags.h:
* gst/id3demux/id3v2.4.0-frames.txt:
* gst/id3demux/id3v2.4.0-structure.txt:
* gst/id3demux/id3v2frames.c: (id3demux_id3v2_parse_frame),
(parse_comment_frame), (parse_text_identification_frame),
(id3v2_tag_to_taglist), (parse_split_strings):
All new LGPL id3 demuxer. Can use zlib for compressed frames,
otherwise it discards them. Works on my test files.

* gst/wavparse/gstwavparse.c: (gst_wavparse_loop):
Don't send EOS to a non-existing srcpad
The debug category can be static

1 files changed, 733 insertions, 0 deletions

diff --git a/gst/id3demux/id3v2.4.0-structure.txt b/gst/id3demux/id3v2.4.0-structure.txt
new file mode 100644
index 00000000..5fa156a0
--- /dev/null
+++ b/gst/id3demux/id3v2.4.0-structure.txt
@@ -0,0 +1,733 @@
+
+Informal standard                                             M. Nilsson
+Document: id3v2.4.0-structure.txt                      16 September 2001
+
+
+                 ID3 tag version 2.4.0 - Main Structure
+
+Status of this document
+
+   This document is an informal standard and replaces the ID3v2.3.0
+   standard [ID3v2]. A formal standard will use another revision number
+   even if the content is identical to document. The contents in this
+   document may change for clarifications but never for added or altered
+   functionallity.
+
+   Distribution of this document is unlimited.
+
+
+Abstract
+
+   This document describes the main structure of ID3v2.4.0, which is a
+   revised version of the ID3v2 informal standard [ID3v2] version
+   2.3.0. The ID3v2 offers a flexible way of storing audio meta
+   information within the audio file itself. The information may be
+   technical information, such as equalisation curves, as well as
+   title, performer, copyright etc.
+
+   ID3v2.4.0 is meant to be as close as possible to ID3v2.3.0 in order
+   to allow for implementations to be revised as easily as possible.
+
+
+1.   Table of contents
+
+        Status of this document
+        Abstract
+   1.   Table of contents
+   2.   Conventions in this document
+   2.   Standard overview
+   3.   ID3v2 overview
+     3.1.   ID3v2 header
+     3.2.   ID3v2 extended header
+     3.3.   Padding
+     3.4.   ID3v2 footer
+   4.   ID3v2 frames overview
+     4.1.   Frame header flags
+       4.1.1. Frame status flags
+       4.1.2. Frame format flags
+   5.   Tag location
+   6.   Unsynchronisation
+     6.1.   The unsynchronisation scheme
+     6.2.   Synchsafe integers
+   7.   Copyright
+   8.   References
+   9.   Author's Address
+
+
+2.   Conventions in this document
+
+   Text within "" is a text string exactly as it appears in a tag.
+   Numbers preceded with $ are hexadecimal and numbers preceded with %
+   are binary. $xx is used to indicate a byte with unknown content. %x
+   is used to indicate a bit with unknown content. The most significant
+   bit (MSB) of a byte is called 'bit 7' and the least significant bit
+   (LSB) is called 'bit 0'.
+
+   A tag is the whole tag described in this document. A frame is a block
+   of information in the tag. The tag consists of a header, frames and
+   optional padding. A field is a piece of information; one value, a
+   string etc. A numeric string is a string that consists of the
+   characters "0123456789" only.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [KEYWORDS].
+
+
+3.   ID3v2 overview
+
+   ID3v2 is a general tagging format for audio, which makes it possible
+   to store meta data about the audio inside the audio file itself. The
+   ID3 tag described in this document is mainly targeted at files
+   encoded with MPEG-1/2 layer I, MPEG-1/2 layer II, MPEG-1/2 layer III
+   and MPEG-2.5, but may work with other types of encoded audio or as a
+   stand alone format for audio meta data.
+
+   ID3v2 is designed to be as flexible and expandable as possible to
+   meet new meta information needs that might arise. To achieve that
+   ID3v2 is constructed as a container for several information blocks,
+   called frames, whose format need not be known to the software that
+   encounters them. At the start of every frame is an unique and
+   predefined identifier, a size descriptor that allows software to skip
+   unknown frames and a flags field. The flags describes encoding
+   details and if the frame should remain in the tag, should it be
+   unknown to the software, if the file is altered.
+
+   The bitorder in ID3v2 is most significant bit first (MSB). The
+   byteorder in multibyte numbers is most significant byte first (e.g.
+   $12345678 would be encoded $12 34 56 78), also known as big endian
+   and network byte order.
+
+   Overall tag structure:
+
+     +-----------------------------+
+     |      Header (10 bytes)      |
+     +-----------------------------+
+     |       Extended Header       |
+     | (variable length, OPTIONAL) |
+     +-----------------------------+
+     |   Frames (variable length)  |
+     +-----------------------------+
+     |           Padding           |
+     | (variable length, OPTIONAL) |
+     +-----------------------------+
+     | Footer (10 bytes, OPTIONAL) |
+     +-----------------------------+
+
+   In general, padding and footer are mutually exclusive. See details in
+   sections 3.3, 3.4 and 5.
+
+
+3.1.   ID3v2 header
+
+   The first part of the ID3v2 tag is the 10 byte tag header, laid out
+   as follows:
+
+     ID3v2/file identifier      "ID3"
+     ID3v2 version              $04 00
+     ID3v2 flags                %abcd0000
+     ID3v2 size             4 * %0xxxxxxx
+
+   The first three bytes of the tag are always "ID3", to indicate that
+   this is an ID3v2 tag, directly followed by the two version bytes. The
+   first byte of ID3v2 version is its major version, while the second
+   byte is its revision number. In this case this is ID3v2.4.0. All
+   revisions are backwards compatible while major versions are not. If
+   software with ID3v2.4.0 and below support should encounter version
+   five or higher it should simply ignore the whole tag. Version or
+   revision will never be $FF.
+
+   The version is followed by the ID3v2 flags field, of which currently
+   four flags are used.
+
+
+   a - Unsynchronisation
+
+     Bit 7 in the 'ID3v2 flags' indicates whether or not
+     unsynchronisation is applied on all frames (see section 6.1 for
+     details); a set bit indicates usage.
+
+
+   b - Extended header
+
+     The second bit (bit 6) indicates whether or not the header is
+     followed by an extended header. The extended header is described in
+     section 3.2. A set bit indicates the presence of an extended
+     header.
+
+
+   c - Experimental indicator
+
+     The third bit (bit 5) is used as an 'experimental indicator'. This
+     flag SHALL always be set when the tag is in an experimental stage.
+
+
+   d - Footer present
+
+     Bit 4 indicates that a footer (section 3.4) is present at the very
+     end of the tag. A set bit indicates the presence of a footer.
+
+
+   All the other flags MUST be cleared. If one of these undefined flags
+   are set, the tag might not be readable for a parser that does not
+   know the flags function.
+
+   The ID3v2 tag size is stored as a 32 bit synchsafe integer (section
+   6.2), making a total of 28 effective bits (representing up to 256MB).
+
+   The ID3v2 tag size is the sum of the byte length of the extended
+   header, the padding and the frames after unsynchronisation. If a
+   footer is present this equals to ('total size' - 20) bytes, otherwise
+   ('total size' - 10) bytes.
+
+   An ID3v2 tag can be detected with the following pattern:
+     $49 44 33 yy yy xx zz zz zz zz
+   Where yy is less than $FF, xx is the 'flags' byte and zz is less than
+   $80.
+
+
+3.2. Extended header
+
+   The extended header contains information that can provide further
+   insight in the structure of the tag, but is not vital to the correct
+   parsing of the tag information; hence the extended header is
+   optional.
+
+     Extended header size   4 * %0xxxxxxx
+     Number of flag bytes       $01
+     Extended Flags             $xx
+
+   Where the 'Extended header size' is the size of the whole extended
+   header, stored as a 32 bit synchsafe integer. An extended header can
+   thus never have a size of fewer than six bytes.
+
+   The extended flags field, with its size described by 'number of flag
+   bytes', is defined as:
+
+     %0bcd0000
+
+   Each flag that is set in the extended header has data attached, which
+   comes in the order in which the flags are encountered (i.e. the data
+   for flag 'b' comes before the data for flag 'c'). Unset flags cannot
+   have any attached data. All unknown flags MUST be unset and their
+   corresponding data removed when a tag is modified.
+
+   Every set flag's data starts with a length byte, which contains a
+   value between 0 and 127 ($00 - $7f), followed by data that has the
+   field length indicated by the length byte. If a flag has no attached
+   data, the value $00 is used as length byte.
+
+
+   b - Tag is an update
+
+     If this flag is set, the present tag is an update of a tag found
+     earlier in the present file or stream. If frames defined as unique
+     are found in the present tag, they are to override any
+     corresponding ones found in the earlier tag. This flag has no
+     corresponding data.
+
+         Flag data length      $00
+
+   c - CRC data present
+
+     If this flag is set, a CRC-32 [ISO-3309] data is included in the
+     extended header. The CRC is calculated on all the data between the
+     header and footer as indicated by the header's tag length field,
+     minus the extended header. Note that this includes the padding (if
+     there is any), but excludes the footer. The CRC-32 is stored as an
+     35 bit synchsafe integer, leaving the upper four bits always
+     zeroed.
+
+        Flag data length       $05
+        Total frame CRC    5 * %0xxxxxxx
+
+   d - Tag restrictions
+
+     For some applications it might be desired to restrict a tag in more
+     ways than imposed by the ID3v2 specification. Note that the
+     presence of these restrictions does not affect how the tag is
+     decoded, merely how it was restricted before encoding. If this flag
+     is set the tag is restricted as follows:
+
+        Flag data length       $01
+        Restrictions           %ppqrrstt
+
+     p - Tag size restrictions
+
+       00   No more than 128 frames and 1 MB total tag size.
+       01   No more than 64 frames and 128 KB total tag size.
+       10   No more than 32 frames and 40 KB total tag size.
+       11   No more than 32 frames and 4 KB total tag size.
+
+     q - Text encoding restrictions
+
+       0    No restrictions
+       1    Strings are only encoded with ISO-8859-1 [ISO-8859-1] or
+            UTF-8 [UTF-8].
+
+     r - Text fields size restrictions
+
+       00   No restrictions
+       01   No string is longer than 1024 characters.
+       10   No string is longer than 128 characters.
+       11   No string is longer than 30 characters.
+
+       Note that nothing is said about how many bytes is used to
+       represent those characters, since it is encoding dependent. If a
+       text frame consists of more than one string, the sum of the
+       strungs is restricted as stated.
+
+     s - Image encoding restrictions
+
+       0   No restrictions
+       1   Images are encoded only with PNG [PNG] or JPEG [JFIF].
+
+     t - Image size restrictions
+
+       00  No restrictions
+       01  All images are 256x256 pixels or smaller.
+       10  All images are 64x64 pixels or smaller.
+       11  All images are exactly 64x64 pixels, unless required
+           otherwise.
+
+
+3.3.   Padding
+
+   It is OPTIONAL to include padding after the final frame (at the end
+   of the ID3 tag), making the size of all the frames together smaller
+   than the size given in the tag header. A possible purpose of this
+   padding is to allow for adding a few additional frames or enlarge
+   existing frames within the tag without having to rewrite the entire
+   file. The value of the padding bytes must be $00. A tag MUST NOT have
+   any padding between the frames or between the tag header and the
+   frames. Furthermore it MUST NOT have any padding when a tag footer is
+   added to the tag.
+
+
+3.4.   ID3v2 footer
+
+   To speed up the process of locating an ID3v2 tag when searching from
+   the end of a file, a footer can be added to the tag. It is REQUIRED
+   to add a footer to an appended tag, i.e. a tag located after all
+   audio data. The footer is a copy of the header, but with a different
+   identifier.
+
+     ID3v2 identifier           "3DI"
+     ID3v2 version              $04 00
+     ID3v2 flags                %abcd0000
+     ID3v2 size             4 * %0xxxxxxx
+
+
+4.   ID3v2 frame overview
+
+   All ID3v2 frames consists of one frame header followed by one or more
+   fields containing the actual information. The header is always 10
+   bytes and laid out as follows:
+
+     Frame ID      $xx xx xx xx  (four characters)
+     Size      4 * %0xxxxxxx
+     Flags         $xx xx
+
+   The frame ID is made out of the characters capital A-Z and 0-9.
+   Identifiers beginning with "X", "Y" and "Z" are for experimental
+   frames and free for everyone to use, without the need to set the
+   experimental bit in the tag header. Bear in mind that someone else
+   might have used the same identifier as you. All other identifiers are
+   either used or reserved for future use.
+
+   The frame ID is followed by a size descriptor containing the size of
+   the data in the final frame, after encryption, compression and
+   unsynchronisation. The size is excluding the frame header ('total
+   frame size' - 10 bytes) and stored as a 32 bit synchsafe integer.
+
+   In the frame header the size descriptor is followed by two flag
+   bytes. These flags are described in section 4.1.
+
+   There is no fixed order of the frames' appearance in the tag,
+   although it is desired that the frames are arranged in order of
+   significance concerning the recognition of the file. An example of
+   such order: UFID, TIT2, MCDI, TRCK ...
+
+   A tag MUST contain at least one frame. A frame must be at least 1
+   byte big, excluding the header.
+
+   If nothing else is said, strings, including numeric strings and URLs
+   [URL], are represented as ISO-8859-1 [ISO-8859-1] characters in the
+   range $20 - $FF. Such strings are represented in frame descriptions
+   as <text string>, or <full text string> if newlines are allowed. If
+   nothing else is said newline character is forbidden. In ISO-8859-1 a
+   newline is represented, when allowed, with $0A only.
+
+   Frames that allow different types of text encoding contains a text
+   encoding description byte. Possible encodings:
+
+     $00   ISO-8859-1 [ISO-8859-1]. Terminated with $00.
+     $01   UTF-16 [UTF-16] encoded Unicode [UNICODE] with BOM. All
+           strings in the same frame SHALL have the same byteorder.
+           Terminated with $00 00.
+     $02   UTF-16BE [UTF-16] encoded Unicode [UNICODE] without BOM.
+           Terminated with $00 00.
+     $03   UTF-8 [UTF-8] encoded Unicode [UNICODE]. Terminated with $00.
+
+   Strings dependent on encoding are represented in frame descriptions
+   as <text string according to encoding>, or <full text string
+   according to encoding> if newlines are allowed. Any empty strings of
+   type $01 which are NULL-terminated may have the Unicode BOM followed
+   by a Unicode NULL ($FF FE 00 00 or $FE FF 00 00).
+
+   The timestamp fields are based on a subset of ISO 8601. When being as
+   precise as possible the format of a time string is
+   yyyy-MM-ddTHH:mm:ss (year, "-", month, "-", day, "T", hour (out of
+   24), ":", minutes, ":", seconds), but the precision may be reduced by
+   removing as many time indicators as wanted. Hence valid timestamps
+   are
+   yyyy, yyyy-MM, yyyy-MM-dd, yyyy-MM-ddTHH, yyyy-MM-ddTHH:mm and
+   yyyy-MM-ddTHH:mm:ss. All time stamps are UTC. For durations, use
+   the slash character as described in 8601, and for multiple non-
+   contiguous dates, use multiple strings, if allowed by the frame
+   definition.
+
+   The three byte language field, present in several frames, is used to
+   describe the language of the frame's content, according to ISO-639-2
+   [ISO-639-2]. The language should be represented in lower case. If the
+   language is not known the string "XXX" should be used.
+
+   All URLs [URL] MAY be relative, e.g. "picture.png", "../doc.txt".
+
+   If a frame is longer than it should be, e.g. having more fields than
+   specified in this document, that indicates that additions to the
+   frame have been made in a later version of the ID3v2 standard. This
+   is reflected by the revision number in the header of the tag.
+
+
+4.1.   Frame header flags
+
+   In the frame header the size descriptor is followed by two flag
+   bytes. All unused flags MUST be cleared. The first byte is for
+   'status messages' and the second byte is a format description. If an
+   unknown flag is set in the first byte the frame MUST NOT be changed
+   without that bit cleared. If an unknown flag is set in the second
+   byte the frame is likely to not be readable. Some flags in the second
+   byte indicates that extra information is added to the header. These
+   fields of extra information is ordered as the flags that indicates
+   them. The flags field is defined as follows (l and o left out because
+   ther resemblence to one and zero):
+
+     %0abc0000 %0h00kmnp
+
+   Some frame format flags indicate that additional information fields
+   are added to the frame. This information is added after the frame
+   header and before the frame data in the same order as the flags that
+   indicates them. I.e. the four bytes of decompressed size will precede
+   the encryption method byte. These additions affects the 'frame size'
+   field, but are not subject to encryption or compression.
+   
+   The default status flags setting for a frame is, unless stated
+   otherwise, 'preserved if tag is altered' and 'preserved if file is
+   altered', i.e. %00000000.
+
+
+4.1.1. Frame status flags
+
+   a - Tag alter preservation
+
+     This flag tells the tag parser what to do with this frame if it is
+     unknown and the tag is altered in any way. This applies to all
+     kinds of alterations, including adding more padding and reordering
+     the frames.
+
+     0     Frame should be preserved.
+     1     Frame should be discarded.
+
+
+   b - File alter preservation
+
+     This flag tells the tag parser what to do with this frame if it is
+     unknown and the file, excluding the tag, is altered. This does not
+     apply when the audio is completely replaced with other audio data.
+
+     0     Frame should be preserved.
+     1     Frame should be discarded.
+
+
+   c - Read only
+
+      This flag, if set, tells the software that the contents of this
+      frame are intended to be read only. Changing the contents might
+      break something, e.g. a signature. If the contents are changed,
+      without knowledge of why the frame was flagged read only and
+      without taking the proper means to compensate, e.g. recalculating
+      the signature, the bit MUST be cleared.
+
+
+4.1.2. Frame format flags
+
+   h - Grouping identity
+
+      This flag indicates whether or not this frame belongs in a group
+      with other frames. If set, a group identifier byte is added to the
+      frame. Every frame with the same group identifier belongs to the
+      same group.
+
+      0     Frame does not contain group information
+      1     Frame contains group information
+
+
+   k - Compression
+
+      This flag indicates whether or not the frame is compressed.
+      A 'Data Length Indicator' byte MUST be included in the frame.
+
+      0     Frame is not compressed.
+      1     Frame is compressed using zlib [zlib] deflate method.
+            If set, this requires the 'Data Length Indicator' bit
+            to be set as well.
+
+
+   m - Encryption
+   
+      This flag indicates whether or not the frame is encrypted. If set,
+      one byte indicating with which method it was encrypted will be
+      added to the frame. See description of the ENCR frame for more
+      information about encryption method registration. Encryption
+      should be done after compression. Whether or not setting this flag
+      requires the presence of a 'Data Length Indicator' depends on the
+      specific algorithm used.
+
+      0     Frame is not encrypted.
+      1     Frame is encrypted.
+
+   n - Unsynchronisation
+
+      This flag indicates whether or not unsynchronisation was applied
+      to this frame. See section 6 for details on unsynchronisation.
+      If this flag is set all data from the end of this header to the
+      end of this frame has been unsynchronised. Although desirable, the
+      presence of a 'Data Length Indicator' is not made mandatory by
+      unsynchronisation.
+
+      0     Frame has not been unsynchronised.
+      1     Frame has been unsyrchronised.
+
+   p - Data length indicator
+
+      This flag indicates that a data length indicator has been added to
+      the frame. The data length indicator is the value one would write
+      as the 'Frame length' if all of the frame format flags were
+      zeroed, represented as a 32 bit synchsafe integer.
+
+      0      There is no Data Length Indicator.
+      1      A data length Indicator has been added to the frame.
+
+
+5.   Tag location
+
+   The default location of an ID3v2 tag is prepended to the audio so
+   that players can benefit from the information when the data is
+   streamed. It is however possible to append the tag, or make a
+   prepend/append combination. When deciding upon where an unembedded
+   tag should be located, the following order of preference SHOULD be
+   considered.
+   
+     1. Prepend the tag.
+
+     2. Prepend a tag with all vital information and add a second tag at 
+        the end of the file, before tags from other tagging systems. The
+        first tag is required to have a SEEK frame.
+      
+     3. Add a tag at the end of the file, before tags from other tagging
+        systems.
+      
+   In case 2 and 3 the tag can simply be appended if no other known tags
+   are present. The suggested method to find ID3v2 tags are:
+   
+     1. Look for a prepended tag using the pattern found in section 3.1.
+
+     2. If a SEEK frame was found, use its values to guide further
+        searching.
+
+     3. Look for a tag footer, scanning from the back of the file.
+
+   For every new tag that is found, the old tag should be discarded
+   unless the update flag in the extended header (section 3.2) is set.
+   
+
+6.   Unsynchronisation
+
+   The only purpose of unsynchronisation is to make the ID3v2 tag as
+   compatible as possible with existing software and hardware. There is
+   no use in 'unsynchronising' tags if the file is only to be processed
+   only by ID3v2 aware software and hardware. Unsynchronisation is only
+   useful with tags in MPEG 1/2 layer I, II and III, MPEG 2.5 and AAC
+   files.
+
+
+6.1.   The unsynchronisation scheme
+
+   Whenever a false synchronisation is found within the tag, one zeroed
+   byte is inserted after the first false synchronisation byte. The
+   format of synchronisations that should be altered by ID3 encoders is
+   as follows:
+
+         %11111111 111xxxxx
+
+   and should be replaced with:
+
+         %11111111 00000000 111xxxxx
+
+   This has the side effect that all $FF 00 combinations have to be
+   altered, so they will not be affected by the decoding process.
+   Therefore all the $FF 00 combinations have to be replaced with the
+   $FF 00 00 combination during the unsynchronisation.
+
+   To indicate usage of the unsynchronisation, the unsynchronisation
+   flag in the frame header should be set. This bit MUST be set if the
+   frame was altered by the unsynchronisation and SHOULD NOT be set if
+   unaltered. If all frames in the tag are unsynchronised the
+   unsynchronisation flag in the tag header SHOULD be set. It MUST NOT
+   be set if the tag has a frame which is not unsynchronised.
+
+   Assume the first byte of the audio to be $FF. The special case when
+   the last byte of the last frame is $FF and no padding nor footer is
+   used will then introduce a false synchronisation. This can be solved
+   by adding a footer, adding padding or unsynchronising the frame and
+   add $00 to the end of the frame data, thus adding more byte to the
+   frame size than a normal unsynchronisation would. Although not
+   preferred, it is allowed to apply the last method on all frames
+   ending with $FF.
+
+   It is preferred that the tag is either completely unsynchronised or
+   not unsynchronised at all. A completely unsynchronised tag has no 
+   false synchonisations in it, as defined above, and does not end with
+   $FF. A completely non-unsynchronised tag contains no unsynchronised
+   frames, and thus the unsynchronisation flag in the header is cleared.
+
+   Do bear in mind, that if compression or encryption is used, the
+   unsynchronisation scheme MUST be applied afterwards. When decoding an
+   unsynchronised frame, the unsynchronisation scheme MUST be reversed
+   first, encryption and decompression afterwards.
+
+
+6.2.   Synchsafe integers
+
+   In some parts of the tag it is inconvenient to use the
+   unsychronisation scheme because the size of unsynchronised data is
+   not known in advance, which is particularly problematic with size
+   descriptors. The solution in ID3v2 is to use synchsafe integers, in
+   which there can never be any false synchs. Synchsafe integers are
+   integers that keep its highest bit (bit 7) zeroed, making seven bits
+   out of eight available. Thus a 32 bit synchsafe integer can store 28
+   bits of information.
+   
+   Example:
+   
+     255 (%11111111) encoded as a 16 bit synchsafe integer is 383
+     (%00000001 01111111).
+
+
+7.   Copyright
+
+   Copyright (C) Martin Nilsson 2000. All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that a reference to this document is included on all
+   such copies and derivative works. However, this document itself may
+   not be modified in any way and reissued as the original document.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked.
+
+   This document and the information contained herein is provided on an
+   'AS IS' basis and THE AUTHORS DISCLAIMS ALL WARRANTIES, EXPRESS OR
+   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+8.   References
+
+   [ID3v2] Martin Nilsson, 'ID3v2 informal standard'.
+
+      <url:http://www.id3.org/id3v2.3.0.txt>
+
+   [ISO-639-2] ISO/FDIS 639-2.
+   'Codes for the representation of names of languages, Part 2: Alpha-3
+   code.' Technical committee / subcommittee: TC 37 / SC 2
+
+   [ISO-3309] ISO 3309
+   'Information Processing Systems--Data Communication High-Level Data
+   Link Control Procedure--Frame Structure', IS 3309, October 1984, 3rd
+   Edition.
+
+   [ISO-8859-1] ISO/IEC DIS 8859-1.
+   '8-bit single-byte coded graphic character sets, Part 1: Latin
+   alphabet No. 1.' Technical committee / subcommittee: JTC 1 / SC 2
+
+   [JFIF] 'JPEG File Interchange Format, version 1.02'
+
+      <url:http://www.w3.org/Graphics/JPEG/jfif.txt>
+
+   [KEYWORDS] S. Bradner, 'Key words for use in RFCs to Indicate
+   Requirement Levels', RFC 2119, March 1997.
+
+      <url:ftp://ftp.isi.edu/in-notes/rfc2119.txt>
+
+   [MPEG] ISO/IEC 11172-3:1993.
+   'Coding of moving pictures and associated audio for digital storage
+   media at up to about 1,5 Mbit/s, Part 3: Audio.'
+   Technical committee / subcommittee: JTC 1 / SC 29
+    and
+   ISO/IEC 13818-3:1995
+   'Generic coding of moving pictures and associated audio information,
+   Part 3: Audio.'
+   Technical committee / subcommittee: JTC 1 / SC 29
+    and
+   ISO/IEC DIS 13818-3
+   'Generic coding of moving pictures and associated audio information,
+   Part 3: Audio (Revision of ISO/IEC 13818-3:1995)'
+
+   [PNG] 'Portable Network Graphics, version 1.0'
+
+      <url:http://www.w3.org/TR/REC-png-multi.html>
+
+   [UNICODE] The Unicode Consortium,
+   'The Unicode Standard Version 3.0', ISBN 0-201-61633-5.
+
+   <url:http://www.unicode.org/unicode/standard/versions/Unicode3.0.htm>
+
+   [URL] T. Berners-Lee, L. Masinter & M. McCahill, 'Uniform Resource
+   Locators (URL)', RFC 1738, December 1994.
+
+      <url:ftp://ftp.isi.edu/in-notes/rfc1738.txt>
+
+   [UTF-8] F. Yergeau, 'UTF-8, a transformation format of ISO 10646',
+   RFC 2279, January 1998.
+   
+      <url:ftp://ftp.isi.edu/in-notes/rfc2279.txt>
+
+   [UTF-16] F. Yergeau, 'UTF-16, an encoding of ISO 10646', RFC 2781,
+   February 2000.
+   
+      <url:ftp://ftp.isi.edu/in-notes/rfc2781.txt>
+   
+   [ZLIB] P. Deutsch, Aladdin Enterprises & J-L. Gailly, 'ZLIB
+   Compressed Data Format Specification version 3.3', RFC 1950,
+   May 1996.
+
+      <url:ftp://ftp.isi.edu/in-notes/rfc1950.txt>
+
+
+9.   Author's Address
+
+   Written by
+
+     Martin Nilsson
+     Rydsvägen 246 C. 30
+     SE-584 34 Linköping
+     Sweden
+
+     Email: nilsson@id3.org
+