Track Number being interpreted from filename, even when Track# tag is deleted

[andrewilley]

I forgot to revisit this topic after we moved on to a new build release thread, and I just noticed the issue again while testing the new smaller View format in build 877, so I thought I'd make a proper topic for it now.

The problem was the way PA interprets its own track numbers based on the beginnings or ends of filenames if there are no valid ID3 tags in files. This is useful for poorly tagged files of course, but in cases such as a folder full of Singles which are not meant to have track numbers, and where all the files have been deliberately edited to tidily remove them, you can inadvertently end up with results like the following:

 

I wonder if a simple option in Settings > Library > Scanner might resolve this, allowing the user to specify whether they want PA to try to create its own track numbers based on filenames, or for it to only use actual track numbers as provided in tags? (Presumably changing such a setting would then need a rescan for it to take effect)

 

The original discussion was back in build 856's thread:

 Andre

[andrewilley]

A related issue in the same thread was with disc numbers being shown as '1' even when the Disc# tag has been manually deleted from the file as it is not part of a set. Three examples, where (1) and (2) are as expected but (3) should ideally not show any Disc Number.

1) Where a file contains both a Track# and a Disc# tag, both numbers are shown correctly:

 

2) Where there is neither a Track# nor a Disc# tag present (such as in a Singles folder) the Disc Number field is correctly left blank, and the Track Number contains just a place-holder dot (although it might be tidier to just leave it empty?) :

 

3) When there is a Track# but not a Disc# tag, the Disc Number field is filled with '1', whereas it would seem more logical and tidier to leave the disc field blank as per example (2) above, as there should be no disc number to show:

 

Andre

[andrewilley]

I was just doing some tag tidying up a few days ago, and that reminded me of this minor bug which still seems to be present as of build 893.

All of the songs shown below have valid tags for Title, Artist, Genre, Year, etc - but they deliberately do not have any Track# or Disc# tags because the songs are all singles rather than belonging to any album. Yet Poweramp is still trying to parse the filename in an attempt to find a track number - either using the start of the song title, or the end of the artist's name - creating the following bizarre results: 

 

My suggestion would be either to make this functionality optional via a Settings switch, or perhaps a more elegant solution would be to only automatically parse the filename for track# digits when there are no normal tags (Title/Artist/etc) embedded in the file at all. The assumption being that if several other tags are correctly populated but Track# and Disc# are not, then that is probably by design.

Andre

[MotleyG]

2 hours ago, andrewilley said:

All of the songs shown below have valid tags for Title, Artist, Genre, Year, etc - but they deliberately do not have any Track# or Disc# tags because the songs are all singles rather than belonging to any album.

The other option (for now at least?)  is to include the track# tag, and use 1 for side A and 2 for side B, so that tag is always populated. It would be far more elegant of a display than what is currently happening when PA pulls arbitrary numbers from other tag values in an attempt to display something relevant.

[andrewilley]

2 hours ago, MotleyG said:

The other option (for now at least?)  is to include the track# tag, and use 1 for side A and 2 for side B

Yeah, it would be possible to insert an (admittedly incorrect) '1' value for all such tracks, but the other 800 or so songs in that grouping do show correctly with the Track# field empty, and having '1's for some songs probably isn't all that much better than random 2s, 17s, 40s and 99s. And of course the same would apply to other types of music with no meaningful track numbering: radio shows, one-part dramas, single concerts, theme park background music loops (yes, that's a thing  ), etc. I did try saving a fake placeholder character into the tag (a fullstop or bullet symbol for example) but anything other than a valid numeric value (1-999) is ignored when parsing the Track# tag contents.

And if you happen to prefer the 'Title Prefix' list mode for displaying track numbers, PA elegantly omits missing track numbers as you would expect (see second half of list below) which only makes the randomly parsed values from filenames look even stranger:

Andre

[andrewilley]

I just noticed while checking something else for someone that these minor bugs are still present in build 956. To more succinctly summarise what turned into a long and rambling thread of example screenshots down to three points:

1. Track numbers should NOT be auto-generated from the beginnings or ends of filenames in cases where the file does contain some valid tags but the Track# tag has deliberately been left empty - such as for singles, or other material where track numbering is not relevant. They should remain as null items. It's not a good look for all singles by UB40 to be listed as Track Number #40, or for the song "99 Red Balloons" by Nena to be interpreted as being Track #99 of some non-existent album.
2. Similarly, if there is a Track# tag but NOT a Disc# tag, PA should not generate an artificial Disc Number of '1'. In such cases, Disc# should remain as an unassigned/null value - i.e. the same sort of null item you see when both the Track# and Disc# tags are empty, where the additional Disc# metadata field remains empty rather than being populated with an irrelevant '1'.
3. Sorting 'By Track #' does not currently work. It instead functions identically to sorting 'By Disc and Track #'. While admittedly not especially useful, if the user has specifically chosen to sort only by Track# alone, instead of by Disc# first and then Track#, then that choice should be honoured. So when sorting 'By Track #', any disc numbers should be ignored and PA should display all of the Track 1s together first, then all of the Track 2s, etc.

Andre

[andrewilley]

* As an addendum to point above (3), to avoid causing confusion to existing users I think that whenever this gets fixed, anyone who has currently selected any 'By Track #' sorting should be automatically migrated to using 'By Disc and Track#' (which is actually what they are getting anyway). That way they won't see any difference in experience unless they choose to.

Andre