SUMMARY For .flac files, Elisa uses the DATE tag to show the year instead of ORIGINALYEAR. Suppose I have a song from 1980 but the digital file I own was released in 2010: Elisa leads users to think this song is 30 years younger. I don't know about other formats. STEPS TO REPRODUCE 1. Have a .flac file with both DATE and ORIGINALYEAR tags 2. Select the Tracks view, point to the song and click on the "i" icon OBSERVED RESULT The year shown is the release year of the medium, not the song. EXPECTED RESULT Elisa shows the year of the song (1980, following my previous example) SOFTWARE/OS VERSIONS KDE Plasma Version: 5.17.4 KDE Frameworks Version: 5.65.0 Qt Version: 5.13.2
Hello, Thanks for your report. Elisa is using KFileMetaData to read metadata from music files. Without checking code of the metadata extractor, I did search for a reference to ORIGINALYEAR tag and could not found it. Picard music tagger can add an originalyear tag but this is not standard. I also had a look at this page: http://wiki.hydrogenaud.io/index.php?title=Tag_Mapping Do you have any reference that could explain what is 'ORIGINALYEAR' and how is it used ?
Changing to NEEDSINFO status as recommended
> Do you have any reference that could explain what is 'ORIGINALYEAR' and how is it used? Well no, I have nothing technical. I'm using Picard in fact as my tag manager. The only reference I found is this, since FLAC uses the Vorbis tagging system (source: https://xiph.org/flac/faq.html#general__tagging): https://xiph.org/vorbis/doc/v-comment.html As far I understand from the reference I linked, there are no "standard" tags, just a minimal list of proposed tags. This then leads to think about how common the ORIGINALYEAR to deserve its parsing code, in my opinion, but I have no data in that regards.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Didn't know I have to change status myself.
Some quick web searching indicates that "original date" is a real thing. It would make sense to support it.