Re: AAC Priming Info Under 64-bit
Re: AAC Priming Info Under 64-bit
- Subject: Re: AAC Priming Info Under 64-bit
- From: Michael Miller <email@hidden>
- Date: Mon, 22 Oct 2012 16:27:36 -0400
Hi Bill,
Thanks for the detailed response and history. I'd previously read the technote you describe and it was very helpful in firming up my understanding. After experimenting, I was more and more convinced that the container format included some extra information about the priming delay such that the codec on its own (and hence AudioConverter) would not be able to announce the delay. Part of the confusion stemmed from the runtime difference between 64-bit and 32-bit but I certainly understand why that decision was made.
As I understand, then, it really is up to AV Foundation to provide some way to report the priming delay if we hope to properly decode it. I'll file a bug with them. For now, I think we can infer the delay from the timing information they provide, as they seem to be accounting for it internally.
Thanks!
Michael Miller
On Oct 19, 2012, at 9:02 PM, William Stewart wrote:
> I'll try to explain some of the history and what you should be doing.
>
> When these codecs (this is true for all freq-domain codecs) were developed, they contain some amount of priming - basically a delay in the bitstream that is created for a number of reasons (encoding quality, overlaps of freq-time domain transformations, etc). There was no standard delay specified (different encoders of different formats introduce different delays) and no standard way of expressing this in the bitstreams. Early implmentations of this problem just specified "X" amount of samples (and others just ignored it).
>
> The data for the priming needs to be contained in the file container (not in the bitstream or its cookie), because it affects how that data looks when relating to timing (think of video sync, etc). For ISO files there is a combination of Edit lists and roll atom, in CAF files we express the priming as a number (in audio samples of the base level sample rate) in the packet table chunk, the "gapless chunk" in M4A files, etc...
>
> Not having this information at hand, we defaulted to 2112 (because at that time the ISO files did not describe this, MP3, other formats never did explicitly, etc...). However, when we went to 64bit all of the file containers (at least for AAC) had well described ways of containing what the actual priming values were. As this can vary based on the encoder used, we decided to remove a default behaviour and require this be explicit.
>
> So, basically, the requirement is the following:
> (1) When reading the file, you need to understand the priming delay contained within the compressed audio data. If the file does not contain this information
> - if AAC, we assume 2112 samples of priming.
> - other formats (MP3, etc) have appropriate default values based on an appropriate value for that format
> (2) Explicitly set the priming value (or handle it yourself) on the decoded output.
>
> It behaves like this in iOS since the first release of iOS.
>
> The ExtAudioFile API takes this into account when you are reading samples from a compressed file.
>
> When writing a file this information should be retrieved from the encoder and placed appropriately in the new file. ExtAudioFile does this.
>
> There is a technote on Apple's developer web site that explains this in more detail (with some diagrams to visualise what is going on, etc).
>
> Thanks
>
> Bill
>
> On Oct 18, 2012, at 12:59 PM, Michael Miller wrote:
>
>> Hi all,
>>
>> I'm running into a strange issue related to priming info in the OS X AAC decoder. Under 32-bit, all is well: my AudioConverter instance reports a 2112 leading frames and 0 trailing frames as expected. However, under 64-bit, identical client code, input and output formats, and magic cookie (i.e., the same file) lead AudioConverter to report 0 leading frames. I narrowed it down to the AAC codec and have reproduced the same behavior querying the decoder directly. I've attached a minimal sample project that demonstrates the issue I'm seeing. I've also filed a bug report under bug ID #12526917.
>>
>> In the mean time, I'm hoping to find some way to work around the issue. Has anyone else run into this particular problem? If so, what have you done to avoid it? I'm considering special-casing the 2112 frames for the AAC format variants but I haven't investigated enough to know if this affects any other formats. I'm also considering making a 32-bit helper process to report the priming info. Unfortunately, I can't use the AudioFile API to get the packet table because I'm dealing with both movie files and audio files. And AVFoundation doesn't seem to provide this information in any direct way, though I can introspect about it in a somewhat sketchy fashion.
>>
>> Thanks for your time!
>> Michael Miller
>>
>> <AACDecoderBug.zip> _______________________________________________
>> 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
>
>
_______________________________________________
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