Non-numeric track indices

[awesomer]

When using the [P] option from #1689, I noticed this discrepancy :

1. Ride My Junk (Squarehead mix) - Waze & Odyssey (6:37)
2. Ride My Junk (Chamboche remix) - Waze & Odyssey (7:48)

vs. existing mb tracklist :

A. Ride My Junk (Squarehead mix) - Waze & Odyssey (?:??)
B. Ride My Junk (Chamboche remix) - Waze & Odyssey (?:??)

http://musicbrainz.org/release/af714e5d-6cbb-497e-a495-868141eff541

I spoke briefly with sampsyo about it, he said that I should file this issue, to request support for non-numeric track identifiers :

1. in the database
2. in tags for formats which support them (ie, not mp3)

[sampsyo]

Yep! Sounds reasonable. It's of course contingent on file formats supporting this kind of data. Another thorny issue is how we'd support both the common case (numbers stored as actual numbers, sorted numerically so 10 appears after 9) and the non-numeric case (stored as strings, sorted as strings, queried using substring search, etc.) without confusing the two.

[diego-plan9]

Sounds like an useful addition indeed! Some preliminary look at the specifications (help would be appreciated in checking the rest of the formats):

• ID3v2.3.0 seems to specifically restrict it to numeric, or at most numeric-with-a-slash-in-between.
  (As a side note, playing around with mutagen allows to enter any string in the TRCK, saving the file without complaints. I'm not sure it's a good idea to differ from the standardand if other popular players/software would choke, though).
• FLAC does not seem to have a strict tags standard, although for the suggested TRACKNUMBER field, it states (a bit loosely):

The track number of this piece if part of a specific larger collection or album

Leaving aside the database/ordering/confusion considerations raised by @sampsyo on the previous comments for a moment and going back to the Print tracks option, I'm wondering if the problem of fully automatically assigning vinyl track numbers during printing when the original files do not have vinyl track numbers is fully solvable: @awesomer, could you let me know if it is common that each side of a vinyl is stored on a separate folder, or for the files it to contain enough information to find out when each side starts?

I have little experience with vinyls, but I believe that both sides of a vinyl are usually considered the same medium (on MB, etc) - ie. a vinyl with 2 tracks on side A and 1 on side B would be listed as one medium, with tracks labelled A1, A2, B1. Might be just a matter of appending a prompt during printing for allowing the user to chose where to "split" the sides, in any case.

[sampsyo]

Here's another idea (I haven't checked yet whether any other software does this): Keep the track-number field numeric, for ordering purposes, and invent a second field for the "human-readable" version of the track number. This would be a string, and it would be solely for cosmetic purposes---sorting and querying wouldn't be affected.

[awesomer]

In general vinyl "rips" in the wild have been tagged with artist, track name, release name and the files intrinsically have durations. They usually have track numbers, even if those are all "0", arbitrary numeric or the correct non-numeric or alpha-numeric designations. I think this is our best chance during this pre-import phase.

It is, in my experience, rare for files to have subdirectories per side. Also, as you say, in MB both sides of one vinyl are a single medium.

Per #musicbrainz IRC, Vorbis and ape2 allow for anything, while "qt comments allow numbers only but for some reason can store them" such that iTunes "won't display them, but it will sort properly". Per the same person, "all the casette/vinyl rips I have have tracks named A, B or A1, A2, B1, B2."

[diego-plan9]

Thanks a lot for sharing your impressions and for taking the time to contact #musicbrainz via IRC, @awesomer! It helps me getting a better picture of the vinyl "conventions" and it's a great pointer towards filling up the file format support list.

Here's another idea (I haven't checked yet whether any other software does this): Keep the track-number field numeric, for ordering purposes, and invent a second field for the "human-readable" version of the track number. This would be a string, and it would be solely for cosmetic purposes---sorting and querying wouldn't be affected.

I like the idea, if only because modifying the existing track DB field sounds a bit daunting. I'm wondering however how it would play in regards to the files tags: would it imply replacing their existing "tracknumber" tag with the new "humantracknumber", or just keep using numbers in the "tracknumber" and maybe add a custom tag with the "human-readable" info? From the looks of it, it looks that the order would be preserved - but it might be not safe to assume that other applications won't try to revert their "tracknumber" tags back to numeric, maybe causing some problems when reimporting or similar commands.

[mikeacameron]

Anything obvious from not adding another field called alt_track_pos and populating the field with whatever data is retrieved from MusicBrainz or Discogs?

For example, here is an XML snippet for track Near Dark by artist Agathodaimon.

<track id="bd4305d4-4b24-3e4d-b1bf-37e0636a34d5">
    <position>7</position>
    <number>B2</number>
    <length>948000</length>
    <recording id="2e7093c9-38f0-4e83-872c-e5ccd4b29d21">
        <title>Near Dark</title>
        <length>948000</length>
        <artist-credit>
            <name-credit>
                <artist id="f6dad765-8c0b-4256-b8d1-c1818b31bbdb">
                    <name>Agathodaimon</name>
                    <sort-name>Agathodaimon</sort-name>
                </artist>
            </name-credit>
        </artist-credit>
    </recording>
</track>

And here is the same track retrieved from Discogs in JSON.

{
    "duration": "15:37",
    "position": "B7",
    "type_": "track",
    "title": "Near Dark"
}

Putting aside the difference between both sources using different track positions (e.g. B2 vs. B7) - if there was another field added to the items table in the database and another property added to class beets.autotag.hooks.TrackInfo, then the user could freely choose whether they would like to format tracks using the index (default) or the new field template value.

MusicBrainz would use XML value number and Discogs would use field position instead of calculating the track index like it is now.

Thoughts?

[mikeacameron]

I forked master and managed to fairly easily implement this with using MusicBrainz as a source. Ignore the whitespace changes - I'm on Windows.

mikeacameron@0d68a12

[sampsyo]

Cool! Perhaps you could open a pull request, @lengtche?

[mikeacameron]

Looks like this can be closed now?

[sampsyo]

Yes, thanks!

[awesomer]

While the original request asked for support for Musicbrainz and Discogs, I'm fine with Discogs support being the request of someone who uses the Discogs plugin. :D

thanks to @lengtche for the contribution! awesome!