Re: AudioFormat::FileDataIsThisFormat
Re: AudioFormat::FileDataIsThisFormat
- Subject: Re: AudioFormat::FileDataIsThisFormat
- From: "Matthew Leon Grinshpun" <email@hidden>
- Date: Tue, 29 Apr 2008 00:01:35 +0200
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