I'm having major problems using lame 3.97 and the RC5 build of lame 3.98 to encode my mp3s. If I use the --preset medium option, lame produces mp3s with the wrong track length. For example, a 3:33 track can show up as having a track length of, say, 10:34. This causes real problems when playing the track on my iPod - fast forward can break, tracks show up multiple times in album listings, the iPod sometimes crashes as it gets to the end of tracks. If I use --preset standard, or don't specify a prefix, track lengths are set correctly. I am not specifying any other options to lame.

The incorrect track length can be seen on my iPod, in the Audio tab of Nautilus's file properties dialog and in Totem Movie Player. In Totem, the track length display actually decreases towards the correct value as the track is played.

For background info, I am transcoding from flac files to mp3 files using a script (flac2mp3.pl by Robin Bowes) that uses flac -d to produce a wav file from a flac file then uses lame to encode the wav file. I haven't yet verified whether this problem occurs when encoding a wav file that wasn't decoded from a flac file. All my transcoding is done on Linux (Debian stable at home and Ubuntu Feisty Fawn and Ubuntu Gutsy Gibbon at work).

Does anyone else get this behaviour when using --preset medium? Can anyone suggest a workaround?

Thanks,

Max Spicer

If lame is encoding from wav files to mp3, who writes the tags?

Try -v instead of --preset medium

I've stripped down my transcoding process to try and get to the bottom of this bug. Normally, the flac2mp3 script would transfer tags from my flac files to the mp3s once lame has created them. However, for now I'm just running "lame --preset standard file.wav". The resultant mp3 therefore has no artist/album/whatever information, and the (incorrect) track length data is derived directly from the (tagless) wav file by lame.

Max



I've just tried this and get exactly the same problem with the track length. Interesting...

Can anyone else confirm whether they get this problem when encoding wav files with either the medium preset or VBR?

Thanks,

Max

If your player software wants to know the track length by looking at an ID3v2 entry TLEN, then your MP3s need to have an ID3v2 tag added.
You may try to add "--add-id3v2 --ta TEST" to your test command above. This will force LAME to add an ID3v2 tag. If you leave out any tagging options, LAME will not add any ID3 tag.

Thanks, I just tried that but get exactly the same results as with --preset medium or -v. I don't think this is a player issue, rather an issue with the mp3 file that lame is producing. I've just tried with mplayer on the mp3 with an id3v2 tag. It reported the track length as 08:09.0. However, it reports the track length on the original wav file as 07:11.0. Basically, no player agrees with any other player.

My latest mp3 was created as follows:
lame --preset medium --add-id3v2 --ta TEST test.wav

Changing --preset medium to -v in the above command gives the same results. In fact, changing --preset medium to --preset standard also gives the same results, whereas using just --preset standard and no other options works fine, which is odd. This was all done with the RC5 build of lame 3.98.

Max

Well, totem always displays the correct play-time on my Linux machine, but when I add the "-t" commandline switch, which disables writing the LAME tag. Do you get the message Writing LAME Tag...done at the end of encoding?

What RC5?

Probably meant b5, I would chalk it up as a typo.

Sorry, I mean b5.

Max



I do get Writing LAME Tag...done at the end of the encoding.

To try and narrow things down a bit, I just tried encoding a wav file that hadn't been decoded from flac first. However, this made no difference.

Is it possible that something else on my system is causing these problems? It happens on two completely separate machines - one running Debian/lenny and the other running Ubuntu/Gutsy Gibbon. Obviously, Debian is the common denominator here. I'll try things out in my Windows VM and report back.

Max

I downloaded Lame 3.98B5 to my Windows XP VM and tried encoding a wav file there. Windows reported the correct track length for the resulting mp3, but if I then copied the mp3 to my Linux box, Totem and Nautilus both reported the wrong track length. It really does look as if there's a bug in the Lame encoder to me. It should surely be able to produce iPod compatible mp3s when called with -v or --preset medium.

Max

If the same MP3 files are OK under Windows but not good under Debian, how can you conclude that there is an encoder problem? To me it looks like a bug in the media library Totem and Nautilus use.

How should the track length be derived? Is it read out of a tag, or calculated from the mp3 itself? Can you recommend a not-broken Linux player that I could use to test this?

Thanks,

Max

The Lame/Xing tag contains the number of encoded MPEG frames. Each frame codes a fixed number of audio samples. There comes the track length.

Some players may rely on attributes in ID3v2, but that's not the right way.

I know this thread is a little old, but this problem still seems to exist in lame 3.98.2.

https://bugs.launchpad.net/ubuntu/+source/g...0.10/+bug/35112

http://ubuntuforums.org/showthread.php?t=270030
(references the above URL)

I would gladly accept the "it's still a bug" response, but Mr. Spoon seems to have found a way around the issue.

dBpoweramp does not suffer from this bug (even in version r12.2, which uses lame 3.97). If you don't mind sharing, how'd you do it, man?

Thanks for your help!

It may be a bug in the frontend using LAME. If LAME is used in a way, such that seeking isn't possible, then LAME cannot write correct LAME/Xing header and your players may show play times way off (because they guess it being some 128 kbps CBR file, depending on the very first frame, and take file length into account, instead of number of frames, which they would have to find and count). And then there is the possibility of simply disabling Xing header too (bad idea, but sometimes in very rare cases you need this feature).
Another source of problems are players, which still don't have any clue about VBR files and how to get the correct play time.

In my particular case, it was my own fault. I was using the -t flag, which means "disable writing LAME tag". Is a "LAME tag" different from an ID3 tag? I didn't want LAME writing the ID3 tags (I wanted to write them using another method), which is why I was using the -t flag.

When I replaced -t with -T (which, conversely, forces LAME to write the tag), audio players such as WinAmp detected the correct track length.

Are there any experts who are able to clarify this issue? Does "LAME tag" refer to an ID3 tag, or are they two different entities?

Thanks!

"LAME tag" has nothing todo with ID3 tags. LAME will write ID3 tags only, if you tell LAME todo so.

Actually I am experiencing this issue using dbpoweramp r13 with lame 3.98.2 (which shows up in dbpoweramps tags as 3.98a). When I encode with m4a and ogg, everything is good , but lame causes foobar to report longer track lengths then the tag shows. These are all flac conversions. Haven't tried from a cd.

Bump. Anybody? I am still having the issue. I Just encoded On The Run and Time from Pink Floyd/DSOTM using dBpoweramp r13.1 converting to lame 3.98 which is showing up in the tags that dBpoweramp shows when highlighting the file in Windows as Lame 3.98U. The tracks that were encoded at V0, V2, V4, V5 and ABR160 all show up as the wrong track lengths in foobar. Most showed up as longer then the actual song, but one of them was less. I also encoded them at CBR256 and the track lengths came up correct. Any ideas?

Thanks