For more about what the OP (me) is talking about, see the links above:
I mean “gapless” in the sense of the listener’s experience of playback of digital files, compared to the experience of playback of the original medium. The question here is specifically what extra information should be in a MusicBrainz Release entry in order to make a “gapless” playback experience possible. (Other things also need to be in place to achieve the “gapless” experience.)
Since the “gapless” I’m talking about here is the playback experience and the metadata in MusicBrainz, audio codecs which don’t alter the length of the audio are a necessary component for the experience, but aren’t part of what should be stored in MusicBrainz. A Release entry describes the original medium and release, not the behaviour of the audio file ripped from the original. There are plenty of codecs and settings which preserve the length of the original exactly, but there is still an issue for Release entries.
Again, a Release entry describes the original medium, not the playback software, so the details of the playback software aren’t part of what should be in the Release entry. However, the playback software may need information about the original medium — the length or absence of inter-track gaps — to be able to reproduce the original playback experience.
If the pauses between music were unimportant, then why did the Artist include them? Or choose not to include them?
This is an example of a “figure and ground issue”. The audible sounds are important, but the gaps, or the continuous play-though, are important because of how they separate or join the audible sounds. In general, for the player to reproduce the Artist’s intent, the player needs to know about the ground as well as the figure.
Imagine you are making a map of the US state of Hawai’i. It consists of 137 islands across 2,400 km. Is your map complete if it shows just the land area of the islands, without any information about the distances and bearings between islands? Surely it matters if the next island is 500km away, or is so close you can step across the gap. This is the same figure-ground issue.
In many cases it is not important. In come cases, it is. In many cases, the default behaviour of MusicBrainz and the rippers and playback gives acceptable results. In some cases, it does not.
Yes, exactly.
You are right, the details of playback software are irrelevant to the MB release.
Agreed, but I’m not sure I understand why this information would be relevant to MusicBrainz?
The gap at the end of a track is included in the lengths of tracks in MB. A piece of silence is as important as a few more bangs on a drum. And the lack of that silence especially important in gapless concept albums like Dark Side of the Moon.
But MB does not break down a track into components of how much drums, guitar and silence make up the track. The trouble is I cannot see any simple way of extracting this data from the mediums we have to hand. It is easy to get full track lengths (including gap) from our media players, but without sitting down with a stop watch on every CD and vinyl I cannot see where you get the lengths of the gaps from.
I read the first two links you supply and it is clear their problems are with their players and source of music. They are choosing the wrong kit and using services like Spotify. I stream music across my house from a KODI media server in gapless format without a trouble. No special kit required.
When I read the Wiki page I think I answer some of my question as to why it is not an issue for me. I rip to lossless FLAC using EAC and as noted on the wiki page all lossless audio file formats are inherently gapless.
IMHO “gapless” would be a candidate for the annotation or the disambiguation field, same as “mono” is used there.
iTunes actually has a gapless tag, at least for MP4. I am not entirely sure how it works, though. I think it disables iTunes cross-fading capabilities for tracks marked as gapless.
In general I think there are two separate issues here. One is what a lot of software players mean when they advertise gapless support. If you have separate files and just start playing the next file after the first ended you will add an additional small gap. If you have a CD ripped that has continuous audio without silence in between you will hear those small interruptions.
So a player supporting gapless playback will ensure the audio of the next file to play will be loaded slightly ahead of time so that it can consecutively send data to the audio output. This is one way to understand gapless support. In this most basic definition you might still have pauses in between tracks if the silence is part of the end or start of the track. If you have ripped your CDs with the silence included and you want to have them played back as they are on the CD this now works well. If there is a bit of silence between the tracks on the CD you will also get that silence on playback, if not it will be without silence.
Now players with gapless support can also sometimes detect and omit silence at the start or end of tracks. In this case you would get continuous audio even when playing back files that have silence at the end. If this is actually wanted everyone has to decide for themselves.
Now the problem as presented here is probably the most sophisticated: It 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. It’s for sure the most flexible, but I don’t know of a player supporting this.
The disc ID doesn’t tell you if there is silence in between or not. Also getting the length of an audio file can be (depending on format and encoding) surprisingly tricky and in some cases it is even just a good guess.
I think one question that needs answering is: is the “gapless information” something intrinsic to the release that can be determined ambiguously, or is it something calculated by the ripping software or audio player on the fly and does this information differ between different programs? The former could be interesting information for MusicBrainz to have, the latter isn’t.
This. 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. e.g. EAC adds the gaps to previous track by default, if not using the copy image option, obviously. How the files will be played by any given piece of software is another story entirely.
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.
If the question here isn’t about DJ-mixes/crossfades, but actually about silence between tracks, then the answer is a stronger “No” because
recordings with variations in the length of silence at either end of tracks are merged.
I don’t think how software rips the gaps is relevant to how the MB database stores information about a medium.
For me what’s more relevant is, is the information about the gaps on the CD’s themselves consistent and measurable. And as far as I know, yes?
Just based off EAC cue sheets, and how they’re considered accurate. Someone correct me if I’m wrong.
Non-CD media is in its own little universe in this regard I suppose.
Well the answer is yes but also no. On paper you simply read the Q subchannel of the CD and all this information is there in all its perfect digital glory.
Reality is more complicated of course. The problem is that we do this with PCs and PC CD-ROM drives are notoriously bad at reading any of this data from audio CDs without stupid errors, which is why EAC has multiple user-selectable modes for how this information is read from the disc, with multiple user-selectable “accuracy” settings. I’ve seen many bad rips over the years.
Quality checking this would be virtually impossible and given that this is useful mostly for compact disc players when actually playing a disc I still don’t really see why this information would be useful for a music encyclopedia? Without the rest of the rip, what would anyone even do with this information?
I think you cannot know, from any logs, if the CD is playing tracks continuously or not.
Whether INDEX 00 is placed 2 seconds prior to INDEX 01 or not, doesn’t change the fact that you won’t know if its content is silence or sound.
It’s just some information about the track content itself.
Like the genre or folksonomy tags, or like AcousticBrainz.
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?
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.)
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.
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.
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.
and,
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.
I can’t say I follow this reasoning. How does knowing how long CD pregaps are help you hear them as intended? Doesn’t that already happen when you put the CD in your CD player?
I think this scenario would benefit from a specific example of a track on MB, and a description of exactly what tags this information would be used to insert and exactly what effect that would have on real-world audio players.
MusicBrainz metadata is about digital music files played on a computer, not about CDs played in a CD player. Let me clarify my wording: “c) because it enables a useful listener feature: for the listener of digital per-track music files, on a music file player, to hear the absence of intertrack gaps — gapless playback — intended by the Artist.”
I think I answered this in my message above. From there:
Is that the sort of specific example you are looking for?
If there are no pregaps on the CD (other than the mandatory 2s track 1 pregap) then they certainly won’t be included in ripped audio files, so the nonexistent pregap audio will not be played, right? I’m still not getting why tracking CD timing information in MB helps playback.
If you rip the CD audio into separate files split according to the TOC track start timestamps, the result is that each track’s pregap gets appended to the previous track (and track 1 pregap would normally not be ripped at all so you probably don’t get HTOA). For sequential playback (starting from an arbitrary file) this is, for all practical purposes, the same as what you’d get from the real CD on a real CD player (starting from an arbitrary track).
Many formats such as flac can exactly represent the ripped CDDA structure via embedded cuesheets that include detailed track and index timestamps. I don’t use such files; TBH I’m not sure how much software exists that can actually simulate how a real CD player works when playing them.
I’m totally unfamiliar with this software, but this seems like an on/off thing and it does not seem like it would need any detailed timing information from the CD to set this tag? From your description, it seems to me that gaps or no gaps this tag needs to be set on any files that come from splitting a CD rip into 1-file-per-track in order for iTunes to play them correctly.
For Picard, since this tool only really supports tagging split tracks, this means that this tag should be set whenever the metadata indicates a CD audio track. I believe most if not all the needed information is already available to tagger scripts. I imagine something like $set(gapless,$ne($find(CD,%media%),)) (totally untested) should handle the vast majority of cases…
I’ll be honest, I think it’s been close to 2 decades since I’ve seen an audio player that failed to play ripped files back to back without delay. I thought this was a long-solved problem (obviously I am mistaken).
From what I know about CD I don’t agree.
CD are played continuously like cassettes.
There is no inter-track.
Everything is intra-track.
There are just markers (indexes) and the tracks themselves are also just markers placed on the continuous wave of sound (that can contain silence in whatever places but obviously often around the track markers, often between indexes 0 and 1.
I have authored myself such seamless play audio CD.
So really I don’t believe we should add the burden of gap management in MusicBrainz other than using disambiguation comments to prevent merging recordings that are not the same (additional silence at the beginning or ending is not a difference).
No, wrong. Many players, including the iTunes player I observed in my example, will leave a gap of a fraction of a second between tracks, unless the track has a metadata tag which tells the iTunes player to make the transition between tracks seamless.
When I say the player leaves a “gap”, I don’t mean something as long as a 2-second silent pause. I mean a fraction of a second, maybe 0.2 seconds. That is less than the conventional silence between tracks of a pop album, but long enough for the listener to hear a gap in the audience cheering, or a break in the music playing through from one track to another.
Again, not in my experience, with my players. The players I know insert a pause of a fraction of a second. Perhaps they are closing one music file and opening the other. So the practical use case is more about getting the music player to reduce a short break in audio to zero break, than about getting silence to exactly the right length.
And remember, not everyone rips files the way you indicate, with silence appended to the end of the previous track’s audio.
So it sounds like you are suggesting a workaround, to set a tag indicating that an album has no inter-track gaps, for every digital music file, even for albums which do have inter-track gaps. That’s an interesting hack. But it is not as clean as setting the tag only for those digital music files where it corresponds to the reality of the original album.
It may be that part of the difference is that we are operating on different definitions of “without delay”. Maybe you are disregarding a brief pause of perhaps 0.2 seconds? Maybe you aren’t testing with albums that have continuous through-playing music, where you might really notice a gap in the rhythm, or a hiccup in the middle of crowd cheers?