MP3 track times are incorrect

Note: this problem does not occur in GRIP, or Goobox, or...

first of all (but unrelated) you should add id3mux at the end of your pipeline to get correct tags ;)

the song times are showed incorrect because there's currently nothing that writes xing headers. in plugins-bad in CVS there was a new element added to do this some days ago, maybe we get this for dapper.

Also unrelated: In that case, I recommend that the id3mux thing get added to the documentation. I'd have never found out about that, otherwise.

Do Xing headers also control what bitrate is reported?

The latest gstreamer0.10-plugins-ugly-multiverse package installs a encoding profile with a pipeline with id3mux... so no documentation needed normally ;)

The xing header includes the track length and average bitrate afaik (or maybe only the length... average bitrate could be calculated from that ;) ). It shows you 32kbit/s because that's the bitrate of the first frame in your MP3 which is quite normal.

After asking on IRC it seems that the xingheader element will stay in plugins-bad for the next time... but I guess I'll package a new CVS snapshot of plugin-bad soon.

Again, offtopic, but id3mux didn't work. Does this even count as a bug? I think it should, because the default sound-ripping option for Ubuntu (sound-juicer) doesn't really make good MP3 rips _at all_, and Dapper is supposed to be all about polish.

This is not a complaint, I'm just saying. It's bad enough (what with the pipeline thing, and the no tags thing, and the track-length thing) that I have actually stopped using Sound-Juicer for the time being (using GRIP now). Which is a shame, because I really liked SJ enough to fix the tags myself, but the track time thing is kind of a showstopper for me.

should that bug be reassign to some gst package?

I'm not sure... whatever you think is best, I suppose.

I've also experianced this bug. It is VERY brutal when exporting these mp3s to iPods or other mp3 players. Seeking was totally disfunctional with the ipod with these messed up track times. I had to rerip my library with grip to get it to work...

Do you still have the issue with the new sound-juicer version? The NEWS for 2.14.1 mentions that:

"* Ship a copy of taglibid3mux and tell people to use id3mux when creating the MP3 profile"

Latest version of SJ as of today. MP3 profile line:

audio/x-raw-int,rate=44100,channels=2 ! lame name=enc quality=0 vbr=4 vbr-quality=2 ! id3mux

Result: Tags are actually correct, but track times are not. They may actually be worse: an 8:00 song reported as 53:57. The whole CD rip is similarly screwed. Am I using the correct audio profile line above?

Sebastian, do you know if that's the correct way to encode?

GonzO, could you install gstreamer0.10-plugins-bad and then try the following pipelines:
audio/x-raw-int,rate=44100,channels=2 ! lame name=enc quality=0 vbr=4 vbr-quality=2 ! id3mux ! xingmux

audio/x-raw-int,rate=44100,channels=2 ! lame name=enc quality=0 vbr=4 vbr-quality=2 ! xingmux! id3mux

I'm not entirely sure where the xingmuxer must be located so please report back which of the two works or if it doesn't change anything at all :)

Neither seems to work. However: the time DOES report right in Xmms and BMP, and the file access is a little less wonky (previously, the incorrect files used to take longer to process and select - I had assumed that this was because of the incorrect times).

However, Rhythmbox still sees the time way off - a 5:00 song was reported as being 28 and change in RB. So, either it didn't work, or it did work, and RB doesn't know what to do with xing headers.

How can I differentiate?

I'm seeing this bug with 6.06.1 LTS. Track times are incorrect in Rhythmbox, Serpentine and Cowbell. The first 2 showed exactly the same "way off" duration, but Cowbell was only a little off.

Track times for Banshee, VLC, Totem and Nautilus properties seem fine.

(The command I used was audio/x-raw-int,rate=44100,channels=2 ! lame name=enc vbr=4 vbr-quality=2 ! xingmux ! id3v2mux)

So I'd say it worked but Rhythmbox, Serpentine and Cowbell aren't using the xing headers correctly.

Same problem.

Dapper 6.06.1
Soundjuicer 2.14.4
GStreamer Pipeline: audio/x-raw-int,rate=44100,channels=2 ! lame name=enc preset=1001 ! xingmux ! id2v3mux

My results:

- the bitrate is shown correctly in Nautilus, Totem and Rhythmbox
- the track time is shown correctly in Rhythmbox
- the track time is wrong in Totem and Nautilus

See also:

http://ubuntuforums.org/showthread.php?p=1505971

Same problem here. Ubuntu 6.06.1, libgstlame 0.10.3, sound-juicer 2.14.4, rhythmbox 0.9.4.1

For me, using the xingmux-plugin it works in xmms, but still not in rhythmbox. By chance, I seem to have found a solution that works (at least for me), though:

The gst-lame documentation (gst-inspect-0.10 lame) lists a "xingheader" option, but states that it is broken, and one is to use xingmux instead. I still tried it, and lo! It works! The pipeline I used is:

audio/x-raw-int,rate=44100,channels=2!lame name=enc preset=1001, xingheader ! id3v2mux

With this, track-lengths are displayed correctly in nautilus, xmms and rhythmbox, and seeking in the files works as expected.

Closing as fixed then...

I have this bug too (ubuntu 6.10, rhythmbox 0.9.6, gstreamer-ugly 0.10.3)

The wiki had a pipeline without xingheader, and the tracks' times were wrong (using that header). Also, since the documentation says that xingheader is broken, I wouldn't really call that a very good fix.

Even so,the pipeline suggested does not work in Rhythmbox; it gives an error "no element xingheader"

I used xingmux like so

audio/x-raw-int,rate=44100,channels=2!lame name=enc preset=1001 ! xingmux ! id3v2mux

And it ripped just fine, however:
Totem displays the time differently all the time (it keeps changing during playback), and Rhythmbox wouldn't import the file, giving a "The MIME type of the file could not be identified" error.

Also, in the thread mentioned, the bug was encountered as of three weeks ago by another member and myself.

This should not have been closed as fixed, as this is still a bug. The following pipelines do not have correct ID3 or track times in Edgy:

audio/x-raw-int,rate=44100,channels=2 ! lame name=enc vbr=4 vbr-quality=2 ! xingmux ! id3v2mux
audio/x-raw-int,rate=44100,channels=2 ! lame name=enc preset=1001 ! id3v2mux

Looks like gstreamer has problems with VBR.

This is still an issue in Feisty (7.04). This pipeline also fails to get the correct track times when playing the resulting mp3 file with Amarok:

audio/x-raw-int,rate=44100,channels=2 ! lame name=enc preset=1001 ! xingmux ! id3v2mux

For what it's worth, I have this same problem with LAME on Windows, too, but only when I have it set to encode through the standard input. Then, iTunes doesn't read track names correctly either. Perhaps the issue lies with the encoder?

I can also confirm that the bug still exists in Feisty.

Using xingheader instead of xingmux (see comment #17) fixed the problem for me. It seemed to worked for a while, so I stopped paying attention.

Recently I dug into it again and noticed that the problem reappeared, at least since January 9th 2007.

Right now:
- "xingheader ! id3v2mux" results in wrong bitrate and track time
- "xingmux ! id3v2mux" results in wrong track time in Totem and Nautilus.

Output of "checkmp3 rippedfileusingxingmux.mp3":

Possible ID3v2 frame found, skipping

An expected frame was not found. Expected it at offset 0x614 (BYTE 1556), now at offset 0x615 (BYTE 1557).
FILE_NAME rippedfileusingxingmux.mp3
GOOD_FRAMES 12760
BAD_FRAMES 1
LAST_BYTE_CHECKED 8059949
VBR_HIGH 320
VBR_LOW 32
VBR_AVERAGE 193
SONG_LENGTH 05:33.34

USER_TIME 0.08s
SYS_TIME 0.03s

This problem still occurs in Gutsy.
Even using "xingmux" the times are not correctly reported in some applications, like Amarok.

Can confirm this in Gutsy. Seems to happen with VBR settings. In Gutsy (for me) there's also the problem, that pipelines including "xingmux" will not appear to be selected in sound-juicer, though are listed in gstreamer pipelines.

However, instead auf xingmux I tried ffmux_mpeg (ffmpeg packages) it works better, but still quite often totally wrong lenght information in totem, rhythmbox (especially) and nautilus.

Without ffmux_mpeg or xingmux (which does not work at all) results are even worse. Personally I don't need mp3 support, but at least when hardy gets released I will recommend ubuntu to more non-technical friends and family. Some of them need correct VBR mp3s. I think mp3 with CBR is not an option. ;-) But the VBRs make problems with many apps, for example with serpentine, when burning an audio cd. If you have many 3-4 min songs, which are displayed as 12 or 15 min songs, you can not measure how much space on the cd will be used.

PS: I noticed with "checkmp3" that nautilus displays the VBR rate also wrong, it shows only the lowest rate used (VBR_LOW) though it must be VBR_AVERAGE.

I have the same problem in gutsy. what a pain. i can't burn cd's because gnomebaker thinks all my 3 minute songs are 15 minutes long.

I have a problem in Hardy Heron, but this only started happening recently.

My pipeline is :

audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=0 vbr-quality=2 preset=extreme ! id3v2mux

I'm getting some song lengths over 10 minutes for a 5 minute song. Some song lengths are over 50 minutes.

Playback seems unaffected, but trying to seek through the song is unwieldly

Due mp3 support can not be officially supported (I guess), this really IS kind of a showstopper bug.

Ripping only CBR mp3s as a workaround is not a good solution. Anyone know why this is so hard to fix? In feisty this worked fine for me. (or at least in edgy) I was hoping this would be solved in hardy. Thanks so far though.

Even though mp3 is not officially supported I think it's very bad that this bug is not fixed for over two (2!!) years.
I understand the reasons to not officially support mp3 but it's a quasi-standard in the digital world.

Does anybody work on this bug any more? Or will we have it still in Ubuntu 10.10? This is one of the bugs who dissapoint non-technophile users very much.

Using Ubuntu 8.10 and this still seems to be an issue. Has any progress been made?

Same problem almost any play show correct time, even checkmp3 says its ok, but rythmenbox mess up the time:
####################
xuedi@delilah:~/music/Jazz/Django Reinhardt/Nuages - Tears/CD 1$ checkmp3 Django\ Reinhardt\ -\ After\ You\'ve\ Gone.mp3
Possible ID3v2 frame found, skipping

FILE_NAME Django Reinhardt - After You've Gone.mp3
GOOD_FRAMES 7137
BAD_FRAMES 0
LAST_BYTE_CHECKED 3545581
VBR_HIGH 320
VBR_LOW 32
VBR_AVERAGE 152
SONG_LENGTH 03:06.43

USER_TIME 0.07s
SYS_TIME 0.00s
###################
For me it would be more interesting if someone knows a tool how to fix that tags afterwards, does someone know such tool?

There's a tool called vbrfix. It looks like it is available as a debian package. I don't know about ubuntu. Gentoo has an ebuild named vbrfixc. It works well for me.

Thanks Derek! Finally some *help*. I'm on intrepid with bells and whistles and was shocked to find out after ripping 9 Gigabytes of my audio CDs using

audio/x-raw-int,rate=44100,channels=2 ! lame preset=extreme mode=0 ! id3v2mux

that most players (including my zen) would be very confused at the times. From the description of the vbrfix package for intrepid I should think it will do exactly what we all want.

Thanks

the problem is still alive

sound-juicer 2.26.1
rhythmbox 0.12.3
gstreamer0.10-ugly 0.10.11
gstreamer0.10-ugly-plugins 0.10.11

using pipeline

audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=1 vbr=4 vbr-min-bitrate=64 vbr-max-bitrate=192 ! id3v2mux

oh yeah, and it doesn't affect only ubuntu (since GNOME can be installed on many other systems anyway); i am using arch linux.

It looks like the "vbrfix" program available through Synaptic fixes this
issue - that is, after processing an MP3 file with vbrfix, the track time
is correctly reported.

From the description in synaptic:

   Unfortunately, the problem is that many MP3 MP3 decoders estimate the
   time of a MP3 file based on the first bitrate they find and the
   filesize. This means that the "prediction" used by such decoders is
   wildly wrong with VBR encoded files and, as a result, you can get
   fairly random times.

[...]

   A VBR null frame is placed at the beginning of the file to tell the MP3
   player information about the song length and indexing through the song.

   The problem arises because some poor encoders don't produce this null
   frame or do so incorrectly and this is what Vbrfix attempts to fix.

So, this is actually 2 or 3 different issues that could be independently
addressed:

a) fixing the encoder to correctly produce that null frame

b) enhancing the mp3 library that rhythmbox relies upon to be more robust
somehow.

c) provide an option to vbrfix files that seem broken from within
Rhythmbox, to repair older rips?

  Brian

Honestly, it looks like this bug has lived forever because it's assigned to the wrong component. I'm sure Sound Juicer can be patched to accurately create the null frame - I don't think this is a problem with the gstreamer framework or how its invoked at all.

This problem can be solved by adding "xingmux" to the gstreamer pipeline.
For example, when I changed the setting for "CD Quality, MP3 (mp3 type)"
from

audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=0 vbr-quality=0 ! id3v2mux

to

audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=0 vbr-quality=0 ! xingmux ! id3v2mux

then track times get encoded perfectly. Seems like all the other metadata
remains intact. Any reason xingmux shouldn't be the default setting?

  Brian

"This problem can be solved by adding "xingmux" to the gstreamer pipeline."

No, it can't - see all the above conversation about the xingheader/xingmux pipeline in this bug report. Fixes it for some apps, but not for others.

On Fri, 21 Aug 2009, GonzO wrote:
> "This problem can be solved by adding "xingmux" to the gstreamer
> pipeline."
>
> No, it can't - see all the above conversation about the
> xingheader/xingmux pipeline in this bug report. Fixes it for some apps,
> but not for others.

Files I have ripped with the pipeline I gave now (under 9.04) appear to
give correct track time lengths in:

rhythmbox
nautilus
serpentine
mplayer
totem

"checkmp3" seems happy with these files too, unlike those of previous
posters.

Could someone check amarok, others?

  Brian

I can confirm that the following command line outputs right bitrate and right track time in Totem on the Arch Linux distribution:

audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=0 preset=standard ! xingmux ! id3v2mux

It should be alright as well in both Ubuntu Karmic and Lucid, I suppose.

Unfortunately this problem is very much still alive!!!! I did NOT have this problem with Jaunty. I've recently done a clean install of Karmic and two problems occur:
1. The track lengths are reported as way too long, i.e a 4/5 min track is reported as 30-40 mins or so
and..
2. the file size of the ripped tracks are significicantly larger than before using the same pipeline settings. e.g
a track that was ripped as 5MB before is now over 7MB

It's only after removing Rhythmbox and reinstalling several times that I managed to get it to play at all.

Rhythmbox 0.12.5
Soundjuicer 2.28.0-1

Well adding "xingmux" to the gstreamer pipeline as described above seems to fix the track length bug in Karmic.

However, it does not fix the file size problem. Should I report this as a seperate bug?

Mike

I confirm, that adding xingmux solves the track length issue in Karmic.