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 320767 - lame may insert id3v1 tag structures inside of mp3 data
lame may insert id3v1 tag structures inside of mp3 data
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
Other Linux
: Normal normal
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 326438 (view as bug list)
Depends on:
Reported: 2005-11-05 16:07 UTC by Shun-ichi TAHARA
Modified: 2006-05-06 11:53 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12

Top 4.75lB of mp3 files (4.75 KB, application/octet-stream)
2005-11-05 16:12 UTC, Shun-ichi TAHARA
Bottom 28.5kB of mp3 file. (28.50 KB, application/octet-stream)
2005-11-05 16:14 UTC, Shun-ichi TAHARA
Experimental patch (545 bytes, patch)
2005-11-06 16:26 UTC, Shun-ichi TAHARA
none Details | Review

Description Shun-ichi TAHARA 2005-11-05 16:07:33 UTC
I found the mp3 files generated by lame plugins, which is launched by
sound-juicer, have much leading or trailing garbage.

They contains signature of encoder (LAME), or even id3v1 tag structure!
Especially, id3v1 tag pattern annoys some player using gstreamer mad plugin,
such as rhythmbox.

Are anything wrong around usage of libmp3lame?

I use sound-juicer-2.12.2 and gstreamer-0.8.11 with lame-3.97b.
And set 'audio/x-raw-int,rate=44100,channels=2 ! lame name=enc' as mp3 encoding
pipeline. Older soundjuicer and lame cause same problem, even with
Comment 1 Shun-ichi TAHARA 2005-11-05 16:12:09 UTC
Created attachment 54356 [details]
Top 4.75lB of mp3 files

It has ID3v1 tag structure from the point of offset 0x3DC, but it is still in
file header.
Comment 2 Shun-ichi TAHARA 2005-11-05 16:14:35 UTC
Created attachment 54357 [details]
Bottom 28.5kB of mp3 file.

It has many 'LAME' signatures.
Yes, it holds ID3v1 tag correctly at the bottom of file.
Comment 3 Shun-ichi TAHARA 2005-11-06 16:18:59 UTC
The signatures, like "LAMEx.yy", are not garbages, sorry.
They are inserted by LAME encoder (as a paddings?).

This problem is that ID3v1 tags can be inserted inside MP3 data.

LAME sets ID3 tags when lame_encode_flush() is called,
Gstreamer lame plugin calls this when it gets GST_EVENT_FLUSH.
I suppose it is harmful.

Now I change the summary of this bug.
Comment 4 Shun-ichi TAHARA 2005-11-06 16:26:15 UTC
Created attachment 54389 [details] [review]
Experimental patch

This patch makes the lame plugin ignore GST_EVENT_FLUSH event.

Using sound-juicer with the lame plugin with this patch
can avoid inserting ID3v1 tag structures inside mp3 files,
but I don't understand whether this solution is right.
Comment 5 Andy Wingo 2006-01-13 12:29:33 UTC
Hi Shun-ichi,

I'm not sure what is sending so many flush events. However I do know that 0.8 is not maintained any more :) Ross is porting sound-juicer to 0.10 these days, so when he finishes with that can you give 0.10 a try to see if you have the same issue?

Comment 6 Andy Wingo 2006-01-13 15:52:17 UTC
*** Bug 326438 has been marked as a duplicate of this bug. ***
Comment 7 Ross Burton 2006-03-03 17:25:48 UTC
This is at the end of a MP3 file generated by SJ 2.13 with GStreamer 0.10:

LAME3.97 (beta)
LAME3.97 (beta)
LAME3.97 (beta)
LAME3.97 (beta)
LAME3.97 (beta)
LAME3.97 (beta)
Comment 8 Tim-Philipp Müller 2006-05-06 11:53:39 UTC
Tag writing support has been removed completely from lame, which means the bug described here shouldn't happen any longer. Please re-open if it still does.

 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