GNOME Bugzilla – Bug 734235
AAC tags are improperly parsed for the "year" field
Last modified: 2014-08-09 23:26:02 UTC
On adding my AAC library to Rhythmbox, Rhythmbox incorrectly reads the "Year" fields for all of my files. The "Year" field for any file contains either the year 2014 or 2013, which may have to do with the time the file was last modified (unknown). Using neroAacTag, the year tag is intact, visible, correct, and unedited after adding these files to to the library, yet it is not detected. These files do have non-standard fields in the tags, which were used by iTunes, but this should not stop Rhythmbox from parsing the correct fields (as it succeeded with the other fields just fine). Upon editing the files in Rhythmbox and correcting the year, all non-standard tags are removed from the files (when printed again using neroAacTag) and the year field is extended from "YYYY" format to "YYYY-MM-DD" format. It is important to note that simply changing the year field from the former to the latter outside of Rhythmbox *does not* cause Rhythmbox to parse the field correctly.
Are these files itunes purchases, or otherwise obtained from apple? Their use of some tags in mp4 files is unclear and seems to trip up parsers that expect normal values there (see bug 731029 for instance). Can you provide output from gst-discoverer-1.0 for one of these files?
The GStreamer bug is quite relevant - though I'm not sure if this is or isn't a duplicate, since it is in another project and Rhythmbox could solve this in other ways. The files were not iTunes purchases or obtained from Apple. Most were extracted with foobar2000 (Win7) to FLAC from the physical CDs and then transcoded to AAC. The rest were extracted by Sound Juicer from Rhythmbox, and transcoded using neroAacEnc. Here is the output from gst-discoverer-1.0 on a file: http://hastebin.com/halosokuli.sm For all of my AAC library, there are two date-related tags: "date" and "datetime". The "date" field is the correct release date of the album and the datetime field is some modification date, I presume. Are either of the date or datetime fields more standard? In this case, Rhythmbox could solve this problem by simply preferring the date field over the datetime field, unless there's a reason why that field is preferred. Possibly of note is that when I tag these files I use the "year" field through neroAacTag, which claims that "year" is the standard and that both "date" and "datetime" are non-standard. neroAacTag shows neither the date nor the datetime tags, but still does show the correct release date as a "year" tag. (I'm removing the NEEDINFO status since I've answered all the questions asked so far.)
(In reply to comment #2) > The GStreamer bug is quite relevant - though I'm not sure if this is or isn't a > duplicate, since it is in another project and Rhythmbox could solve this in > other ways. Rhythmbox uses GStreamer to read tags. If this had been a format-specific parsing bug, it would need to be fixed in GStreamer. > The files were not iTunes purchases or obtained from Apple. Most were extracted > with foobar2000 (Win7) to FLAC from the physical CDs and then transcoded to > AAC. The rest were extracted by Sound Juicer from Rhythmbox, and transcoded > using neroAacEnc. > Here is the output from gst-discoverer-1.0 on a file: > http://hastebin.com/halosokuli.sm Since this will probably expire at some point: Topology: container: Quicktime audio: MPEG-4 AAC Properties: Tags: datetime: 2013-01-08T11:11:51Z date: 1971-01-01 'datetime' here comes from the qt creation date field in the mvhd tag, not a separate tag of its own. 'date' comes from the yrrc tag. Formats that I actually care about only seem to use the datetime field, which is mostly why rhythmbox currently prefers that, but since it appears date is more useful for mp4 and unused elsewhere, I'll change it to use date in preference to datetime.
fixed in commit 277dba4
Hi again, I cloned master and it appears that I am still exhibiting the problem. My AACs are still showing only the datetime year and not the date year. Perhaps it is because they are not mp4's and are m4a's?
Have you forced rhythmbox to re-read the tags?
Ah! Sorry, it appears that I failed to properly install the newest version and an older version remained in its wake. Excuse me, and thanks for the fix!