Skip to main content

Topic: LAME 3.99.5 VBR FAILS at song length (Read 3671 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • bsperan
  • [*]
LAME 3.99.5 VBR FAILS at song length
For years I've been using old software without VBR. Recently, I found myself editing audio and I was excited to use VBR.

After downloading and installing the latest LAME release (3.99.5), I read the documentation and tried to encode some waves.

However, no matter what options I seem to use (and I've tried many different options, including various "MP3 header/stream options"), whatever variable bit rate MP3 I produce gives Winamp a false indication of length. (Specifically, in Winamp v5.601.)

For example, if I encode a .WAV of length 2:16 (2 minutes, 16 seconds), it will produce an MP3 that Winamp identifies as having a length of 7:52.

Now, I realize that I could update my Winamp to a more recent version. However, 1) there are plenty of others out there who use similar outdated decoder software and 2) I am perfectly happy with the Winamp I'm using.

Further, I have never before encountered a problem with a VBR encoded MP3 not displaying the length properly. And I have played a -lot- of different MP3's! This tells me that other people (mostly musicians) are using software to encode their MP3s with VBR in a way that does not confuse my Winamp.

So, please, can somebody tell me what options to use to produce a VBR MP3 that does not confuse older software? Do I need to install an older version of LAME, or what?

At this point, I feel like giving up on LAME or even VBR and going with something else.
  • Last Edit: 15 March, 2013, 09:42:48 PM by bsperan

  • shadowking
  • [*][*][*][*][*]
LAME 3.99.5 VBR FAILS at song length
Reply #1
Try to force minimum bitrate : eg  -V2 -b128 -F

Do you get correct length If you disable tags using -t ?
wavpack -b4x4s1c

  • lvqcl
  • [*][*][*][*][*]
  • Developer
LAME 3.99.5 VBR FAILS at song length
Reply #2
@bsperan:
How exactly do you encode to MP3? what options, commandline switches etc?

@shadowking:
Maybe the problem is that he does use -t switch?
  • Last Edit: 16 March, 2013, 05:09:27 AM by lvqcl

  • [JAZ]
  • [*][*][*][*][*]
LAME 3.99.5 VBR FAILS at song length
Reply #3
It's strange. Winamp has supported correct VBR duration since long ago (back to 2.x versions even).

encoding to vbr with lame is as simple as executing:

lame -V2 infile.wav outfile.mp3

( capital V and no space between V and 2, although I believe that recently the space doesn't matter)

Out of winamp whatsnew, I've only seen this entry in 5.61 that might (just might) have something to do with your wrong duration:
* Fixed: [in_mp3] Wrong bitmask for calculating AAC framelength
* Fixed: [in_mp3] Incorrectly reported approximate frames


Another thing that can cause problems is if you are adding album art or something that winamp doesn't recognize in front of the mp3 file ( Winamp understands ID3 V2 and APE tag, so it should still be able to find the correct VBR header)

  • o-l-a-v
  • [*][*][*]
LAME 3.99.5 VBR FAILS at song length
Reply #4
Encode it with TAudioConverter and see if that works: http://sourceforge.net/projects/taudioconverter/
I've never had problems with that GUI and lame
Does foobar read correct length?

  • bsperan
  • [*]
LAME 3.99.5 VBR FAILS at song length
Reply #5
Try to force minimum bitrate : eg  -V2 -b128 -F

Do you get correct length If you disable tags using -t ?

I have tried forcing min bitrate. Though, I've only tried really low values, such as 32.

And I almost always use the -t option.

@bsperan:
How exactly do you encode to MP3? what options, commandline switches etc?

Typically, I try something like lame -V5 -t input.wav output.mp3. But I've tried that with various extra options, as well.

@shadowking:
Maybe the problem is that he does use -t switch?

That might be. I don't recall weather or not I tried without it.


Out of winamp whatsnew, I've only seen this entry in 5.61 that might (just might) have something to do with your wrong duration:
* Fixed: [in_mp3] Wrong bitmask for calculating AAC framelength
* Fixed: [in_mp3] Incorrectly reported approximate frames

That's very interesting. I just might update Winamp after all.


Another thing that can cause problems is if you are adding album art or something that winamp doesn't recognize in front of the mp3 file ( Winamp understands ID3 V2 and APE tag, so it should still be able to find the correct VBR header)

I don't bother with anything like album art.

Encode it with TAudioConverter and see if that works: http://sourceforge.net/projects/taudioconverter/
I've never had problems with that GUI and lame
Does foobar read correct length?

I'll keep that in mind. However, I had no patience, so I decided to try Audacity 2.0.3 with the LAME 3.99.3 install package. It worked like a charm. 

I'm not sure whether it was the -t switch or what. But I removed LAME 3.99.5 and I don't feel like testing further. I much prefer using Audacity to the command line LAME, anyway. But, one day I might find the need to batch encode a lot of files at once.

BTW: The reason I did not post about this on the Winamp forum is that I became frustrated with their customer support. Specifically, a few years ago I submitted a bug report to their bug report thread. And I was almost completely ignored.

It was a pretty serious bug, too. I reported how adding file info to .ogg (vorbis) damages files. That is, using the "in_vorbis.dll" plugin to edit the tags on a variable bit rate .ogg music file will significantly shrink the file, reduce the bitrate and the music thereafter sounds noticeably worse! (Apparently, the plugin re-encodes the file just to add tag info!  ) But only one member seemed to show any concern about that...

As a workaround, I had to make sure I kept backups of my music and try to remember not to use Winamp to edit tags on .ogg. Instead, I use WinVorbis for that.
  • Last Edit: 16 March, 2013, 03:37:49 PM by bsperan

  • db1989
  • [*][*][*][*][*]
  • Global Moderator
LAME 3.99.5 VBR FAILS at song length
Reply #6
@shadowking:
Maybe the problem is that he does use -t switch?

That might be. I don't recall weather or not I tried without it.

[…]

I'm not sure whether it was the -t switch or what. But I removed LAME 3.99.5 and I don't feel like testing further.

So, wait: you don’t want to do something very easy to test whether the issue was caused by something you did, so you’re just going to stop using LAME? What’s the point of others suggesting fixes if you just say you don’t want to try them? People might as well stop trying to help.

As for the stuff about Winamp and Vorbis, firstly, it’s quite off-topic, and anyway: I’m not going to let it continue unless it can be proven by bit-comparison between unmodified and modified files that the data is being altered (as opposed to, for example, padding being removed). In addition, claims about things sounding “noticeably worse” must be backed up by objective testing methods, as stated clearly in our rules.
  • Last Edit: 16 March, 2013, 03:46:34 PM by db1989

  • lvqcl
  • [*][*][*][*][*]
  • Developer
LAME 3.99.5 VBR FAILS at song length
Reply #7
And maybe -t is not the only suboptimal switch in the command line.

  • bsperan
  • [*]
LAME 3.99.5 VBR FAILS at song length
Reply #8
So, wait: you don’t want to do something very easy to test whether the issue was caused by something you did, so you’re just going to stop using LAME? What’s the point of others suggesting fixes if you just say you don’t want to try them?

No offense, but as I explained: In the meanwhile (since I started this thread) I had found something which worked and was more to my liking that the command line LAME.

I had already uninstalled LAME 3.99.5. Further, I could not recreate the experiment perfectly because I don't have the same .WAV samples now. (At this point, I'm not even sure which samples I had been using.)

But just for your sake:

I reinstalled LAME 3.99.5 and tried some WAVs on that and on LAME 3.99.3. I tried several WAVs in each and whenever I used the -t switch, playing the resulting MP3 in Winamp (v5.601) gave an incorrect length:

lame -V5 -t input.wav output.mp3

Though, in my test cases the length was reported as shorter than actual, rather than longer (as was my original problem).

When I tried the same WAVs with the same options, but left out the -t option:

lame -V5 input.wav output.mp3

...the resulting MP3 played find in Winamp with the correct length.

Also, I got the same results using either v3.99.5 or v3.99.3.

So, from my limited testing, it does seem like using the -t option was the culprit.

People might as well stop trying to help.

I had addressed every reply in this thread. And it's not like I wasn't helped. I learned quite a bit about LAME and Winamp, both. I wasn't aware of those issues with Winamp or that they had been fixed in a more recent version. And while I currently don't plan to use command-line LAME much, it will probably come in hand down the road. (I do take notes about this stuff and keep them with my backups, in case I want to reinstall LAME.)
  • Last Edit: 17 March, 2013, 02:38:45 AM by bsperan

  • [JAZ]
  • [*][*][*][*][*]
LAME 3.99.5 VBR FAILS at song length
Reply #9
Well, yes... it was the -t option.

The -t option has two meanings:

When encoding with Variable bitrate (this case)
-t   Disable VBR informational tag

When decoding to wav
-t   Disable writing wav header when using --decode


In any of both cases. Why would you want to use it? Or said it in other words, was it your decision, or you took the settings from someone else's advice?