HTOA/pregap tracks (AKA track 0)

[pdf]

MusicBrainz now appears to support HTOA/pregap tracks in the DB, it would be good to be able to support them in beets. Currently beets wants to either rename or drop these additional tracks.

[sampsyo]

Can you make a proposal for how beets could better handle this kind of track? What should we do that would be better than renaming or dropping?

[pdf]

There's now an optional <pregap> element available on the recordings for a release. The <pregap> element(s) appears at the top level of the <medium> (outside the <track-list>), and it's attributes/elements are equivalent to a <track> element.

This is slightly complicated because not all drives can rip HTOA, so not all rips will include it, but with the popular tools on a supported drive, it should be ripped to a separate 'track 0' file.

I think the simplest proposal would be to generate two matches for any release that includes a pregap - one that includes the pregap track, and one that doesn't. This should present the highest likelihood of a good match, even in the case of multiple media where one of the media is missing from disk, and it allows the user to select the best match. Doing it this way means the matching code doesn't need any modification either.

EDIT: here's an example: http://musicbrainz.org/ws/2/release/fa2abd91-f698-4935-980b-9a7f55444899?inc=media+recordings

[sampsyo]

Aha! Thanks for the extra background; this really helps. Indeed, it seems like the MusicBrainz data source should produce pregaps as extra TrackInfo objects, perhaps with a new flag along the lines of inessential as proposed in #1089.

[ruippeixotog]

I stumbled today with this problem when importing this album (API result here). Is there any timeline for adding this feature?

I agree with @pdf suggestion about generating two matches as to account for drives that doesn't support ripping HTOA. But meanwhile, I think that the most correct behavior for beets would be to treat pregap tracks as other normal tracks. While users with missing pregap tracks could still import those albums with just a missing track "warning", users with pregap tracks wouldn't have to drop them completely or manually import and tag them.

Personally, I consider pregap tracks important and I would take them as missing if I didn't have them, even if it was for hardware reasons :)

[sampsyo]

Just including the tracks does seem fine to me. There's no specific timeline, but contributions would be appreciated!

[ruippeixotog]

Ok, no problem, I'll see what I can do :)

[ruippeixotog]

Musicbrainzngs doesn't return pregap tracks yet - I just did a pull request adding support for them. Once that is merged I already have Musicbrainz working with pregap tracks, but I suppose it'll have to wait until a new version of musicbrainzngs is released...

[sampsyo]

Awesome! Maybe we should add support to beets now, but let it detect whether the data is present. That way, well be ready when the new version of the library is out (or if people want to run it from git).

[ruippeixotog]

Ok, I did pull request #1493 for that then :)