Track number odd behaviour with a multi-disc album

[ac16161]

Just downloaded an album from HDTracks that was originally a double CD. Tracks 1-19 have a disc tag=1 and tracks 20-32 have disc tag=2. They are all in the same album folder.

When viewed in Kinksy, the tracks show as 1-19 then the numbers jump to 39-51. I played with the mergefolderalbums property and it did not fixt it. In the end, I edited the disc tag for tracks 20-32 to 1, then on a re-scan all was fine in Kinsky. Has minimserver got confused due to the track numbers not starting at 1 for the "disc 2" tracks?

One other small point: I was surprised after another download that "MIKA" and "Mika" were regarded as separate artists. Is case-sensitivity deliberate?

Thanks.

[simoncn]

(20-06-2015 11:17)ac16161 Wrote:  Just downloaded an album from HDTracks that was originally a double CD. Tracks 1-19 have a disc tag=1 and tracks 20-32 have disc tag=2. They are all in the same album folder.

When viewed in Kinksy, the tracks show as 1-19 then the numbers jump to 39-51. I played with the mergefolderalbums property and it did not fixt it. In the end, I edited the disc tag for tracks 20-32 to 1, then on a re-scan all was fine in Kinsky. Has minimserver got confused due to the track numbers not starting at 1 for the "disc 2" tracks?

MinimServer is not "confused" but is working as designed. It is normal for the tracks on disc 2 to be tagged as disc 2 / track 1 / track 2 etc. and MinimServer is allowing for this by adding 19 to all the track numbers in disc 2.

Quote:One other small point: I was surprised after another download that "MIKA" and "Mika" were regarded as separate artists. Is case-sensitivity deliberate?

Thanks.

It is deliberate. If MinimServer were to automatically combine "MIKA" and "Mika", it would not be able to know which of these spelllings you want to be used for the combined artist.

[ac16161]

Thanks, I think the root cause here is the slightly peculiar authoring on the tags. However, could the track counter coding get round this by only incrementing the disc 2 track numbers if the lowest disc 2 track number is not greater than the highest disc 1 track number? I.e build in a check to see if an increment is actually required?

[simoncn]

(20-06-2015 17:44)ac16161 Wrote:  Thanks, I think the root cause here is the slightly peculiar authoring on the tags. However, could the track counter coding get round this by only incrementing the disc 2 track numbers if the lowest disc 2 track number is not greater than the highest disc 1 track number? I.e build in a check to see if an increment is actually required?

The current scheme is intended to produce "correct" numbering even if some files from disc 2 are missing or have been excluded because of scanning errors. The approach you are suggesting might produce a "false positive" result in such a case.

Before I consider making any change to the current approach (which has worked well for some years), I would like to establish whether the tagging of this album is an isolated case or whether HDtracks is tagging all multidisc albums in this way. Any information or specific examples (of either tagging style) would be appreciated.

[ac16161]

The behaviour occurs with two Murray Gold albums I just downloaded. In both cases the disc 2 track numbers run on from disc 1, but the disc 2 tracks do have a disc tag set to 2, hence Minimserver shows the wrong tracknumber for the disc 2 tracks. I have the original CDs and in at least one case, the disc 2 track numbers on the inlay also run on from disc 1 (the other CD I can't find). So probably HDTracks are honoring the tracknumbering of the original packaging, or otherwise they just use what they get from the record label. I can't think of any other multi-disc downloads just now. I think the current approach works fine for multi-disc sets that are ripped from CD, but as we've seen here there is potential for Minimserver track numbering to fall over with multi-disc downloads depending on the authoring approach used.