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

[andrewilley]

I was just checking on something else for different issue, and I noticed that this bug still remains in the current builds.

Incorrect track numbers are still being generated from the start (or end) of song filenames, even when the file is fully tagged but with a deliberately empty Track# tag - such as when a song is a single and not part of an album, so it shouldn't have a track number at all.

For example, all of the below song files have correct Title, Artist, Genre, Year, etc tags - but specifically no Track# tag. However PA creates incorrect numbers from the filenames instead of leaving them blank as intended:

With or Without You - U2.mp3
The Future's So Bright, I Gotta Wear Shades - Timbuk 3.mp3
5 Years Time - Noah and the Whale.mp3
7 Years - Lukas Graham.mp3
9 to 5 - Dolly Parton.mp3
Temptation - Heaven 17.mp3
19 - Paul Hardcastle.mp3
22 - Taylor Swift.mp3

 

Oh, and the related bug of the Disc# entry being assigned a notional value of '1', even though the Disc# tag is not present/empty, is also still there - but only when a Track# tag is in the file.

Andre

[maxmp]

@andrewilley scanner option is possible, though it will be applied globally to all files. May be the option should be tristate: disabled/enabled for all files/enabled for files without any tags.

[andrewilley]

@maxmp Globally is fine - and it would obviously need a one-off Full Rescan once implemented in order to update the database.

Not sure if it even needs an extra manual switch though? The current logic of trying to parse [Track-if-numeric] and [Title] details from the source filename seems perfectly fine if there is no embedded tag data at all. But if there is at least a Title tag then it seems redundant to even try to glean anything extra from the filename.

And while you're at it, in the same way that a missing Track tag generates null content for Track# (rather than inventing Track# = '1'), so a missing Disc tag should do the same for Disc#. Currently if there is a valid Track tag, even a missing Disc tag stills creates Disc# = '1' rather than generating a null Disc# field. It looks neater in the library views if Disc# is only displayed when it is actually necessary - i.e. when it was scanned as a real value of '1' from the file.

Andre

[maxmp]

@andrewilley right, added that logic without option, though option is still possible if ever requested.

[ihaspei]

@maxmp please make the track number only visible on album list. right now you can see the track number on every list of songs in any category except for playlists.

thanks for the updates!

[andrewilley]

@ihaspei There is already a control that does basically what you want in Settings=>Library=>Lists

The option I use (above) only shows the Track# info when viewing songs within album or folder views - so not in All Songs, High/Low Rated, Most Played, Playlists, Queue, etc. For example:

It also does not include the Track# on the Player Screen, which you can find from the optional 'Show Track Counter' feature anyway.
 

The above also neatly illustrates why I was asking for empty Disc# tags to be treated as being null values by the way: I don't need to see a superfluous '1' next to every song's meta info for albums that only have one disc and for which the embedded Disc tag is empty. A Disc Number is only relevant if I have actually set tags for Disc#=1, Disc#=2, etc. For example:

Andre

[ihaspei]

i actually have that option like you

but the thing is that the track number its shown on other lists too, where it is irrelevant to show the track number

that was my request

 

1 hour ago, andrewilley said:

I don't need to see a superfluous '1' next to every song's meta info for albums that only have one disc and for which the embedded Disc tag is empty. A Disc Number is only relevant if I have actually set tags for Disc#=1, Disc#=2, etc.

i personally don't use the "show disc" option, but i'm with you on that take. i would also suggest that if that option it's activated, the disc tag should be only shown when the album has more than 1 disc, and for a better visual representation could be shown as on spotify, making a separation showing "disc 1" and then the list of songs and so on, it looks more clean.

 

[andrewilley]

Agreed, all of the various "All <Catgeory> Songs" lists should behave the same way as the "All Songs" Category, which does not show track numbers. A missed flag for those lists I guess.

Andre

[maxmp]

@andrewilley@ihaspei I'll exclude these sub-categories from the showing track number, thanks for the request.