Jump to a different year? Take your pick! ☸ 2000 ☸ 2001 ☸ 2002 ☸ 2003 ☸ 2004 ☸ 2005 ☸ 2006 ☸ 2007 ☸ 2008 ☸ 2009 ☸ 2010 ☸ 2011 ☸ 2012 ☸ 2013 ☸ 2014 ☸ 2015 ☸ 2016 ☸ 2017 ☸ 2018 ☸ 2019 ☸ 2020 ☸ 2021 ☸ 2022 ☸ 2023 ☸ 2024 ☸
Table of Contents
Guidelines for Audio Tagging (GAT), version 2.5
The goal of this document is to provide a logically consistent framework for tagging both commercial and noncommercial audio recordings in a relatively simple fashion (hah! fitting both needs together is a somewhat complex task that will require resolution of competing needs and exceptions!). This system grew out of frustration with the incompleteness/inconsistency of standard tagging systems (see Hydrogen Audio's terrific primer page for additional background).
Note the “standard” originally established for tag fieldnames relied only on upper case A-Z characters. Later developments relaxed this “requirement” to permit UTF-8 characters, though this system, being english-biased, sticks to the standard alphanumeric subset of 26 roman letters plus 10 decimal digits. In some cases compound word fieldnames are concatenated (eg., ALBUMARTIST), but in other cases they may be underscore-linked (none used here) or space-delimited (eg., ALBUM ARTIST) for readability. In other words, it's not especially consistent!
Tags named in brackets are optional (but useful!); these tags probably don't apply to some sorts of recordings (for example, a commercial release probably doesn't have an associated venue).
Most of the examples (and syntax) below are specific to Foobar2000, since that's the media engine I use for playing and tagging my collection, however, the general concepts certainly apply to other applications, such as MediaMonkey, MusicBrainz Picard or Tag&Rename.
Notation
As with the initial presentation of tags for definition, later references to tag-names are given in upper-case rather than %-delimited, as used in Foobar 2000 string formatting commands, in order to immediately distinguish them from plain text.
As with Foobar 2000 usage, bracket-delimited tags are optional, and may be omitted or left empty at user discretion.
Summary Lists of Tags by Type
The following lists relate all of the tags defined in detail in the following sections.
At present the shortcuts don't work because the anchor links are broken with the latest definition list plugin. Rats!
Basic Tags
ARTIST <html>♦</html> ARTISTSORT <html>♦</html> ABBR <html>♦</html> ALBUM ARTIST <html>♦</html> ALBUM <html>♦</html> STATUS <html>♦</html> EVENT <html>♦</html> VENUE <html>♦</html> CITY <html>♦</html> STATE <html>♦</html> ST <html>♦</html> COUNTRY <html>♦</html> CCODE
Date Tags
DATE GIG <html>♦</html> DATE RELEASE <html>♦</html> DATE REPRINT <html>♦</html> DATE TAGGED <html>♦</html> DATE PURCHASED <html>♦</html> DATE LONG
Detail Tags
PERFORMER <html>♦</html> CREDITS <html>♦</html> URL <html>♦</html> REFLINK <html>♦</html> SRCCHAIN <html>♦</html> SRCNOTES <html>♦</html> XFRCHAIN <html>♦</html> XFRNOTES <html>♦</html> NOTES <html>♦</html> TAGSYS <html>♦</html> ISO639-2 <html>♦</html> TOTALTRACKS
Track-Level Tags
TRACK <html>♦</html> TITLE <html>♦</html> SET <html>♦</html> S TRACK <html>♦</html> S TOTALTRACKS <html>♦</html> DISC <html>♦</html> D TRACK <html>♦</html> D TOTALTRACKS <html>♦</html> TRACKNOTE
Collection-level Tags
These tags apply to a group of files representing an album or a show. The files need not be enclosed in any sort of containing archive or directory, though both are useful for establishing a physical hierarchy of files.
Basic Tag Definitions
- ARTIST
- Primary performance name for a given performer or group, such as might be read from a printed advertisement or label (eg, 'John Doe', not 'Doe, John').
Note that when ARTIST is empty, standard Foobar2000 field remapping checks other metadata fields and then substitutes data (for display) in this order: ALBUM ARTIST, COMPOSER, PERFORMER.
Note also that given common usage, it's nearly impossible for ARTIST to correspond to PERFORMER in anything other than a many-to-many relationship. MusicBrainz has a great article about naming issues.
- ARTISTSORT
- Name used for sorting/filing purposes (eg, 'Doe, John' not 'John Doe'); commonly equal to ARTIST for simple band names.
Note that leading articles should be moved to the end no matter the language. Some examples:
'the Rolling Stones' is entered as 'Rolling Stones, the'
'Das Racist' ⇒ 'Racist, Das'
'Los Lobos' ⇒ 'Lobos, Los'
If this seems weird to you, it's because you're not thinking like a librarian/archivist.
- [ABBR]
- Originally this field contained the etree-compliant band/artist abbreviation. Although it's use is no longer necessary with the demise of 8+3 filenaming, brevity is still helpful for readability. After all, would you rather look at a folder with tracknames like “Florence and the Machine 2015-10-21 U.C. Berkeley Greek Theatre t01.flac” or “F+tm2015-10-21Greek_t01.flac”? The problem here is that it's impossible to standardize things to guarantee short readable filenames – there are just too many possibilities for artist and venue names. So compromise is necessary. Relax. Take a deep breath. Name things how you like. Don't freak out if I think your carefully curated and shared files should be named differently…they're mine now, right? Feel free to retag and rename mine as you see fit for yourself. Now exhale. See? Easy, wasn't it?
- [ALBUM ARTIST]
- This tag is typically used for collections that contain tracks by multiple artists; my preference is to use 'Various Artists' in this field, then to fill ARTIST as appropriate on a track-by-track basis. More info on the use and reasoning behind this approach is given in the foobar wiki.
- ALBUM
- The name of the commercial/ROIO release for this collection. If ALBUM is empty, standard Foobar 2000 field remapping will redirect VENUE here, so leave this field empty for live recordings unless you want to emphasize a commercial/ROIO title instead.
- STATUS
- Set to one of the following two choices: CRM or NCO
- CRM = Commercially Released Media, or Copy-Righted Media.
- NCO = recording of Non-Commercial Origin (everything not CRM!)
Note that an NCO can easily become CRM (due to the action of the artist or agents thereof), but a CRM cannot easily become an NCO.
Instant-live recordings and promotional material is generally CRM, even if it was offered freely by the artist/management.
A commercial recording that is out of print is still a CRM provided that ownership rights to the recording have not passed into the public domain!
The fact that copyright law varies from country to country complicates the situation immensely.
I would argue further that ROIO's sold without artist approval are NCO rather than CRM.
In any case, it is obviously an exercise for the tagger/reader to determine which of the two labels should be applied!
- [EVENT]
- An optional descriptive field, eg, “18th Annual San Jose Jazz Festival”
- VENUE
- Full name of venue; note that standard Foobar 2000 behavior is to map VENUE to ALBUM when ALBUM is empty.
- [ADDR]
- Street Address of the venue.
- CITY
- Full name of USPS-designated city (if USA), native (romanized) spelling preferred if location is a non-English speaking locale.
- ST
- Official USPS 2-letter abbreviation code, see the USPS list
- [STATE]
- Optional full name of state (useful for non USA locations; may be used for provinces, regions and other equivalent geographic units), native (romanized) spelling preferred if location is a non-English speaking locale.
- [COUNTRY]
- Full name of country, native (romanized) spelling preferred if location is a non-English speaking locale.
- CCODE
- ISO-3166-1 alpha-2 three-letter country codes such as USA and DEU. For CRM, this field can be used to indicate the release country for a particular media item (eg., to differentiate between US and British releases of the same album).
Date Tag Definitions
- DATE GIG
- YYYY-MM-DDThh:mm:ssTZD, or more likely, the truncated Calendar date version, YYYY-MM-DD, in accordance with ISO-8601.
Calendar date of a performance or recording session. May vary by track for a compilation or CRM item. Will be used to fill the DATE display field in preference to other DATE variants that follow.
- DATE RELEASE
- YYYY-MM-DD; date that a CRM was originally released for purchase, OR date that a particular torrent was seeded (as referenced in the CREDITS and/or URL fields).
- DATE REPRINT
- YYYY-MM-DD; date that a CRM was re-released for purchase (perhaps after being remastered, other times by being licensed to another publisher).
For example, Exile on Main Street gets DATE RELEASE of 1972-05-12 no matter what version is under consideration, while the 2010 USA 2-CD deluxe remaster adds DATE REPRINT of 2010-05-18.
- [DATE TAGGED]
- YYYY-MM-DD; date that a fileset was tagged (useful for comparing against reference updates given by external sources) - useful for personal collection cataloging.
Can be set automatically via $date(%last_played%) or $date(%last_modified%) in foobar2000.
- [DATE PURCHASED]
- YYYY-MM-DD; date that a CRM fileset was purchased - useful for personal collection cataloging.
- DATE LONG
- DDDD, MMM D, YYYY (example: “Friday, September 9, 2005”). While this field is simply a reformatted version of DATE, Foobar 2000 currently lacks any such date-string handling functions, so it's just easier to add this info by hand, despite the hassle.
Detail Tag Definitions
- PERFORMER
- Ideally, this is an alpha-ordered list where each entry is in the form
"name: instrument[, instrument2[,instrument3...]];" eg., "Jerry Garcia: guitar, vox; John Kahn: bass; Ron Tutt: drums."
The final list element should terminate with a period instead of a semicolon. This field may be modified on a per-track basis. The field may also include conductors, choir-masters and any other contributors deemed worthy of note by the tagger, where the job function appears as an “instrument”. This mode of usage obviates the need for specialized but little-used tags such as CONDUCTOR, LYRICIST, REMIXER and so on.
When viewed in a JSON editor, this sort of list will automatically be decomposed into it's individual elements. But as a raw tag, things are not so readabile, as each list element follows the next without whitespace (a newline would be terrific!), and asking for the list to be alpha-ordered doesn't make for ease of entry.
Far better would be an unordered array {[name1, instrument1],[name2, intrument2],…} where alphabetization and output-formatting of multi-element entries is performed by the software rather than the user.
Unfortunately, sorting a list of names in a manner that catches all of the weirdness allowed in English usage has stymied many a programmer. If anyone knows how to program Foobar 2000 to accomplish this task, please let me know!Also, as of v2.4, this field may include markdown formatting (most likely initial bullets: “* ”), but such visual markup is NOT required. As of v2.5, use of markdown formatting is discouraged – a tag is considered raw content, not formatted data.
- CREDITS
- Free-form field giving the name (and possibly email address) of one or more persons involved in recording, transferring, encoding and sharing of this recording. New references/comments should appear on new lines. Samples follow.
Recorded by Jean Lerond <lerond@gmail.com> Transfered by Randy Vogel <randy@funfolks.net> on 2012-03-14 Tagged by [Randy Vogel] on 2012-03-16
I realize that the example uses some of the date fields – I think this makes the credits more useful and readable – don't you? Note also the use of markdown reflink style in the third example. In order for that link to be valid, the REFLINK field MUST include the link target, as shown in the next preview box
[Randy Vogel]: mailto:randy@funfolks.net
- URL
- An un-ordered array of markdown formatted internet reference lines.
These can be formatted inline:
[URL handle](URL)
Or by reference, using a subsequent entry in the REFLINK field:
%URL% contains [URL handle] %REFLINK% contains [URL handle]: URL
Choice to use either style is left to the tagger. The goal here is for ease of readability. Any or all of the following URLs may be included: official artist/performer, record label/publisher, copyright/legal, download/torrent source, lyrics page, et cetera; each may include optional explanatory text comments.
Three such useful URLs are:- MusicBrainz ArtistID, for performers, such as that for the acclaimed jazz musician, Pharoah Sanders.
- MusicBrainz ReleaseID, for albums, such as Pharoah Sanders Quartet: the Creator Has a Master Plan.
- MusicBrainz RecordingID, for songs, such as Welcome from the previously cited album.
Note that like many other resources on the Internet, MuscBrainz is imperfect, and the album used as an example does not appear to connect properly to Pharoah the individual, only to his eponymous quartet. Foobar 2000 can find these links semiautomagically via the optional musicbrainz plugin component. I have nothing against including pointers to other resources, such as pages from AllMusic or Discogs that offer the first release of Pharoah's classic tune, recorded on Valentine's Day in 1969 – the point is simply to direct the interested reader to further information regarding this listening matter.
For live shows, I prefer references to the eTree database, particularly for shows and sources. For example:- eTree showID, for shows, such as that for The Absolutely Unofficial Blue Jeans Bash.
- eTree shnID, for individual recordings, such as Jim Cooper's recording of the Grateful Dead on Feb 13, 1970.
In practice, however, I commonly just use 'eTree showID' or 'eTree shnID' rather than the more detailed handles given in the two previous examples, hence:
[eTree showID](http://db.etree.org/lookup_show.php?shows_key=391656). [eTree shnID](http://db.etree.org/shn/123814).
- REFLINK
- This field is used to store longer URLs in order to maintain readability by using reference link style in the CREDITS and URL fields rather than inline link style. Usage examples have been provided above.
- SRCCHAIN
- Master recording details, usage varies by CRM/NCO Status.
For CRM, this might include the label/distributor/publisher name, catalog number, 10- or 13-digit Universal Product Number (UPN– the bar code value that appears on most commercial releases), musicbrainz album ID, Amazon ASIN or any other data you wish to use that will identify this particular release. The only constraint is that for easier parsing, each piece of information should appear on a new line.
For NCO, this field consists of an ordered list of text comments describing the recording equipment and setup used to create the original master recording represented by this fileset. In the interest of standardization, sample values for this field (and XFRCHAIN) have been accumulated into a reference_equipment_list.
- [SRCNOTES]
- Optional free-form text field for any comments about the recording source.
- XFRCHAIN
- Detailed notes about the transfer process(es).
For CRM, this is where you would place descriptive info about the means by which analog media was ripped (eg., encoding settings) to create the digital file being tagged.
For NCO, this field consists of an ordered list of text comments describing the recording equipment and setup used to convert this fileset from the original recording to its current state. In the interest of standardization, sample values for this field (and XFRCHAIN) have been accumulated into a reference_equipment_list.If known, it's nice to specify the date of the transfer operation(s), as shown in the examples.
- [XFRNOTES]
- Optional free-form text field for any comments about the recording transfer.
- [NOTES]
- Optional free-form field for any other comments or information about the recording. COMMENT should map to this field (NOTES was chosen over COMMENT for brevity).
- TAGSYS
- The string 'GATvN.M = where N.M version number of this tagging system – GATv2.5 at present! This field is used to provide backwards compatibility in foobar string coding - ie., to let the software to know to process v1 tags differently than v2.
- ISO639-2
- 'eng' unless you are tagging in another language, in which case that ISO code goes here instead. The goofy fieldname arises because that's the ISO standard reference number for these codes.
- [TOTALTRACKS]
- Total number of tracks in a collection. This value is typically autogenerated by software.
Track-level Tag Definitions
While the previously covered collection-level tags will be uniform throughout a particular show or release, track-level tags will necessarily vary.
- TRACK
- Track number, from 01 to 99. The leading zeroes are required in order to permit easier sorting. Duplication of track number within a collection indicates a user tagging error!
- [ARTIST]
- Used in conjunction with ALBUM ARTIST to indicate track-specific artist info. In other words, existence of an ALBUM ARTIST tag demotes ARTIST from a collection-level tag to a track-level tag.
Still confused? Consider the following example.
- TITLE
- properly capitalized name of the song or file. I've adapted the info presented on that Capitalization Rules page into a list of no caps/exceptions here.
Ideally, all titles are standardized: 'Not Fade Away' not 'NFA', 'Tangled Up in Blue' not 'Tangled' and so on. Many resources exist to help determine the proper name of a tune — learn to use them!
Asterisks, flags or footnote icons do not belong in the song title. Your software should be fully capable of displaying such track-level commments in an appropriate fashion!
Non-song tracks should be identified by bracketing, eg, [Announcer Introduction] or [banter] or [encore break] or similar entry. Keep it simple!
Classical track titles should be named in accordance with MusicBrainz style guidelines.
Note that if the TITLE field is empty, the Foobar 2000 default remapping substitutes FILENAME.
- [PERFORMER]
- As with ARTIST, it's permissible to annotate this information at track-level rather than collection-level, provided that the tagger wishes to take the extra time to do so.
- SET
- One of 1, 2,… E, E1, E2,… S, X, A, B,… etc, (sublists continuing as needed).
Some additional explanation: use number for a particular set (if known), or as a suffix to another ID (eg, E1 = 1st Encore Set)
E = encore set; S = Soundcheck; X = excerpts (actual set unknown); A = early show; B = late show.
- [S TRACK]
- Counter for ordinal position of this track within a set.
- [S TOTALTRACKS]
- Total number of tracks in a set. May include encore tracks at user discretion (for example, I don't count multiple encores as a set unless the encore duration exceeds 15-20 min).
- [DISC]
- If the TITLE is part of a multidisc set, this counter is used to denote which audio cd this track would be part of; Foobar 2000 automatically maps the longer tag DISCNUMBER to this field.
- [D TRACK]
- Counter for ordinal position of this track within an audio cdr.
- [D TOTALTRACKS]
- total number of tracks in an audio CD corresponding to a subset of tracks in this collection.
It's up to you whether or not to include DISC, D TRACK and D TOTALTRACKS info in your tagging, as such information relates less to the files being tagged and more to the presentation of those files on various physical media. I consider them optional, however, I understand that many people consider that information about the physical media is what ought to be catalogued by these tags.
- [TRACKNOTE]
- Free-form text field for entry of any additional information about this track.
The most likely use for this field is to give subtitle information such as '(take five)' or '(dub remix)'.
The next most likely use for this field is as a placeholder for track-level [PERFORMER] or [TRACK PERFORMER] tags. When track-level variances to collection-level functions are known, that info may be entered on a track-by-track basis. Unfortunately, this means lots more work for the tagger, but if you really care to know which tunes in a Dylan performance feature him playing harmonica, this is where that information could be annotated.
Yet another use for this field would be as a container for lyrics, or a URL pointing to lyrics.
Note that it's simple to hack Foobar 2000 title display strings to check or make use of this field! Exactly what to do is left to the user!
Deprecated Tags
Moved to a separate page to improve readability: Deprecated Tags
Changelog
Moved to separate page: changelog
