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: about encoding and decoding using lame (Read 2349 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

about encoding and decoding using lame

hello every one!
I encoded and then decoded a piece of wav file using lame 3.96.I‘ve met some problems:
1.  if the number of samples in file is 819200, the expect number of frame in mp3 file is 819200/1152~=712.but actually, it is 714 (822528 samples). the lame showed following comments:
Frame                |  CPU time/estim | REAL time/estim | play/CPU |    ETA
710/713  (100%)|    0:00/    0:00|    0:01/    0:01|  20.449x|    0:00
2.  if i decod the mp3  to wav using decode option, the lame shows following comments:
skipping initial 1105 samples (encoder+decoder delay)

Is there anyone who explain them clearly for me?
thanks

about encoding and decoding using lame

Reply #1 –
This is what probably happened:

You got 714 or 715 mp3 frames
one of'em being a "header frame" containing the LAME-Tag (and no audio -- or at least no samples of your signal)
and the remaining frames are "audio frames"

Due to the nature of the filterbank frames overlap -- one frame is derived by MORE than 1152 samples and also AFFECTS more than 1152 samples. That's the reason for the filterbank delay (on both sides, encoder & decoder). So, when you decode the MP3 again, you need to skip some samples at the start to compensate for the delay. Because of this delay and to make the signal a multiple of 1152 samples the encoder pads the signal at the end with at least 1152 null samples (usually more) so the decoder is able to correctly decode the end as well.

Now, the current LAME version (as decoder) is known to compensate for the delay at the start (so your original and decoded files are in sync) but it won't remove trailing samples (that have been padded) like the Foobar2k player does. (The amount of padding is specified in the LAME header, so a decoder COULD compensate for that, too)

Another thing is: Due to the LAME-tag/VBR/INFO header frame (which should not be decoded as an audio frame) OTHER decoders might produce a rather large delay because they DO decode this frame to silence.

Something along those lines

Sebi