GNOME Bugzilla – Bug 335515
[id3tag] xingmux and id3mux don't work together
Last modified: 2006-10-31 19:22:05 UTC
Please describe the problem: When ripping a CD, use the following pipeline: lame <options> ! xingmux ! id3mux no ID3 tags are written. However: lame <options> ! xingmux ! tagid3v2mux works fine Steps to reproduce: 1. setup an audio property: "audio/x-raw-int,rate=44100,channels=2 ! lame name=enc vbr=4 preset=1001 ! xingmux ! id3mux " 2. use rhythmbox with new ripping patch at #322268 (sound-juicer should also work, but untested 3. rip a CD Actual results: tracks have xingheaders but no ID3 information Expected results: ID3 info be written Does this happen every time? Yes Other information: This pipeline works: "audio/x-raw-int,rate=44100,channels=2 ! lame name=enc vbr=4 preset=1001 ! xingmux ! tagid3v2mux"
Using the "xingmux ! id3mux", when the rip is in progress it appears that the tags are being written to the file (checking using hexdump) and "file new.mp3" reports it as having ID3 tags, but after it has been written, the tags are removed (maybe by the xingmux element?)
It might be id3mux putting xingmux at the beginning of the stream (where it just added its ID3v2 tag) rather than at the beginning of the mp3 data (ie right after the ID3v2 tag) when xingmux tries to seek to 0 upon receiving EOS.
Created attachment 61831 [details] hexdump of in-progress rip (before xingmux writes headers) hexdump -Cv of file before end of rip using "xingmux ! id3mux"
Created attachment 61832 [details] hexdump after rip is complete (xing headers written)
If tagid3v2mux works and id3mux doesn't, then this is most likely an id3mux bug. I suspect it probably doesn't adjust newsegment event offsets properly or something similar. For the time being I prefer getting id3v2tagmux in a state where it can be moved into -good (and then ultimately replace id3mux) rather than trying to fix up the rather messy id3mux codebase.
Oops, sorry for the wrong reassignments from -ugly to -good, I mixed id3mux (from -bad) and id3demux (from -good) ;)
What's the status on this? Has this been resolved by your other fixes to id3mux by any chance, Alex?
Now that the id3v2mux is in -good and in the released version and id3mux is deprecated in favour of the taglib-based retagger, I'm closing this as a WONTFIX. I haven't tested whether my fixes to id3mux fixed it yet, but given that id3mux is broken in so many other ways, seems sensible to be close this bug.
*** Bug 368420 has been marked as a duplicate of this bug. ***