Multichannel decoding
Multichannel decoding
- Subject: Multichannel decoding
- From: Alexander Cabanilla <email@hidden>
- Date: Thu, 21 Apr 2011 11:46:28 -0400
Hello all,
I'm currently working on a multichannel decode on the iPhone and having issues around conversions. More specifically, I've created a 6 channel m4a ('aac ') file by using afconvert. As a sanity check, I used afconvert to decode the 6 channel m4a file back to wav and successful created a 6 channel wav file. All's good so far.
I place the m4a file in my iOS project and begin to use the Extended Audio Services to open and decode the file. The file description structures come back fine with the proper sample rate, number of channels, and encoding type. I attempt to set a client file format for audio conversion with the ExtAudioFileSetParameter and kExtAudioFileProperty_ClientDataFormat. This is ok as well. However, any subsequent read to of the file with ExtAudioFileRead produces only two channels. This appears to be a mix down of most of the channels (more on this below). A subsequent read of the associated audio converters channel maps shows {0, 1, -1, -1, -1, -1} indicating exactly what is received from the file read calls -- only the first two channels are populated with the mix down. Any attempt to change the channel map with a channel index beyond 1, e.g. AudioConverterSetProperty with kAudioConverterChannelMap, fails with a return error code of -50. The -50 is not defined in the documentation and I can only assume it is a general error.
What I would like to achieve is a decode of the m4a file into 6 distinct audio channels of pcm values. Unfortunately, I've hit a wall. Does anyone have any ideas?
As as aside, it seems to be that attempting to force specific audio channel layout tags, e.g. Hexagonal, AAC_6_0, etc, can have detrimental effects on the attempt to set the kExtAudioFileProperty_ClientDataFormat. More specifically, it can fail the set property call but still produce a mixed down version.
I have considered attempting to forego the Extended Audio File Services and use Audio File Services instead. However this would only be beneficial if there were known issues with the Extended Audio File Services and not Audio File Services. I understand the former to be built on top of the latter.
Thanks in advance,
Alex
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden