Notice: A non well formed numeric value encountered in /sites/ on line 96 Notice: A non well formed numeric value encountered in /sites/ on line 96 Notice: A non well formed numeric value encountered in /sites/ on line 96 Deprecated: Function create_function() is deprecated in /sites/ on line 104 Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /sites/ on line 845 Deprecated: Function create_function() is deprecated in /sites/ on line 111 FS#6501 : DataBase does not recognise Year tag in OGG files



FS#6501 - DataBase does not recognise Year tag in OGG files

Attached to Project: Rockbox
Opened by Eddy (bascule) - Thursday, 04 January 2007, 10:23 GMT
Task Type Bugs
Category ID3 / meta data
Status Closed
Assigned To No-one
Operating System All players
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


I noticed (using a custom_tagnavi file selecting by year) that I had a lot of tracks listed with a year of "0". As all my music is well tagged, I was looking for some differentiation as to which ones were causing the problem.

My tracks are a roughly 70/30 mixture of .ogg and .mp3, with varied bitrates from different sources and ripped/tagged with different applications.

I re-initialised the database and then set up two simple tagnavi selections, one for all tracks with Year == "0" and one for all tracks with Year != "0".

To my surprise, it neatly divided my entire music collection into .ogg in the Year == "0" playlist and .mp3 in the Year != "0" playlist.

It appears, therefore, that the DataBase initilisation does not correctly read the year tag from .ogg files.
This task depends upon

Closed by  Dan Everton (safetydan)
Monday, 05 March 2007, 09:29 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fix committed.
Comment by Mark Arigo (lowlight) - Thursday, 04 January 2007, 17:01 GMT
There are two "year" references for the metadata in the id3 struct: id3.year (an integer) and id3.year_string (pointer to a string). The database is only storing the integer value of id3.year; however, the vorbis date tag uses id3.year_string since it can contain non-numeric characters.
Comment by Alan F (alsaf) - Monday, 26 February 2007, 22:42 GMT
The year tag is being displayed succesfully on WPS screen. I checked the tag details for OGG files on wps screen and year is being displayed.

On tag search menu the year tag is always displayed as 0. I created an entry in tagnavi.config to search for tracknum tag between a certain range and this is working successfully. The Tracknum tags are being displayed as tag filter.

AFAIK all vorbis comments are stored as unicode strings. The correct year tag is not being used in tagtree.c
Comment by Eddy (bascule) - Wednesday, 28 February 2007, 16:19 GMT
Correct, it's just the Database that does not work. There is a comment in the code (can't remember which file, id3.c or metadata.c?) that explicitly references the problem and says something along the lines of:
'We are not going to try and parse the vorbis datetime field because it's a string rather than an integer and could concievably contain anything'
MP3's, on the other hand, have both types available, so the Database reads the integer version.
Interestingly (but off topic) the WPS and ID3 Viewer screens show the string version of the MP3 datetime:
Comment by Alan F (alsaf) - Thursday, 01 March 2007, 11:28 GMT
Thanks Eddy.

I commented out lines 223, 224 and 226 in metadata.c and compiled it for rockbox simulator. The year tag works for OGG files as per attached screenshot.

Could the if statement in line 223 if (type != TAGTYPE_VORBIS) be changed to check length of string is 4?

I only have a basic knowledge of C and have only had experience of writing basic python scripts but will look into this later.
Comment by Dan Everton (safetydan) - Thursday, 01 March 2007, 11:49 GMT
Try the attached patch. I wrote it quickly and I've only done limited testing but I think it should work. Not the most efficient way though.
Comment by Alan F (alsaf) - Thursday, 01 March 2007, 12:39 GMT
I applied patch to metadata.c and compiled.

I amended the tagnavi.config file as below:

"Year" -> year -> artist -> album -> title = "fmt_title"

I set the date tag on an OGG file using the following command:

vorbiscomment -w -t "DATE=200" 09-Heroin.ogg

For testing I used to the following data:


In each test, I amended the ogg year tag, ran the simulator, re-iniatilsed the database, then used the year search option.

For each test, the OGG file was always displayed as 0 year in tag search expect 2001-01-01 which was displayed as 2001.

Comment by Mark Arigo (lowlight) - Thursday, 01 March 2007, 17:46 GMT
The simpliest solution is for get_metadata to read a "YEAR" tag that is assumed to be a 4-digit numerical year. I know that YEAR is not a "standard" tag (meaning other apps will not automatically read/write it), but since vorbis comments are arbitary, it can be easily added anyway.

I think this approach is better than trying to parse the year out of the date tag or complicating the database by adding another string field.
Comment by Alan F (alsaf) - Friday, 02 March 2007, 10:32 GMT

The tagging application I use would not allow me to enter the year tag anything other than a 4 digit number and had to do testing using a CLI command. I would assume other tagging applications have the same facility for vorbis comments.
Comment by Dan Everton (safetydan) - Friday, 02 March 2007, 11:01 GMT
A YEAR tag is probably the simplest solution for us, but I'm not sure making people re-tag their files is the simplest solution for the user.
Comment by Dan Everton (safetydan) - Friday, 02 March 2007, 11:29 GMT
Slightly revised version of the patch. Turns out we don't need to check before calling atoi that the string actually is numeric. If we get wacky results back from atoi, just pretend we didn't try and parse it. This handles the common case for Ogg files that are "correctly" tagged as year-month-day.
Comment by Eddy (bascule) - Sunday, 04 March 2007, 23:36 GMT
Fantastic! Thanks for the patch, that's fixed my Database at a stroke...

All my .oggs can now be correctly browsed by year.

Any chance of a commit for this...?