Support for full date in sorting

[Kundun]

Hi there,

I'm here to ask to support full date in sorting and grouping. If you have a tons of album from the same year it can be problematic to sort or group albums by year (plus this can be useful in the album view for artists with significant output in a single year, cfr. this). This can be implemented using the id3v2.3 tag TDAT or the id3v2.4 tag TDRC.

 

A short summary (from id3 specification):

• TDAT:The 'Date' frame is a numeric string in the DDMM format containing the date for the recording. This field is always four characters long.
• TDRC: The 'Recording time' frame contains a timestamp describing when the audio was recorded. [...] The timestamp fields are based on a subset of ISO 8601. When being as precise as possible the format of a time string is yyyy-MM-ddTHH:mm:ss (year, "-", month, "-", day, "T", hour (out of 24), ":", minutes, ":", seconds), but the precision may be reduced by removing as many time indicators as wanted. Hence valid timestamps are yyyy, yyyy-MM, yyyy-MM-dd, yyyy-MM-ddTHH, yyyy-MM-ddTHH:mm and yyyy-MM-ddTHH:mm:ss. All time stamps are UTC.

 

The TDAT tag was changed to the TDRC one in id3v2.4, but I suggest to support both of them (probably most of the time only one of those will be present, not both), since most of other players/taggers support only TDAT (probably due to parsing criticalities related to the variable timestamp length of TDRC). I myself use the TDAT tag only, it's just way more straightforward and more supported.

 

If those fields are not present then a timestamp like "YYYY-01-01" can be inserted in the internal DB, as many others do in this case. I know that it will need a full rescan of the user music library to function properly, but by settings "YYYY-01-01" as the default timestamp this won't affect or break anything, since the fallback sorting will always be the alphanumerical order (as it is right now).

 

Thank you for your job and have a happy new year!

 

Related request:

• Choose Metadata Field for Year
• Сортировка альбомов

Edited January 26, 2021 by Kundun

[andrewilley]

ID3 v2.4 opens a whole can of worms with dates, and I'm not sure how compatible that usage has become anyway. Apart from the v2.3 TYER, TDAT, TIME, TORY, TRDA (year, date-DDMM, time, original release year, recording date) it also offers TDRC (recording date in full), TDRL (release date in full), TDOR (original release date in full). Some software (such as foobar2000) even says it makes further use of the user-defined tag TXXX (I've seen thing like rip-date, etc).

The most common usage I've seen in the wild though is to completely ignore all of that over-thinking and simply extend the original v2.3 TYER tag beyond its first four digits - either with a basic YYYY-MM-DD date such as 2020-12-31, or full UTC spec in the form 2020-12-31T07:00:00Z. I'm not sure how much point there is in storing release hour/minute/second though, but I guess best to support it when it is present.

I can't see that it would be too hard to store full dates in the Year field in the database (even convert to UNIX timestamps?) and make the sort-by-year option reflect that extended information if present. It would probably require a Full Rescan for existing users, but that's not a major hassle as a one-off task.

Andre 

[GeilerHeinz]

I would appreciate very much if PA would parse date tag in the format YYYY-MM-DD. 

Regards

[Absinthequ]

On 1/27/2021 at 2:20 PM, GeilerHeinz said:

I would appreciate very much if PA would parse date tag in the format YYYY-MM-DD. 

Regards

This seems to be the new standard across the board.

Like many people i like to sort my albums in order they were released. Currently after sorting by year,  it resorts to alphabetical. This is a problem because lot of artists i follow release multiple albums a year and there is no way to keep them in the correct order. It would also be nice to look at albums in the years category listed in the order they were released. Like when i look at my list i could see albums in the middle that came out in summer and towards the end albums that came around Christmas. It feels odd to go to years category and see a Christmas album listed in the middle of the year list. 

 

Edited April 6, 2021 by Absinthequ

[andrewilley]

The de facto standard (although it's technically wrong) seems to be to use the TYER tag to store fully formatted dates as YYYY-MM-DD - even though there are separate date tags already (such as TDAT, and all the others I mentioned above). I agree it would be nice if this type of TYER formatting (and the more correct TDAT if present) was noticed and parsed as a full date into PA, and used for sub-sorting Year lists.

Andre

[Kundun]

I still suggest to use TYER+TDAT as the preferable method, and TYER in the YYYY-MM-DD format as a fallback method, maybe using a priority list like the following:

1. TYER+TDAT
2. TYER YYYY-MM-DD
3. TYER YYYY-01-01

 

Just to give a little bit of context on why I suggest to do so:

• From a metadata tagging point of view I am a Picard user, and what Picard does is to store the TYER (YYYY) and TDAT (DDMM) in a compliant way, even though the input field is just a single "date" field where you can put YYYY or YYYY-MM-DD (Picard will update TYER only or both TYER and TDAT accordingly to user input).
• From a desktop playing point of view I am an MPD (Linux) and Foobar200 (Windows) user, and both of them do recognize the TYER+TDAT combo properly.

Those are just three examples of three popular apps (I mean, in their own niches) that do support the TYER+TDAT combo, so considering to use that as the preferable method (since it's id3 compliant too) is to me pretty logical, and having some sort of priority list like the one above (and by that covering more use cases) sounds like the right choice to me.

Edited April 6, 2021 by Kundun

[Kundun]

A few days ago I was also thinking that showing the complete YYYY-MM-DD everywhere may result in a bloated UI, so maybe it's a better idea to show that in the Years category only (when a specific year is selected)? Or maybe make it toggleable?

[andrewilley]

Yes, it would make sense to read the various formats that are found in the wild - such as TYER/TDAT or extended TYER. And if neither of those are found but there is a TDRL, TDOR or TDRC tag, fall back to using those instead.

Should Year-only files be treated as YYYY-01-01, or sorted after files with full dates?

Andre

[6b6561]

IMHO it doesn't make much sense to be over creative and tweak the code to accept strange versions in the wild unless it's a common mutation. I would leave it as an exercise for the user to fix their tags to adhere to the standard.

I assume that the dates should be scanned into the DB when the files are added and I would say that the magic should be applied at this point. Basically what poor Max would have to do is to create a table of all supported file formats and how to treat the meta data of each format...

• mp3 v2.3 tags should be read as TYER + TDAT, if TDAT is empty treat it as 01-01 if a valid date is required.
• mp3 v2.4 tags, read them according to ISO 8601, add "01" for MM and DD as needed.
• flac
• wav
• ...

I wonder if there is a standard for how to sort "year only" files? If not, then I would sort them with MM and DD set as "01".

What I believe will be trickier is how to handle non-standard stuff such as:

• date strings with dates separated by periods or dashes. How should those be handled, replace the "./" by a "-" and hope for the best?
• How about strings with MM and DD swapped? Any of these around?
• TYER where someone has been creative and used something like YYMM as that's a valid four number string.
• completely missing dates, import them as 1000-01-01 and get them at the beginning of the list

[andrewilley]

@6b6561 I'm sure any such feature would do all the parsing from ID3/Vorbis/etc at the scanning stage, once scanned the date would be stored as an internal YYYY-MM-DD format (or Unix stamp) in the database.

If month (and optionally day) are added to TYER, they should  be considered as continuing in standard Unix (ISO 8601) format - e.g. today: 2021-04-06T17:26:04Z . TDAT is already in the ID3 spec too, as four digits DDMM. Similarly "/" or "." should not be used, although I guess it would be simple enough to treat them as dashes if encountered, but mixed-up entries in files are really down to the user to fix.

I think missing either DD or MM should be treated as zero values, so both missing would always be sorted before Jan 1st. And if a song is only missing the day, the entry would be sorted prior to the 1st of the given month.

Andre

[6b6561]

17 minutes ago, andrewilley said:

I'm sure any such feature would...

More or less fully agreed, sounds like we are quite aligned on this topic.

[maxelo]

please make this happen!, I love Poweramp been using it from years

 

[maxelo]

any news on this request?

[andrewilley]

@maxelo Not present in build 911, and I understand the next release will be more about underlying changes that are needed to keep up with Google's Android ASK version requirements, so there won't be too many feature additions this time. 

Andre

[mhb2862]

What are the odds of this happening? It's a nightmare trying to organize artists like The Beatles who have multiple albums released in the same year.

[Peter Cuevas]

+1

[andrewilley]

I must admit I think it would be a nice feature too - but it would probably involve a full rescan of the database and also some changes to allowed field sizes in some layouts.

There are also a number of different conventions out there in the wild - some per specs, others that have happened organically:

Andre

[mhb2862]

Oh well. Hopefully it can be figured out easily. Or maybe another way to individually sort albums under the artist category so they can be inline in actual release order.

[Ash Roarshock]

+1

[fyourself]

+1