id3v2.3.0.txt

更新mp3

     <Header of 'Equalisation', ID: "EQUA">
     Adjustment bits    $xx

   The 'adjustment bits' field defines the number of bits used for
   representation of the adjustment. This is normally $10 (16 bits) for
   MPEG 2 layer I, II and III [MPEG] and MPEG 2.5. This value may not be
   $00.

   This is followed by 2 bytes + ('adjustment bits' rounded up to the
   nearest byte) for every equalisation band in the following format,
   giving a frequency range of 0 - 32767Hz:

     Increment/decrement   %x (MSB of the Frequency)
     Frequency             (lower 15 bits)
     Adjustment            $xx (xx ...)

   The increment/decrement bit is 1 for increment and 0 for decrement.
   The equalisation bands should be ordered increasingly with reference
   to frequency. All frequencies don't have to be declared. The
   equalisation curve in the reading software should be interpolated
   between the values in this frame. Three equal adjustments for three
   subsequent frequencies. A frequency should only be described once in
   the frame.


4.14.   Reverb

   Yet another subjective one. You may here adjust echoes of different
   kinds. Reverb left/right is the delay between every bounce in ms.
   Reverb bounces left/right is the number of bounces that should be
   made. $FF equals an infinite number of bounces. Feedback is the
   amount of volume that should be returned to the next echo bounce. $00
   is 0%, $FF is 100%. If this value were $7F, there would be 50% volume
   reduction on the first bounce, 50% of that on the second and so on.
   Left to left means the sound from the left bounce to be played in the
   left speaker, while left to right means sound from the left bounce to
   be played in the right speaker.

   'Premix left to right' is the amount of left sound to be mixed in the
   right before any reverb is applied, where $00 id 0% and $FF is 100%.
   'Premix right to left' does the same thing, but right to left.
   Setting both premix to $FF would result in a mono output (if the
   reverb is applied symmetric). There may only be one "RVRB" frame in
   each tag.

     <Header for 'Reverb', ID: "RVRB">
     Reverb left (ms)                 $xx xx
     Reverb right (ms)                $xx xx
     Reverb bounces, left             $xx
     Reverb bounces, right            $xx
     Reverb feedback, left to left    $xx
     Reverb feedback, left to right   $xx
     Reverb feedback, right to right  $xx
     Reverb feedback, right to left   $xx
     Premix left to right             $xx
     Premix right to left             $xx


4.15.   Attached picture

   This frame contains a picture directly related to the audio file.
   Image format is the MIME type and subtype [MIME] for the image. In
   the event that the MIME media type name is omitted, "image/" will be
   implied. The "image/png" [PNG] or "image/jpeg" [JFIF] picture format
   should be used when interoperability is wanted. Description is a
   short description of the picture, represented as a terminated
   textstring. The description has a maximum length of 64 characters,
   but may be empty. There may be several pictures attached to one file,
   each in their individual "APIC" frame, but only one with the same
   content descriptor. There may only be one picture with the picture
   type declared as picture type $01 and $02 respectively. There is the
   possibility to put only a link to the image file by using the 'MIME
   type' "-->" and having a complete URL [URL] instead of picture data.
   The use of linked files should however be used sparingly since there
   is the risk of separation of files.

     <Header for 'Attached picture', ID: "APIC">
     Text encoding      $xx
     MIME type          <text string> $00
     Picture type       $xx
     Description        <text string according to encoding> $00 (00)
     Picture data       <binary data>


   Picture type:  $00  Other
                  $01  32x32 pixels 'file icon' (PNG only)
                  $02  Other file icon
                  $03  Cover (front)
                  $04  Cover (back)
                  $05  Leaflet page
                  $06  Media (e.g. lable side of CD)
                  $07  Lead artist/lead performer/soloist
                  $08  Artist/performer
                  $09  Conductor
                  $0A  Band/Orchestra
                  $0B  Composer
                  $0C  Lyricist/text writer
                  $0D  Recording Location
                  $0E  During recording
                  $0F  During performance
                  $10  Movie/video screen capture
                  $11  A bright coloured fish
                  $12  Illustration
                  $13  Band/artist logotype
                  $14  Publisher/Studio logotype


4.16.   General encapsulated object

   In this frame any type of file can be encapsulated. After the header,
   'Frame size' and 'Encoding' follows 'MIME type' [MIME] represented as
   as a terminated string encoded with ISO 8859-1 [ISO-8859-1]. The
   filename is case sensitive and is encoded as 'Encoding'. Then follows
   a content description as terminated string, encoded as 'Encoding'.
   The last thing in the frame is the actual object. The first two
   strings may be omitted, leaving only their terminations. MIME type is
   always an ISO-8859-1 text string. There may be more than one "GEOB"
   frame in each tag, but only one with the same content descriptor.

     <Header for 'General encapsulated object', ID: "GEOB">
     Text encoding          $xx
     MIME type              <text string> $00
     Filename               <text string according to encoding> $00 (00)
     Content description    <text string according to enc骴ing> $00 (00)
     Encapsulated object    <binary data>


4.17.   Play counter

   This is simply a counter of the number of times a file has been
   played. The value is increased by one every time the file begins to
   play. There may only be one "PCNT" frame in each tag. When the
   counter reaches all one's, one byte is inserted in front of the
   counter thus making the counter eight bits bigger.  The counter must
   be at least 32-bits long to begin with.

     <Header for 'Play counter', ID: "PCNT">
     Counter        $xx xx xx xx (xx ...)


4.18.   Popularimeter

   The purpose of this frame is to specify how good an audio file is.
   Many interesting applications could be found to this frame such as a
   playlist that features better audiofiles more often than others or it
   could be used to profile a person's taste and find other 'good' files
   by comparing people's profiles. The frame is very simple. It contains
   the email address to the user, one rating byte and a four byte play
   counter, intended to be increased with one for every time the file is
   played. The email is a terminated string. The rating is 1-255 where
   1 is worst and 255 is best. 0 is unknown. If no personal counter is
   wanted it may be omitted.  When the counter reaches all one's, one
   byte is inserted in front of the counter thus making the counter
   eight bits bigger in the same away as the play counter ("PCNT").
   There may be more than one "POPM" frame in each tag, but only one
   with the same email address.

     <Header for 'Popularimeter', ID: "POPM">
     Email to user   <text string> $00
     Rating          $xx
     Counter         $xx xx xx xx (xx ...)


4.19.   Recommended buffer size

   Sometimes the server from which a audio file is streamed is aware of
   transmission or coding problems resulting in interruptions in the
   audio stream. In these cases, the size of the buffer can be
   recommended by the server using this frame. If the 'embedded info
   flag' is true (1) then this indicates that an ID3 tag with the
   maximum size described in 'Buffer size' may occur in the audiostream.
   In such case the tag should reside between two MPEG [MPEG] frames, if
   the audio is MPEG encoded. If the position of the next tag is known,
   'offset to next tag' may be used. The offset is calculated from the
   end of tag in which this frame resides to the first byte of the
   header in the next. This field may be omitted. Embedded tags are
   generally not recommended since this could render unpredictable
   behaviour from present software/hardware.

   For applications like streaming audio it might be an idea to embed
   tags into the audio stream though. If the clients connects to
   individual connections like HTTP and there is a possibility to begin
   every transmission with a tag, then this tag should include a
   'recommended buffer size' frame. If the client is connected to a
   arbitrary point in the stream, such as radio or multicast, then the
   'recommended buffer size' frame should be included in every tag.
   Every tag that is picked up after the initial/first tag is to be
   considered as an update of the previous one. E.g. if there is a
   "TIT2" frame in the first received tag and one in the second tag,
   then the first should be 'replaced' with the second.

   The 'Buffer size' should be kept to a minimum. There may only be one
   "RBUF" frame in each tag.

     <Header for 'Recommended buffer size', ID: "RBUF">
     Buffer size               $xx xx xx
     Embedded info flag        %0000000x
     Offset to next tag        $xx xx xx xx


4.20.   Audio encryption

   This frame indicates if the actual audio stream is encrypted, and by
   whom. Since standardisation of such encrypion scheme is beyond this
   document, all "AENC" frames begin with a terminated string with a
   URL containing an email address, or a link to a location where an
   email address can be found, that belongs to the organisation
   responsible for this specific encrypted audio file. Questions
   regarding the encrypted audio should be sent to the email address
   specified. If a $00 is found directly after the 'Frame size' and the
   audiofile indeed is encrypted, the whole file may be considered
   useless.

   After the 'Owner identifier', a pointer to an unencrypted part of the
   audio can be specified. The 'Preview start' and 'Preview length' is
   described in frames. If no part is unencrypted, these fields should
   be left zeroed. After the 'preview length' field follows optionally a
   datablock required for decryption of the audio. There may be more
   than one "AENC" frames in a tag, but only one with the same 'Owner
   identifier'.

     <Header for 'Audio encryption', ID: "AENC">
     Owner identifier   <text string> $00
     Preview start      $xx xx
     Preview length     $xx xx
     Encryption info    <binary data>


4.21.   Linked information

   To keep space waste as low as possible this frame may be used to link
   information from another ID3v2 tag that might reside in another audio
   file or alone in a binary file. It is recommended that this method is
   only used when the files are stored on a CD-ROM or other
   circumstances when the risk of file seperation is low. The frame
   contains a frame identifier, which is the frame that should be linked
   into this tag, a URL [URL] field, where a reference to the file where
   the frame is given, and additional ID data, if needed. Data should be
   retrieved from the first tag found in the file to which this link
   points. There may be more than one "LINK" frame in a tag, but only
   one with the same contents. A linked frame is to be considered as
   part of the tag and has the same restrictions as if it was a physical
   part of the tag (i.e. only one "RVRB" frame allowed, whether it's
   linked or not).

     <Header for 'Linked information', ID: "LINK">
     Frame identifier        $xx xx xx
     URL                     <text string> $00
     ID and additional data  <text string(s)>

   Frames that may be linked and need no additional data are "IPLS",
   "MCID", "ETCO", "MLLT", "SYTC", "RVAD", "EQUA", "RVRB", "RBUF", the
   text information frames and the URL link frames.

   The "TXXX", "APIC", "GEOB" and "AENC" frames may be linked with
   the content descriptor as additional ID data.

   The "COMM", "SYLT" and "USLT" frames may be linked with three bytes
   of language descriptor directly followed by a content descriptor as
   additional ID data.


4.22.   Position synchronisation frame

   This frame delivers information to the listener of how far into the
   audio stream he picked up; in effect, it states the time offset of
   the first frame in the stream. The frame layout is:

     <Head for 'Position synchronisation', ID: "POSS">
     Time stamp format         $xx
     Position                  $xx (xx ...)

   Where time stamp format is:

     $01  Absolute time, 32 bit sized, using MPEG frames as unit
     $02  Absolute time, 32 bit sized, using milliseconds as unit

   and position is where in the audio the listener starts to receive,
   i.e. the beginning of the next frame. If this frame is used in the
   beginning of a file the value is always 0. There may only be one
   "POSS" frame in each tag.


4.23.   Terms of use frame

   This frame contains a brief description of the terms of use and
   ownership of the file. More detailed information concerning the legal
   terms might be available through the "WCOP" frame. Newlines are
   allowed in the text. There may only be one "USER" frame in a tag.

     <Header for 'Terms of use frame', ID: "USER">
     Text encoding        $xx
     Language             $xx xx xx
     The actual text      <text string according to encoding>


4.24.   Ownership frame

   The ownership frame might be used as a reminder of a made transaction
   or, if signed, as proof. Note that the "USER" and "TOWN" frames are
   good to use in conjunction with this one. The frame begins, after the
   frame ID, size and encoding fields, with a 'price payed' field. The
   first three characters of this field contains the currency used for
   the transaction, encoded according to ISO 4217 [ISO-4217] alphabetic
   currency code. Concatenated to this is the actual price payed, as a
   numerical string using "." as the decimal separator. Next is an 8
   character date string (YYYYMMDD) followed by a string with the name
   of the seller as the last field in the frame. There may only be one
   "OWNE" frame in a tag.

     <Header for 'Ownership frame', ID: "OWNE">
     Text encoding     $xx
     Price payed       <text string> $00
     Date of purch.    <text string>
     Seller            <text string according to encoding>


4.25.   Commercial frame

   This frame enables several competing