Lame encodes silent signals at a higher bitrate

[yingx2]

I made an audio clip which contains several silent intervals in it and encoded it with Lame 3.97. I was surprised that those muted parts (completely no sounds or noise at all) were not compressed any stronger than the normal passages under VBR compression. Actually I believe they were encoded at a higher bitrate.

You can download the clip here:
http://myweb.hinet.net/home1/joefox/test.wav

I would be really grateful if some nice people can help me to test this "problem" by encoding it with any VBR method offered by Lame. I've also tried some of those alt presets and got the same results. Is this supposed to be a normal behavior?

[tebasuna51]

Tested your sample with Lame 3.97b3 at -V 5.

Signal fragments encoded at 100 Kb/s (in average).
Low volume noise fragments encoded at 74 Kb/s (in average).

Edited your sample replacing noise with real silence and Lame use 32 Kb/s (minimum) for this fragments.

Conclusion: Lame don't recognize the noise automatically :rolleyes:

[GodofaGap]

Yes, your silence is not digital silence. :)

[yingx2]

Thanks a lot! I thought those silent intervals were completely muted. I captured this clip and inserted these "silent" segments by muting and unmuting the line in input back and forth.

Can you please download my encoded clip to tell me its bitrate distribution? I saw the bitrate fluctuate at a pretty high level during the playback of those low volume parts in winamp but maybe it's not so reliable.
http://myweb.hinet.net/home1/joefox/test.mp3

And may I have your edited clip or any audio source with one or several digital silences in the middle for testing purposes?

I know little about audio encoding. As a result, I am not quite comfortable with Lame's VBR compression method. In video compression, dark/low motion/blur scenes always consume much less bits than bright/high motion/sharp ones. As an ameture I would assume the same applies to audio encoding and imagine, for example, heavy metal music should be harder to compress since it's more complex and its audio signal varies really dramtically. But I see no such pattern in terms of bitrate allocation for my VBR mp3 encodes. It looks to me like it's just jumping up and down quite randomly throughout the whole song, soft part or noisy part alike. Can you offer a simple explaination about how Lame's VBR algorithm works in layman's terms? I know this isn't such a good request...

[tebasuna51]

Can you please download my encoded clip to tell me its bitrate distribution? I saw the bitrate fluctuate at a pretty high level during the playback of those low volume parts in winamp but maybe it's not so reliable.
Your test.mp3: sounds 188 Kb/s, silences 163 Kb/s
My test_v5.mp3 (http://www.mytempdir.com/910200): sounds 100 Kb/s, silences 33 Kb/s

Use an audio editor like Audacity (free, 3 MB download) to make your sources with digital silences.

[GodofaGap]

s an ameture I would assume the same applies to audio encoding and imagine, for example, heavy metal music should be harder to compress since it's more complex and its audio signal varies really dramtically. But I see no such pattern in terms of bitrate allocation for my VBR mp3 encodes. It looks to me like it's just jumping up and down quite randomly throughout the whole song, soft part or noisy part alike.
It works pretty much the same as for video. Heavy metal usually results in high bitrates for a given V setting. It might just be that your intuition in what is difficult and easy to compress is not well developed. Visualising audio compression is a tad more difficult than visualising video compression. For example, in your case where you hear silence, LAME sees a lot of noise. One could argue though, that the psychoacoustic model should be adjusted so that noise below or around the hearing treshold should be ignored. But Lame certainly isn't varying the bitrate at random.

[check]

The winamp bitrate feedback widget shows the bitrate of the frame that is currently being decoded as far as I know. This means that the bitrate will be shown for x milliseconds into the 'future', depending on what length of time you have set the buffer or prebuffer to (I think :P)