How to denote gapless audio in a MusicBrainz Release entry?

[IvanDobsky]

This thread is already on lots of tangents… so off down a rabbit hole the OP has picked on

@Jim_DeLaHunt

@IvanDobsky

So the gap is part of the ripped recording, and therefore already in the database.

I believe this is incorrect.

I have just been doing work on a strange compilation CD. It consisted of a bootlegger lifting lots of Album tracks. He then chopped the gaps from the ends of the tracks. And then trimmed the tracks agressivly by removing many intros and outros of the actual music. He was making a gapless release of tracks that originally had gaps between them, squeezing more onto one CD-R.

Playback of the rips of the original album had gaps between tracks. Playback of his compilation had music piled on top of music with barely any space between end of one and start of the next.

Due to this research I was listening to both tracks being played at the same time and then directly comparing times on my copies of VLC/Audacity and the MB database. This is why I was pointing to the gaps being in the ripped recordings. And it is these ripped recording times that get uploaded.

In this case I was also working from discIDs too. It was due to variations between the recordings and the original discIDs I dived into this. The discID times are the same ones as you see on your media player. These are the lengths of the rips that EAC produces.

@Jim_DeLaHunt

Apple Music supplied this album as *.m4a files without the pgap tag.

As noted with your earlier links, this is showing the problem lies with your source and choice of media player. You should nag Apple Music to sell you the music in the format the artist intended. This is not data that MB should be storing to make up for the failings in the source data.

Buy CDs, rip with EAC, playback with a decent media player and you will get your gapless perfection. I know that’s what I do with very little effort. (And I have far too many gapless albums)

@Jim_DeLaHunt

Again, not in my experience, with my players. The players I know insert a pause of a fraction of a second.

As repeated by many other people above - look at using a better media player. iTunes and Apple Music are the faults here. Geek software written by music geeks always handles things like Gapless better than a Mega-Company seller like Apple.

[IvanDobsky]

I am still curious as to how you suggest this data is retrieved. The only accurate way I can see of doing it is for every editor to upload their tracks into Audacity and then note the length of the gaps. A stopwatch is not going to be accurate enough to record the differing lengths of the gaps, and as pointed out above by @draconx there is nothing in the discID that actually notes the lengths of these gaps. The times in a discID used by MB includes the gap or lack of gap as part of the track length.

Being the kind of mad \ curious geek I am I’m about to reload a few tracks into Audactiy and double check the gaps at the ends, then compare to DiscIDs TOCs. just to double check my post above.

[Deleted_Editor_1801019]

Just for the sake of the argument: When ripped correctly in EAC wih cuesheet, the gaps should be visible in the cuesheet, IMHO.

[IvanDobsky]

Following my earlier post, I have been throwing a few tracks of an example album into Audacity to look at the gaps at the ends. The FLAC lengths are the same as the TOC lengths. And this example album (nsfw) is an interesting one as all the gaps are of differing lengths, and sometimes there is no gap due to all kinds of extra samples and content between the songs.

Just that one random example shows you can’t have a “per release” setting for “gapless”. And every gap is a different length. Also when is a gap a gap or just a quieter section?

Rip accurately. Problem solved.

Edited to add: Argh! CUE Sheets I was about to fire up EAC to generate a CUE sheet, and then remembered last time I looked at this. So instead I now run away and leave you with a help page on EAC and Gaps https://wiki.hydrogenaud.io/index.php?title=EAC_Gap_Settings

[draconx]

@Jim_DeLaHunt

When I say “track” and “gap”, I mean as ordinary listeners understand these terms.

The point is that normal CD rips split into tracks include all the pregap audio (except track 1) so all such CD rips are inherently “gapless” (that is to say: all such files should be played back to back without delay between them to reproduce exactly the original CD audio waveform).

Doing anything else requires special tools to dump and interpret the playback timestamps from the program area.

That’s why I believe tracking detailed CD program timestamp information in MB does nothing to help set this “gapless” flag in your tagger: the medium format is sufficient for the task.

@Jim_DeLaHunt

I am familiar with the technical CD structure and its terms “track” and “index”. Note that CD players … treat the sound between index=0 and index=1 specially. That is the part of the audio which I am calling “gap”.

This is not accurate: normal CD players do not give the pregaps any special treatment. The only practical difference the pregaps have during playback is how the timestamps are displayed (since the track timestamps during the pregap are negative, and some [rare?] CD players will also display the track subdivision index).

[Deleted_Editor_1801019]

You cannot discuss CD structure by looking at extracted files and calling the playback in a digital player “gapless”. That is comparing apples with oranges.

[jesus2099]

Well, the CD structure has been very very well described, I think, by @draconx already.
Now he addresses your issue of playing gapless files.

It’s really a matter of what encoder and player you use, IMO.
On Windows, I advise doing both ripping (LAME MP3 or FLAC) and playing with foobar2000, as it works.
I don’t have enough experience on other platforms to make advice.

It has little to do with MB, indeed.

[Kid_Devine]

@Jim_DeLaHunt

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.

iTunes should transition seamlessly from one track to the next, regardless of any metadata tags. Here are a couple of things that may be preventing seamless transitions:

1. Make sure that Crossfade Songs is turned off (check under Preferences > Playback).
2. If you are checking transitions by jumping to the last few seconds of a track, the software may not have time to pre-load the start of the next track. Try giving it 10 seconds or more.

[outsidecontext]

@Jorgosch

You cannot discuss CD structure by looking at extracted files and calling the playback in a digital player “gapless”.

Well, this needs to be part of the discussion. As I wrote above the ability to playback multiple audio files without introducing a short artificial pause is exactly what many players mean when they advertise to support gapless playback.

And actually for many users that is all they need to be able to playback their CD rips exactly as they experience the CD. That’s because default rips always include the pregap of the next track in the previous track.

@Jim_DeLaHunt

I expect that most CD ripping software would give me 10 audio files from both CDs. It would omit the silent gap at the end of tracks 1–9,

This is a wrong assumption. Most ripping software includes the pregap as explained above. See also the excellent EAC page @IvanDobsky linked above . For many simpler rippers it is the only mode. And actually this is also how digital downloads are usually done.

It makes sense, because otherwise you would have missing silences or even missing audio in between.

That also means that the majority of users don’t have this issue at all. It just works as expected. You only get into this trouble if you rip without pregaps. And I think this alone explains a lot why many above doubt the need for this

[aerozol]

@outsidecontext

You only get into this trouble if you rip without pregaps. And I think this alone explains a lot why many above doubt the need for this

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. Or probably just not quite understanding the discussion.

On a basic level: If it is recommended to rip with a cue sheet for the most ‘accurate’ representation of a CD, why would it not be helpful for MB to store (for instance, for the most basic comparison) this cue sheet?

[Deleted_Editor_1801019]

Cue sheets can be a valuable source for track lengths and ISRC codes.

[outsidecontext]

@aerozol

It’s so interesting to me how much of this discussion has turned to how software can deal with the rips…

It’s how the discussion started: How, if you have files ripped without the gaps, can one tell a player to add gaps? Maybe there are some tags for this? Could this be stored in MB to make it available to taggers? It’s not surprising that the following discussions circle around the technical details of CDs, rippers and players then

[IvanDobsky]

@aerozol

On a basic level: If it is recommended to rip with a cue sheet for the most ‘accurate’ representation of a CD, why would it not be helpful for MB to store (for instance, for the most basic comparison) this cue sheet?

I was going to suggest that uploading a CUE sheet would solve the question. And then started to re-read that EAC link I posted a couple of replies back. There are at least three types of CUE sheets - gaps before a track, after a track or part of the track. And the default one that EAC puts out doesn’t include these gaps as the gaps are already in the ripped music files.

@outsidecontext

How, if you have files ripped without the gaps, can one tell a player to add gaps?

You can’t because the gaps are different for every track, even on one album. Only if a ripping tool has been altered to not rip gaps and then a CUE file supplied with those gaps listed separtely. And then you could reassemble music and gaps separately.

Or just let the decent ripping tools deal with gaps and gapless playback like that have done for years.

[Deleted_Editor_1409249]

Thread like this are a prime example of why cue sheets shouldn’t exist. They serve no purpose and complicate things far beyond what most people understand. When CDs are ripped properly (gaps appended to the previous track as silence), there is no need and you have a perfect audio copy (so long as the files are lossless and you use a competent ripper!).

These can always be compared to original CDs using tools like foo_bitcompare for foobar2000 or you can perform online lookups against what other people have ripped to make sure it’s bit for bit identical. See AccurateRip, CUEtools database etc.

[Deleted_Editor_1409249]

@IvanDobsky

Or just let the decent (non-Apple) ripping tools deal with gaps and gapless playback like that have done for years.

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

I hate Apple as a company but they’ve done the right for many years regarding gapless playback - at least with Apple Lossless and AAC. Long before the iphone was ever a thing, ipods were probably the only mainstream portable devices that had proper gapless playback support when used with AAC files.

[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.