After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 329184 - [lame] remove tag writing support
[lame] remove tag writing support
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
git master
Other Linux
: High normal
: 0.10.4
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 326903 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-01-30 10:18 UTC by Tim-Philipp Müller
Modified: 2006-05-06 11:39 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Start of doubly-tagged MP3 (4.38 KB, audio/mpeg)
2006-04-15 07:29 UTC, Joe Wreschnig
Details

Description Tim-Philipp Müller 2006-01-30 10:18:15 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).
Comment 1 Andy Wingo 2006-01-31 10:25:20 UTC
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.
Comment 2 Andy Wingo 2006-02-07 12:44:52 UTC
*** Bug 326903 has been marked as a duplicate of this bug. ***
Comment 3 Alex Lancaster 2006-02-16 15:34:29 UTC
(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).

Comment 4 Alex Lancaster 2006-03-23 10:09:18 UTC
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.
Comment 5 Alex Lancaster 2006-03-23 10:11:25 UTC
(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). 

Comment 6 Tim-Philipp Müller 2006-03-23 11:33:36 UTC
No, it hasn't been removed yet on purpose, it just doesn't work properly (partly probably because we don't flush at EOS)
Comment 7 Alex Lancaster 2006-03-23 12:10:04 UTC
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.
Comment 8 Joe Wreschnig 2006-04-15 07:29:05 UTC
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.
Comment 9 Joe Wreschnig 2006-04-15 07:29:29 UTC
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.
Comment 10 Tim-Philipp Müller 2006-05-06 11:39:04 UTC
 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.