Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Possible bug in LAME 3.98 (Read 5219 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Possible bug in LAME 3.98

I don't know if this has been reported elsewhere, but I have discovered that LAME 3.98 sometimes produces MP3 files that play back at the wrong speed (!).  We are using VBR encoding.  It is possible that CBR files are OK.

LAME 3.98.2 appears to be OK (as are 3.96.1 and 3.97).  I have to say I am baffled that nobody but me seems to have noticed this problem, but two of our users have reported it and sent us sound samples to confirm.  I can post these if anyone is interested.
I am an independent software developer (VinylStudio) based in UK

Possible bug in LAME 3.98

Reply #1
So what's the problem here? If it's fixed in 3.98.2, I don't understand the purpose of this thread.

Possible bug in LAME 3.98

Reply #2
care to reproduce the issue in 3.98?

Possible bug in LAME 3.98

Reply #3
So what's the problem here? If it's fixed in 3.98.2, I don't understand the purpose of this thread.

I guess the purpose is to tell people who have not yet upgraded that they should stop using 3.98.

Also, if the bug was not known about in 3.98 then maybe it is not truly fixed in 3.98.2 but only appears in different samples. We need to know which is the vase.

Possible bug in LAME 3.98

Reply #4
I hope this isn't a lame(!) attempt to drive traffic to your site?

Possible bug in LAME 3.98

Reply #5
I'm not sure I can, but sending LAME 3.98.2 to the user who reported the problem made it go away when generating the same MP3 file in otherwise identical circumstances.

Simon, I resent that remark.  I felt this was something people might like to know.  Nevertheless, I have removed the link.
I am an independent software developer (VinylStudio) based in UK

 

Possible bug in LAME 3.98

Reply #6
Sorry Paul. It's just the link contained exactly the same information as your first post. I was expecting a discussion of the issue on your forum.

Possible bug in LAME 3.98

Reply #7
A sample and a description on how to reproduce the problem would be helpful to solve this issue.

Possible bug in LAME 3.98

Reply #8
To Simon: OK, point taken.

To pdq: yes, quite

To Robert: No, I can't reproduce the problem here, nor I have not observed it during routine testing.  Also, if it were widespread, I'm sure we would have received more bug reports.  But a user has sent in two files, one encoded with LAME 3.98 and one with 3.98.2 from the same source material, which demonstrate the problem.  The one encoded with LAME 3.98 plays about 10% more slowly than it should - specifically the duration is reported as 3:00 (mm:ss) rather than 2:44 as it should be.

The files are here if you want to take a gander:
    http://www.alpinesoft.co.uk/private/correct.mp3 (LAME 3.98.2)
    http://www.alpinesoft.co.uk/private/dragging.mp3 (LAME 3.98)

If you listen to 'dragging.mp3' you will hear the pitch (and tempo) suddenly shift down a tad about 15.8 seconds in.  This then lasts until the end of the track.  correct.mp3 plays correctly.  I have not examined the MP3 frame headers but it looks as if LAME has switched sample rates on us part-way through the file.  We would not handle that correctly (although just one errant frame would not throw us off in this way).  I will see if I can lay my hands on the source material for you.  Encoder parameters are: VBR new, Quality 7, 44kHz.

I had a bug report from another user of a similar (but different in detail) problem but I think that might be a red herring.  Worryingly, his problem did *not* go away with LAME 3.98.2  I have asked him to try LAME 3.96.1.  I will keep you posted. [Edit] This does indeed seem to be a red herring - LAME 3.96.1 does it too.  Some other force seems to be at work.  Leave this one with me. [/Edit].

You know, I hope I'm right about all this.  It would be terribly embarassing otherwise.

---

Addendum: I just took a quick look at the MP3 frame heaers.  They are correct (they all report 44kHz).  But LAME switching (internally) from 44kHz to 48kHz would account for the discrepancy in track duration, pretty much.  I'll try to get you the source material.
I am an independent software developer (VinylStudio) based in UK

Possible bug in LAME 3.98

Reply #9
I've just compared 3.98 with 3.98.2 again, and there are no changes which would count as a fix for the described problem. As the problem seemed to get resolved by sending an update, I believe it could have been "solved" because of a different use case.
<speculation mode on>
Maybe the user had a bunch of files, mostly 44.1 kHz stuff with one 48 kHz file inbetween. After sending him the update, the user encoded only the problem sample and was happy now.
</speculation mode off>
We need more info about what really happened and how the workflow looks like. (Are we talking about lame_enc.dll or lame.exe) There may be some bugs in LAME, but it may be a misunderstanding in using LAME too.

Addendum: I just took a quick look at the MP3 frame heaers.  They are correct (they all report 44kHz).  But LAME switching (internally) from 44kHz to 48kHz would account for the discrepancy in track duration, pretty much.  I'll try to get you the source material.

As duration was extended, it is more like feeding a 48 kHz file and telling LAME the samplerate is 44.1 kHz.

Possible bug in LAME 3.98

Reply #10
Robert,

Thanks for doing that.  As a result, I remain worried that we are still shipping flawed software despite upgrading our users to LAME 3.98.2.

We are talking about lame_enc.dll. None of the things you suggest could feasibly have happened, given the way our software works.  If you listen to the 'dragging' sample I think you will be forced to agree.  The transition happens right in the middle of a section of music, 15.8 seconds in.  Also, the customer was able to reproduce the problem when I asked him to switch back to LAME 3.98 and send me the result.

What I *do* think is that there might have been something subtly different in the encoding process.  One file has a couple of seconds of silence on the front that the other does not.  Anyway, I will see if I can get hold of the source material and reproduce the problem here.  I for one would like to see this laid to rest.  In the meantime, thank you for your time.

Update, 11Nov08:

Well, the customer has kindly sent me his files and I cannot reproduce the fault.  I think, on balance, I am relieved about this.  Nevertheless, *something* is going on and I can't imagine how my own software could cause an effect like this.  Anyway, thank you again Robert for your time.  If I learn anything more I will post back to this thread.  Would someone please reply to this message so that I can make a new post, should I need to in future.  Thanks.
I am an independent software developer (VinylStudio) based in UK