Soundconverter creates VBR MP3 files with incorrect length/bitrate

[James Lee]

Binary package hint: soundconverter

Installed soundconverter (0.9.1) through Synaptic, on Ubuntu Edgy. I have the gstreamer0.10-plugins-ugly and gstreamer0.10-plugins-ugly-multiverse packages installed, so LAME support should be fine.

The mp3 file which is created plays fine and is a sensible size, however the length reported by my media player (Winamp on Windows) is incorrect. Winamp thinks the file is a CBR file (even though the bitrate does change during playback), and the length is reported as filesize / bitrate (which is incorrect, as the bitrate is wrong here).

This is reproducible, using both Vorbis and Musepack files as input (these are the only ones I've tried). Tell me if there's any useful info I can attach here (I'm not attaching the entire mp3 file produced, for copyright reasons).

[James Lee (james-lee)]

Same bug is present in 0.9.3 (using the package in edgy-backports).

[PtOLU8zjbZxlgNOiyGyd (lkgdx5kefrptmd7ccufa-deactivatedaccount)]

The problem is that soundconverted attempts to use gstreamer lame's xingheader option, which hasn't worked ever (see the header comments in this file: http://webcvs.freedesktop.org/gstreamer/gst-plugins-ugly/ext/lame/gstlame.c?revision=1.102&view=markup).

The correct solution, as suggested in that header comment, is to add xingmux to the output pipeline. I'm attaching a unified diff file against 0.9.3-1ubuntu1 that fixes the problem permanently.

I will report this

[PtOLU8zjbZxlgNOiyGyd (lkgdx5kefrptmd7ccufa-deactivatedaccount)]

[I hit the send key before finishing the entry...]

I have already sent the patch upstream and added a comment to an already existing bug report.

Bug:
https://developer.berlios.de/bugs/?func=detailbug&bug_id=6187&group_id=3213

Patch:
https://developer.berlios.de/patch/?func=detailpatch&patch_id=1902&group_id=3213

[James Lee (james-lee)]

Great, thanks for that! I've built this fix on top of the latest 0.9.3 source, and this does indeed fix the problem.

That was quick... presumably this should be in the next soundconverter release - maybe in time for the next Ubuntu.

[William Grant (wgrant)]

As the Debian/Ubuntu maintainer of SoundConverter, I'll wait for a while to see if upstream releases a new version with this patch included. If so, I'll update the package. Otherwise, as it gets close to the release of Feisty, I'll upload a new version of 0.9.3 with the patch applied.

[GautierPortet (kassoulet)]

Thank you for the patch !

But, xingmux seems to be broken:
http://bugzilla.gnome.org/show_bug.cgi?id=397759

I'm not to sure what to do now: without xing header half of mp3
players wrongly handle vbr mp3s, and with a broken xing header the
other half will be angry :)

On 2/26/07, William Grant <email address hidden> wrote:
> As the Debian/Ubuntu maintainer of SoundConverter, I'll wait for a while
> to see if upstream releases a new version with this patch included. If
> so, I'll update the package. Otherwise, as it gets close to the release
> of Feisty, I'll upload a new version of 0.9.3 with the patch applied.

a new version should be out probably tomorrow.

--
Gautier Portet <kassoulet gmail com>
  --==-- http://kassoulet.free.fr --==--

[Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen)]

Has this been fixed yet? I've been hit with this one recently. I converted all my jamendo ogg's to MP3's since my player can't handle them.

Is there a way to fix the length now btw?

PS. Rhythmbox and totem report the wrong length as well.

[William Grant (wgrant)]

I'll upload 0.9.4 to Ubuntu in the next few days.

[William Grant (wgrant)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

  status fixreleased

This is fixed in 0.9.4, which I just uploaded.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF50uJAc+S8KckfcURAgDJAJ9yVjjXUFsPwL+WD8VHcfqkAJHGRwCeMgbt
mxDoWJ72pWmvlftSRgtmhk0=
=gzZg
-----END PGP SIGNATURE-----

[TommyKeswick (mrwilloby-aol)]

I just installed soundconverter (0.9.4-0ubuntu1) on Feisty and the problem still exists.

Transcoding from FLAC to VBR MP3 results in the time/length of track being way off.

[Sune Bredahl (sune-bredahl-deactivatedaccount)]

I still have this issue in soundconverter (1.4.1-0ubuntu1) in Jaunty. ABR and VBR mp3s appear to be 160kbps CBR.

[GautierPortet (kassoulet)]

It's not 160 CBR, but VBR with 160 max. Yes, this sucks.
version 1.4.4 fixes the problem.

http://developer.berlios.de/project/showfiles.php?group_id=3213

[Sune Bredahl (sune-bredahl-deactivatedaccount)]

Great, thanks!

[Ola Sundvall (ola-sundvall-gmail)]

This issue still seems to be alive.. I have converted FLAC files to VBR mp3, quality option Very High. I run Lucid (10.04) with gstreamer0.10-plugins-ugly installed. Soundconverter 1.4.4 seems to do its work but the bad time count is still there. I have tried to repair, rebuild and remove Xing header with mp3 Diags, with no success. Am I doing something wrong? I have a whole bunch of gstreamer0.10-plugins installed (base, good, bad, fluendo etc.), but that is maybe not the problem?

[KevinR (kevin-rotz)]

I agree with Ola, I think that this problem still exists in version 1.4.4 (at least on the version available in Ubuntu). Previously I was running Ubuntu 10.04, but upgraded this week to 10.10.

At first I noticed that when I used VBR to convert some flacs for use on my Android device that the Android player seemed to not only have trouble seeking but also was reporting the wrong time position within files. Just today I converted a few files with Soundconverter and installed MP3 Diags; it reported having a different frame count than the Xing tag reported on the converted files.

[Matt Harrison (mattharrison)]

I am getting the same issue with 1.5.4. If I use CBR than the length reports correctly, but ABR or VBR are both off.

[Matt Harrison (mattharrison)]

The version I had had this line:

if have_xingmux and properties[self.mp3_mode][0]:

I changed it to:

if properties[self.mp3_mode][0]:

and it worked. I couldn't find any reference to have_xingmux being set anywhere in the file.

I looked in the Trunk and that line seems to be changed to:
if available_elements['xingmux'] and properties[self.mp3_mode][0]:

So, it looks like it has been fixed, just not in the version I'm running.

[GautierPortet (kassoulet)]

have_xingmux is not referenced anywhere because it's dynamically created at start, it's replaced by available_elements in the next version, but the generated files will have the same problem.

The real underlying problem is in gstreamer, which seems to be unable to generate a proper xing header.

This problem was fixed back in 2007, I'll investigate to find out what is happening.