Greetings,
I have been experimenting with the Intel UMC::AACEncoder 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 AAC file generated with the Intel AAC encoder, I
notice that it is shifted by about 2 frames (1024 samples per frame in
AAC LC profile). 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.
Thanks.
