Expanded "Year" field reading in metadata

[bigdonkey1]

Hi there, I've been using Poweramp off and on for a while now and after recently refreshing my phone and loading it up with albums i've run into an issue a number of people seem to have before (i've found the issue mentioned by googling which is what led me here); When an Artist has multiple releases within a single year they default to alphabetical sorting for that year. IE if an album beginning with "A" was released in December it would appear before an album beginning with "D" that was released in June.

This is an awkward issue to be sure, but is particularly frustrating to me as i had already solved this issue on my desktop music library by using Full Dates in the "Year" field using a 10 digit system of Year/Month/Day (For example today would be written as 2020.06.16). The issue in Poweramp (and most android music players i've tried as alternatives that all have the same issue), is that it only seems to read the first 4 digits (2020) and no further. Attempting to manually add anything to that field in the tag editor just does nothing and files that already have the year field up to 10 digits simply have the rest cut off. 

 

Is there any way to remove this limitation to allow for greater flexibility in the organisation of an artist's discography?

I could have sworn i had resolved this issue on a previous version of the app through this method but am not sure if this is just a poor memory or a setting i had enabled and now can't find again. If there is a way around this please let me know, though sorting by Folder is not an option due to the file naming structure listing date up front ([2020.06.16] Fake Album Name) and would massively clutter the browsing experience or require manually renaming every single folder as it is moved onto my phone.

Thanks

for reference i am on android 10 and version v3-build-874-arm64-play

[andrewilley]

The original ID3 spec lists the release field as a 4-digit year-only, although the v2.3 and then v2.4 specs widen this and add tons of new fields, many relating to time/date such as TDAT (date), TIME (time), TRDA (recording dates), TYER (year) and TDRC (recording time, a combi of the previous fields).  Vorbis (FLAC files) single DATE tags have, as far as I know, always allowed for longer strings.

At present PA acts like almost every other player in that it treats the date field as a 4-digit year and ignores any supplementary day/time info, which is also how the majority of music files are encoded. I have seen a few files in the wild which use yyyy-mm-dd (with hyphens separators, but never fullstops). Out of interest, I've just checked my own Singles folder, and out of 754 files a total of 26 have valid yyyy-mm-dd coding (although to be fair nearly 300 haven't even got year tags - probably tracks that I ripped from CD myself years ago). 

I don't know the technicalities of how PA's internal database works ( @maxmp , over to you) but I wouldn't have thought that if enough demand exists it should be too complicated to read the whole field. Then wherever a full date does exist it could be used for subsequent date-sorting purposes. Otherwise, assume yyyy-99-99 so undated stuff gets placed alphabetically at the end of any date-sorted lists, in the same way tracks with no year are handled now. This could be especially useful for Singles collections where you may have dozens (hundreds?) of songs that were released in any one year and it might be nice to have them sorted by date if that is provided - so for example Summer or Xmas releases would get grouped together within any given year group.

At the end of the day (sorry, no irony intended!) it's up to Max to balance the workload required against the demand though.  

Andre

[maxmp]

@andrewilley at this moment year is always just yyyy. For ID3V2 the tag reader reads just first 4 symbols from TDRC, but that can be customized further to read more.

[andrewilley]

If it doesn't complicate the database or cause any other coding issues, it might be worth scanning and allowing for sorting using the full ISO 8601 date format, if detected. I think it's safe to ignore any time-of-day elements though, so just look for valid date strings of the form yyyy-mm-dd, or yyyy-mm, or yyyymmdd, with any unknown/missing elements being treated as high numbers for sorting purposes (so songs which include month/day get sorted before ones that only include year). Any such change would obviously need a full rescan.

[While checking through my own music files for reference, I found one album in which the date field was set to 10/7/19 - that was never going to work in anything. Safe to ignore I think!]

Andre

[Absinthequ]

+1

This would also help the Year category. Right now an album that came out in January may show up at the end of the list because the album starts with a Z. This would allow to sort by release date.

One of my favorite artists came out with 4 albums in 2019 and they don't show up in order. I have many noticeable instances of this in my library.

[LABB]

+1

I also think this is a good feature to have. Most of my albums have the Date tag using YYYY-MM-DD format, and when sorting by year, it would be better to sort by Date, when such information is available.

An example I have experienced earlier is when I want to hear all Beatles' studio albums in order, and it puts Yellow Submarine after Abbey Road, because they're both from 1969 and A precedes Y. But in this case Yellow Submarine must precede Abbey Road, because it was released earlier in that year.

[Absinthequ]

On 6/16/2020 at 7:30 AM, maxmp said:

@andrewilley at this moment year is always just yyyy. For ID3V2 the tag reader reads just first 4 symbols from TDRC, but that can be customized further to read more.

A side note/question on how year sorting works (for songs). Right now the default after sort by year is to sort by title, can the default be sort by filename instead?

I guess the other question is if not, is there a possibility of multiple tier sorting for this option? 

Examples:

1. If I sort songs by Year, In a folder/album of multiple artists "Oldies" for example. I may have 5 songs by an artist in one year, but they appear shuffled among 100 other songs because it's looking for Title. If they were sorted by filename, it would group the artists after it sorted by year because all of the songs usually start with artist in the filename.

2. I now go back to a regular album and now that I've chosen "sort by song year" all of my songs are now out of order because they are sorted by Title. If they were sorted by filename, they would be in the correct order as they all have the number in the filename when dealing with a regular album.

3. If it's all the same artist in the folder "Singles" or "B-Sides" for example, sorting by filename wouldn't affect anything, unless your filenames were badly named or started with numbers. But then they would still sort by year first, but then appear shuffled within each year (as multiple artists does now). But most people just have "artist - title" in these situations and would only affect people with files named odd.

If Anyone that can think of a reason I'm wrong jump right in, but I can't think of any reason if you're dealing with a folder/album of multiple artists, why you would ever want to sort by title as default after sorting by year. This will always cause the songs to be shuffled when dealing with multiple artists of the same year and shouldn't make any difference to single artist albums. If you have a folder of multiple artists and they're named odd and start with numbers, then you wouldn't care anyways, they're shuffled as it is by title.

The best fix may be Sort by year, then sort by artist, then sort by title. But I don't know how that all works and if that's possible.

sorry for so many edits

[andrewilley]

5 hours ago, Absinthequ said:

I guess the other question is if not, is there a possibility of multiple tier sorting for this option? 

I've actually had a long-standing request in place for that sort of user-customisable Library view for a few years now. I think Max does have something in mind for the future, but I'm not sure how it will work.

For what it's worth, the concept I suggested would perfectly solve your problem (and most other category sorting/grouping feature requests):

Andre