GNOME Bugzilla – Bug 329184
[lame] remove tag writing support
Last modified: 2006-05-06 11:39:04 UTC
Tag writing support should be removed from the Lame plugin. (It doesn't work anyway currently, as the last buffer isn't flushed on EOS, so the tag is never pushed out in the current 0.10 version) Reasons: a) it has never worked in the 0.10 series b) Lame only supports a very very small number of tags c) Lame only writes tags with ISO-8859-1 encoding, even when told to write ID3v2 tags, so a lot of users will never be able to write tags containing strings in their language with lame d) Lame writing tags causes problems when used with muxers like avidemux or matroskamux (although one could give lame a property to disable tag writing, but people would still need to find it and disable that). I say let's remove it before it's too late and recommend id3mux as replacement (and check that id3mux actually works).
For the record I have been recommending id3mux, but I don't know if it works. We should check -- although it appears stefan is hacking it.
*** Bug 326903 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > For the record I have been recommending id3mux, but I don't know if it works. > We should check -- although it appears stefan is hacking it. If bug #323658, is any indication, I suspect not. Also bug #309609 has a patch which attempts to use the id3demux ! id3mux pipeline in gst 0.10, but doesn't work and has similar effects to bug #323658 (although it doesn't have the tag duplication problem that ID3 tagging in gst 0.8 has).
Tags don't appear to be written at all using the lame element with CVS gst-plugins-ugly, So has lame ID3 tag writing actually been removed now, or does it just not work properly? If it has been removed, this bug could be closed. I've found that using: "lame <options> | id3mux" works fine. However, no xing headers are written (deprecated) and currently xingmux doesn't work with id3mux, see bug #335515.
(In reply to comment #0) > I say let's remove it before it's too late and recommend id3mux as replacement > (and check that id3mux actually works). id3mux does work now for me using lame (and so does the new tagid3v2mux, using the "lame <options> ! tagid3v2mux" pipeline).
No, it hasn't been removed yet on purpose, it just doesn't work properly (partly probably because we don't flush at EOS)
What's the consequence for a pipeline that uses "lame ! id3mux" if it suddenly starts working? Will id3mux take precedence? Will lame overwrite id3mux's ID3 tags, or will it write two blocks? Seems somewhat dangerous to have it still there but not working. If people start using the id3mux after lame (which James Livingston originally suggested to me to test integrated ripping in rhythmbox, see bug #322268) and lame springs back to life somewhere along the way, I can see many bug reports.
Created attachment 63539 [details] Start of doubly-tagged MP3 This file came from Banshee's CD ripper. It has two ID3 tags; the latter suggests it was written by LAME and is invalid.
Yesterday a Quod Libet user showed me a very odd MP3 file he said came from Banshee; I've attached the first 4KB of it here. From the looks of it, LAME writing is working, because the file has an ID3v2.4 tag followed by an (invalid, improperly encoded) ID3v2.3 tag. Only the latter tag as a TSSE frame, pointing to LAME being its creator. (The ID3v2.4 tag also has some oddities like data length indicators for every frame and a completely empty TLEN frame.) So, please remove LAME tag writing support. It's just generating garbage.
2006-05-06 Tim-Philipp Müller <tim at centricular dot net> * ext/lame/gstlame.c: (gst_lame_get_type), (gst_lame_release_memory), (gst_lame_init), (gst_lame_sink_event), (gst_lame_setup), (gst_lame_change_state): * ext/lame/gstlame.h: Remove tag writing from lame (which was completely broken anyway, #329184). Leaving GstTagSetter interface around for now, albeit non-functional. Should be removed completely in 0.11. Use the 'id3v2mux' plugin from -good for writing tags.