Re: AudioQueue and Seeking in a VBR file
Re: AudioQueue and Seeking in a VBR file
- Subject: Re: AudioQueue and Seeking in a VBR file
- From: "Matthew Leon Grinshpun" <email@hidden>
- Date: Wed, 26 Mar 2008 19:33:33 +0100
Sorry, I was hasty in writing this e-mail. Here is a corrected version:
First, thanks for everyone's help in answering my previous question
about audiofilecomponent. I'm working on something for Ogg at the
moment... I have a tangentially related concern that is bothering me a
bit:
I am working with audio queues and wondering how to properly keep
track of time, as well as seek to a certain position, in VBR files.
Basically, I'm wondering what the most commonly implemented solution
is to the problem, as I'm sure it's one that many people working with
these files face at some point.
The only obvious solution to the issue seems to me to develop a
function that iterates over the entire file and builds a "map" of the
number of frames contained in each packet. I assume I can just
allocate, say, a UInt64 for each packet and store a corresponding
frame number. Is this the way this task is generally performed, or is
there a cheaper (clever) way to get around this issue? In the case of
CoreAudio, is doing AudioFileRead() and then inspecting the packet
descriptions the best way?
On Wed, Mar 26, 2008 at 7:24 PM, Matthew Leon Grinshpun
<email@hidden> wrote:
>
> Hi,
>
>
>
>
> First, thanks for everyone's help in answering my previous question about audiofilecomponent. I'm working on something for Ogg at the moment... However, I have a concern that has
>
> I am working with audio queues and wondering how to properly keep track of time, as well as seek to a certain position, in VBR files. Basically, I'm wondering what the most commonly implemented solution is to the problem, as I'm sure it's not one that many people working with these files face at some point.
>
>
> The only obvious solution to the issue seems to me to develop a function that iterates over the entire file and builds a "map" of the number of frames contained in each packet. I assume I can just allocate, say, a UInt64 for each packet and store a corresponding frame number. Is this the way this task is generally performed, or is there a cheaper (clever) way to get around this issue? In the case of CoreAudio, is doing AudioFileRead() and then inspecting the packet descriptions the best way?
>
>
> -Matthew
_______________________________________________
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