Supported Formats

MP3copy copies any file — music or not — but it reads tags and manages cover art only for recognized audio formats, and only some of those get the full set of features.

Full support

MP3, FLAC, WAV, and AIFF get every music-aware feature MP3copy has:

The disc preview showing a track's embedded cover art while it copies

Other audio formats

Other formats macOS itself recognizes as audio — AAC/M4A among them — are still copied and treated as music like the fully supported formats above, with their tags and any embedded artwork read for the disc preview and for name optimisation. They aren't included in the automatic fallback-cover embedding, since that relies on a per-format way of adding an image to a file that doesn't already carry one, which isn't implemented for these formats.

Non-audio files

Anything else — images, booklets, and so on — is copied through unchanged alongside the music it came with. Playlists are the one exception: their internal references to the music files' paths and names may be corrected — see below for how.

Fallback cover art

When a track has no embedded artwork of its own, MP3copy looks for a separate cover image sitting in the same folder — named (case-insensitively) cover, albumart, or folder, optionally followed by a number, with any image extension (cover.jpg, AlbumArt-2.png, folder_1.tiff, and so on). If more than one match its folder, cover is preferred over albumart, which is preferred over folder; among ties, the one with no trailing number wins, then the lowest number.

Image files over 2 MB are skipped and never used as a fallback cover — a file that large is almost certainly a print-resolution scan rather than the kind of compact artwork a music file normally carries, and embedding it would bloat every track it's attached to. When a candidate is used, it's embedded exactly as found — original resolution, original format, no resizing or recompression.

Playlists

M3U, M3U8, PLS, and CUE playlists are rewritten as they're copied: MP3copy checks every track reference in the playlist against the tracks it's actually copying, and corrects the reference if its path or file extension no longer matches — for example a playlist that still says 07 Song.wav for a track that's actually an MP3 now, or one whose paths were rewritten because the tracks themselves were renamed. Every corrected reference is reduced to just the track's own file name, since a playlist that ships alongside its tracks never needs more than that to find them again.

File systems

MP3copy reads the destination's file system (FAT32, exFAT, NTFS, APFS, and others) to estimate available space accurately — not just the sum of the queued files' sizes, but rounded up to that file system's real allocation block size, plus what its directory catalog needs to grow by to hold the new entries. That's also why copying strictly one file at a time matters most on FAT32 destinations specifically: creating a file there through the usual temporary-name-then-rename approach can shuffle where its entry actually lands in the directory, silently scrambling alphabetical order even when every file was written in the right sequence — MP3copy writes directly to the final name instead, avoiding that.

Ignored files

MP3copy skips any file or folder whose name starts with a dot — these are hidden files and folders, including the small companion files (._Name) that macOS creates next to ordinary files on file systems that can't store its extra metadata, like FAT32 and exFAT. It also skips a set of known system and junk files even when they aren't marked hidden: .DS_Store, .Trashes, .Spotlight-V100, .fseventsd, .TemporaryItems, .apdisk, .DocumentRevisions-V100, Thumbs.db, desktop.ini, System Volume Information, and $RECYCLE.BIN.

This isn't just tidiness: some MP3 players don't treat a leading dot as meaning "hidden" and will try to play a file if its extension matches a music format. MP3copy never copies these files, so they simply aren't there to cause that problem on the destination.