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 617545 - Files created with lamemp3enc does not show correct values (at least) for length and bitrate.
Files created with lamemp3enc does not show correct values (at least) for len...
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
0.10.14
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-05-03 16:50 UTC by Yogesh Marwaha
Modified: 2010-05-03 17:30 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Yogesh Marwaha 2010-05-03 16:50:21 UTC 
Using 'lame' element (which is deprecated, as per documentation) everything seems fine but when 'lamemp3enc' is used files so created does not show correct values for length and bitrate, though it plays fine.

Here are the examples: -

gst-launch -v cdda://1 ! audioconvert ! lame ! filesink location=track.mp3
gst-launch -v cdda://1 ! audioconvert ! lamemp3enc ! filesink location=track.mp3

Using lame: length: 285; bitrate:128; size:4.4 MiB
Using lamemp3enc: length: 1054; bitrate:32; size:4.0 MiB


gstreamer version: 0.10.29
gstreamer-ugly version: 0.10.14
I'm on openSUSE 11.2 32-bit
Comment 1 Sebastian Dröge (slomo) 2010-05-03 17:30:41 UTC 
You have to add the xingmux element after lamemp3enc (or lame) if encoding in variable bitrate mode. Otherwise the length can't be estimated properly.

(It worked with plain lame because that defaulted to 128 kbit/s constant bitrate while lamemp3enc defaults to a more useful variable bitrate profile)