Re: AudioFormat::FileDataIsThisFormat
Re: AudioFormat::FileDataIsThisFormat
- Subject: Re: AudioFormat::FileDataIsThisFormat
- From: Brian Willoughby <email@hidden>
- Date: Mon, 28 Apr 2008 14:09:00 -0700
Matthew,
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.
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?" 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. 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.
You will probably have to do the same. I'm sure that Ogg has a
public, open specification. In fact, I'd almost bet that the format
has a magic number at the start, in the long-standing Unix
tradition. I'll let you find the answer. You should implement your
own Ogg format test, hopefully based on a simple magic number, and
then clean up after yourself if necessary. This is a fragile
approach, because you must update your code if the Ogg specification
were to change. It seems rather unlikely, though, that Ogg would
change something so fundamental in the future. If anything, the
format probably has a version number embedded, so that the basic
identifiers need never change, even when the format changes.
As an example, I have an Objective C class cluster designed to handle
any audio file format. The problem is that the parent class must
have some code to peek into the file before it can determine which
subclass to instantiate. Thankfully, Objective C offers class
methods, so I have implemented tests in each class which can detect
basic validity of each supported format. However, the code still
must rewind the data stream before passing it on to the format-
specific class, because every file parser expects to have access to
all of the data.
Hopefully, this has pointed you in the right direction. If anyone
has a more elegant solution, I wouldn't mind reading it.
Brian Willoughby
Sound Consulting
On Apr 28, 2008, at 12:32, Matthew Leon Grinshpun wrote:
I've been working on trying to put together an afil component for Ogg
Vorbis. From my research, it looks like this might be the first third
party afil component (can anyone confirm this?) so I'm going by trial
and error a lot. One of the big mysteries to me right now is how to
properly deal with the FileDataIsThisFormat method of AudioFormat.
As I understand, when I perform an AudioFileOpen on a file, the Audio
File API goes first asks all the afil components if the file's
extension matches. If a component matches the extension, it goes to
the next step: It puts some data from the beginning of the file into a
buffer, which it feeds to the component's format's
FileDataIsThisFormat method to confirm the match. This is where my
befuddlement sets in.
First, the size of the buffer given to FileDataIsThisFormat seems to
always be exactly 8192 bytes. This is something of a mystery to me,
and I'd really appreciate it if someone could inform me why this
seemingly arbitrary number was picked. Working with this limited
buffer, I'm often unable to determine whether the file is, or is not,
actually an Ogg Vorbis file (libvorbis, for example, will always tell
me that this 8K buffer does not represent an ogg vorbis file-I suspect
that other libraries would have a similar issue with such a buffer).
If there's no way to get around this 8k limit, my next question is a
more general one: is there any way I would be able to determine
through my AudioFormat class whether the file attempting to be opened
is, indeed, an ogg file before handing it off to the AudioFileObject
for opening? I am curious as to why the API won't just hand me a
pointer to the file object, or a datasource representation, and let me
have my way with it.
I hope I have explained the issue clearly enough. It is, admittedly, a
bit obscure, especially as nobody else seems to be trying to create an
afil component.
_______________________________________________
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