History:Performances And Recordings Proposal
|Status: This page describes an active proposal and is not official.|
For many, if not most, Releases it is often useful to document information about the location and time when a the music was recorded. This is especially important for performance-oriented types of music, including concerts, classical or modern, Jazz performances, etc. It is also relevant, though in a slightly different way, for studio-recorded albums.
Enter below a list of features that will be needed to document "recorded at" and "performed at" information.
This point needs a bit of discussion.
Songs are generally recorded in two different (but sometimes overlapping) ways: the "live" recording, which generally means the track or song was recording during a single, continuous performance, usually in front of public; and the "studio" recording, which happens usually in specialized locations, with many different takes, maybe with instruments recorded separately in both time and space. (There are situations where for a single song instruments are recorded in a studio, vocals in a different -- presumably specialized -- studio, and an orchestral track is recorded again elsewhere -- maybe a concert hall -- and the many recordings are mixed together later, in another specialized studio.) Often a combination can be made: a song may be recorded live, but some instruments may be recorded later in a studio and added to the "album" release.
End-users usually view the two processes differently. This proposal uses "performed at" for songs played live and "recorded at" for studio-recording; it tries to use both ("recorded/performed"), for the general "put music to physical support" sense, but some errors may slip by. If someone has a suggestion for some other terms, to clarify this ambiguity, please post a note in the Discussion section below.
I briefly considered that the wording used in the interface be picked according to whether the track is "live" or not. However: (1) We don't have yet a clear way to record this info for a song. (2) The "live" release attribute can be misleading, as some live albums sometimes have studio-recorded bonus tracks. (3) The "(live)" track annotation needs parsing, which can cause slow performance and maybe confuse the scripts. (4) There's always the case where a track contains both material performed live and recorded in the studio.
Thus I propose the events have a field to pick between the two. So when adding a new recording, the user must pick between the two. However, in this case we can use guessing (based on the release attribute and the track name), because that's only done at edit time and the user can check.
There is a very useful distinction between a release recorded "together", e.g. a concert, and releases where tracks have been recorded separately. (This can mean studio albums, live collections, and probably other things.) Both views are very useful, and I suggest we need both per-release and per-track "performed/recorded events".
For both track and releases, there may be several recordings. Thus the recording/performance would be potentially multi-valued, just like the release events; however, the semantic is different: an album may be released several times, but several recordings may be used on an album.
The per-release events should look very similar to the "release events" that we have right now. I propose to add rows below the "release events" rows.
The per-track events should look similar to the way track ARs are presented right now.
- A concert recording (live album, bootleg) will have a single row below, with the recording date & location.
- A live album released after a two-day concert may have two rows below, with two different dates. If enough info is available, each row may have a short comment stating which tracks come from which date.
- A live VA album (say, bands that played at a festival) may have a recording interval below, with the date of the festival, and one below each track that specifies the exact date when it was performed.
- A live compilation album (live tracks played by a band during its career) may have no recording date below, but have one under each track -- or at least those where the info is known.
- A studio album may have several interval-dates below, each marked with a comment. For example, "recorded at X concert hall, 1994-04-07 to 1994-06-01 (orchestra)", "recorded at Y studio, 1994-5 (vocals)", "performed live at Z stadium, 1994-01-05 (band)". Some or all tracks may have more precise dates, depending on information available.
- A track may have been simply recorded at several moments or during several intervals. It will have an AR for each.
Some recording events, especially live performances, are anchored in a single precise date in time, the day of the concert. For others -- e.g. festival-albums or studio recorded-tracks -- there may be an interval. Thus, we need two date fields; the user will be able to fill in one or two, depending on what makes sense. Note that a single "month-only" date can also denote an interval, or at least a fuzzy period; this is popular on some kinds of liner notes.
It needs to be decided if we allow such entries without a date. It is conceivable that the venue is known but not the date -- not even the year -- for a certain recording; however, this is probably rare, and not requiring at least a fuzzy date (year or year-month) may encourage users to be lazy. This is not a problem for some (hard-core discography buffs) but may be for one-time users adding a bootleg.
Another interesting question is whether or not we need times: for a track live recording it is perfectly conceivable that the exact interval interval the track was played be available down to the second, but will this ever be useful?
In cases where a track or release is recorded in several venues, there will be one recorded/performed event for each venue, either with a generic date ("August 1994") for both or with different, precise dates for each, depending on information availability.
Because many releases or tracks will have several recorded/performed events, we'll need a field to enter clarification, when possible. I believe a fixed-value field is not sufficient, so I propose a free-form text field similar with the "comment" field we have for Artists and Labels. However, there's no reason to make it obligatory, or to forbid it for objects with a single event. (Example: an album may have a live concert and a few studio "bonus tracks". It will have one performance event, with the mark "except tracks 8-11".)
For some kinds of recordings, another important information is the person who did the recording, as opposed to actually performing the song. This is usually the "recording engineer", or the "recorded by" role. Most often this is encountered for studio albums.
We already have a "recorded by" relationship, but it only contains the dates, not the location. Also, many recorded/performed events don't have such information.
I am tempted to suggest that we keep the two separate, ignoring the slight duplication of dates. However, it could be a good idea to include this information in the "recording" events, as an optional field that is filled-out when appropriate. Many albums have a "Recorded, mixed and mastered at [the X studio] between [date] and [date] by [someone] and [someone else]."
The obviously leads us to further complications: There are other events to record at the same time besides recording, despite the fact that mixing and mastering dates rarely get more detail than above. (An obvious exception are "remaster" releases.) Also, there is a further problem with having several people on the same event (two engineers, maybe a co-engineer), which can complicate issues immensely.
On the other hand, we could simply split this proposal into:
- Adding a "performed at" event, with everything described above this sub-section, which should be relatively simple and generally useful, and
- Extending the ARs with a "[x-ed [and ..]] by [y [and ...]] at [z] between [t] and [v]", which covers any role like "recorded", "mastered", "produced", "mixed", etc. This could be quite complex, though.
We need to decide how recording/performance info will be for users editing and viewing the data.
I propose that release-level recording/performance info be edited and presented exactly the same as the release-date info is edited and presented now, by an additional row below the "release date" fields. Thus an album may have several release dates; live albums (and studio albums where info is available) will have one or more performance/recording dates; bootlegs will have (usually) no release dates, only performance.
For track-level information, I propose an edit interface identical with the way ARs are edited right now. A new "add recording info" button/link might be a good idea though for starting the edit, as the object-to-object way of adding ARs is probably too clunky for track-to-venue links. The display would be similar to the way ARs are displayed right now: below the track in the release view, and in the AR box in the track view.
This proposal has LocationProposal as a prerequisite, thus we need location objects first. (Alternatively, we could just use a text-field+country for the location, but that would be more error-prone, cause lots of duplication for popular location, and would not allow looking at all concerts in the venue.)
Without the "recorded by" information, this proposal can be implemented the same way "release info" rows are implemented currently. This includes automatic ARs from labels to releases turning into ARs from venues to performances/recordings.
The "recorded by" information can complicate issues a bit:
- From the database point of view we could extend the "recorded by" AR to be, in addition to "person -> track" and "person -> release" (where 'person' is the engineer), also "person -> recording_date", but the UI needs to be thought out carefully. There are complex possible situations where can have (say, for an album) a single recording engineer but many recording events (say, a live album after a 20-concert series, with each track recorded elsewhere), or a single recording event with many engineers, or both. It might be useful thus to have "record events with recording engineers" for some releases, and "per-track record events without engineers plus per-release 'recorded by' ARs".