[AnalogKid]

Since it appears Dave will be introducing the sort tags then it makes sense to me to have the sort criteria configurable in the settings, so you could have:

Configure "Sort by Date" to use: Release date / Recording date

Release date uses TDRL and falls back to TYER if not present
Recording date uses TDRC and falls back to TYER if not present

Happy with making this configurable, that is also how my use of artist sort name etc. implementation works. However it does get harder when it comes to passing this out to the JSON API. As I understand the principles from Montellese the API needs to be independant of the effects of user system settings that it can not change. That is it will need to be able to set whether it is using release date or recording date.

Do we follow Picard and have (release) date (TDRC/DATE) and original release date (TDOR/ORIGINALDATE), or do we also have TDRL and if so what Vorbis tag is equivalent?

The way sorthing works it needs a populated field of data, and is not able to fallback to another value in the middle of sorting, so we are talking about adding 2 (or 3) fields to the data stored and deciding how they are populated when the file tags are scanned. This also means a database conversion from Year values to full date values when upgrading.... Just thinking aloud really.

If there's no fancy SQL query, then yes, I guess you'd have to create a faux / deduced field (something like 'fauxDate'). I believe you'd only need to use one field for this though.
When a file is scanned, and all tags read, at that point, you're able to 'deduce' the date (based on your priority algorithm).
This raises a new issue - if the user changed the preference for which date fields to use, you'd have to go through the entire DB and refresh the 'fauxDate'.

If you allow the user to choose which field they want, then you don't have to worry about what Picard or any other tagger uses, although as you highlight, Vorbis comments aren't the same is ID3, and appear to be much more limited with only 'Date' as some sort of standard.

For the JSON API, can you not have a field which is 'Sorting Date' (i.e. your 'fauxDate') ?



p.s. If you're able to use a database query, you SHOULD be able to create a query that CAN prioritise the fields - but it might be a medium complexity query. For performance reasons, the 'fauxDate' might be easier. A few database purists might object to it though.
Using some medium complexity query should be able to generate the 'fauxDate' on the fly without having to actually store it in the database.