iTunes 4: The Music Library Acquires a Checkout

A music collection can be well organized on a shelf and remarkably untidy on a disk. The files exist, but their names disagree about artists, track order, and what counts as an album. A player can open them one at a time. A library needs to make them behave like a collection.

Apple’s iTunes began as a Macintosh music-management application in January 2001. Its launch announcement described importing CDs, encoding MP3s, searching a library, assembling playlists, and burning audio CDs. Purchasing from Apple’s store was not part of that first release.¹

On April 28, 2003, iTunes 4 acquired the Music Store. The application connected browsing, purchase, download, organization and playback. A song could move from a shop listing into the listener’s library without requiring a separate sequence of unrelated programs.²

The resulting convenience had two sides. The application arranged the music and helped govern its permitted use. A library that knows what you own can also be the place that tells you which computer is allowed to play it.

The shop has a precise beginning

The April store launch was for Mac users with a US billing address and a suitable Mac OS X installation. The announcement specified 99 cents per song, previews, a catalog exceeding 200,000 tracks, and 128-kbit/s AAC music files.²

Those details define the period product. This was a download purchase service, not today’s subscription-streaming library. The ordinary unit was a track or album bought for subsequent playback, rather than temporary access to a vast catalog under a monthly listening plan.

Windows access arrived on October 16, 2003. Apple’s announcement presented the same store and pricing through iTunes for Windows, alongside library features such as Smart Playlists and CD burning.³

That expansion mattered because the music arrangement was no longer limited to the Mac desktop. The application, store and iPod could form a connected product relationship for Windows users too. This is a documented platform expansion, not a claim that Apple invented digital music purchasing.

The store launch also required music-company agreements and catalog preparation. An elegant checkout cannot sell recordings whose rights haven’t been arranged. The application was one visible part of a larger negotiation between software, devices and the recording industry.

A library remembers more than a filename

A file contains encoded audio. A library record supplies a way to find, group and interpret that file: artist, album, track number, duration, and other attributes. These are conceptual roles, not a reconstruction of iTunes 4’s private library format.

The distinction is useful because different questions require different descriptions. “Play this file” needs a location and a decoder. “Play the third track of this album” needs ordering metadata. “Show all tracks by this artist” needs a consistently recorded artist identity.

Renaming every file isn’t enough to solve those problems. A filename can carry useful information, but a structured record lets the application distinguish fields rather than guessing where one label ends and the next begins.

It also makes human inconsistency visible. Suppose one track says The Evening Quartet and another says Evening Quartet. Grouping by an exact artist field treats them as different values. The computer has preserved the information it received, including the part you didn’t mean to give it.

Good library tools help users correct such metadata. The mechanism remains simple: an organized view depends on organized fields. A tidy display is the output of a data model, not proof that the music has been cataloged correctly.

A playlist can be a question

An ordinary playlist can store a selected sequence of tracks. A rule-based playlist can instead describe which tracks belong. When the library’s relevant values change, evaluating the rule again can change the selection.

Smart Playlists are documented in Apple’s October 2003 Windows release. The example below explains the general mechanism without claiming to reproduce the exact menu wording, defaults or internal query language of that release.³

Invent five tracks with a rating and a play count:

Track	Rating	Plays
Harbor Lights	5	1
Small Hours	4	4
Paper Moon	3	0
Last Tram	4	2
Blue Window	5	7

Define our teaching rule as: select tracks rated at least four whose play count is less than three. Harbor Lights and Last Tram qualify. Small Hours has enough stars but too many plays. Paper Moon has few plays but an insufficient rating. Blue Window also exceeds the play-count limit.

Original CC0 teaching diagram, 2026. Invented tracks and general rule evaluation; not an iTunes screenshot or exact Smart Playlist implementation.

Now play Last Tram once more and record the play. Its count rises from two to three, so it no longer satisfies “less than three.” Reevaluate the rule and only Harbor Lights remains.

That changing membership is the useful property. A fixed list preserves a choice made at one moment. A rule preserves a condition. Both can be valuable, depending on whether the listener wants a carefully arranged program or a selection that responds to the library.

The rule is also literal. “Less than three” and “three or fewer” produce different results at the boundary. A friendly interface doesn’t remove logic; it gives logic more approachable clothing.

The example was executed as a Python filter over invented records. It checks membership before and after the play-count update. No historical iTunes runtime was used, and the titles don’t identify real recordings.

Compression buys space with a different promise

The store’s stated 128-kbit/s rate provides a useful arithmetic exercise. Consider an invented four-minute track encoded at a constant 128,000 bits per second. Its audio payload would occupy:

$128{,}000 \times 240 \div 8 = 3{,}840{,}000\text{ bytes}.$

That’s 3.84 MB in decimal units, or about 3.66 MiB. Container information, artwork, tags and any applicable protection overhead would add to a complete file’s size. Actual encoding behavior may also differ from this constant-rate teaching assumption.

For comparison, uncompressed two-channel audio with 44,100 samples per second and 16 bits per sample has a raw rate of 1,411,200 bits per second. The same duration requires 42,336,000 bytes of sample data.

The ratio is 11.025 to one. This is a comparison of the stated data rates, not a subjective sound-quality score or a measurement of an actual store download. A smaller payload doesn’t tell us how a particular recording sounds to a particular listener.

Original CC0 diagram, 2026. Calculated constant-rate payloads; excludes file-container and metadata overhead and does not depict historical transfer performance.

At an imagined connection delivering exactly 32,000 payload bytes per second, 3,840,000 bytes would take 120 seconds. That connection rate is invented. The arithmetic shows why file size matters to delivery, while real download time also depends on protocol overhead, congestion and the server.

Apple’s launch language made favorable claims about AAC sound quality. This article doesn’t turn those claims into independently established listening results. Compression is an engineering compromise, and preference deserves more evidence than a press release adjective.

A purchase carries conditions

At launch Apple advertised use on up to three Macintosh computers, playback on iPods, and personal CD burning. The software-supported rights were part of the product being sold, alongside the recording.²

A conceptual rights system has at least three objects to keep straight: the media bytes, the purchase entitlement, and the devices authorized to exercise that entitlement. Possessing a copy of the file doesn’t automatically answer every authorization question.

That helps explain why a library application can have responsibilities beyond decoding audio. It may need to identify an account or an authorized computer before playing purchased content. The general explanation here doesn’t describe FairPlay’s private cryptographic implementation.

The tradeoff is convenient integration with dependence on the surrounding system. A listener benefits when purchase, organization and playback fit together. The same fit can make moving the collection to another environment more complicated if that environment doesn’t support the applicable format and protection rules.

A rule enforced by software also needs to remain distinguishable from a statement about law. The launch announcement describes Apple’s offered usage conditions. This article records those historical terms without offering a modern legal interpretation of music copying.

Later music isn’t the same product

In January 2009, Apple announced a transition to DRM-free iTunes Plus music, at 256-kbit/s AAC, and changes to track pricing. That belongs to the later store, rather than to April 2003.⁴

The distinction matters to collectors of software history. A modern file bought through an evolved service may have different restrictions, bitrate and pricing from a file bought at launch. The continued product name doesn’t freeze its technical and commercial properties.

It also shows that integration is not one permanent contract. The application can keep its role as a library while the purchase terms change around it. The useful question is which release and which transaction a claim describes.

Likewise, the original iTunes application, the 2003 store, and later subscription services are separate milestones. Compressing them into “Apple launched digital music” discards the mechanisms that made each stage consequential.

The collection becomes the interface

What interests me about iTunes 4 is the way purchasing joined an existing act of organization. The application already had a reason to know artists, albums and playlists. The shop made that same environment the point of entry for new music.

The worked playlist illustrates how structured metadata lets a collection respond to a rule. The payload calculation illustrates why compressed files made acquisition and storage more manageable. The rights discussion explains what convenience could bring along with the audio.

None of those mechanisms guarantees good taste or accurate tags. A carefully filtered library can still contain five spellings of the same artist and an unfortunate amount of a song you thought you liked last summer.

The consequential change was making music acquisition part of the software that managed listening. Buying a track became the beginning of a continuing library relationship. The checkout was small; the collection around it was the product.

Sources

Footnotes

1. Apple, iTunes introduction, January 9, 2001. Library, MP3 import and CD burning, before the store. ↩

2. Apple, Music Store launch, April 28, 2003. Platform/geographic boundary, AAC rate, prices and usage conditions. ↩ ↩² ↩³

3. Apple, iTunes for Windows launch, October 16, 2003. Platform expansion and Smart Playlist feature; illustrative rule is original. ↩ ↩²

4. Apple, Changes Coming to the iTunes Store, January 6, 2009. Later DRM-free music and pricing transition, not assigned to launch. ↩