AAC Encoder and Apple Software

AAC Encoder and Apple Software


I have recently tested out the UMC::AACEncoder through the audio_codec_con.exe application.

I encountered a problem when trying to play those files through QuickTime and iTunes. I have encoded a sample 32 bits signed PCM wav file that is a little more than 5 seconds long.

I have used the following command to perform the conversion and generate an AAC encoded track.

audio_codec_con -ct aac_enc -br 128 -aac_o MP4 -aac_p AAC_LC -aac_s lr -aac_ns 0 Sample.wav Sample.m4a

Now the problem happens when I try to play the file in iTunes or QuickTime. QuickTime outputs no sound and iTunes plays the file but with lots of audible static.

Other software like Winamp and Windows Media Player are able to playback the file correctly. AAC files encoded by iTunes or Nero Digital Audio+ command line tool playback fine on all software as well including iTunes and QuickTime player.

So the question is whether anyone is aware of a discrepancy in either the UMC::AACEncoder or in the apple Quicktime decoder with respect to the AAC format specification that could explain why Apple software cannot playback the files I generated using UMC?


6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Here's an update to the situation.

I was thinking that the problem lay with the Intel implementation so I was wondering whether the problem was the AAC encoding or the packing into an mp4 file.

Therefore I decided to extract the RAW AAC track from the file and then I repackaged it into an mp4 container. That newly generated file played back correctly in iTunes and QuickTime player. So I came to the conclusion that the MP4 container generated by the sample application was not correct. I looked into the container and it was branded as mp41 instead of the m4a or mp4 I was expecting.

Keep in mind that I do not know much about the MP4 container but mp41 did not seem familiar to me. Is this an older version of the MP4 spec?

In any case, all I needed was for the RAW AAC streams to be correct which it seems to be since I am able to read it back after extracting it and repackaging it into an MP4 container. All is well I guess.



there is ISO spec for MP4 container which I believe IPP AAC muxer do support. If you find it is not a case please submit your issue report through Intel Premier Support



I have linked the aac_enc.lib and mp3_enc.lib to audio_codec_con, but when I run it theaudio_codec_con complains codec not found like below:

/_bin/linuxem64t_gcc3> ./audio_codec_con -ct aac_enc -aac_p AAC_LC -br 64 test.wav test.adts
The codec 'aac_enc'is not found.

/_bin/linuxem64t_gcc3> ./audio_codec_con -ct mp3_enc test.wav test.mp3
The codec 'mp3_enc'is not found.

How do I fix it? THanks.

Just to keep everyone on sync with that: IPP audio_codec_con sample relies on shared libraries for codecs, so appropriate shared libraries should be available at run time.



Concerning playback on Apple software. It's a known bug which will be fixed in ver.6.0.

The problem is in MP4Muxer. It sets one wrong bit which is responsible for frame length. Some decoders ignore it and play such streams without problem. Even iPod nano plays it OK. But iTune and QuickTime use it. It seems that they support both 960 and 1024 frame length.


Leave a Comment

Please sign in to add a comment. Not a member? Join today