id3guide.html

更新mp3

<TD ALIGN=CENTER>4.5K - 8K</TD>

<TD ALIGN=CENTER>8.5K - 16K</TD>

<TD ALIGN=CENTER>16.5K - 32K</TD>

<TD ALIGN=CENTER COLSPAN="3">N/A<BR>
(HFS&nbsp;can't handle disks&nbsp;&gt;&nbsp;2GB)</TD>
</TR>

<TR>
<TD>MacOS 8.1 and later<BR>
(HFS+)</TD>

<TD ALIGN=CENTER>0.5K</TD>

<TD ALIGN=CENTER>1K</TD>

<TD ALIGN=CENTER>2K</TD>

<TD ALIGN=CENTER COLSPAN="4">Default is 4K; user-selectable up to 4K</TD>
</TR>

<TR>
<TD>CD-ROM, 650MB<BR>
(ISO&nbsp;9660)</TD>

<TD ALIGN=CENTER COLSPAN="3">always 2K</TD>
</TR>

<TR>
<TD>DVD-ROM<BR>
(UDF)</TD>

<TD ALIGN=CENTER COLSPAN="7">always 2K</TD>
</TR>
</TABLE>

<P>Advanced operating systems employ tricks to optimize disk space. For
example, Novell NetWare 4 uses 64K disk blocks but can split a block into
0.5K pieces, thus creating the illusion of 512-byte blocks. UNIX&nbsp;file
systems have their own methods to utilize disk space efficiently.</P>

<P><B>James's</B> shortcut on choosing an appropriate cluster size: 2K
(Nice even number, not too big, not too small)</P>

<H2><A NAME="ROmedia"></A>3.2 Read-only media</H2>

<P>Never assume a .MP3 file is writable unless the user is specifically
editing the tag. MP3 files can be stored on read-only media such as a CD-ROM
or a network share. If the user is editing the tag, it is an error if the
file is write-protected because the user's changes cannot be saved. If
a player is merely updating the playcounter or popularity-meter, it should
not pop up a message complaining the file cannot be written to. </P>

<P><B>James</B>: Include a visual cue to indicate whether the file is write-protected.
For example, a small icon similar in size and color to the stereo indicator
in WinAMP. A quick glance will determine whether certain settings will
be saved. </P>

<H2><A NAME="SmallFrames"></A>3.3 &quot;Insignificant&quot; frames</H2>

<P>&quot;Insignificant&quot; frames are small frames that don't necessarily
have meaning when a ID3v2 tag is created. The issue is whether the tag
editor should add these frames when they do not already exist. </P>

<P>For example, if Joe is adding tags to a fresh batch of .MP3 files, should
the tag editor include a playcounter [PCNT] frame in the tag? The tag editor
has no idea how many times the particular file has been played; unless
Joe tells it otherwise, the editor has to create a [PCNT] frame with a
count of 0. </P>

<P>There are two ways to look at this. On the one hand, the frame is so
small it takes almost no effort to include it. Since there will usually
be a few hundred bytes of padding, the ten bytes used by the counter frame
is in a sense &quot;free.&quot; A player will probably add it later anyway
when the file is used. </P>

<P>On the other hand, if the frame is not holding useful information, why
bother adding it? Padding, if used, effectively reserves space for these
frames. Consider also the absence of a frame can be meaningful: the lack
of a playcounter frame may indicate &quot;I do not know how many times
this piece has been played&quot; as opposed to a count of 0, which
indicates &quot;This song has never been played.&quot; </P>

<P>These can be considered &quot;insignificant&quot; frames: </P>

<UL>
<LI>Playcounter [PCNT]<BR>
(<B>James</B>: an integrated ripper-encoder-tagger can include a playcount
of 0 in newly created files, since by definition they have never been used..)
</LI>

<LI>Others, anyone?</LI>
</UL>

<P><B>Martin</B>: It is considered good manner to allow the user to disable
writing of frames (s)he doesn't want. At least in an advanced menu in a
hidden place. Perhaps the user doesn't want the TSI, TLE, TMT and MLL frame
to be added automatically, even though it might be the default setting.</P>

<H2><A NAME="iformat"></A>3.4 Preferred image formats</H2>

<P>A question Martin gets often is why the ID3v2 document says &quot;...
PNG&nbsp;and JPEG picture format should be used...&quot; Interoperability
means it is almost guaranteed another ID3v2 tag/picture decoder can handle
the PNG and JPEG formats. The chances a Macintosh application can display
BMP files are slim; likewise, the complexities of EPS and TIFF are best
left out.</P>

<P>Consider these other arguments favoring PNG and JPEG:</P>

<UL>
<LI>PNG compresses better than BMP, GIF and most other lossless formats.</LI>

<LI>JPEG has superior compression to most formats, especially for photographic
pictures. (JPEG is not suitable for line-art and computer-generated graphics
- use PNG for these.)</LI>

<LI>Both formats are patent- and royalty-free (which is not the case with
GIF, whose LZW compression algorithm is patented by Unisys.) </LI>
</UL>

<P><B>Martin</B>: The freedom to use whatever format you like in the picture
frame is of course a freedom under responsibility. Do you want to make
cross platform tags? Do you want to avoid legal trouble, at least for the
principle? If so, use PNG and JPEG.</P>

<P><B>Dirk</B>: Applications may want to convert the incoming picture type
to PNG or JPEG first, or failing that, at least inform the user that they
<I>should</I> be using PNG or JPEG, but allow the user to override this
if they insist on using, say, a PCX.</P>

<H2><A NAME="manytags"></A>3.5 Multiple tags</H2>

<P>Decoders should be prepared to handle multiple ID3v2 tags per stream.
This is especially important for players/decoders wanting to handle netradio-type
applications since the notion of distinct files may not apply. </P>

<P><B>Dirk</B>: An easy way to achieve this would be to use a central 'frame
dispatch' routine, kind of like a demultiplexer. </P>

<H2><A NAME="unsync"></A>3.6 Unsynchronization</H2>

<P>The ID3v2 standard states&nbsp;&quot;The only purpose of the 'unsychronisation
scheme' is to make the ID3v2 tag as compatible as possible with existing
software <I>[at the time the ID3v2.2 standard was drafted]</I>&quot; What
are the implications?</P>

<OL>
<LI>.MP3 decoders, regardless of age, will not be affected by extraneous 
data (i.e., tags)&nbsp;that does not contain a MPEG&nbsp;sync sequence.</LI>

<LI>There is minimal impact if a decoder does not recognize ID3v2 tags
but encounters something with a sync sequence. At worst a click or pop
will be heard at the beginning of the piece, as if some data corruption
has occurred.</LI>

<LI>New software is expected to take advantage of ID3v2. Unsynchronization
is not necessary with ID3v2 compliant software.</LI>
</OL>

<P>(Software which does not behave according to items 1 and 2 above are
categorically deemed &quot;broken.&quot; Microsoft's Media Player is an
example of such software.)</P>

<P><B>Martin</B>: I believe that unsynchronization should be done as seldom
as possible since it increases the size of the tag as well as the parsing
time. In other words, I think unsynchronization should be turned off as
default.</P>

<P>However, it is important to be able to undo unsynchronization when reading
tags; otherwise unsynchronized tags will not be read correctly.</P>

<P>
<HR WIDTH="85%"></P>

<H2><A NAME="rtfm"></A>4.1 RTFM (details are important!)</H2>

<P>When the ID3v2 document refers to another standard it is assumed that
the implementor is familiar with that standard as well. When it says URL
it does not mean 'www.buymusic.com', it means 'http://www.buymusic.com/'
A&nbsp;&quot;URL&nbsp;containing an e-mail address&quot; must include the
'mailto:' qualifier. Those who at least take a quick look at the related
standards will not make these kinds of mistakes.</P>

<P>If these details are so important, why aren't they spelled out in the
ID3v2 standard? According to Martin, &quot;There has been people who said
to me, 'You must write these kind of things in the document, or else people
will make these mistakes.' The latest ID3 v2.01 draft is <I>only</I> 74,657
bytes of pure text because I did not. Guess why there are references to
the standards in the document!&quot; </P>

<H2><A NAME="cB4e"></A>4.2 Compression before encryption</H2>

<P>Encryption works by scrambling data to produce what amounts to random
bits for an attacker. Data compression works by replacing or removing redundant
information. It follows that the output of any decent crypto algorithm
will not be compressible; therefore if you wish to use both compression
and encryption, you must compress the data before encrypting it. </P>

<P>Compressing before encryption also affords better security, since predictable
headers and such will be hidden by compression. </P>

<P>Remember: <I>compression</I> comes before <I>encryption</I> in the dictionary
(at least in English) and that is how it should be in your application.
</P>

<H2><A NAME="userErr"></A>4.3 Validating user input</H2>

<P>Never trust the input from the user to be sensible or formatted correctly.
Is the ISRC a valid one? Does the month 13 exist? Could this piece of music
be from disc 5 out of a 3 disc set?</P>

<P><B>Dirk</B>:&nbsp;Personally, I think having input validation occur
when the user signifies that the tag is &quot;finished&quot; is a good
way of going about it, if only because I know I'll get half way through
something and want to stop and do something else before I forget.</P>

<P><B>James</B>:&nbsp;Extremely strict validation becomes restrictions
on versatility and usability. An option to turn off or accept potentially
invalid data can be included somewhere. For example, by default Microsoft
Visual Basic checks for syntax errors as code is entered; however, users
can disable that feature if they wish to delay syntax checking until compile
time. </P>

<P>Things to watch out for (this is by no means an all-inclusive list):</P>

<UL>
<LI>Properly formatted URLs (see <A HREF="#rtfm">RTFM</A>, above.)&nbsp;But
should your application verify whether the URL actually exists? That may
be too complicated; Martin and James's opinion is no verification.</LI>

<LI>Proper MIME types.</LI>

<LI>Are characters valid?&nbsp;Most text fields forbid control characters,
even newlines. NULs are not allowed except in Unicode strings or to indicate
end-of-string for terminated strings.</LI>

<LI>Numerical strings must consist solely of the characters '0' through
'9'</LI>

<LI>Are lists handled properly?&nbsp;The list separator is a slash:&nbsp;/
What happens if the user enters a / in an item?</LI>

<LI>Are characters such as ( escaped where necessary?</LI>

<LI>Do dates and times make sense? Years must be four digits long and be
in the right century.&nbsp;(No Y2K problems here!)</LI>

<LI>Is an image really the format the user claims it is? Some people believe
renaming a .BMP file to .PNG will change its format accordingly.</LI>
</UL>

<P>Your application should never crash because the user does something
stupid. Likewise, your application should not crash because of erroneous
or malformed data in a tag. It is particularly important your application
can recognize Unicode text frames and ignore them if the operating system
or your program cannot handle Unicode.</P>

<P>
<HR WIDTH="85%"></P>

<H2><A NAME="Credit"></A>Credits &amp; Contributors</H2>

<UL>
<LI><A HREF="mailto:[e-mail]">Dirk Mahoney</A>, creator of the <A HREF="http://www.id3.org/id3lib/">ID3Lib</A>
C++ tag processing library.</LI>

<LI><A HREF="mailto:[e-mail]">James Lin</A>, author of
these Guidelines.</LI>

<LI><A HREF="mailto:[e-mail]">Martin Nilsson</A>, author of the
ID3v2 standard.</LI>
</UL>

<H2><A NAME="Refs"></A>References</H2>

<UL>
<LI><A HREF="http://www.id3.org/">www.id3.org</A>: Home of the <A HREF="http://www.id3.org/develop.html">ID3v2
Informal Standard</A> and lots of other useful material.</LI>
</UL>

<P>
<HR WIDTH="85%"></P>

<H2><A NAME="copyright"></A>Copyright &amp; Legal Notice</H2>

<P>Copyright &copy; 1998 James Lin and Merlin's Workshop. </P>

<P>The goal of this document is to provide hints on how to implement the
ID3v2 standard(s) correctly and efficiently. Distribution of this document
is unlimited as long as no changes are made to its content: </P>

<P><B>This document and translations of it may be copied and furnished
to others, in any format or medium, provided no modifications are made
to the content unless written permission has been obtained from the author.</B>
</P>

<P><B>This document is provided &quot;AS IS&quot; without warranty of any
kind, either expressed or implied, including but not limited to, the implied
warranties of merchantability and fitness for a particular purpose.</B>
</P>

<P><B>In no event unless required by applicable law will the author of
this document be liable for damages, including any general, special, incidental
or consequential damages arising out of the use or inability to use any
information (including but not limited to loss or corruption of data or
losses sustained by third parties), even if the author has been advised
of the possibility of such damages.</B> </P>

<HR WIDTH="100%"></hr><p>Copyright &copy; 1998 Merlin's
Workshop. <I>Last updated October 22, 1998</I> </P>

</BODY>
</HTML>