Re: AudioFormat::FileDataIsThisFormat
Re: AudioFormat::FileDataIsThisFormat
- Subject: Re: AudioFormat::FileDataIsThisFormat
- From: William Stewart <email@hidden>
- Date: Mon, 28 Apr 2008 15:30:34 -0700
A general thing I'd like to add.
In Leopard with AudioFile we added equivalent calls for Create and
Open that take CFURL rather than FSRef. Going forward, we will not be
supporting the FSRef version on the audio file components (the FSRef
version of the Audio File API will continue to work however), so
please make sure that you are implementing these API - the simple
implementation can be to just take the CFURL and convert this to an
FSRef and then call you existing FSRef versions if that is what you
have).
The 8K bytes are provided because for some file formats - MPEG is one
- you might not actually know for quite a number of bytes. For CAF
files (as a counter example) you just need the first 8 bytes to make
this determination.
There are a couple of basic questions here:
- is this your file?
- what format is the data in this file if it is yours?
Both of these should be answered with as little information as you
need... If you are uncertain, then there are "uncertain results" that
you can provide:
- definitely my data
- definitely not my data
- "I don't know"
One of the things I would encourage you to do (I have no idea how
practical this is), is to not read more information from the file than
is absolutely necessary to answer a specific question. For instance,
with MP3 files the packet table is built up as the caller drives you
through the file. We have an "estimated duration" property and for MP3
we really do make an estimate of this based on the information at
hand. There is a "real duration" property as well - in that case we
will read through the entire file to calculate this - and this can
take some time. The comments in AudioFile.h should help out with this
Bill
On Apr 28, 2008, at 3:01 PM, Matthew Leon Grinshpun wrote:
Brian,
First off, thanks for the advice. I was generally thinking that I
would resort to doing what you describe, which I suppose shouldn't be
too difficult, but I was really hoping that I could just "cheat" and
write some simple AudioFile to libvorbis glue code and be done with
it. Oh well :)
I am still curious about why I get handed 8192 bytes, but I doubt that
knowing the answer to this question would in any way help me solve my
problem. It's just a curiosity at this point, that's all.
I have yet to work with Ogg directly, so I cannot give a detailed
answer as
to why 8192 bytes is insufficient for the API to detect whether a
given file
is Ogg format or not.
Not sure if it's the API itself or the way I'm working with it. I,
too, was a bit confused by this, as the entire header should, in
theory, be well under 8192 bytes...
However, I will say that it is incredibly rare for a file format
API to
have a function which is geared towards the simple test of "is this
data
valid for this format?"
I suppose that libvorbis falls under the exception here, as it does in
fact have a suite of functions geared toward quickly examining a data
stream and determining if it is valid Ogg Vorbis... But as I said, it
doesn't seem to be happy with just the first 8192 bytes of a file.
Usually, the API assumes that you already have
confirmed the format, and are passing valid data. I assume that
the Ogg API
is expecting an entire stream, not an excerpt. That's probably not
a rare
situation, either.
This certainly appears to be the case, which is probably the source of
my problem. That said, when I look at the code it's doing a lot more
than just taking a peek at the magic number at the beginning of the
file.
In nearly every case, I have had to research the file
format specification and write my own code to peek at the data
independently
to determine whether it is valid *before* handing the data on to a
specific
API.
It looks like that's what I'm going to start doing. As you wrote, it's
a public, open format so it shouldn't be a big deal, but I partly
asked my question out of curiosity as to what is going on behind the
scenes in the audiofile API. Still wondering if anyone has some
insight here.
Thanks again,
-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
_______________________________________________
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