GNOME Bugzilla – Bug 675275
MP3 files encode with incorrect track length
Last modified: 2014-04-02 10:01:57 UTC
Distribution: Mageia 2 Cauldron Beta 3 (kernel-desktop-3.3.4-1.mga2) Arch: x86_64 Component Version: Sound Juicer 3.3.90 gstreamer0.10-lame (0.10.19-2.mga2.tainted) lame 3.99.5 (3.99.5-1.mga2.tainted) lib64lame0 3.99.5 (3.99.5-1.mga2.tainted) Description of Problem: When ripping / importing tracks as .mp3, the encoded tracks have an incorrect track length - either too short or ridiculously long. Examples - Track 3's actual length is 4:30 but the ripped mp3 reports only a length of 2:55 Track 13's actual length is 5:43 but the ripped mp3 reports a length of 8:12 I can attach the affected file(s) upon request if it'd help. I'm mostly a graphical user so if I need to do anything fancy involving the command line to help further troubleshoot, I would need assistance. Actual Result(s): MP3s imported by Sound Juicer are corrupted and report incorrect track lengths. Expected Result(s): MP3s should be successfully imported and encoded without errors / defects.
Probably because the file doesn't actually encode a track length and so it's extrapolated from the bitrate, which is variable. Or something.
This is the behaviour I'd expect from VBR mp3s encoded without a xing/lame header (added by the xingmux gstreamer element)
I thought I fixed this in the old SJ so this is totally a regression in the new profile stuff. I'm looking at you, Chrisophe. ;)
Andrew, can you confirm xingmux is installed on your machine? "gst-inspect-0.10 xingmux' should tell you
Output of gst-inspect-0.10 xingmux Factory Details: Long name: MP3 Xing muxer Class: Formatter/Metadata Description: Adds a Xing header to the beginning of a VBR MP3 file Author(s): Christophe Fergeau <teuf@gnome.org> Rank: none (0) Plugin Details: Name: mpegaudioparse Description: MPEG-1 layer 1/2/3 audio stream elements Filename: /usr/lib64/gstreamer-0.10/libgstmpegaudioparse.so Version: 0.10.19 License: LGPL Source module: gst-plugins-ugly Source release date: 2012-02-20 Binary package: Mageia gstreamer0.10-plugins-ugly package Origin URL: http://www.mageia.org/ GObject +----GstObject +----GstElement +----GstXingMux Pad Templates: SINK template: 'sink' Availability: Always Capabilities: audio/mpeg mpegversion: 1 layer: [ 1, 3 ] SRC template: 'src' Availability: Always Capabilities: audio/mpeg mpegversion: 1 layer: [ 1, 3 ] Element Flags: no flags set Element Implementation: Has change_state() function: gst_xing_mux_change_state Has custom save_thyself() function: gst_element_save_thyself Has custom restore_thyself() function: gst_element_restore_thyself Element has no clocking capabilities. Element has no indexing capabilities. Element has no URI handling capabilities. Pads: SRC: 'src' Implementation: Has custom eventfunc(): gst_pad_event_default Has custom queryfunc(): gst_pad_query_default Has custom iterintlinkfunc(): gst_pad_iterate_internal_links_default Has acceptcapsfunc(): gst_pad_acceptcaps_default Pad Template: 'src' SINK: 'sink' Implementation: Has chainfunc(): gst_xing_mux_chain Has custom eventfunc(): gst_xing_mux_sink_event Has custom queryfunc(): gst_pad_query_default Has custom iterintlinkfunc(): gst_pad_iterate_internal_links_default Has setcapsfunc(): gst_pad_proxy_setcaps Has acceptcapsfunc(): gst_pad_acceptcaps_default Pad Template: 'sink' Element Properties: name : The name of the object flags: readable, writable String. Default: "xingmux0"
*** Bug 556201 has been marked as a duplicate of this bug. ***
So this is a problem with the profile implementation in gstreamer. There is a GStreamer bug that I've lost working on this. I guess a workaround is to hack the containers and do more work in SJ.
I can confirm that this happens to me too, quite annoying. Also affects import of CDs via rhythmbox. sound-juicer-3.4.0-1.fc17.x86_64 gstreamer-0.10.36-1.fc17.x86_64 gstreamer-0.10.36-1.fc17.i686 lame-3.99.5-1.fc17.x86_64 rhythmbox-2.97-1.fc17.x86_64
Any chance of a fix soon? Apart from this bug I find sound-juicer the most convenient of the current crop of CD rippers, but the bug makes it just about unusable for me. What about the GStreamer bug? "mp3 duration" and "mp3 length" draw blanks on their bugzilla and I've no idea what else to search for, because I don't understand what you mean by "profile implementation". If it's been fixed in gst-1.0, updating sound-juicer to use that would be a better investment than a workaround IMO. Meanwhile is there a possible user workaround? In GNOME 2 I vaguely remember being able to edit audio "profiles" to control how applications encoded audio, and this involved gst pipeline syntax. In GNOME 3 is it still be possible to edit these profiles, and if so could a user change the pipeline to force it to include xingmux?
One work-around would be to make lame encode into constant-bitrate mp3 instead of VBR until this gets fixed properly.
Any news about this bug? I use Fedora 18 and the bug is still present. I've found some sort of workaround, accordingly to th GStreamer Ugly Plugins 1.0 Plugins Reference Manual [1], by manually adding a Xingmux index to the mp3 with gst-launch audiotestsrc num-buffers=1000 ! audioconvert ! lamemp3enc ! xingmux ! filesink location=example.mp3 but you need to do this for every single song and it's very annoying. Isn't there a way to automatically do this during the ripping/importing with Rhythmbox or SoundJuicer? I check on Asunder and it creates the Xingmux index automatically. You can check if the song has the Xingmux index with strings example.mp3 | grep Xing Like Tony Houghton I find sound juicer very nice and it's a pity that it is affected by this bug...but switching to the obsolete constant-bitrate is not an option imho. Thanks for all your efforts, regards Marco Milone [1] http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-ugly-plugins/html/gst-plugins-ugly-plugins-xingmux.html [2] http://littlesvr.ca/asunder/
Created attachment 257337 [details] [review] Fix MP3 encoding This is a bit of a hack but it's the simplest way I could think of to fix it. Gstreamer's encodebin creates variable bitrate MP3 files without an Xing header (bug 649841) which means their length and bitrate are misreported. Fix this by making MP3 a special case with our own pipeline rather than using encodebin.
Thanks Philip for the update on this. Would this fix change/affect the final encoding? Thanks again, this is much appreciated, the bug makes soundjuicer almost useless.
Hi Marco, the patch doesn't change any of the encoding settings, it just adds the xingmux element to create the xing header.
Perfect, thanks again!
Review of attachment 257337 [details] [review]: Did you try just appending a ! xingmux element after encodebin in the mp3 case rather than manually creating the pipeline? A bit more special casing is needed in the sj_extractor_supports_profile() codepaths, especially as mp3 is one of the codecs most likely to be missing. ::: libjuicer/sj-extractor.c @@ +274,3 @@ GstElement *encodebin; + const char *profile_name; + static const char * mp3_pipline = "lamemp3enc ! xingmux ! id3v2mux"; mp3_pipeline, not pipline
Review of attachment 257337 [details] [review]: Scratch my comment about appending ! xingmux as this is not going to work since we'll end up with roughly lamemp3enc ! id3mux ! xingmux. Some gstreamer guy was telling me this should be working with encodebin though :-/
I don't think this can work already with encodebin, as far as I know it only supports one "container/tag", but you need two basically. What you can do is register a static (application-specific) plugin that is just a GstBin containing id3mux + xingmux and that proxies the tag setter interface (if needed). Pretend it's a muxer and use custom caps, or give it a higher rank than id3mux, so that encodebin then picks that bin as muxer element.
gstencodebin has two comments here: http://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/gst/encoding/gstencodebin.c#n108 /* TODO/FIXME * * Handling mp3!xing!idv3 and theora!ogg tagsetting scenarios: * Once we have chosen a muxer: * When a new stream is requested: * If muxer isn't 'Formatter' OR doesn't have a TagSetter interface: * Find a Formatter for the given stream (preferably with TagSetter) * Insert that before muxer **/ http://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/gst/encoding/gstencodebin.c#n1156 /* Check if we need a formatter * If we have no muxer or * if the muxer isn't a formatter and doesn't implement the tagsetter interface */ Unfortunately this wont help :/ The id3mux elements are Formatters and implement the TagSetter. The xingmux elemnt is not a muxer and is not autopluggable. Setting rank=marginal and adding it to the muxer category + creating a container profile for "audio/mpeg, mpegversion=1, layer=3", will plug xingmux, but then we won't get id3mux. Creating a nested container profile unfortunately does not work (bug?). id3mux : Formatter/Metadata Implemented Interfaces: GstTagSetter Pad Templates: SRC template: 'src' application/x-id3 SINK template: 'sink' ANY id3v2mux : Formatter/Metadata Implemented Interfaces: GstTagSetter Pad Templates: SRC template: 'src' application/x-id3 SINK template: 'sink' ANY xingmux: Formatter/Metadata, RANK_NONE Pad Templates: SINK template: 'sink' audio/mpeg, mpegversion: 1, layer: [ 1, 3 ] SRC template: 'src' audio/mpeg, mpegversion: 1, layer: [ 1, 3 ]
any progress?
This still happens in sound-juicer 3.5.0. It is a regression from older GNOME when you could edit the gst pipeline used by sound-juicer directly.
Created attachment 270246 [details] [review] (In reply to comment #16) >Did you try just appending a ! xingmux element after encodebin in the mp3 case >rather than manually creating the pipeline? I tried it with gst-launch before I wrote the original patch, as you predicted it didn't work. >A bit more special casing is needed in the sj_extractor_supports_profile() >codepaths, especially as mp3 is one of the codecs most likely to be missing. I've added that now although if the mp3 encoder is missing wont !rb_gst_check_missing_plugins (profile, NULL, NULL) work as the profile still contains the missing encoder? There is the possibility that the profile specifies a proprietary mp3 encoder so we should still check for lamemp3enc though. >::: libjuicer/sj-extractor.c >@@ +274,3 @@ > GstElement *encodebin; >+ const char *profile_name; >+ static const char * mp3_pipline = "lamemp3enc ! xingmux ! id3v2mux"; > >mp3_pipeline, not pipline >Fix MP3 encoding Fixed.
*** Bug 725713 has been marked as a duplicate of this bug. ***
(In reply to comment #23) > >A bit more special casing is needed in the sj_extractor_supports_profile() > >codepaths, especially as mp3 is one of the codecs most likely to be missing. > > I've added that now although if the mp3 encoder is missing wont > !rb_gst_check_missing_plugins (profile, NULL, NULL) work as the > profile still contains the missing encoder? There is the possibility > that the profile specifies a proprietary mp3 encoder so we should > still check for lamemp3enc though. What I meant is if we are hardcoding the plugins we are going to use rather than relying on encodebin, we need to make sure these specific plugins are here. The comment about 'as mp3 is one of the codecs most likely to be missing" is indeed a bit off as in usual setups, the rb_gst_check_missing_plugins() call will fail if lamemp3enc is not there.
(not especially enthusiastic into having to have such a workaround in apps but well...)
Attachment 270246 [details] pushed as commit 7eefb93 - Fix MP3 encoding