It ships with a lot of code samples in several languages to help you get started, but it consists on calls to a "Get" method, giving the property name as a string parameter, not always so easy to remember and so use. Therefore, I don't think it's AAC's fault.When it comes to get maximum details about multimedia files, you may use the well known MediaInfo open source software, as it will go deeply in the contained streams, and report all relevant details.īut if you like to build your own application to manage your multimedia files, and want to get all these details, you won't re-invent the wheel, but get the MediaInfo DLL library. if you take one of the offending MP4/M4A/AAC files and extract the AAC audio with MyMP4BoxGUI and check the raw AAC with MediaInfo it'll simply report 6 channels (or whatever the correct channel count may be). but I also assumed the "mp4a.channelcount" problem was a container level problem (ie MP4) and nothing to do with the audio stream (ie AAC) as such. The way I read the explanation here, it seems that MediaInfo knows to ignore the obsolete channel count for other audio formats but for some reason it doesn't for AAC. The subject came up at doom9 a while ago in a thread I was posting in, otherwise I'd probably still be oblivious to the reason myself. It'd be like believing what MediaInfo reports for aspect ratios. Or if I had noticed, I'd just not paid any attention to it. ![]() I'd never even noticed the issue in question because the first thing I do after the audio is encoded is mux it into an MKV along with the video, and MediaInfo then reports the channel count correctly. ![]() I've been encoding multi-channel audio as AAC for years, and I've never had a problem with it. Or you could extract the audio with MyMP4BoxGUI and get MediaInfo to look at the extracted stream.īottom line: It's normal, the audio is 6 channel, and don't take what MediaInfo says as gospel. Maybe the obsolete channel count data gets dumped by MKVMerge during the re-muxing process or it's ignored by MediaInfo when the container is MKA/MKV, but MediaInfo will simply report it as being 6 channel when the AAC audio is in an MKA/MKV container. Or you can open the MP4/M4A with MKVMergeGUI and resave it as an MKA/MKV. ![]() You could import it into Audacity to check the channel count but that's pretty slow. The channel count displayed will change according to the audio being played. There's ways to look at the audio to confirm it's multi-channel-ness, such as playing it with foobar2000 and looking at the output meters. ![]() I tested the popular AAC encoders, and for the record, it appears NeroAAC is the only encoder which doesn't write the obsolete data, as when you view an MP4/M4A written by Nero with MediaInfo, it'll simply show the correct channel count. I don't understand why MediaInfo looks at it at all. Samplerate field is 16.16 fixed-point, so not enough to represent high samplerate such as 96kHz. On the other hand, I can say for sure that nothing in AudioSampleEntry (mp4a) matters and cannot be taken seriously.įor example, samplesize field (typically it is 16) is non-sense for AAC. However, it seems that no such restriction present in the new spec (4th ed Therefore, maybe I should fix qaac to write actual number of channels. Mp4a.channelcount is intentionally set to either 1 or 2, since in the former spec (ISO 14496-12) only 1 or 2 was allowed. This is how the author of QAAC explains it:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |