📄 id3guide.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"><HTML> <HEAD> <TITLE>ID3v2.3 Programming Guidelines</TITLE> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META NAME="GENERATOR" CONTENT="Mozilla/3.04Gold (WinNT; I) [Netscape]"> <link href="id3lib.css" rel="stylesheet" type="text/css"> </HEAD><BODY><h1>ID3v2.3 Programming Guidelines</h1><center><IMG SRC="id3v2.gif" HEIGHT=50 WIDTH=52></centeR><P>Applies to: ID3v2.3<BR>Old versions: <A HREF="id3g-2.htm">ID3v2.2 Guidelines</A> (ID3v2.2 is obsoleteand should not be used for new tags.)</P><H2>Table of Contents</H2><P>1. <A HREF="#Intro">Introduction</A> <BR>1.1. <A HREF="#Usage">Use of this document</A> <BR>2. <A HREF="#id3v23new">What's new</A> in ID3v2.3? <BR>3. Programming Considerations <BR> 3.1 <A HREF="#padding">Padding</A> <BR> 3.2 <A HREF="#ROmedia">Read-only media</A> <BR> 3.3 <A HREF="#SmallFrames">"Insignificant"frames</A> <BR> 3.4 <A HREF="#iformat">Preferred image formats</A><BR> 3.5 <A HREF="#manytags">Multiple tags</A> <BR> 3.6 <A HREF="#unsync">Unsynchronization</A> <BR>4. Pitfalls & General Advice <BR> 4.1 <A HREF="#rtfm">RTFM</A> and yes, the detailsmatter! <BR> 4.2 <A HREF="#cB4e">Compression before encryption</A><BR> 4.3 <A HREF="#userErr">Validating user input</A><BR>5. <A HREF="#Credit">Credits</A> <BR>6. <A HREF="#Refs">References</A> <BR>7. <A HREF="#copyright">Copyright & Legal Notices</A> </P><P><HR></P><H2><A NAME="Intro"></A>Introduction</H2><P>There are many people who enjoy .MP3 compressed music. The MP3 specificationonly defined the storage of musical data and did not provide the storageof metadata related to the musical composition; e.g., title, composer andartist, publisher, etc. The ID3 tag standard was created to remedy thisneed... </P><P><B>Rationale:</B> Specifications are like grammar: they provide therules of formatting data but few clues as to how to speak concisely andefficiently. The goal of this document is to answer the "Should Ido..." and "Would doing X make it easier/faster/smaller..."type questions. </P><P><B>Audience:</B> This document is geared toward programmers dealingdirectly with ID3v2.3 tags. There is a heavy slant towards writing tagscorrectly since decoding is relatively straightforward. You should familiarizeyourself with the <A HREF="http://www.id3.org/develop.html">ID3v2 and relatedstandards</A> since this document refers to and uses the terminology fromthose documents.</P><P><B>Coverage:</B> Although ID3v2 tags were created for use withMPEG Layer-3 audio streams, flexibility was a goal from the start.Even though much of this document refers to .MP3 files, the principlesare generally applicable to other formats.</P><P><HR WIDTH="85%"></P><H2><A NAME="Usage"></A>Use of this document</H2><P>These are merely Guidelines and as such they are not part of the ID3v2standard. </P><OL><LI>If anything in this document contradicts the published ID3v2 standard,then the standard shall prevail. The ID3v2 standard always has the finalword.<LI>These Guidelines are not binding on anyone (whereas the standard <I>is</I>binding, for obvious reasons.) This means you, as a programmer, shouldnever assume anyone else will abide by these guidelines. A protocol designeronce said:<OL><P><I>"Be flexible in what you accept, but strict in what you write."</I></P></OL><LI>Use your judgement and common sense.</LI></OL><P><HR WIDTH="85%"></P><H2><A NAME="id3v23new"></A>What's new in ID3v2.3?</H2><P>For starters, the naming convention changed. "ID3v2" now refersto the family of frame-based tagging methods which utilize the 10-byteheader beginning with "ID3" followed by version information."ID3v2<B>.3.0</B>" refers to the informal standard dated September1998. The informal standard formerly known as "ID3v2" has beenrenamed to "ID3v2.2"</P><P>This document concentrates on ID3v2.3. The previous standard, ID3v2.2, is nowobsolete; the Guidelines for ID3v2.2 may still be found <A HREF="id3g-2.htm">here</A>.</P><P>A summary of the differences between ID3v2.3.0 and v2.2 is listed below.Section numbers match the <A HREF="http://www.lysator.liu.se/id3v2/id3v2.3.0.txt">ID3v2.3.0 Informal Standard</A>.</P><H3>Structural changes:</H3><UL><LI>The <B>Frame Header</B> has been expanded. The Frame ID and Frame Sizefields are now four bytes long. Two bytes of Flags have been added. See§3.3.</LI><LI>An optional <B>Extended Header</B> can follow the ID3v2 tag header§3.2. Among other things, the extended header can store a CRC of theentire tag.</LI></UL><H3>Clarifications:</H3><UL><LI>Pre-defined Frame IDs have been renamed to four characters long.</LI><LI>Unicode strings are now <I>required</I> to start with the Byte Order Mark (BOM)character. See §3.3.</LI><LI>Compression and encryption are done on a frame-by-frame basis. Thecompression algorithm are those offered in zlib. §3.3</LI><LI>Attached Picture [APIC] frame: the Image Format field has beenreplaced MIME Type §4.15.</LI></UL><P><B>New frames:</B> </P><UL><LI>Position Synchronization frame [POSS] §4.22</LI><LI>Terms of Use frame [USER] §4.23</LI><LI>Ownership frame [OWNE] §4.24</LI><LI>Commercial frame [COMR] §4.25</LI><LI>Private frame [PRIV] §4.28</LI><LI>Encryption Method Registration [ENCR] §4.25</LI><LI>Group ID Registration [GRID] §4.26.Used in conjunction withnew frame features described in §3.3</LI><LI>Text frames: Internet Radio Station Name [TRSN] and Internet RadioStation Owner [TRSO]</LI><LI>URL link frames: Official internet radio station homepage[WORS] and Payment [WPAY]</LI></UL><P><B>Deleted frames:</B> Encrypted meta-frame.</P><P><HR WIDTH="85%"></P><H2><A NAME="padding"></A>3.1 Padding</H2><P>The use of padding and how much should be used has been a matter ofdebate ever since the first draft of ID3v2. (Take a look in the mailinglist <A HREF="http://www.id3.org/maillist.html">archives</A> for arguments.)</P><P>Before making recommendations let's quantify the issue:</P><UL><LI>A two minute song compressed at 44Khz and 128Kb/sec takes about 1990K (slightlyless than 2MB) of disk space. The average size of .MP3 files in mycollection is 3.5MB</LI><LI>ID3v1 and Lyrics3 tags are only 128 bytes and 3K, respectively - andthey served most songs just fine.</LI><LI>An ID3v2 tag with basic information (title, artist/composer, copyright) istypically less than 1K in size. Toss in publisher information and lyricsand it comes out to 3K or so.</LI><LI>Adding a 3K tag to a 2MB song will increase its size by 0.15%</LI><LI>Adding a 10K tag to a 2MB song increases its size by 0.5%</LI><LI>Suppose a CD-ROM holds 160 songs. Tagging all of them with 3Ktags requires less than a megabyte.</LI></UL><P>So in reality tags are tiny compared to the amount of audio data accompanyingit. A few KB of padding will not increase the file size noticeably. Rememberalso the padding is required to be 0's, which means on a slow modem linkthe padding is compressed significantly.</P><P>There is but one reason to use padding: since ID3v2 tags are storedat the beginning of the file, it would be a major pain to rewrite the entiremulti-megabyte file to add a 50-byte frame. Padding reserves space in advance.</P><P>The issue then is how much padding should be used. </P><P><B>James's</B> recommendations:</P><UL><LI>What do most people care about? Probably title, artist, composer,band, publisher, lyrics and copyright. 4K will usually be enough for allthat plus some miscellaneous information such as media type, file size,playcounter, time codes, etc.</LI><LI>If you are editing an existing tag and run out of room (meaning youmust rewrite the entire file) then double the amount of space reservedfor the tag. For example, a file has a 4K tag filled with 3K of data. Userwants to add 2K of data, so you rewrite the file reserving 8K at the beginning;then save the 5K of data and leaving 3K of padding. </LI><P>Obviously there should be an upper bound on doubling; a reasonable numberwould be 16K or 32K. For example, a file has a 25K tag but only 4K of paddingleft and the user wants to add 7K of new data. Rewrite the file and reserve41K: save 28K of tag data and leave 13K of padding.</P><LI>Pictures are large and vary in size. If there are pictures then youshould add more padding; use your judgement here.</LI><LI>Do not forgo padding in files destined for read-only media or streamingapplications. The user may want to save the file to another location andedit the tag.</LI><LI>Include an option to let the user disable padding if (s)he <I>really</I>wants to.</LI></UL><P><B>Martin</B> has a good idea: Add enough padding to round out the fileto a full cluster. Obviously a minimum amount of padding has to be addedto be useful, but beyond the minimum, everything up to the next clustersize will not occupy additional disk space. (Each operating system hasits own terminology; Microsoft uses <I>cluster,</I> Apple uses <I>allocationblock</I>. How files are stored on disk is beyond the scope of this document;consult an OS book and API reference for details.)</P><P>Here are some common cluster sizes:</P><TABLE BORDER=1 ><TR><TH ROWSPAN="2" NOWRAP>Operating system<BR>(file system type)</TH><TH ALIGN=CENTER COLSPAN="7" NOWRAP>Disk size </TH></TR><TR><TD>< 256MB</TD><TD>up to 512MB</TD><TD>up to 1GB</TD><TD>up to 2GB</TD><TD>up to 8GB</TD><TD>up to 16GB</TD><TD>> 16GB</TD></TR><TR><TD>DOS & Windows 95<BR>(FAT16)</TD><TD ALIGN=CENTER>4K</TD><TD ALIGN=CENTER>8K</TD><TD ALIGN=CENTER>16K</TD><TD ALIGN=CENTER>32K</TD><TD ALIGN=CENTER COLSPAN="3">N/A<BR>(FAT16 can't handle drives > 4GB)</TD></TR><TR><TD>Win95 OSR2 & Win98<BR>(FAT32)</TD><TD ALIGN=CENTER>N/A</TD><TD ALIGN=CENTER COLSPAN="4">4K</TD><TD ALIGN=CENTER>8K</TD><TD ALIGN=CENTER>16K or 32K</TD></TR><TR><TD>Windows NT<BR>(NTFS)</TD><TD ALIGN=CENTER COLSPAN="7">0.5K to 64K<BR>(0.5K to 4K clusters are most common)</TD></TR><TR><TD>MacOS pre-8.1<BR>(HFS)</TD><TD ALIGN=CENTER>0.5K - 4K</TD>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -