Solved Song sorting by dates (TDOR, TDRC, TDRL) not just YEAR
#16
Vorbis comments have no official standard, but DATE, ORIGINALDATE, and YEAR seem to be the generally accepted tags.

Really Vorbis is more flexible then ID3, but media players don't seem to have made use of it. There is an arguement that says the way all tag processing is hard coded into Kodi is a limit, and that a user configurable meta model would be better, but that is not where we are. Optional fields, or one field meaning configurable things causes problems.

For your interest Kodi does not use SQL to do the sorting, it fetches all the data using queries without ORDER BY statements and then sorts the results set locally. So determining values for a date field to sort by could be done locally, but it is the local parsing of the data into objects and then sorting etc. that makes Kodi slow on large music collections. A "fancy SQL query" could be used to get a value from a variety of fileds, but I learned long ago avoiding null fields can save a lot of headaches.
Reply
#17
Here's a little mySQL fiddle if it's of any use:

http://sqlfiddle.com/#!9/976283/5


It shows how you can generate the 'fauxDate' on the fly with a mySQL query - far simpler than I'd imagined!

Doing it this way would at least create the 'fauxDate' on the fly, then allow sorting to occur by Kodi.
It's not clear to me (but you will know) if you can manually sort the results first prior to creating objects (preferable), or if it the objects are created first then sorted, but at least you'd not be checking multiple fields at this point as the query will have done that work for you.
Reply
#18
Thanks but the SQL is not a problem, I know well how to do that. I do wonder at the performance issues on a large song collection though. Would need checking on both SQLite and MySQL.

Also yet to convince myself if there is a need for 3 dates or just 2 (in addition to year).
Reply
#19
(2016-08-25, 17:35)DaveBlake Wrote: Thanks but the SQL is not a problem, I know well how to do that. I do wonder at the performance issues on a large song collection though. Would need checking on both SQLite and MySQL.

Also yet to convince myself if there is a need for 3 dates or just 2 (in addition to year).

If you store TYER already, then you probably need to also store any other date field that you are offering as a preference.
If you don't store all the other date fields, but only one 'fauxDate' then if the user chooses to use a new date preference from the UI, you'll have to rebuild that column which means scanning all the tags again.

Does that not leave with two options? TYER + FauxDate or TYER + all other selectable date fields.
Reply
#20
If anyone would like to add to this discussion now is the time. I'm looking at implementing the various date tags in v18
Reply
#21
If we still get Picard's originaldate I'm fine Tongue
Reply
#22
FWIW MediaMonkey 4 supports read write for date

ID3v2: TDRC TYER
Vorbis: YEAR, DATE
WMA: Year OriginalReleaseTime
AAC/M4a: day
APE: YEAR
WAV/RIFF: ICRD IYER(read only) TDRL TYER(read only)

All are held internally as "date" yyyymmdd

There is also "originalyear" (really original date)
ID3v2: TORY
Vorbis: ORIGINAL YEAR
WMA: OriginalReleaseYear
AAC/M4a: oday
APE: Original Date
WAV/RIFF: n/a

scott s.
.
maintainer of skin  Aeon MQ5 mods for post-Gotham Kodi releases:
Matrix see: Aeon MQ5 Mod Matrix release thread
Nexus see: Aeon MQ5 Mod Nexus release thread
Aeon MQ 5 skin and addon repo 11.1.0
Reply
#23
To describe my ideal tagging scenario in simple terms - there would be one value that governs the release/album, and another that governs the song itself (I need to study the proper application of the various year tags available, but you get the idea).

Kodi would use the release/album value for album sorting, or for displaying the year next to an album title in the music player.

The song value could be used in smart playlists, or any type of operation that involves a track outside of its album context.


(2017-05-11, 02:03)scott967 Wrote: FWIW MediaMonkey 4 supports read write for date

ID3v2: TDRC TYER
Vorbis: YEAR, DATE
WMA: Year OriginalReleaseTime
AAC/M4a: day
APE: YEAR
WAV/RIFF: ICRD IYER(read only) TDRL TYER(read only)

All are held internally as "date" yyyymmdd

There is also "originalyear" (really original date)
ID3v2: TORY
Vorbis: ORIGINAL YEAR
WMA: OriginalReleaseYear
AAC/M4a: oday
APE: Original Date
WAV/RIFF: n/a

scott s.
.

I have my music in Apple Lossless format (ALAC) and have been trying to figure out what it supports beyond the basic YEAR tag (a lot of lists I've seen don't explicitly mention ALAC by name). I see "oday" listed here next to AAC/M4a - does this accomodate ALAC?
Reply
#24
(2017-06-09, 20:50)Busta Uppa Wrote: I have my music in Apple Lossless format (ALAC) and have been trying to figure out what it supports beyond the basic YEAR tag (a lot of lists I've seen don't explicitly mention ALAC by name). I see "oday" listed here next to AAC/M4a - does this accomodate ALAC?
No AAC/M4a does not refer to the ALAC file format.

I believe, but untested as I prefer using open source lossless formats rather than propriatory Apple ones, that ALAC format has the same tagging as FLAC i.e. Vorbis comments. There is no formal standard for Vorbis comments, you could add any name of tag (and tagging software like Mp3tag will let you), but common practice would suggest that in future Kodi supports

ORIGINALDATE (same use as TDOR in mp3)
DATE or YEAR (same use as TDRC in mp3)
RELEASEDATE (same use as TDRL in mp3)
Reply
#25
@black_eagle this is the old discussion of date tag processing (if you have not already found it), but worth resurrecting if you are wanting to work on this.
Reply
#26
@DaveBlake Yes, thank you for the heads up Smile

Most of this discussion seems not to involve the tag I have currently implemented ha ha !!  I have used TORY/ TDOR (and the equivalent for vorbis/wma/ape) which according to the id3v2 spec is "The 'Original release year' frame is intended for the year when the original recording, if for example the music in the file should be a cover of a previously released song, was released."  Most of my stuff has this tag set.

I can add processing for other fields so they are available as listitems but having checked lots of albums, none of the other date fields seem to be populated by picard (although I'm aware people may have done so manually or that other software might well populate them.  Picard also doesn't map original release date to any tag for mp4 files but if there is a standard tag for that format then I will add it. @scott967 seems to have identified oday as the correct tag.

So what we have (on my current branch) is Kodi reading TDRC or TYER for album release date and TDOR or TORY for original release date.  Picard doesn't appear to populate any other date tags for MP3.  There is no mapping for TDRL for instance or not that I can see in the docs.
Learning Linux the hard way !!
Reply
#27
I am in the process of adding DSD files in .dsf format to my collection. They are taggable, but unfortunately only with id3v2.3. This is just a heads up that after browsing this thread everything already seems to be in place for it to work properly.

I'm using

xml:
<musiclibrary>
<itemseparator>;</itemseparator>
<artistseparators>
<separator> feat. </separator>
<separator> Feat. </separator>
<separator> with </separator>
<separator> ft. </separator>
<separator> Ft. </separator>
<separator> / </separator>
</artistseparators>
</musiclibrary>
which seems to split everything correctly.
Reply
#28
@HeresJohnny , yeah I have a working build, but I could do with some suggestions for the strings displayed in the GUI.  At the moment, I've modded my skin to show Original date which is original release date of album, and Release date which is the date this particular album was actually released/re-released.  Original date seems OK, but can't say I'm too enthusiastic about release date.

Suggestions most welcome Smile
Learning Linux the hard way !!
Reply
#29
Not sure if I am the best candidate for suggestions because I use my own tagging system.Whereas DISCOGS uses the general "date" field as the date of the first release, musicbrainz uses it to write the date of the current release. I always overwrite that with the first release date and use another field in foobar2000 (my main player) to show the re-release date (actually DISCOGS_RELEASE). That leads to the somewhat unfortunate situation that the MUSICBRAINZ field for first release date is unused by me.

This is probably going to be one of those dividing decisions but the most important date for me is the original release date. Everything else about a re-release I can see from other metadata, like "DeLuxe", "Remastered" or "With Strawberry Flavour" etc. MUSICBRAINZ is also not always correct/complete in this regard. If an artist only has a later release of an album in his release group then the date of that re-release is passed to the tagger as the original release. DISCOGS is much more complete but I guess that ship has sailed... Music
Reply
#30
(2020-02-06, 01:08)HeresJohnny Wrote: Not sure if I am the best candidate for suggestions because I use my own tagging system.Whereas DISCOGS uses the general "date" field as the date of the first release, musicbrainz uses it to write the date of the current release. I always overwrite that with the first release date and use another field in foobar2000 (my main player) to show the re-release date (actually DISCOGS_RELEASE). That leads to the somewhat unfortunate situation that the MUSICBRAINZ field for first release date is unused by me.

This is probably going to be one of those dividing decisions but the most important date for me is the original release date. Everything else about a re-release I can see from other metadata, like "DeLuxe", "Remastered" or "With Strawberry Flavour" etc. MUSICBRAINZ is also not always correct/complete in this regard. If an artist only has a later release of an album in his release group then the date of that re-release is passed to the tagger as the original release. DISCOGS is much more complete but I guess that ship has sailed... Music
In case @black_eagle is looking for input from the peanut gallery, I'm in full agreement - not only is the original release date the only one that really matters to me, but I've gone to some trouble ensuring that's the date that ends up in the tag Kodi has historically stored and used.  I would urge that the Vorbis YEAR and equivalent always be at least an option to use as the canonical "what to display and sort by" data.

But while I do use Musicbrainz data by way of a mp3tag script, I don't currently use Picard, so maybe I'm another edge case.
Reply

Logout Mark Read Team Forum Stats Members Help
Song sorting by dates (TDOR, TDRC, TDRL) not just YEAR0