GNOME Bugzilla – Bug 311679
[lame] doesn't write GST_TAG_DATE correctly
Last modified: 2006-03-13 11:13:39 UTC
Sound-Juicer should tag the Year information metadata field. An example where this is handy is where I have the entire catalogue of Bob Dylan, and being able to see the year of the disc is very handy. This a big enough problem for me to use other ripper/encoders until SJ implements it. If this were to be implemented an output like the following could be handy: Artist/Year-AlbumName/TrackNumber-TrackTitle.suffix
SJ embeds the year information if the metadata provides it, so go to musicbrainz an fill it in.
This really doesn't seem to work for me. I'm using 2.10.1 from ubuntu hoary. I have ripped single tracks from 5 fairly mainstream albums and none of them have the year field filled. e.g. Rage Against The Machine The Battle Of Los Angeles mp3info gives: File: Rage Against the Machine/The Battle of Los Angeles/01 - Testify.mp3 Title: Testify Track: 1 Artist: Rage Against the Machine Album: The Battle of Los Angeles Year: Comment: Genre: [255] If you visit: http://musicbrainz.org/showartist.html?artistid=381 It appears that musicbrainz has date information that isn't being written. This isn't a single case. I got the same outcome with 5 discs but I won't bore you with the details of each one.
Year information is only written with 2.11.1 onwards.
ok, now using 2.11.90. now it seems that the year keeps being written as "9999". This happened with three tries with 3 different CDs. e.g. File: 01 - Testify.mp3 Title: Testify Track: 1 Artist: Rage Against the Machine Album: The Battle of Los Angeles Year: 9999 Comment: Genre: [255]
Hm. Can you rip an Ogg and check the metadata?
Here's some relevant output from ogginfo: User comments section follows... TITLE=Testify ARTIST=Rage Against the Machine TRACKNUMBER=1 TRACKTOTAL=13 ALBUM=The Battle of Los Angeles MUSICBRAINZ_ALBUMID=7e638a51-a1b1-4b96-a8af-2fbbaa45539a MUSICBRAINZ_ALBUMARTISTID=3798b104-01cb-484c-a3b0-56adc6399b80 MUSICBRAINZ_ARTISTID=3798b104-01cb-484c-a3b0-56adc6399b80 MUSICBRAINZ_TRACKID=08b9a74b-f922-4860-b25c-aba3047cb670 DATE=1999-10-25 Could this have anything to do with the different formats for dates on musicbrainz, i.e. YYYY-MM-DD or just YYYY?
Right, this is a bug in the LAME encoder. GStreamer people: the LAME plugin isn't writing the GST_TAG_DATE tag correctly. Instead of writing 1999-10-25, it's writing something else which is interpretted as 9999.
Ross, do you use id3mux or lame itself for tag-writing?
Lame writes TYER 2004 for a 2004 CD, which is good. id3mux writes TDRC 2004, for which I have no idea what that means (date-of-release?), but it looks good. Lex, can you attach the first 1 kB of one output file, and what version of gst-plugins?
gstreamer 0.8.10 if that's what you where wanting to know. How do I get the 1st 1kb into a file? (PS - might be a while before I respond as it's late at night here)
head -c1k file > file.hdr
Created attachment 49850 [details] 1st 1k of mp3 file
There is no tag :). Can you attach the last 1 kB also (s/head/tail/)?
Created attachment 49851 [details] last 1k of mp3 file
000003A0 00 52 61 67 65 20 41 67 61 69 6E 73 74 20 74 68 .Rage Against th 000003B0 65 20 4D 61 63 68 69 6E 65 00 00 00 00 00 00 54 e Machine......T 000003C0 68 65 20 42 61 74 74 6C 65 20 6F 66 20 4C 6F 73 he Battle of Los 000003D0 20 41 6E 67 65 6C 65 73 00 00 00 00 00 39 39 39 Angeles.....999 000003E0 39 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9............... 000003F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 FF ................ 00000400 Indeed 9999, and not what I see. I see the correct year there... Odd... I'll have a better look.
Oh, as for version, I need version of gst-plugins, not gstreamer. rpm -qa|grep gst | grep plugins
I'm on a Debian-based system here (Ubuntu). libgstreamer-plugins0.8-0_0.8.10 ??
It can only write a year, not a full date (ie. this isn't a free-form string, it can only contain a 4 digit date): void id3tag_set_year(lame_global_flags *gfp, const char *year) { lame_internal_flags *gfc = gfp->internal_flags; if (year && *year) { int num = atoi(year); if (num < 0) { num = 0; } /* limit a year to 4 digits so it fits in a version 1 tag */ if (num > 9999) { num = 9999; } if (num) { gfc->tag_spec.year = num; gfc->tag_spec.flags |= CHANGED_FLAG; } } }
My 2 cents is that we should set the year and disregard the remaining info. e.g. musicbrainz gives date as 2005-07-29, write year as 2005 instead of 9999. I don't think I even want to have it set as YYYY-MM-DD, if we could do so.
We don't do it on purpose. ;).
OK, can you explain the reason why?
The piece of code I pasted is from lame, not from Gstreamer. We'd just need to have a "buffer" function in GStreamer that handle that sort of date data. It still doesn't make it handle all the free-form dates you can put in ogg files ("1st December 2004", "Yesterday morning", "01/12/2004", etc.) but it's better than nothing, and means that metadata from sound-juicer won't be completely lost.
We have that, we use julian dates (and internally, we use glib's GDate). And the code looks correct. I don't see this going wrong (although it obviously does go wrong. Free-text string conversion is left to applications.
add_one_tag() in gstlame.c is buggy; if it doesn't know how to write a tag it will try to write an uninitialized pointer. I don't know why lame is writing tags at all. There are a number of bugs open about lame and tag writing, but people should be using id3mux instead. Perhaps we should remove this code from lame.
Andy, can we do "lame ! id3mux" and expect it to work?
Mmm, it should, if you send the tag events directly to id3mux. Otherwise if they come in the pipeline I think lame will eat them. lame needs fixing. id3mux might need love as well, I don't know of anyone that uses it.
GST_TAG_DATE handling is fixed for the 0.10 lame element as well now: 2006-01-23 Tim-Philipp Muller <tim at centricular dot net> * ext/lame/gstlame.c: (add_one_tag): Fix handling of GST_TAG_DATE (#311679), don't pass an uninitialised string pointer to lame if we don't know how to handle the tag type, and fix minor memory leak. Are there still other outstanding issues now?
Should this be closed?