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 556201 - mp3 files ripped give wrong bitrate and playtime values
mp3 files ripped give wrong bitrate and playtime values
Status: RESOLVED DUPLICATE of bug 675275
Product: sound-juicer
Classification: Applications
Component: metadata
git master
Other All
: Normal normal
: ---
Assigned To: Sound Juicer Maintainers
Sound Juicer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-10-13 22:17 UTC by Marcin
Modified: 2012-05-18 18:34 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22

Attachments
screenshot of the rhthmbox (245.08 KB, image/png)
2008-10-13 22:19 UTC, Marcin 		Details

Description Marcin 2008-10-13 22:17:46 UTC 
Please describe the problem:
Sound ripped from CD with the following settings:
audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=1 vbr=4 vbr-quality=2 quality=2 ! id3v2mux

give wrong bitratevalues in property boxes of songs. Instead ~ 10-192 kbs gives 32 kbs in gnome nautilus sound file proeprties box and in rhtythmbox.

Also playtime of the song is from the outer space. On the ~ 78 min record playtimes given of songs in above mentioned progs sums far out of range the total total playtime of the record.

Steps to reproduce:
1. Rip with above settings
2. Invoke propeties box of the sounf file in nautilus
3. or import songs in rhthmbox
4. check the bitrate read or play time displayed


Actual results:
values of bitrate and playtimes seems to be unreasonable in property boxes

Expected results:
correct bitrate values ( or its reasonable aproximation if vbr included ) and correct playtimes

Does this happen every time?
yes

Other information:
Comment 1 Marcin 2008-10-13 22:19:22 UTC 
Created attachment 120537 [details]
screenshot of the rhthmbox

This is to aid describe the bug
Comment 2 Marcin 2008-10-13 22:24:20 UTC 
a little correction. in seems to gice values from the range 160-196 kbs. Explanation: I write it from the user view - not technical one. But for the average user if it rips  with high vbr quality reading of 32 kbs  is misleading and gives the feeling that prog is malfunctioning.
Comment 3 Paul W. Frields 2012-05-17 17:32:32 UTC 
This still occurs in the sound-juicer 3.4.0 release.  The problem is a missing "xingmux" element before the id3v2mux.
Comment 4 Ross Burton 2012-05-18 10:26:54 UTC 
Hm.  Christophe, any idea how to get a xingmux in from a profile?  It won't autoconstruct it because it's sink and src caps are audio/mpeg mpegversion=1 layer=1,3.

Hmm.
Comment 5 Christophe Fergeau 2012-05-18 10:53:04 UTC 
Honestly, no clue, I haven't looked at the profile stuff in depth, I've mainly stolen it from rb
Comment 6 Christophe Fergeau 2012-05-18 11:22:31 UTC 
Looking around bugzilla, I've found https://bugzilla.gnome.org/show_bug.cgi?id=649841 which may be relevant. By the way, https://bugzilla.gnome.org/show_bug.cgi?id=675275 is a duplicate, since the encoding code has changed since this bug was opened, I'd tend to mark this one as a duplicate, and have the discussion in bug #675275
Comment 7 Ross Burton 2012-05-18 18:34:31 UTC 
Agreed.

*** This bug has been marked as a duplicate of bug 675275 ***