How to denote gapless audio in a MusicBrainz Release entry?

[IvanDobsky]

@marc2k3

Or you could stop pedalling horse poop about something you have no clue about.

Sorry, I was just going by the example the OP was using as he said his issues were coming from Apple Music sourced files being played back on his copy of iTunes. I know that iTunes is loved by many which is why this is a puzzle as to what Apple Music has done. I’d love to get my hands on those files he has bought and look at them in Audacity.

I was about to go and re-edit that opinionated bit in my post but a phone call appeared and you then beat me to it. I am certain that if iTunes had ripped that CD it would be gapless and no problems.

[draconx]

The OP said iTunes needed special “pregap” tags in order to play back ripped CDs correctly without introducing artificial delays between the tracks ripped from the CD, and that tracking detailed pregap information for CD releases in MB would somehow help taggers (Picard, specifically) produce these tags for files ripped from those CDs.

I disagree: if required, then the tags in question should simply always be set on CD rips for the technical reasons described previously as it was described to be an on/off thing. I believe taggers can do this with information already available on MB (medium format alone should handle most cases).

Now people are saying that iTunes does not need any such special tags for gapless playback of ripped CDs, which suggests we really don’t need this information for tagging CD rips.

I’ve never used this player, so I’m slightly confused now.

[Jim_DeLaHunt]

Again, thank you for all the discussion. It continues to twist and turn in many directions, but I think we are contributing useful information.

I would like to respond to discussion about music player apps and how they relate to gapless playback.

Some people experience gapless playback with their normal ripping and music playing apps. That’s great.

However, not all music players have this “gapless playback” behaviour.

I did a quick test of a few music player apps on one Linux system (Lubuntu) and one macOS system which I had handy, using the Apple Music m4a format music files of the Release The Ship, where the original LP and CD play continuously with no break between tracks.

On Linux, some apps played back gaplessly, some played back with gaps, and some just didn’t work very well. (I didn’t take note of the app names, sorry.)

On macOS, VLC 3.0 left short but definite breaks open in playback as it moved from one track to the next. I would say the breaks were 0.1-0.5sec long. This is not surprising, because gapless playback has been a missing but requested feature for 15 years, which may finally appear in VLC 4. (If you are getting gapless playback from VLC 3, you are doing well.)

Quicktime Player only opens one file at a time, and won’t open a sequence of files to play together, so it has no way of attempting gapless playback.

And, I must report that my earlier report about iTunes was incorrect. I reported that iTunes inserted gaps, until I added a tag pgap (which Picard calls gapless) to the music files; then iTunes played the files without gaps. I was passing on an observation by someone else, and they were using streaming services rather than iTunes in their initial test. iTunes (12.8, macOS 10.13.6 High Sierra) plays these music files gaplessly, by default, even without the pgap tag.

Thus, I now know that macOS, Windows, and Linux each have some music player apps which will play back an album’s worth of per-track music files gaplessly by default. And, I no longer have examples of major music playing apps which require special gap-related tagging to enable gapless playback.

Understanding this greatly reduces the value of adding metadata about inter-track gaps to MusicBrainz, because one can already get the desired gapless playback experience even without it. The value proposition is now only that the metadata describes true facts about Release layout on CD or LP or cassette media, and it advances MB’s mission of being the “ultimate source of music information”. That is not enough. There are many other MB improvements which also have these qualifications, plus deliver more user value.

That said, I have found out some interesting things about the CD-DA format, which responds to other parts of this thread. Those follow in a separate message.

[Jim_DeLaHunt]

@aerozol

…It’s so interesting to me how much of this discussion has turned to how software can deal with the rips… it doesn’t seem common for MB, which is usually always trying to represent the medium itself. I don’t really have a horse in this race, but I am quite surprised.…

I am not surprised. Over the years, I have seen a lot of MB features which are driven at their core by the desire for better Picard tagging or other forms of user value. The MB feature discussion is framed around representing Releases and Works themselve, because that is a wise way to design a database. But the motivation comes from the user value.

Consider:

• Advanced Relationships provide a way to describe who worked on a Release in ways that Album Artist and Track Artist can’t capture.
• Album and Track Artist credits deal with artist collaborations better than the old collaboration Artist system. It lets each Artist’s album list include the Release, and makes it easier for Picard to add multiple Album Artist tags for the collaborators to music files.
• Separating the Recording entity from the Track entity made it possible for multiple Releases to benefit from the work of adding performer relationships for one Release. Picard can better tag music files for all of the multiple Releases.
• Adding the Work entity made it possible for multiple Releases to benefit from the work of adding composer and lyricist relationships for one Release. Picard can better tag music files better for all of the Releases.

Keeping user value in mind is a great way to prioritise proposals for improving MusicBrainz. And user value often turns on specific apps and workflows.

[outsidecontext]

I think this has all been said, but maybe just to be clear on one thing:

The original questions was basically about how to get the playback experience with or without gaps as it is on the CD. Basically you want to playback an album that is one continuous stream of uninterrupted audio exactly like this, but if there are some small pauses in between tracs those should be there, too.

Now there is one wrong assumption: That tracks get ripped without the pregap included by default.

If the default would be indeed to exclude the pregap everyone would have had this problem the last 25 odd years of ripping CDs. You would think one would have come up with a solution.

And actually this is for most practical applications a solved issue: Include the pregap in the previous track. For most practical uses this totally solves the issue. Audio can be played back as is without gaps. No need for specific file formats with advanced features like indexes or special metadata support in players. It is also what makes sense if you have a digital download with separate files. It would be strange to have small inter-track files or something like this.

So this solution works good enough for most cases to a degree that probably most listeners don’t experience this as a problem at all as long as their player can technically do gapless playback.

There are of course limitations for this. E.g. if you have crowd noise and applause in the pregap this is fine if you playback the entire live album, but if the track is in a random playlist it can be annoying.

So I understand the original post more as a discussion to see if there could be a more sophisticated solution that takes care of such things and e.g. allows to more exactly specify such inter-track audio. But while I find this interesting as a theoretical discussion, but I also think that the current solution works well enough that there is not enough interest to change the implementation of current playback software and devices.

Not against having the ability to store such information in MB, though. More details about the actual structure of a CD, why not. If someone cares to extract and submit this it sounds fine to me. I just don’t believe it would help in any way for better(?) gapless playback in players.

@Jim_DeLaHunt

However, not all music players have this “gapless playback” behaviour.

Yes, absolutely. But this is a technical deficiency, no amount of metadata can change that. It’s not because the players insert some gap, but because they don’t take care to produce a continuous audio stream also on file change.