Problem of MP3 encoding

[postaquestion]

I have been experimenting with the Intel UMC::MP3Encoder and the audio_codec_con.exe application and I have noticed something that I wish to confirm here as I did not see it in any of the documentation I looked at. When I look at the waveform of the wav file obtained by decompressing an MP3 file generated with the Intel MP3 encoder, I notice that it is shifted by about 2 frames. This means that when I compress a file, 2 frames of silence are inserted at the beginning. When the file reader reaches the end of the file, the program stops sending out GetFrame requests to the codec and so the compressed file actually misses the two ending frames because everything was shifted due to the two silent frames at the beginning.

I would like to know if this is normal behavior as I wish to use the codec on a per-frame basis meaning that I want to send a frame to the encoder to be encoded and I wish the returned encoded frame to be the one that corresponds to the one I input instead of it being the result of the 1024 samples frame I put in 2 GetFrame calls earlier.

If that is the case, is there a way to get around it? I'm assuming the 2 frame delay is due to some buffering to allow tools that require previous samples to perform their work. However in my case, I need the encoded frame returned to correspond to the input uncompressed samples I put in in the same GetFrame call.

[Ying_S_Intel]

Here is the response provided by our engineeirng team:

The presence of delay between encoded and decoded samples is a normal behavior of audio codecs. The main reasons of this delay are time to frequency domain transformation and look ahead due to block switching algorithms.

To avoid missing frames after decoding file one can extend this file by padding zeros (or just call GetFrame some times more with input buffer filling by 0)

Hope it helps.
Thanks,

Ying