ABSTRACT

MP3 is the predominant digital music format and ID3 is its embedded metadata scheme. Media player applications often use ID3 rather than file name to principally identify a file, and little directions or guidelines have been imposed on ID3 as it has grown through five versions since 1996. Successive releases have grown tremendously in supported size, and threaten to burden the user with unneeded layers of file management for MP3s.

This paper examines each release of ID3, its relationship to MP3, and potential applications of it beyond simple static data. Strengths and weaknesses of each implementation are identified, and ID3’s technical specifications are summarized. In addition, a simple ID3v1 tag editor is introduced along with a brief critique of the C# programming language.

KEY WORDS

ID3, ID3v1, ID3v2, MP3, MPEG, MPEG-1, MPEG-2, Layer III, metadata, tag, audio, codec, music, sound, song, library, DRM, C#, .NET, PureMP3.

Bahnck 1

ACKNOWLEDGEMENTS

I would like to thank Dr. Tom Way for serving as my advisor on this project, and Villanova University for affording me the opportunity to serve as a tuition scholar for the last two years.

Bahnck 2

MP3 DATA: SEPARATING THE ESSENTIAL FROM THE EXCESSIVE

Tom Bahnck

M.S. Computer ScienceDepartment of Computer Science

Villanova UniversityVillanova, PA 19085

USA

TABLE OF CONTENTS

1. Introduction 32. MP3 & ID3 43. MP3 Encoding 44. ID3 Tags 65. ID3.org 86. ID3 Version 1 87. ID3 Version 2 98. ID3v2 and DRM 109. Trends and Recommendations 1110. Microsoft's C# Language: A Brief Critique 11References & Bibliography 14Appendix A: PureMP3: An Original ID3v1 Tag Editor For the .NET Platform 15Appendix B: ID3v1 Genres 25Appendix C: ID3v2 Common Standard Frames 26Appendix D: PureMP3 Source Code 27

1. INTRODUCTION

MP3 and ID3 have been a prevalent digital music platform since their popularization in the late 1990s. Developed as a means to reduce digital audio files to tolerable sizes, MP3 stemmed from the limited storage space commonly available in the 1980s and 1990s. The codec was developed by Fraunhofer IIS and Thompson Multimedia, and employs a two-pass algorithm which eliminates useless and redundant audio information. As a complement to MP3, ID3 was invented in 1996 in order to store metadata about songs. Consecutive releases of ID3, up to version 2.4 today, continue to add additional layers of management to MP3 files, and may be neither necessary nor desirable to common users.

ID3 version 1 contains seven metadata fields, including artist, title, and album information, and occupies a fixed 128 bytes. Each field’s maximum length is 30 characters, and no future fields can be developed. As a response, version 2 was created, introducing variable length fields and extensibility. Version 2 tags could

occupy up to 256 megabytes total, with 16 megabytes of data per field maximum.

ID3v2 was explored as a platform for digital rights management, but quickly abandoned as a result of its openness and limited earning potential. Proprietary encoding formats such as WMA (Windows Media Audio) and AAC (Advanced Audio Coding) provide stronger security to content distributors, and promise greater royalty payments to their developers. Until a proprietary format surpasses MP3 in quality and ubiquity in the future, MP3 will continue to flourish and require ID3 management.

PureMP3 (see Appendix A), an original ID3 editor, simplifies ID3v1 management. Written in C# for the .NET platform, PureMP3 provides the user the option to edit or wipe ID3v1 tags from MP3 files. It features an intuitive, Windows XP-style interface, and employs a robust validation scheme for ID3v1’s fixed-length data fields.

Bahnck 3

While C# closely resembles Java, and .NET the JVM (Java Virtual Machine), Microsoft’s new language adds select C-style syntax and functionality to the object-oriented paradigm. .NET programming is closely, but not exclusively, tied to Visual Studio and Microsoft platforms.

Although PureMP3 offers some simplification for ID3 management, future ID3 releases are expected. These releases will inevitably add even more layers of management to MP3 files. The common user’s best strategy for minimizing such additional work is to disallow ID3 tagging when encoding, and disable ID3 recognition on playback.

2. MP3 & ID3

Since the widespread adoption of MP3 as the de-facto digital music standard, ID3 has been covertly adopted along with it as a means to identify and classify musical content. In its evolution through 5 versions from 1997 to 2005, ID3 grew from 6 fields of fixed-length data to over 74 fields spanning a maximum of 256 megabytes. As MP3 was developed from the need to shrink audio data files to tolerable storage requirements, ID3 grew from a negligible suffix on MP3 to a cumbersome identification scheme best suited for disc jockeys and digital music retailers.

ID3 tags have enjoyed growing recognition throughout media applications, portable music players, and sound editors. Consisting of metadata, including fields for genre, recording year, and track number, the tags identify and classify sound files at a granular level. However, many ID3 fields contain subjective information, such as genre, mood, and comments, and often change according to user. As these tags have become an identification requirement to be managed along with the filename, they introduce five additional layers of management, many of which are of trivial value to the common user. Each version of ID3, which is continually supported as ID3 versions advance, introduces a new layer, and sections 6 and 7 discuss these layers in detail.

Pre-dating the need for ID3 is the need to logically name data files for basic identification on a storage medium, such as a hard drive or flash memory. Assuming most users are rational, that is, they will use the artist name and song title, or combination of either to name their music data files, MP3s are discernable without ID3 tags. Therefore, to justify the mandatory coupling of MP3 data with ID3 tags, there must be a clear benefit to the added layers of management it introduces.

Initially, ID3 was a simple supplement to the end of MP3 data files, carrying only the most obvious metadata for music. Figure 1 displays ID3 version 1 tags, as shown in Apple’s iTunes, a popular home computer media player. However, in an effort to support variable-length fields, facilitate streaming MP3, and mimic the structure of MP3 frames themselves, ID3 bloated to a sizable segment at the beginning of MP3 files. Portions of ID3 tags in version 2 can even dictate or manipulate playback, and in order to fully understand how these technologies complement each other, one needs to have a basic understanding of the MP3 codec.

Figure 1: iTunes display of ID3v1 tags

3. MP3 ENCODING

MP3, a nickname for the full audio encoding standard MPEG-1/MPEG-2 Layer III, is standardized under ISO 11172-3. ISO 11172-3 specifies guidelines for coding moving pictures and associated audio at data rates up to approximately 1.5 Mbps, and thereby encompasses MPEG-1, MPEG-2, and MPEG-4 video, as well as other lossy audio encoding techniques. Surprising, a lack of technical information is published specifically for MP3 as opposed to the other flavors of MPEG (Moving Picture Experts Group), and the full ISO specification is too cumbersome for a personal enthusiast to make use of. For the developer, the ISO standard lacks best-practice implementation techniques which would be useful in building new media applications.

The majority of information published was created in or about 2000, approximately three years after Winamp penetrated the mainstream and popularized MP3. Most content concentrates on reviewing media player applications, bit rate encoding strategies, and digital

Bahnck 4

music library management. Scot Hacker’s MP3: The Definitive Guide [7], dedicates only about 40 pages to the technical inter-workings of the MP3 codec, yet approximately 320 pages to playback, management, and downloading MP3 files. This amounts to approximately an 8:1 ratio of playback information to codec information.

Bahnck 5

The Codec

ISO oversaw the MPEG standards creation process, mandating implementation rules so that all MP3 vendors could compete on a level playing field. However, private companies developed MP3 technology and continue to reap profits from it today. The primary developer and patent holder of MP3 is The Fraunhofer Institute for Integrated Circuits (Fraunhofer IIS), of Erlangen, Germany. Thompson Multimedia (San Diego, California) owns a subset of those patents, and together with Fraunhofer imposes a royalty fee schedule on those who implement MP3 technology.

While decoding MP3 is not covered in the patent, all distributors who encode MP3 are required to pay licensing fees. Figure 2 contains the MP3 royalty fee schedule as of 2000.

Figure 2: Fraunhofer/Thompson licensing fees for MP3

1. Flat yearly fee of $15,000.2. Unit fee per encoder [7]:

Number of encoders shipped

Fee per encoder

1 – 1,000 $25/unit1,001 – 2,000 $20/unit2,001 – 3,000 $15/unit3,001 – 10,000 $10/unit10,001 – 100,000 $5/unitMore than 100,000 $2.5/unit

3. If the user is required to pay for an encoded song or track, $.01 per track must be paid to Fraunhofer.

The MP3 data structure is segmented into frames, each beginning with a header containing metadata about the frame. A data frame follows, containing the actual audio data, in a setup mirroring that of standard Ethernet packets.

The MP3 codec is known as a perceptual codec. It compares stored audio data to known human psychoacoustic data models, and eliminates sounds that humans cannot and will not perceive.

The encoding process takes two passes on raw audio data. First, the encoder discards any sounds with frequencies above 20 kHz, which is beyond the range of human hearing. Then the encoder eliminates data it determines is irrelevant, according to a psychoacoustic model, from the original sound file. This data can never be reconstructed, and as a result this is known as lossy compression. The second pass follows an algorithm known as Huffman coding, which reduces size based on spatial redundancy. In contrast to the first encoding pass, the second pass ensures a flawless reproduction of the

original data upon decompression, and is therefore known as lossless compression.

Variable Bit Rates (VBR) vs. Constant Bit Rates (CBR)

The MP3 bit rate refers to the number of bits stored per second of audio data. The overall bit rate is not as relevant to sound reproduction as the number of bits allocated to each frame, which the encoder determines when the original audio data is processed. MP3 uses one of two encoding techniques, the first sampling at a constant rate throughout the entire data file, and the second at a variable rate calculated uniquely for each frame.

A constant bit rate (CBR) ensures a predictable final file size, but does not always represent audio data sufficiently to reproduce a rich sound in every frame. For instance, songs with very high frequencies or complex tones at certain points can produce complex sine waves, better represented with a higher data rate than the rest of the song. For these instances, a variable bit rate (VBR) is best.

In comparison, some points in a song may have low or very simple frequencies, and may sufficiently be represented with a low bit rate. However, with a CBR higher than necessary for those frames, an excess amount of bits per second will be used to encode the low frequencies, and produce an unnecessarily large file size.

VBR encoding relies on a threshold measure rather than an explicit bit rate to determine sound quality. Generally the threshold scale is arbitrary from program to program, but usually follows a range from 1 – 9 or 1 – 100. The threshold represents a distortion ratio, and the CPU determines the optimal bit rate per frame based on the amount of distortion the user deems tolerable. While VBR sounds like a better option than CBR, it can introduce compatibility problems on older players, and may cause timing difficulties for some decoding applications.

Sample Rates vs. Bit Rates

Bit rates indicate the amount of data stored to represent a sound for every second of audio. Sample rates, however, measure the frequency (in kHz) with which the audio signal is stored. Stored audio frequencies cannot be higher than half the sample rate. The human range of hearing is approximately 20 – 20,000 Hz, and therefore CD audio sampling is done at 44.1 kHz, or double the human hearing range.

Bahnck 6

Decoding

Like the Society of Motion Picture and Television Editors standardize frame rate for video playback at 24 frames per second (fps), MP3 standardizes playback at 38 fps. Each frame contains 26 ms of audio data, and the higher the bit rate of the MP3 file, the larger each frame’s size. Figure 3 displays a formula for the total size in bytes of any MP3 frame as a function of bit rate and sample rate.

Figure 3: MP3 frame size as a function of bit rate and sample rate [7]

FrameSize =144 * BitRate / (SampleRate + Padding)

MP3 Byte Structure

MP3 files contain millions of contiguous frames, alternating header and audio frames. Figure 4 shows the layout for MP3 header frames.

Figure 4: MP3 header frame layout [7]

Offset PurposeLength (in bits)

0 – 10 Frame sync 1111 – 12 MPEG audio version (MPEG-

1, 2, etc.)2

13 – 14 MPEG layer (Layer I, II, III, etc.)

2

15 Protection (if off, then checksum follows header)

1

16 – 19 Bitrate index (lookup table used to specify bit rate for this MPEG version and layer

4

20 – 21 Sampling rate frequency (44.1kHz, etc., determined by lookup table)

2

22 Padding bit (on or off, compensates for unfulfilled frames)

1

23 Private bit (on or off, allows for application-specific triggers)

1

24 – 25 Channel mode (stereo, joint stereo, dual channel, single channel)

2

26 – 27 Mode extension (used only with joint stereo, to conjoin channel data)

2

28 Copyright (on or off) 129 Original (off if copy of original,

on if original)1

30 - 31 Emphasis (respects emphasis bit in the original recording; now largely obsolete)

2

32 total header bits

Header frames begin with an 11 bit sync block, and continue with 21 bits of metadata for the following data frame. A weak copyright protection scheme is employed, where a single bit at offset 28 signifies whether copying the audio is illegal or not. ID3 version 1 tags are tacked at the end of the bit stream, and ID3 version 2 tags are generally stored at the beginning of the bit stream.

Bahnck 7

4. ID3 TAGS

ID3 tags often complement playlists and music libraries. Most media player applications display ID3 data, rather than file name, while a song is being played. Media applications that use a music library as an interface, such as Musicmatch Jukebox and Apple iTunes, use ID3 tags to categorize songs.

ID3v1 & ID3v2 Introduction

ID3 version 1 (ID3v1) consists of the last 128 bytes of an MP3 file. Seven possible fields – artist, album, title, year, comments, track number, and genre – have fixed character limits. The largest fields, at 30 characters, are artist, album, and title.

ID3 version 2 (ID3v2) is a completely different implementation of embedded metadata. Version 2 tags are usually stored at the beginning of an MP3 file, in order to deliver the metadata first over streaming media. However, no specification requirement or structural constraint in the file demands them to be stored in the beginning. They can be stored at the end of the file, or interspersed throughout MP3 header and audio data frames.

Version 2 tags are not limited to ASCII-text based information. Their dramatically raised size limitation, 16 megabytes, allows binary data to store bitmaps, pages of lyrics, or even synchronized lyrics. Bitmap data is generally used for an album cover or artist image, and synchronized lyrics can be used to facilitate karaoke. Version 2 tags are extensible, in that any developer can implement a new tag to store his own custom fields. For example, new space can be declared to store a digital signature, image, or other embedded file.

The concept of using ID3 tags to store digital signatures is not new. In fact, the idea of using ID3 for digital rights management (DRM) was introduced before Sony, Apple, and Microsoft released proprietary encodings. Section 8 explores this concept further. The total size of all ID3v2 frames is capped at 256 megabytes with 74 frames standardized.

Some applications recognize the growing problem of disparate file names and ID3 tags. In an effort to simplify the additional layers of management that ID3 imposes, Musicmatch Jukebox 10, MACAST for Mac, and id3ren for Linux offer batch renaming of files based on their tags, and vice versa. These applications prove that the cumbersome aspect of ID3 tag management is not unrecognized in the industry, and seek to remedy it.

Bahnck 8

Windows XP & Mac OS X: Native OS Recognition

Windows XP recognizes ID3 in its operating system shell. When a properties dialog is opened on an MP3 file, Windows allows the user to edit ID3 fields. The equivalent operation in Mac OS X simply displays ID3 fields along other music-related options. Figures 5 and 6 show both Windows XP and Mac OS X’s native recognition of ID3 tags.

Figure 5: Native Windows XP ID3 recognition

In Windows XP, editing an ID3 tag is as simple as clicking in the Value property column, shown in Figure 5. The user enters a new value, in the same manner as renaming a file in Explorer or on the Desktop. The user however, cannot differentiate between ID3 versions, nor does the OS indicate which it is displaying. Through experimentation with PureMP3, described in Appendices A and D, I discovered that the OS recognizes and sets both versions of ID3 in the file properties dialog.

The fields that the OS displays are standard in both v1 and v2, and it therefore assumes that the values should be the same in each version. If a value exceeds the character length for v1, Windows truncates it to the maximum size. When the user edits a field and applies

his changes, Windows sets both versions of ID3 to match his entry. Additionally, Windows allows batch operations, where the user can select multiple MP3 files, open a properties dialog, and then set field values for all at once.

Figure 6: Native Mac OS X ID3 Recognition

Mac OS X does not display ID3 tags to the user, nor does it provide the opportunity to edit them. However, it integrates an MP3 decoder, so the user can playback the MP3 file from the OS shell without launching a third party application.

Musicmatch & iTunes

Bahnck 9

Several MP3 applications for personal computers have exploded and dissipated over the last decade, most notably Winamp. Winamp released its final version this year (2005), and is credited with popularizing MP3. Recently, vendors have been trying to transform mainstream media players to serve a business model, focused on downloading songs online. Two of the most popular programs are Musicmatch Jukebox for PC and iTunes for Apple Macintosh [6].

Problem: Redundant and Conflicting Data

Sections 6 and 7 will introduce disparity in ID3v1 and v2 tagging schemes, where ID3v1 is subdivided into v1 and v1.1 recognition, and version 2 is tailored to v2.2, 2.3, and 2.4 specifications. The common end-user cannot and should not be responsible for knowing the differences between these versions, yet he is left the responsibility to manage them in order for his media player applications to display accurate information. iTunes introduces a conversion operation to port tags from one version to another, and Musicmatch introduces the concept of Super Tagging, which automatically downloads tags, or batch-converts them.

Figure 7 displays Musicmatch’s interface for editing ID3 tags. It does not show the end user which version it supports, nor give the user the option to specify the version. In the lower-left area of the window there are three buttons for Super Tagging: Tag From Filename, Lookup Tags, and Rename Files. These are Musicmatch’s answers for synchronizing ID3 schemes.

Tag From Filename allows the user to specify a pattern to which his filenames conform, and instructs Musicmatch to set ID3 tags in appropriate fields based on that pattern. Lookup Tags allows the user to download appropriate tags based on the song, and automatically populates them from Musicmatch’s database. Rename Files is the reverse of Tag From Filename, allowing the user to rename their files to a pattern, using each file’s ID3 information.

Figure 7: Musicmatch Jukebox ID3 dialog

Bahnck 10

Figure 8: iTunes Convert ID3 Tags Dialog

iTunes’ ability to port ID3 information from one version to another supports all versions from 1.0 to 2.4. These specifications can contain very different field value constraints, such as is the case from version 1.1 to version 2.2, and iTunes does not disclose how it adjusts offending values to fit the destination version.

5. ID3.ORG

All information resources on ID3 point to ID3.org [15], managed by Martin Nilsson and launched in 1998. ID3.org contains a sizable amount of information on ID3 version 1 and 2 tags; however, it does not claim to be the official managing body of ID3 technology, and no other ID3 resource claims otherwise. ID3.org publishes unofficial standards, resembling RFCs, for ID3 version 2 tags. No unofficial standard has ever been promoted to official.

6. ID3 VERSION 1

The original version of ID3, version 1.0, was created by Eric Kemp in 1996 and is still the most widely recognized. All current MP3 players now set and edit version 2 tags by default, but they are still backward-compatible with ID3 version 1.0. This persistent backward compatibility is responsible for the cycle of an additional layer of file management per ID3 release. Without backward compatibility, there would be only one persistent layer of additional management, which would be the current ID3 version.

In 1997, Michael Mutschler devised a way to steal a byte from the ID3 version 1.0 specification to represent a track number [15]. Figure 9 displays the byte structure of ID3 version 1 and 1.1 tags.

Bahnck 11

Figure 9: Byte Structure of ID3v1 Tags [10]Field Offset Length Data Type“TAG” 0 – 2 3 StringSong Title 3 – 32 30 StringArtist 33 – 62 30 StringAlbum 63 – 92 30 StringYear 93 – 96 4 StringComments 97 – 126 (v1.0)

97 – 124 (v1.1)3028

String

Track 126 (v1.1) 1 ByteGenre 127 1 Byte

128 Bytes Total

The perceived shortcomings of ID3v1 explain why the 126th byte was ideal for transforming to track number. The 1.0 specification states that the comments field should be 30 characters. However, Mutschler asserted that 30 characters was not enough space for a comments field to store anything useful, and therefore, was a prime candidate to split into two fields. Regardless of the actual length of data in a field in ID3v1, it must fill the unoccupied space in the fixed-length field with “0” bytes. As a result, Mutschler inferred that any application reading version 1 tags should stop reading the field after it encounters a zero byte. This turns zero bytes into terminating characters, and the rest of the space in the fixed-length field could be claimed as free space. One byte could represent an integer up to 255, easily covering most valid track numbers, so Mutschler claimed one at the end of the comments field.

However, his reasoning is flawed. In order to maximize performance, I believe applications would more likely grab a block of bytes known to be the size of the fixed-length field, and pass them directly to the program for usage. If they used his strategy, applications would process one byte at a time, check whether its value is 0, and if not, grab another byte. If so, it would halt and skip the remainder of bytes which the current field could hold. Grabbing blocks is more efficient, sure to adhere to accepted ID3 standards, and easier to implement. However, many programs recognizing ID3 adopted Mutschler’s change, and it warranted a new version number, 1.1.

Technical Specifics

The version 1 specification says that values stored as strings should be encoded with ISO 8859-1, the Latin-1 character set widely recognized in Windows system fonts and HTML. However, many developers use the host system’s default encoding in order to support non-Western European languages. As a result, decoding discrepancies can surface when MP3 files are passed internationally from machine to machine.

The first field in Figure 9 consists of a string of 3 characters, “TAG.” It identifies the existence of and beginning of an ID3v1.x tag. Programs will not interpret the last 128 bytes of an MP3 file as an ID3 tag without the “TAG” identifier, but luckily the existence of an improperly identified 128 bytes at the end of the file will not affect playback. Unless the bytes conform to the standard MP3 audio header and data frame format, the program will not interpret them as audio data.

When initially under development, version 1 tags were to be stored at the beginning of an MP3 file. Early MP3 players exhibited unpredictable behavior though, when non-sound related bytes were placed at the beginning of the MPEG stream. They halted playback, emitted a surge of noise, or failed to recognize the file entirely.

The genre field, the last field in ID3v1, is displayed to the user as a variable-length string to the effect of “Jazz,” “Hip-Hop,” or “Rock and Roll.” However, genre is stored as only a single byte because the version 1 specification explicitly maps index numbers to pre-defined genre strings. All developers recognizing ID3v1 must hard-code this correlation in their programs, and the situation has produced some diverging genre set support. While the only official standard genre indices are 0 – 79, Winamp in its flourishing popularity in the late 1990s took upon itself the freedom to extend the genre set to 149, adding 70 proprietary classifications. To this day, player support for both genre sets are mixed; most robust media applications recognize Winamp proprietary tags, while other programs recognize only the original standard set.

Advantages and Limitations

The advantages of ID3 version 1 are clearly its minimal storage requirements, and simplicity from a developer’s standpoint. Additionally, unlike v2 tags, v1 tags can be added to the end of any MP3 file with ease, i.e. without needing to rewrite or displace any other part of the MP3 file. However, music enthusiasts complain that it cannot accurately represent many song titles, album names, or artist names under a space constraint of 30 characters, and they wished to be able to store many more fields. For the average user, version 1 tags seem adequate if not already excessive given the user’s file naming convention. However, the effort for drastically different version 2 tags was already under way.

7. ID3 VERSION 2

Bahnck 12

The most common reason I found for moving ID3 tags to the beginning of the file in version 2, was timely delivery of metadata in streaming situations. Theoretically, in the instance of an internet radio station for example, the station would want to deliver song identification information to the listener’s client application at the beginning of a song’s playback. This is understandable, even though often over traditional radio, disc jockeys routinely do not identify the songs they play until after the songs have ended. However, since the Internet is an entirely different delivery medium, with the potential for on-demand sales, advantages in identifying the song immediately are clear.

Technical Overview

As shown in Figure 10, version 2 tags begin with the string identifier “ID3” as opposed to “TAG”. The next 3 fields are the only fixed-length fields in ID3v2.

Figure 10: Byte Structure of ID3v2 Tags [12]Field Offset Length Data Type“ID3” 0 – 2 3 StringSubversion 3 1 BytePadding (optional) 4 – 5 2 ByteTotal Size 6 – 9 4 ByteFRAME 1 (F1) Variable Variable StringF1 Length Variable Variable ByteF1 Padding Variable Variable ByteF1 Data Variable Variable ByteFRAME 2 (F2) Variable Variable StringF2 Length Variable Variable ByteF2 Padding Variable Variable ByteF2 Data Variable Variable ByteF3 – Fn…

16 Megabytes Maximum Size of Each Frame256 Megabytes Maximum Total Size

Audio Data Follows

The ID3 prefix is immediately followed by a subversion number (2, 3, or 4 corresponding to version 2.2, 2.3, or 2.4), identifying the revision of ID3v2 implemented. The padding in the third field is optional, and the final fixed-length field is four bytes, storing the total ID3v2 tag size.

Following these introductory fields are all ID3v2 frames, each consisting of a frame code, length, padding, and data. The variable-length frames define their own contents, allowing extensions for any number of conceivable category types, such as images or links, or even volume, balance, and equalizer settings. Frames are accessed through either standard 3 – 4 character identification codes, or proprietary codes determined by the developer. Appendix C contains a list of commonly stored frame names and their codes.

A few standard codes are “TTL” for title, “TYE” for year, and “COM” for comments. The chief differences between ID3 versions 2.2, 2.3, and 2.4 are the names of the standardized codes, and the addition of more codes. The lyrics frame has its own technical specification, Lyrics3, and more information on lyrics can be found at http://www.id3.org/lyrics3.html [15].

The v2 specification states that strings should be stored in Unicode, so they can be extracted in any language without obfuscation. Additionally, ID3v2 employs an unsynchronization scheme, to ensure tags don’t mirror the header and data frame structure of raw MP3 data, which prevents ID3v2-incompliant programs from playing back tag information as audio.

Advantages and Limitations

Version 2 has clear advantages over version 1, assuming ID3 tags are indispensable to the user. Every song name, artist, and album can be transcribed without being abbreviated. An author can store up to 16 megabytes of his own comments in a file. Encoding, decoding, and playback-specific settings can be embedded into MP3s to ensure the exact same sound is reproduced every time.

The limitation in version 2 is best demonstrated in file sharing, where an original encoder does not hold any autonomy over a file. The originator’s personal comments and equalizer settings are subjective and may not apply to the receiver, and his transcription of lyrics, or even song title, artist, and album information may be inaccurate. Nonetheless his metadata propagates, adding additional overhead in download time, and the task of correcting or removing his information at each recipient.

Of course, MP3s have been shared both legally and illegally since their inception, facilitated most directly by their small file sizes. Rather than embrace MP3 holistically as a legitimate content distribution mechanism, many vendors have sought proprietary encryption schemes for their songs through companies such as Microsoft with WMA (Windows Media Audio), and Apple with AAC (Advanced Audio Coding). Why could not ID3, with its extensibility to store any metadata pertaining to a file, store a digital rights key for content distributors?

8. ID3v2 AND DRM

Clearly there are billions of dollars in revenue to be made from the right content encryption scheme, potentially curing the headaches that the RIAA and

Bahnck 13

MPAA have suffered since the advent of widespread file-sharing. Microsoft and Apple most notably have released proprietary encryption schemes for content distribution, but WMA and AAC have largely not been adopted as mainstream and trouble-free encodings. With the popularity that MP3 already enjoys, and built-in capabilities of ID3 to store up to 256 megabytes of binary data for any purpose, why haven’t developers embraced ID3 for a digital rights solution?

Fair-Play DRM: Why Not ID3?

The succinct answer is, less money stands to be made from developing digital rights into an open standard, and it is MP3 and ID3’s openness exactly that eliminates the effectiveness of any digital rights solution that can be introduced.

The majority of income that is made off digital media formats comes from royalty payments. Figure 2 showed the royalty schedule for Fraunhofer and Thompson, and represents the complete pool of money that the companies can make from their MP3 invention. The schedule was enforced only after Fraunhofer realized the popularity and full potential of its technology. While ISO standardization did not eliminate the requirement for client applications to honor the Fraunhofer copyright, it did publish the architecture of the encoding for any developer to study. Developers were then empowered to write personal MP3 encoders without paying royalties, and indeed they did, and release their applications in the file-sharing underground.

With the architecture of MP3 known, developers could undermine the already weak copyright mechanism built into MP3: The copyright bit at the 28th offset in each header frame. Simply running the file through an application written to parse MP3 headers and flip the copyright bit would be sufficient. How would ID3 be any different with its specification open as well?

In order for any DRM key embedded in an ID3 tag to be successful, all client applications would need to recognize ID3-based DRM and honor it. With the widespread distribution of MP3 players already in the world, this notion would also require a next-generation player capable of DRM, without backward-compatibility to unsigned MP3 files. Under these requirements, the application would automatically enforce security restrictions on DRM-tagged files, and disallow playback on untagged files. This would be the only way to give full assurance to content distributors that their property would be, indeed, wholly shielded from improper access methods.

Additionally, content distributors would need full assurance that their encryption could not be cracked or

removed. In the same manner in which a simple application can undermine MP3 header copyright flags, it could easily remove or blank a DRM ID3 tag. It would entail simply hashing the file for the correct ID3 frame, and removing or wiping it.

Since Fraunhofer and Thompson already stand as the sole beneficiaries to MP3, little or no royalty money stands to be made from a third party working a DRM scheme into the audio encoding. Simple circumvention techniques exist to crack potential ID3-based DRM, so the application fails as a real benefit of ID3 tagging. In the future, I believe we stand to see stronger, embedded, proprietary audio encryption schemes tailored to larger profit margins, from the likes of Microsoft and Apple.

Bahnck 14

9. TRENDS AND RECOMMENDATIONS

ID3 shows no signs of waning. Most of my research for this project has come from technical specifications and music enthusiast websites, and the enthusiasts embrace ID3. However, the majority of these sources seemed not to be common collectors of digital media; rather, they tend to be amateur disc jockeys and composers.

Software has always demonstrated a trend of including more and more high-end features in programs for the power user, and masking them for the modest user. For example, Microsoft Office has the ability to extend its API to custom Visual Basic libraries, which a personal developer can author. With this technology, Visual Basic for Applications (VBA) users can customize their copies of Office and unlock many capabilities which the average user does not, and likely does not need, to know. And in consecutive releases since Office 97, Microsoft has upgraded VBA to take advantage of even more advanced technologies, such as OLE, ODBC, and .NET.

In order to continue making money off of their applications, media application vendors must add features instead of strip them away, and in that spirit I believe we can expect ID3 standard frame sets to grow, compiled into future releases, with backward compatibility. In that sense, the five layers of management already in existence from versions 1.0, 1.1, 2.2, 2.3, and 2.4, will expand to encompass even future versions.

As stated earlier, in order to warrant the layers of management’s existence, they must provide a clear service to the end user. The reason for the wild popularity of MP3, is that it is simple to use, and end user is everyone. Therefore applications cannot subdivide between the power user and the casual user, as Windows may with Professional and Home editions, and Office with Basic and Professional editions. MP3 has relevance to everyone enjoying music; unfortunately, the 256 potential megabytes of ID3 overhead with it may not.

My recommendation for the reader seeking to minimize his MP3 identification duties, is to ignore ID3 tags. Set rippers not to automatically write them, and media player applications not to display them where possible. However, since this view seems to be in the minority given my research, I have written an original program for wiping and editing ID3 tags in files. Coupling this with an interest to learn the C# programming language, I authored the .NET application PureMP3.

10. MICROSOFT’S C# LANGUAGE

A Brief Critique

Appendix A describes the interface of PureMP3. However, as a developer well versed in object-oriented Java and C++ programming, I am compelled to include a critique of C# .NET with this project, stating my observations from PureMP3’s .NET implementation.

The .NET CLR

The driving factor behind .NET was to expedite Windows programming. Under .NET, developers should be able to create forms (GUIs) faster, access the common Windows framework more quickly and reliably, and better integrate web services. The result should be a streamlined, more stable successor to the Win32 API, and shorter application development schedules.

“.NET” itself, which has been a confusing label ever since its launch, refers to a common runtime not unlike the JVM (Java Virtual Machine), only specific to Windows. The .NET CLR (Common Language Runtime) consists of executables, assemblies, and a Common Type System (CTS) set of conventions. Modules in .NET, analogous to .class binaries in Java, are named .netmodule. It is worth noting that assembly, in .NET, takes on a different meaning from the traditional definition of assembly as platform dependent code, one step away from machine language. Assemblies, in .NET, refer to intermediate language code libraries and a metadata file that describes and links them.

.NET can be accessed by any programming language adhering to Microsoft’s Common Language Specification (CLS). By working .NET’s syntax into C++, Visual Basic, and even Python and Perl, Microsoft was able to release .NET implementations of the most common languages, alleviating the headache of migrating code for many developers, and continuing the write-once-run-everywhere philosophy.

At compilation, code is translated from any .NET compliant language into intermediary language (IL), and finally to a portable executable (PE) [9]. Portable executable files can call upon .netmodules and instantiate them, not unlike Java classes, or calling Win32 .DLL libraries. Metadata is very important at compile time, specifying outside resources, assembly directives, and entry points. Some of these resources can be specified in what is called response files, which are text files containing compiler flags so that the developer does not have to list them on the command line. Other resources are linked through assembly XML files, which classes can reference or the compiler can reference when needed.

Microsoft developed the C# language specifically for the .NET platform. Applications written in C# cannot

Bahnck 15

compile down to native machine code, as C++ and Visual Basic applications can. C# syntax mimics Java, with hints of legacy C support. Like C/C++, C# supports preprocessor directives, such as #define, #if, #else, #elif, etcetera. Syntactically, C# differs in that most of its predefined member functions and fields begin with a capital letter, where in Java they are generally lower case. Additionally, while Java only allows source files to declare themselves a part of one package, C# allows multiple namespaces (its equivalent to package) to exist in a single source file.

C# supports pointers, as well as references, and adds an interesting method for declaring get and set functions for member attributes. Figure 11 demonstrates the new get and set implementation method for a sample member.

Figure 11: Sample get and set accessors in C#// Declare string field FirstName in any// class

public string FirstName { get { return fn; } set { fn = val; }}

// 'set' accessor invoked// "Tom" stored in fnmyObj.FirstName = "Tom";

// 'get' accessor invoked// Value in fn sent to stdoutConsole.Write(myObj.FirstName);

So long as any new language adheres to the MSIL (Microsoft Intermediate Language) instruction set specification, included with the .NET SDK, it can support the .NET CLR. Compilers already exist for other platforms, including Linux, Mac OS X, Solaris, and even PlayStation 2 and Xbox. These compilers are managed by open source advocacy groups [3], who tend to port them to other platforms out of anti-Microsoft sentiment.

While I cannot vouch for the quality of .NET implementations on non-Windows platforms, I can say that it was fairly easy to learn as a current Java developer. C purists have often called for low-level accessibility to memory and objects, despite the security advantages in a robust object-oriented framework like Java. Conversely, Java advocates denounce the free and open access to memory in C, which breaks the ideal object-oriented paradigm. Microsoft has attempted to strike a happy balance, releasing C# as an object-oriented programming

language with hints of C, which may facilitate broader appeal between both camps of developers.

The most difficult aspect of programming PureMP3 in C# was designing and implementing the main GUI form without Visual Studio. Any beginner in C# .NET learns very quickly that .NET development is tailored closely to Visual Studio .NET, and that Microsoft seeks to boost sales with its latest language. Visual Studio provides a visual design view for doing GUI layouts, and automatically produces a solid code framework for the form which the developer can customize afterward. Additionally, Visual Studio .NET automatically tracks all linked resources, and manages assemblies, response files, and manifests, for the developer. The advantage is less headache when developing a complex application with many components, but the drawback is a $1,000+ price tag associated with Visual Studio.

I developed PureMP3 without the aid of any C# IDE; instead, I downloaded the free compiler with the .NET SDK, and used a simple text editor with C# syntax coloring. I approximated pixel measurements from component to component on the form, and tweaked layouts through trial-and-error. Since PureMP3 consists of only five source modules (see Appendices A and D), coordinating application resources was not a very large task, but I did see the advantages to using Visual Studio .NET once a developer would become proficient with the IDE. MP3 files and ID3 tags were easily represented using a C# class, and a central Command library was used to bridge the GUI and the actual ID3 manipulation operations.

Given the opportunity to code the application again, now knowing the nuances of C#, I would code it in Java, because there was no advantage in using the .NET framework for this application. In Java I would have inherent support for all major platforms, and have access to free IDEs which may aid in compilation and constructing the GUI. Additionally, I found the convention in C# of naming member fields and functions with a capital letter cumbersome, as opposed to the traditional lower-case convention. Typing a member took two keystrokes (SHIFT + [letter]) at the beginning instead of one, and this amounted to many additional keystrokes over the course of authoring the program.

Conclusion

ID3 recognition is built into most, if not all, mainstream MP3 applications today, including Apple’s iTunes and Musicmatch Jukebox. While most provide the user an interface for editing them with ease, none offer the ability to wipe them from the file as PureMP3 does. When a user deletes values from the ID3 fields displayed

Bahnck 16

in commercial applications, generally the applications keep the ID3 tag space intact, therefore preserving the additional storage they demand, but storing simply blank strings. PureMP3 is not unlike this, since it addresses only ID3v1 tags which are capped at 128 bytes. In order to remove that small segment from the end of an MP3 file, an application would need to rewrite the entire file from the beginning, omitting the last 128 bytes. I decided that is an unacceptable performance tradeoff for simply deleting the last 128 bytes from a file.

ID3 tags are here to stay, insofar as MP3 remains popular. Users can expect to continue the responsibility of managing tag information for as long as their music libraries are based on the same format. The next leap in audio encoding technology could be tied to DRM, in which case, content distributors will exercise greater influence over the next encoding’s prevalence. In tandem with the future format could be a metadata tagging scheme similar to ID3, but the end user would not be as likely to see exponentially growing, standard frame sets in incremental releases without an open standard. The owner of the encryption technology would control its tagging scheme, and likely not expand it in size without restrictions as it would in the open source community. However, the flourishing popularity MP3 enjoyed, along with its companion ID3, was fueled by its free and open nature, a benefit which professed DRM-suitors cannot attain.

Bahnck 17

REFERENCES & BIBLIOGRAPHY

[1] Adams, Doug. About ID3 Tags. http://www.dougscripts.com/itunes/itinfo/id3tags00.php. Doug Adams, 2001-2005.

[2] Apple Computer, Inc. iPod + iTunes. http://www.apple.com/itunes/, various sources. Apple Computer, Inc., 2005.

[3] Bollow, Norbert. DotGNU Project. http://www.dotgnu.org/, various sources. Norbert Bollow, 2005.

[4] Brook, Tony. MP3 Metadata ID3 Tag Management + Filenames. http://www.silentway.com/forum/viewtopic.php?t=67. Tony Brook, 2005.

[5] C# Corner. C# Language. http://www.csharpcorner.com/, various sources. C# Corner, 2000-2004.

[6] France, Jasmine and Kim, James. CNET’s Quick Guide to Free Media Jukeboxes. http://reviews.cnet.com/4520-6450_7-5613940-1.html?tag=nav. CNET Networks, Inc., 1995-2005.

[7] Hacker, Scot. MP3: The Definitive Guide. First Edition. Cambridge: O’Reilly & Associates, Inc., 2000.

[8] Jones, Allen; Freeman, Adam. C# for Java Developers. Redmond: Microsoft Press, 2003.

[9] Kaufman Jr., Sanders. Under the Covers of the .NET CLR. http://builder.com.com/5100-6386-1049897.html. CNET Networks, Inc., 2004.

[10] Lenards, Andrew. CSC 386 – C# Programming for the .NET Platform. http://www.cs.arizona.edu/classes/cs386/fall04/handouts/19.html. Andrew Lenards, 2003.

[11] Liberty, Jesse. Programming C#. First Edition. Cambridge: O’Reilly & Associates, Inc., 2001.

[12] McMahon, Steve. vb accelerator. http://www.vbaccelerator.com/home/VB/Code/vbMedia/Audio/Reading_and_Writing_MP3_ID3v1_and_v2_Tags/article.asp, various sources. Steve McMahon, 2004.

[13] Microsoft Corporation. Microsoft Developer Network. http://msdn.microsoft.com/, various sources. Microsoft Corporation, 2004.

[14] Musicmatch, Inc. New Musicmatch JukeBox 10. http://www.musicmatch.com/download/plus/jukebox_intro.htm?OS=pc&MODE=input&BTD=1&DID=, various sources. Musicmatch, Inc., 1998-2005.

[15] Nilsson, Martin. ID3v2. http://www.id3.org/, various sources. Martin Nilsson, 1998-2005.

[16] Petzold, Charles. Programming Microsoft Windows With C#. Redmond: Microsoft Press, 2003.

[17] Reynolds, Matthew. .NET 247. http://dotnet247.com/, various sources. Matthew Reynolds, 2001-2004.

[18] Sloboda, Tilo. Comparison of ID3 Standards. http://www.unixgods.org/~tilo/ID3/docs/ID3_comparison.html. Tilo Sloboda, 2005.

[19] Wikipedia. ID3. http://en.wikipedia.org/wiki/ID3. Wikimedia, GNU Free Documentation License.

Bahnck 18

APPENDIX A: PureMP3: AN ORIGINAL ID3v1 TAG EDITOR FOR THE .NET PLATFORM

Objective

PureMP3 is intended to allow a user to wipe or edit ID3v1 tags from an MP3 file. It provides the user a concise, intuitive interface for deleting or manipulating MP3 metadata.

A variety of open source MP3 and ID3 programming libraries are available at http://www.id3.org/implement.html [15]. I used none of them. I needed a simple class to store ID3 tags, the current MP3 file location, and status information, and a command library to work with a Windows XP-style GUI. I revised a version of the ID3 icon freely available at http://www.id3.org/develop.html to use as the program icon.

One dilemma I encountered when implementing the wipe functionality was, if an application wants to remove the last several bytes from a file, it must rewrite that file from the beginning. MP3 files can be quite large, covering ten or 20 megabytes, and I decided that for performance purposes it would suffice to simply zero-out an ID3 tag. As a result, the 128 byte ID3 tag space is left existing, but wipe operations can be performed instantaneously. All of its fields are actually filled with zeros, and applications interpret them as blank. I figured this would scale the application better as well, if batch operations were added in a future release that I may develop.

Usage

The application features an intuitive interface, with a prominent Status pane to the right in order to prompt the user and display important messages. Initially, the user is presented with a status message instructing him or her to load an MP3 file.

Figure A.1: PureMP3 initial state

Figure A.1 shows PureMP3 in its initial state. All action components, such as buttons, text fields, and menu items are deactivated until the user loads an MP3. The user can load a file by pressing the Load button, selecting Load from the File menu, or using the shortcut key CTRL-L. Once a file is loaded, all fields are populated with the ID3v1.x information if

Bahnck 19

it exists. Figure 2 shows the state of PureMP3 after loading the example file, Moby – Extreme Ways, from The Bourne Supremacy soundtrack.

Bahnck 20

Figure A.2: Enabled components and populated fields after MP3 loaded

The Edit operation is selected by default. Selection of the radio button Edit or Wipe either activates or deactivates the text fields, respectively. Since all ID3v1.x fields have strict limitations on their length, I felt an inline validation scheme was warranted. My validation design avoids two common scenarios that confuse the user. First, rather than simply validate each text field before saving, or when the user finishes typing them, the application validates values at each keystroke, informing the user how many characters he or she has left in real time. This way the user does not unknowingly enter a value which is too long, and then through trial and error revise it down to a value 30 characters or less; the user has a real-time update of the validity of his or her values. Second, when a user surpasses the maximum character limit, or in the case of Year enters a non-integer value, the offending field’s background turns red, and the user is warned in the status box that if he or she saves the MP3 now, his or her value will be truncated or set to a default. Figures A.3 and A.4 demonstrate validation while a value is still under the maximum character limit, and then when it surpasses the limit.

Bahnck 21

Figure A.3: Validation on Artist when the value is under the maximum character limit

Figure A.4: Validation on Album when the value is over the maximum character limit

Once the user completes his or her edits and hits the Save button in the Action group, the status confirms that the edits have been committed. Figure A.5 shows PureMP3’s status message after a successful save, and A.6 shows the same MP3 reloaded, in order to verify that the new data is in place.

Bahnck 22

Figure A.5: Status after successful save

Figure A.5: New data displayed after MP3 reloaded

When the user selects the Wipe radio button in the Operation group, all fields are disabled. Upon pressing Save, all field values are blanked out and the blank ID3 tag is committed to disk. The user is shown a status message verifying the action. After a wipe, the Track Number appears as 0, and the Genre appears as Blues, because zero is technically a valid track number, and Blues is the genre category which corresponds to an index of zero. Figure A.6 shows PureMP3 when the Wipe radio button is selected, Figure A.7 shows the application after a wipe has been committed, and Figure A.7 shows the wiped file reloaded, in order to confirm the ID3v1.x tags are gone.

Bahnck 23

Bahnck 24

Figure A.6: Wipe operation selected

Figure A.7: Wipe committed

Bahnck 25

Figure A.8: Wiped file reloaded, all fields set to zero

If the user is confused or requires instructions, he or she can display an application help file by selecting PureMP3 Help from the Help menu, or using the shortcut key CTRL-H. The help file is stored in XHTML, and the application loads the system default web browser in order to display it. Figure A.9 shows the help file loaded.

Bahnck 26

Figure A.9: PureMP3 Help file

Finally, if the user selects About in the Help menu, or uses the shortcut key CTRL-A, a new Windows form is displayed with program identification, author, and copyright information. The button displaying an astronaut, as well as the “Tom Bahnck” label link, invoke a system call for a URL, directing the user to my website Bahnck.net. Figure A.10 contains the About box.

Figure A.10: Help > About box

Architecture

PureMP3 consists of five C# modules described below. A full listing of each main class is included in Appendix D.

PureMP3.cs:

Bahnck 27

Serves simply as an entry point to the application. Its sole purpose is to invoke the GUI class in order to display the main Windows form.

GUI.cs:A critical module which contains the main application interface. All Windows components for PureMP3, including

the text fields, labels, buttons, menu items, and icons, are created and assembled here. Additionally, the GUI class is responsible for executing text field validation, and storing genre categories. GUI.cs also instantiates and manipulates an MP3 class, used to store the current MP3’s ID3 information in memory before committing it to disk. Among the most lengthy operations in GUI.cs are the validation functions, each of which are implemented as their own event handlers on the keystroke event in any text field. Figure A.11 shows the source code of the validation function for Artist. One of the most difficult aspects of getting validation on every keystroke to work properly was detecting the type of key pressed, a destructive character or non-destructive character. I discovered that on keypress events, the application returns to the programmer the value of the text field before processing the new key. Therefore, in order to perform validation properly, the function has to manually assess the new key and then validate, first appending the new character to the string or removing the last character from the string, in order to give an accurate status to the user.

Figure A.11: Artist validation function// ------- IN-LINE VALIDATION: ARTIST -------protected void eventHandlerValidateArtist(object orig, KeyPressEventArgs evtArgs) { if (evtArgs.KeyChar == (char)8 || evtArgs.KeyChar == (char)127) { // BACKSPACE or DELETE was pressed

if (txtArtist.Text.Length != 0) { if ((txtArtist.Text.Length - 1) > ARTIST_LEN) { statusUpdate("err", "Artist Invalid", ("Artist length cannot exceed " + ARTIST_LEN + " characters. If saved, the artist will be truncated.")); txtArtist.BackColor = Color.LightCoral; } else { statusUpdate("ok", "Artist", (Convert.ToString(ARTIST_LEN - (txtArtist.Text.Length - 1)) + " characters remaining.")); txtArtist.BackColor = Color.LightGoldenrodYellow; } // end if } else { statusUpdate("ok", "Artist", ARTIST_LEN + " characters remaining."); txtArtist.BackColor = Color.LightGoldenrodYellow; } // end if

} else { // NON-DESTRUCTIVE character was pressed

if ((txtArtist.Text.Length + 1) > ARTIST_LEN) { statusUpdate("err", "Artist Invalid", ("Artist length cannot exceed " + ARTIST_LEN + " characters. If saved, the artist will be truncated.")); txtArtist.BackColor = Color.LightCoral; } else { statusUpdate("ok", "Artist", (Convert.ToString(ARTIST_LEN - (txtArtist.Text.Length + 1)) + " characters remaining.")); txtArtist.BackColor = Color.LightGoldenrodYellow; } // end if

} // end if} // end eventHandlerValidateArtist

MP3.cs:A simple class for storing ID3 data. Figure A.12 shows the fields stored. The rest of the class consists mainly of

setters and getters. Most manipulation of this class’ data is handled through GUI.cs and Commands.cs.

Figure A.12: MP3.cs class fields

Bahnck 28

private string filePath;private bool hasV1;private string v1Title;private string v1Artist;private string v1Album;private string v1Year;private string v1Comments;private byte v1TrkNum;private byte v1Genre;

Commands.cs:A static class used to invoke the Save and Load commands from the GUI. Its two functions, invokeLoad and

invokeSave, simply prepare the temporary values stored in an MP3 class, and handle file stream operations.

AboutBox.cs:The Windows form displayed on the Help > About command. It constructs a new simple Windows form with basic

application, author, and copyright information. A button with an image background as well as a URL label invoke a system call to the default web browser, in order to direct the user to Bahnck.net.

Bugs

Only one minor bug surfaced in PureMP3 which I could not remedy. I cannot tell whether it is a nuance of the .NET framework or a flaw in my source code, but the peculiarity of it leads me to believe that it is a .NET framework configuration issue.

PureMP3 uses two outside image resources, an application icon and a background image for the About box button. Figure A.13 shows how these icons are instantiated in GUI.cs and AboutBox.cs.

Figure A.13: Icon object instantiationtry { stdIcon = new Icon("assets\\puremp3.ico"); this.Icon = stdIcon;} catch (Exception) { // use default icon}

The location of the image resource is identified by a simple relative path, which should work from any compilation location so long as the images reside in a subdirectory assets from the current location, and are properly linked in the response file. When the application is compiled, no errors occur and it runs displaying the proper images. However, if the program is moved from that initial compilation location, and without recompiling, run again, the program does not find the image files in assets. The result is a default icon displayed as the program icon, and no astronaut image displayed in the About box. However, if the program is recompiled in the new location, it finds the images and displays them properly. Figures A.14 – A.17 show the adjusted behavior of the program for these file-not-found circumstances.

Figure A.14: Default .NET application icon

Figure A.15: Correct linked .NET application icon

Bahnck 29

Bahnck 30

Figure A.16: Adjusted About Windows form for missing image state

Figure A.17: Correct button image in About Windows form

This behavior leads me to believe that the .NET compiler, as well as interpreter, is a run-time necessity as well as a compile-time necessity, and critical for informing the system of the location of referenced resources. Windows may require some explicit compiler instructions or flags in order to remedy this situation that I am not aware of. However, the bug is not critical and does not affect functionality of the program. It is peculiar behavior, and worth investigating in the future as more image-heavy forms may not be able to adjust for the circumstance as readily.

Bahnck 31

APPENDIX B: ID3v1 GENRES

0. Blues1. Classic Rock2. Country3. Dance4. Disco5. Funk6. Grunge7. Hip-Hop8. Jazz9. Metal10. New Age11. Oldies12. Other13. Pop14. R&B15. Rap16. Reggae17. Rock18. Techno19. Industrial20. Alternative21. Ska22. Death metal23. Pranks24. Soundtrack25. Euro-Techno26. Ambient27. Trip-hop28. Vocal29. Jazz+Funk30. Fusion31. Trance32. Classical33. Instrumental34. Acid35. House36. Game37. Sound Clip38. Gospel39. Noise

40. Gospel41. Noise42. Alt. Rock43. Bass44. Soul45. Punk46. Space47. Meditative48. Instrumental pop49. Instrumental rock50. Ethnic51. Gothic52. Darkwave53. Techno-Industrial54. Electronic55. Pop-Folk56. Eurodance57. Dream58. Southern Rock59. Comedy60. Cult61. Gangsta62. Top 4063. Christian Rap64. Pop/Funk65. Jungle66. Native American67. Cabaret68. New Wave69. Psychedelic70. Rave71. Showtunes72. Trailer73. Lo-Fi74. Tribal75. Acid Punk76. Acid Jazz77. Polka78. Retro79. Musical

80. Rock & Roll81. Hard Rock82. Folk83. Folk-Rock84. National Folk85. Swing86. Fast Fusion87. Bebob88. Latin89. Revival90. Celtic91. Bluegrass92. Avantgarde93. Gothic Rock94. Progressive Rock95. Psychedelic Rock96. Symphonic Rock97. Slow Rock98. Big Band99. Chorus100. Easy Listening101. Acoustic102. Humour103. Speech104. Chanson105. Opera106. Chamber Music107. Sonata108. Symphony109. Booty Bass110. Primus111. Porn Groove112. Satire113. Slow Jam114. Club115. Tango116. Samba117. Folklore118. Ballad119. Power Ballad

120. Rhythmic Soul121. Freestyle122. Duet123. Punk Rock124. Drum Solo125. A cappella126. Euro-House127. Dance Hall128. Goa129. Drum & Bass130. Club-House131. Hardcore132. Terror133. Indie134. BritPop135. Negerpunk136. Polsk Punk137. Beat138. Christian Gangsta Rap139. Heavy Metal140. Black Metal141. Crossover142. Contemporary Christian143. Christian Rock144. Merengue145. Salsa146. Thrash Metal147. Anime148. JPop149. Synthpop

Genres 0 – 79: ID3v1 StandardGenres 80 – 149: Winamp proprietary [19]

Bahnck 32

APPENDIX C: ID3v2 COMMON STANDARD FRAMES

FrameCode By Subversion

2.2 2.3 2.4Content group description TT1 TIT1 TIT1Title/songname/content description TT2 TIT2 TIT2Subtitle/description refinement TT3 TIT3 TIT3Lead performer(s)/soloist(s) TP1 TPE1 TPE1Band/orchestra/accompaniment TP2 TPE2 TPE2Conductor/performer refinement TP3 TPE3 TPE3Composer TCM TCOM TCOMLyricist/text writer TXT TEXT TEXTAlbum/movie/show title TAL TALB TALBTrack number/position in set TRK TRCK TRCKDate TDA TDAT  Year TYE TYER  Time TIM TIME  Recording dates TRD TRDA  Recording time     TDRCOriginal release year TOR TORY  Original release time     TDORBeats per minute TBP TBPM TBPMCopyright message TCR TCOP TCOPPublisher TPB TPUB TPUBEncoded by TEN TENC TENCLength (ms) TLE TLEN TLENOriginal album/movie/show title TOT TOAL TOALOriginal filename TOF TOFN TOFNOriginal artist(s)/performer(s) TOA TOPE TOPEOriginal lyricist(s)/text writer(s) TOL TOLY TOLYFile owner/licensee   TOWN TOWNInternet radio station name   TRSN TRSNInternet radio station owner   TRSO TRSOMood     TMOO

Table adapted from comprehensive list [18].

Bahnck 33

APPENDIX D: PureMP3 SOURCE CODE

Please see the pages following pages for a full listing of PureMP3’s class files.

Bahnck 34