GST_TAG_DATE and GST_TAG_DATE_TIME mismatches in m4a
I received a couple m4a files from a ripped album, that happen to be misinterpreted in gnome-music as 2 separate albums, it seems to boil down to the date component in album/disc URNs being slightly different.
Looking into the gstreamer extractor code, we seem to use GST_TAG_DATE_TIME first and GST_TAG_DATE as a fallback. There's some different cases here:
- File has only one of either fields, choice is easy there
- File has the same date on both, except accuracy. We should probably pick the more accurate GST_TAG_DATE_TIME
- File has both dates set, but they are different.
The last case is what applies here, presumably GST_TAG_DATE contains album release date, and GST_TAG_DATE_TIME contains later dates that differ in seconds/minutes between the 2 files, probably ripping time. So it would seem that we must actually obey GST_TAG_DATE in these cases, It seems both totem and rhythmbox agree in doing this.
I'm doing a MR that:
- Ensures nie:contentCreated and album/disc URNs use the same date
- Ensures album/disc URNs only use date (i.e. no time details) as that can be no good in the case we get it wrong
- Similarly prefers GST_TAG_DATE if both are different.
Edited by Carlos Garnacho