Great discussion, everyone! But it’s going in lots of different directions, so it’s hard to reply to every comment. Here I’ll pull together a thead about: does metadata about inter-track gaps belong in MusicBrainz?
Thesis: the content of a CD or LP audio signal consists of tracks and inter-track gaps. They are different kinds of content. Artist Intent determines where the tracks start and stop, and whether there are inter-track gaps, and whether those gaps are silent or have audible content. Metadata describing the gaps is in scope for MusicBrainz. Having it would provide concrete, practical benefits for certain use cases. There ought to be an optional way of describing gaps as part of a Release entry.
What kind of Releases will find gap metadata significant? It is Releases where the Artist decided that the content of one track should follow the content of a preceding track with zero pause, seamlessly, so that for example a musical beat is not interrupted. There are several examples of such Releases in this thread. They tend to be concept albums, live recordings, opera, and classical music works (if much longer than pop songs). I’m willing to believe that gap metadata will not be significant for most Releases in MusicBrainz.
To clarify:
Crossfade (a Release where the Artist records a crossfade from one track into the next, but still labels the two tracks as different, rather than as one long track) is not my use case, but it is one of the use cases where the absence of an inter-track gap is significant information. (If my reference to an enhancement request about “Crossfade” in my first message confused the discussion, I apologise.)
I read this as evidence that the Artist and the CD player designers consider inter-track gaps to be a different kind of content than tracks. The Artist uses the CD format to indicate that the crowd noise (starts at INDEX=00) is not part of the track proper (which starts INDEX=01). The CD Player jumps to the start of the track proper (INDEX=01) when shuffling, but plays track, then inter-track gap, then next track, when in consecutive order.
I read this as more evidence that the CD format designers recognise inter-track gaps (from INDEX=0 to INDEX=1) as different from track content (from INDEX=1 to start of next TRACK). During the inter-track gap, the timestamps are negative. When jumping to a TRACK, the CD player goes to INDEX=1 instead of INDEX=0.
And note the use of that term “pregap”, because:
If someone rips a CD this way, then the CD’s “pregaps” become the music file’s “post-gaps”, and are attached to a different track. This says to me that they don’t belong to either track. It makes sense for MusicBrainz to describe them as entities separate from either track.
And, different rippers behave differently, and are configured differently. We should not base MusicBrainz handling of inter-track gaps on one way of using one ripper, to put gaps at the end of the previous track’s file. And, digital music files bought as digital media likely will not have silent gaps appended to the end.
I believe this is incorrect. The track length in the database is not defined as the length of audio in a digital music file. It is whatever length Picard uploads via a TOC file, or whatever length a user types in by reading a listing on the back cover of the Release, or from a web store’s listing. I expect only some, maybe none, of those values will include the duration of an inter-track gap. A user typing in a track length based on the audio duration of a ripped music file is probably a small fraction of the cases.
By the way, apparently Discogs agrees that inter-track gap duration is not part of the track.
I think this confuses Releases with Recordings. They are different. A Recording describes the contents of a Track, not of inter-track gaps. The Release has a tracklist with separate track durations from the durations of the linked recordings. Multiple Releases using the same Recording might all have different Track durations, for valid reasons. The inter-track gaps are a property of the Release’s medium, and won’t propagate to the Recording entities. And by the way, the fact that a Release (= Track contents) disregards silence at either end points to the inter-track gaps as being a different kind of content than the tracks.
The most useful metadata about inter-track gaps is: a) gap is absent, b) gap is present and silent, c) gap is present and has audible content, or d) no information about gap (the default). This is something which a human could determine with high reliability by just listening to the Release on CD or LP or cassette media.
It could also be determined by something like an enhanced libdiscid or Picard tagger, but I wouldn’t base a proposal for this metadata on an enhancement like this. It would be useful simply with human input on those Releases where gapless playback mattered to the Artist.
What about finding inter-track gap metadata from the Disc ID?
and,
This is a factual question. Someone could read the MusicBrainz server code which creates a Release Entry based on a Disc ID, and see if it is aware of inter-track gap information. But the answer appears to be “no”. The Disc ID Calculation article says the disc ID is based only on the CD’s internal track-start addresses, with no information about INDEX=0 or INDEX=1. And,
So, let’s assume that present mechanisms don’t provide any automated way to get information about inter-track gaps. The only way to enter it will be for editors to do so manually. That means that for the foreseeable future, inter-track gap metadata will be entered by humans, and only where it makes a difference. In addition to allowing metadata on inter-track gaps, MusicBrainz needs some reasonable default assumption about inter-track gaps in the absence of metadata, and absence will be the usual case.
I disagree with this view. The silence is an inter-track gap, a piece of content distinct from the tracks. Whether someone’s ripped file contains the silence is not a question for MusicBrainz metadata design.
That’s interesting Let’s think about the inter-track gaps of the LP medium for a moment. The gap before track 1 of an LP is probably silent by definition, because once the audio begins, we consider track 1 to begin. The gap between tracks has a physical purpose, to let the person operating the turntable see where to put the needle to play a specific track. And unlike a CD, an LP has a usable gap after the final track. It spirals into an inner self-connected groove. It is normally silent, but I have heard audio in this gap used for artistic effect by Monty Python and others. Metadata on inter-track gaps should be able to describe LP and other media, not just CDs.
I think it is still quite feasible to have simple metadata about whether inter-track gaps are present or absent between tracks of an LP. (I don’t know if it’s reasonable for an LP to have a gap with audio, because the gap is measured mostly by silence. One could look for the different colour of the groove in the gap, I suppose.)
What about storing gap metadata as an annotation, instead of as structured data?
and,
Yes, editors can put anything into a Release annotation, including gap metadata. But part of the value proposition is that gap metadata be visible to taggers, so that they can tag music files, so that players provide a gapless playback experience. Taggers cannot read annotations reliably. Thus, to deliver value, this metadata deserves to be structured in the database.
Because a) it is part of describing the Release fully, b) it advances MB’s mission of being the “ultimate source of music information”, and c) because it enables a useful listener feature: for the listener to hear the intertrack gaps intended by the Artist. Here’s the scenario: MB stores metadata that inter-track gaps are included or not included in the Release. A tagger uses this metadata to include or not include a “gapless” tag in digital audio files ripped from that Release. A player uses the “gapless” tag to either do special work to read in the next file before the previous file finishes playing, or to allow a gap. (Some players apparently do this special work for gapless playback all the time. But some need the tag: I’ll post separately about that.)
iTunes actually has a gapless tag, at least for MP4. I am not entirely sure how it works, though.…
I think I know. The MP4 format defines a tag pgap
, which Picard calls gapless
. If present in a sequence of m4a
files, the Apple iTunes player, when playing those files, provides a gapless listening experience. I just put this to use: the Release The Ship was authored with no inter-track gaps on either side of the LP. Apple Music supplied this album as *.m4a
files without the pgap
tag. iTunes played it with short, fractional-second but noticeable, gaps between tracks. When I used Picard to add gapless
tags with value 1
, iTunes played these files gaplessly, as the Artist intended.
[OP proposal] would allow you to either already rip the audio without silence or have the player remove the silence, but then opt-in per file and maybe depending on the playback (album playback or random shuffled playlist) to have the player add a small gap again.
No, I’m not going that far. The value of allowing metadata about inter-track gaps in MusicBrainz is primarily to let Picard add tags to music files for Releases that have no intertrack gaps, to encourage players to provide the correct gapless playback experience. This would be a simple enhancement for Picard. The feature you describe — having players add a small gap again — is possible, but it’s not the primary value is see from the metadata.
By the way, @outsidecontext, you gives a really good summary of the thread here. Thank you.
There may be gaps between the tracks on a CD, the gaps can contain audio or they can be totally silent. How gaps are ripped is totally up to the ripping software.…
Standalone players start playback of any track from the INDEX 01 position defined in the TOC, and continue towards the end of the media unless instructed otherwise. There is no skipping or even detecting of any gaps.
Trying to denote ‘gapless playback’ somehow on MB is uttely pointless, IMHO.
How gaps are ripped is not the concern of the MusicBrainz database. But inter-track gaps should be. These gaps exist on CD or LP medium because the Artist put them there. They exist whether the medium is ripped or not. And I argue it is in scope, and useful, for MusicBrainz to be able to store metadata about them.
Standalone CD or LP players are not part of the value proposition for this metadata. The Artist authored the medium with gaps, or without them, based on how those players play the audio continuously. Instead, taggers and players of digital music files are what benefit from this metadata — by letting the tagger pass on the metadata about the Artist’s desired playback experience, and by letting the player deliver that experience.
I wonder what all the fuss is about. MB is about identifying music, not pauses between music.
and,
If I may sum up the discussion how I understand it: It’s structure of a CD vs. content of a CD. Which of these is MB striving to preserve?
I think this is the wrong way to frame the question. MusicBrainz "collects music metadata… [and] aims to be… The ultimate source of music information". Metadata describing structure of a CD is in scope. Metadata describing the content of a CD is also in scope.
For example, MusicBrainz has a way of noting which person was producer for a release, and whether two Releases re-use the same Recording. That is metadata about content, not about structure.
Whether you call inter-track gaps “structure” or “content”, metadata about them is in scope for MusicBrainz.
Interestingly, I can’t find anyplace where the MusicBrainz documentation specifies what the track length field means, or how to determine track length. It’s probably one of those things which is so apparently simple that it’s easy to overlook its hidden complexity.
Sorry this has turned out so long. Thank you for all the discussion.
Given all this discussion, I now am firmly of the opinion that metadata describing the inter-track gaps of Releases is in scope for MusicBrainz. Having it would provide concrete, practical benefits for certain use cases. There ought to be an optional way of describing gaps as part of a Release entry.