History:Live Track Style

Style for Live Tracks

• Status: This is a ProposedStyleGuideline.

Purpose

This page describes the style to be used for naming live tracks. It only deals with the ExtraTitleInformation part of the TrackTitles, i.e. the part that describes whether the track is a live recording and possibly the date and venue for the recording. All other parts of the track title should be entered according to the normal OfficialStyleGuidelines.

Naming of live tracks depends on whether they are

1. a track on a Release, or
2. a NonAlbumTrack

Live Tracks on Releases

If all tracks on a Release are live, the release should have the ReleaseAttribute "live", and TrackTitles should not contain ExtraTitleInformation about the date and venue of the live performance. This information belongs into the ReleaseAnnotation.

If only some tracks on a Release are live, append " (live)" to the MainTitle, like this:

• "MainTitle (live)"

Add all date and venue information to the ReleaseAnnotation (example).

If more information is needed to distinguish between two tracks with the same title on one release (e.g. because the release has songs from more than one live session), more information can be added to the track title as explained for non-album tracks below.

There is an exception to this guideline:

If an release with the ReleaseAttribute "Live" has more than one track with the same name, they can be differentiated by appending the date and venue as follows: "Song Name (1980-01-18: Brussels, Belgium)". Basically, the same style is used as for non-album tracks, but without adding the 'live' part (because this information is already included in the ReleaseAttributes). It's also possible to append a number to the title as follows: "Song Name (1)" and "Song Name (2)". This is usefull for tracks that have no date information, or for tracks that are from outtakes (example).

Live Non-Album Tracks

For NonAlbumTracks it is best to include as much information as possible into the TrackTitle in parantheses as ExtraTitleInformation. Some possibilities are listed below. The date and venue naming format is exactly the same as in UntitledBootlegStyle.

1. "MainTitle (live, Radio 3FM, 2004-05-23: Effenaar, Eindhoven, The Netherlands)"
2. "MainTitle (live, 2004-05-23: Effenaar, Eindhoven, The Netherlands)"
3. "MainTitle (live, 1969-01-16: New York, NY, USA)"
4. "MainTitle (live, 2004-11)"
5. "MainTitle (live, 2004: The Netherlands)"
6. "MainTitle (live, New York, NY, USA)"
7. "MainTitle (live, Radio 3FM)"
8. "MainTitle (live, 2004)"
9. "MainTitle (live)"

Notes

Track 'version' information should be in a different pair of parentheses ('acoustic' is considered a version, like a remix name):

• "Song Name (live) (acoustic)"

Status: This detail is disputed.

Discussion

Ordering of live attributes: if a track is acoustic and live, I think it should have (live, acoustic, date: location) or similar appended to it, although this looks a bit clumsy. I am certain, though, that live should be before acoustic. Any nicer-looking suggestions? --MichelleW

This is a lot of text to burden the title with. I could see the usefulness on a bootleg, where it may be difficult to establish the information from liner notes/discographies (if any) but it seems like overkill for official releases where the information is more readily available through other means.

Perhaps a better way to handle this would be to extend the release data to individual tracks as well as release? (Although that only gives you country-level resolution on the location) --Dupuy

This proposal is partly to counteract the problem of having different live versions of a track on the same release. Often the tracknames get amended to "Trackname 1", "Trackname 2" or random variations thereof ("(1)", ", 1" etc.) I agree it's rather bulky though. --MichelleW

For jazz recordings it is quite usual to label them "(take 1)", "(take 2)" etc. so I would not mind that. Following the general idea of the StyleGuidelines such information should be in brackets and lower case. Isn't that enough? --DonRedman

I think separation of the venue and location is needed rather than commas delimiting both venue, city and country. I would also omit the state for the US, the city and country are suffice, the state is seldom included. Sometimes the day is not available, in those instances I would use 1970-04. --Dave

• I thought the state was quite useful for the US, since there's so many cities with the same name (Springfield, for example) --ZeroGravitas

For live tracks on a live release, I feel that putting the location, date, etc information in the release annotation is enough. Putting it in the track title would make it really bulky. Maybe something could be made as an add-on for release annotations for live albums, kind of what Dupuy was suggesting, for a release attribute per track, but in a (fixed) annotation form? --Sambalbij

• Release date != performance date. Sometimes if tracks on normal release where released before the liner notes say something like "all tracks released under blah instead of track X released under foo in (some date)". For this a release date would be correct but normally this is better done by linking this track to the original release via AR. So what we whould need if ever was a performance date/venue field. But I think this would be a little overkill. Annotations/comments are enough for this. And as we don't have this yet for tracks I agree that release annotations or this style guideline are the way to do it (with a small preference for the guideline but mostly I'd follow ArtistIntent on the covers). --Shepard

I agree with Sambalbij, location, date, etc information in the release annotation is EXACTLY where such information should go. In the case of a non-album track, than the information should be as simple (such as something simple as mm/dd/yy) as possible to prevent long file names. Dates and cities are NOT part of the name of the track. Its a note and should be treated as such. --BrianG

A thought: Windows Media Player says there's a "Recording Date" field. Not sure where venue would go, though. --MichelleW