Bug 107456 - Wrong bitrate field when encoding mp3 from audio cd
Summary: Wrong bitrate field when encoding mp3 from audio cd
Status: RESOLVED DUPLICATE of bug 79235
Alias: None
Product: kio
Classification: Unmaintained
Component: audiocd (other bugs)
Version First Reported In: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: icefox
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-06-15 12:58 UTC by Iñaki Baz Castillo
Modified: 2005-06-15 21:52 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Iñaki Baz Castillo 2005-06-15 12:58:06 UTC
Version:           desconocido (using KDE 3.4.1, Debian Package 4:3.4.1-1 (3.1))
Compiler:          gcc version 3.3.6 (Debian 1:3.3.6-5)
OS:                Linux (i686) release 2.6.10

KDE 3.4.1.

I select 192kbps for the lame encoding bitrate in KDE, but when I extract the mp3 files from audio cd in audiocd:/ or media:/hdd, the resulting mp3 file has a wrong bitrate label, in fact it shows 32kbps, so file properties shows 32kbps and amaroK too.

If I open this file with XMMS it shows the real value of the bitrate: 192kbps.

If you need more data (like KDE lame encoding configuration...) please tell me.
Comment 1 icefox 2005-06-15 21:05:21 UTC
Do you use variable bit encoding?
Comment 2 Iñaki Baz Castillo 2005-06-15 21:35:44 UTC
|| ------- Do you use variable bit encoding?

Yes, I have selected 224 kbps with variable bit encoding.

If I open the encoded mp3 with XMMS and see "File info" I can read "VBR (avg. 
215 kbps)", so I think is correct.
But if I open the same file with amaroK o see properties with Konqueror I can 
read "Ratio: 32kbps".
215 is OK but 32 not.

Why XMMS can see the real value and KDE not?
Comment 3 icefox 2005-06-15 21:52:39 UTC
This is a duplicate of bug number: 79235.  See it for more details into why it is occurring.  Luckly it has been resolved, but it was a very large code change (complete re-write of the encoder) so I put it in for 3.5 and not part of the 3.4.x releases. 

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