I have seen this problem both when using Banshee and Sound Juicer. I'm using Ubuntu 12.04 on a Thinkpad 14". I'm not sure about the make of my internal CD drive, but would be glad to provide you with that information if someone tells me how to. I have not had access to an external CD drive so that I could tell if the problem is my internal CD drive.

Anyway, the problem: The mp3 files I have ripped show wrong lengths. For example when I ripped Peacebone by Animal Collective, which's length is 5:13, the file was 25 minutes long, according to my phone and banshee. The players skip to the next song before playing the whole 25 minutes. However, I'm not comfortable not knowing if I'm listening to the whole thing or the real length of the song.

This far the problem has disappeared on a second rip, although the file lengths are still occasionally a few seconds longer than they're supposed to be.

  • After a bit more testing it seems that the music itself has the right lengths: the files whose lengths seem to be too short keep on playing after the displayed track time is over and the files that are too long skip to the next song when they're supposed to. However, the problem is still annoying and makes me worry about the quality of the ripped music.
    – Heihej
    May 12, 2012 at 10:16
  • 2
    Track lengths are often calculated from filelength and average expected mp3 data throughput. Some players continuously recalculate the duration, some don't. Some store the track length in a database once it was figured out, some don't ... Only when a track is fully processed, the exact duration is known.
    – jippie
    May 12, 2012 at 10:45
  • This problem has not been present for all my songs, so its hard to believe that its caused by how the player reads the files. This would still mean there is something wrong with the file.
    – Heihej
    May 12, 2012 at 11:16

2 Answers 2


Starting around Ubuntu 12.04, when you rip CDs in Ubuntu using Rhythmbox or Sound Juicer the default settings will create VBR MP3s, but the VBR headers don't get added, so just about any program you open the MP3s with will show the incorrect track length, including the default music player (Rhythmbox) and the default file manager (Nautilus).

The easiest solution is to add the VBR header to the MP3s after ripping them:

  1. Install vbrfix by running this command in a terminal:

    sudo apt-get install vbrfix
  2. Now CD to the folder where the mp3s are that you need to fix:

    cd /path/to/mp3s
  3. Run this command to add the VBR headers to the mp3s:

    find . -type f -iname '*.mp3' -exec vbrfix {} {} \;
  4. Vbrfix seems to leave behind a couple of temporary files, so clean them up:

    rm vbrfix.log vbrfix.tmp

An alternative solution is to change the default preset so that the CDs are ripped as CBR instead of VBR MP3s. There's a pretty good explanation here: https://askubuntu.com/a/154933/18665

A profile like this ought to do the trick (change the bit rate as desired):


As with any bug, if you're experiencing this problem I'd highly recommend you go to the bug report and mark that it affects you (near the top left), so that it gets more attention. The bug report is here: Rhythmbox does not add VBR headers when ripping CDs to MP3

  • 1
    vbrfix worked for me. Then I rescanned the banshee library to pick up the change.
    – isaaclw
    Apr 30, 2015 at 19:54

From my experience this problem occurs when ID3 tags are invalid. You could try to delete all ID3 tags from the given files and then rewrite them. I recommend mutagen for this, it's a metadata manipulation library with some useful utilites.

First install mutagen

sudo apt-get install python-mutagen

Now go to a folder with some problematic MP3 file and run mid3v2 on it:

mid3v2 --delete-all your_file.mp3

This will remove all metadata from a given file, which means no title, no artist, no album cover, but the file should display correct length.

You can repopulate metadata using e.g. Picard, which is available in Ubuntu as picard package.

Edit: There's also MP3 Diags application which should be able to fix VBR headers and some other problems with MP3 files. It's available in Ubuntu as mp3diags (or from Ubuntu Software Center)

Another, more specific, solution is VBRFix – console version (without Qt GUI) is available in vbrfix package. If you want GUI, you'll probably have to compile it yourself.

  • Thanks for the answer, I was not aware that track length is tagged. Picard told me that the tag was correct in Peacebone, but in the details window it gave me the 25 minute value. I deleted all the tags from the file and, for some reason, can't rewrite the tags with picard, do you know how this is supposed to be done?
    – Heihej
    May 12, 2012 at 11:13
  • Picard works slightly different to other tag editors, you just feed it the tracks to tag and match them with an album from MusicBrainz database. See the howto guide: musicbrainz.org/doc/How_to_Tag_Files_With_Picard If this type of editing doesn't work for you (or you can't find the album in MusicBrainz database), try EasyTAG (easytag package)
    – jnv
    May 12, 2012 at 11:32
  • On the other hand there may be an easier solution with MP3 Diags – mp3diags.sourceforge.net I've edited my answer, take a look.
    – jnv
    May 12, 2012 at 11:46
  • Re-tagging the files doesn't seem to help. I tried to rebuild the VBR data using mp3diags, which was claimed to repair problems with incorrect durations being shown. This did indeed change the duration displayed on my devices for the better, but they still aren't correct (Peacebone is now 6:53 long, while it is supposed to be 5:13).
    – Heihej
    May 12, 2012 at 14:09
  • There's also vbrfix package which is a console version of the aforementioned VBRFix. Otherwise you could try to rip those files again; I can only recommend to use FLAC, Ogg Vorbis or AAC (if your phone can play any of this) but you could also rip the CD as CBR or ABR MP3 which is less prone to invalid length information. Ripping into WAV (or FLAC) and reencoding to VBR MP3 might be also an option. Or just try again with original settings, maybe the encoder just had a bad day.
    – jnv
    May 12, 2012 at 14:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.