Fix disc number mess

[derat]

I've noticed that a small number of songs (from albums) have their Disc field set to 0 rather than 1 in datastore. I think that these are (mostly) limited to songs that I reimported last year to rewrite their artist names (see #18). I was very confused by this:

• Older songs have Disc set to 1.
• Newer songs have Disc set to 1.
• I don't think I've made any changes to nup update or to the server code that would automatically remap 0 to 1 when songs are imported.

My workaround for this was to make "first track" queries use Disc <= 1 (see d1abc3c), but this has the unfortunate effect of using an inequality filter, requiring extra composite indexes in datastore (see #35).

ID3v2.4 (and v2.3) store the disc number in the TPOS frame:

TPOS
The 'Part of a set' frame is a numeric string that describes which
part of a set the audio came from. This frame is used if the source
described in the "TALB" frame is divided into several mediums, e.g. a
double CD. The value MAY be extended with a "/" character and a
numeric string containing the total number of parts in the set. E.g.
"1/2".

Looking at this more closely, I think that there must've been a change made either to MusicBrainz or to Picard sometime around 2014 or 2015 to set TPOS to 1/1 for single-disc releases. Some files timestamped 2014-09-01 don't have TPOS frames, but other files from 2015-10-23 do.

As for why the old files have Disc set to 1 in datastore even though they don't have TPOS frames, my current theory is that all of those were just imported from an older SQLite database and never actually scanned by nup update.

[derat]

Before I understood what was going on here, I started retagging some files so they'd have TPOS frames, but I now see that there are thousands of files that are missing TPOS. I could retag and reupload just the files that have Disc set to 0 in datastore, but I don't really see much benefit from doing that.

I think I should probably add something to nup update to try to identify files that should have TPOS but don't and set Disc to 1 automatically, and then use that to fix the songs that have currently have 0.

[derat]

This is still a bit strange, as I have various miscellaneous files with their album set to [non-album tracks], MusicBrainz Album Id set to a (deleted?) MBID, and a non-zero track number. When I load these files in Picard, it looks like it wants to remove the release IDs and track numbers:

I don't seem to be able to load these MBID from the MusicBrainz site -- presumably they've been deleted. I'm not sure exactly what changed here and couldn't find anything in the MusicBrainz forums, but I think that non-album tracks used to be listed on the site (which is presumably where the track numbers came from). IIRC I was taking advantage of this to set a "default" cover image for these tracks.

I probably won't bother retagging the files, but it seems reasonable to make nup update avoid automatically setting Disc to 1 for files with the album name [non-album tracks].