Re: FLLR (compression ?) in AIFF file
Re: FLLR (compression ?) in AIFF file
- Subject: Re: FLLR (compression ?) in AIFF file
- From: "Stephan M. Bernsee" <email@hidden>
- Date: Thu, 14 Aug 2008 08:34:14 +0200
On 14.08.2008, at 00:38, William Stewart wrote:
On Aug 13, 2008, at 12:53 PM, Stephan M. Bernsee wrote:
Alright then, since you brought it up: as you know, ExtAudioFile
doesn't exist on certain handheld Apple platforms (let alone
platforms other than Apple!), and quite frankly, (Ext)AudioFile can
be a pain in the butt to use (*especially* ExtAudioFile due to its
lack of multithreading support). I'm pretty sure I'm not the only
here one who had suffered a headache from using it one time or
another...
That is a separate issue. Lets compare apples with apples:
(1) ExtAudioFile is built on top of 2 API sets:
AudioConverter
AudioFile
By doing this you are able to specify a convenient format for you to
deal with the file in, and have the audio converter convert formats
from the file format to your client format. I think you totally
underestimate the complexities of dealing with frame accurate
reading from files with compressed formats such as ALAC or AAC (to
take one example).
I don't think that I do, but in the applications where I am actually
using miniAIFF I am not interested in reading compressed file formats.
Like I said, this is for evaluating technology where it is important
that there are no artifacts. You cannot use MP3, AAC or any other
format that uses lossy data compression for this.
You could not use your AIFF parsing code to do this kind of operation.
No, probably not. At least not without making lots of redundant calls.
Because there is a potentially complex operation going on between
the file system and the client code, you really can't do this well
though multi-threaded access using a single object. If you want to
read the file from different threads then you can simply create one
ExtAudioFile object per thread.
I cannot do this in my application for various reasons, therefore I
had to create a layer that serialized the calls to a single instance
of ExtAudioFile. This was definitely not fun and as a developer I
would have preferred that it rather "just worked". If you're
interested in learning what your developers' needs are then I would
kindly ask you to accept this as a fact rather than trying to explain
away my needs. Of course there are always ways to deal with a
situation like this by working around a given limitation but it costs
time and money and doesn't really help the project forward.
But we are still comparing apples to oranges
(2) Audio File API is much closer to the parser you would write -
in fact it does exactly what you describe your parser doing - fopen,
fread, etc... It does NO translation of data between what is in the
file and what you read.
It provides two read calls:
ReadPackets
- this asks the audio file object to do some parsing of the data
for you and to at least return the data in a packetised format -
which is most convenient for dealing with the rest of the CA API set
I agree. However, as soon as you need to touch that data you need to
do conversions. Most audio developers (myself being one of them)
expect to see that data simply as multi-dimensional float array - they
don't want to deal with platform specific data structures and they
don't care about setting up data converters or anything of that sort.
The easier they get to the contents of a file in a format that they
can process (which is usually float) the better.
ReadBytes
- just reads the audio bytes - its essentially a call through to
fread
All of the state for reading a file is passed to these calls, so
AudioFile can be used with impunity from multiple threads.
I know. But like I said, the AudioFile API has a steep learning curve
for someone who is not familiar with that API and its data structures.
I too have found ExtAudioFile easier to understand and to work with
(and I have the feeling that some people at Apple would agree with me,
otherwise you wouldn't have created it in the first place). However,
its multi-threading issues make it difficult to use since you can be
sure to run into problems, eg. when doing audio playback with realtime
DSP processing.
Sure - I am glad that you have found our code useful. I would
rather understand on this list why somebody can't use our code than
have people promoting alternatives just because someone posts a
vague comment about not being able to understand our API.
I really appreciate your interest in learning what your developers'
needs are and I was simply trying to explain what I as a developer
would expect from an API like this. From the questions I see in this
forum I gather that I am not alone and the things that I had mentioned
are stumbling blocks for other developers on a daily basis as well.
I don't see that it is helping us to support developers using CA
APIs to have this list used to encourage people to just "give up"
and go use some other code.
I'm 100% with you on this, and like I said, I truly appreciate your
help and the insight that all of you provide in this forum. That
having said, you should also give us an opportunity for criticism -
however ingenious a solution might seem to you at first there are
always people who think differently (!) and might find your solution
difficult to understand. Nothing of what I have said is to be taken
personally, I am merely offering my opinion and suggestions for
improvement. If you don't agree that's fine with me - I can live with
the CA API as it is and will use other alternatives if I have to.
However, if you're trying to understand why the same questions come up
every other day then it might be a good idea to think about what
people are asking for, even though you might not agree or find their
demands to be irrelevant. Put together a FAQ with some code and either
offer that FAQ to the people who are asking, or (even better) change
the API so that these questions go away. This is the one and only way
to make everybody happy.
If you want to promote your own products, please do so on your own
forums.
Hey, I am not promoting anything here - if we're not allowed to
compare CA with what we're using out here how would you ever
accomplish your goal of learning what we need? And just for the
record, someone else brought up miniAIFF in this context and I was
merely responding to your message that suggested other people can't
write good file parsers. There are many excellent developers outside
Apple who know their stuff and have to deal with and maintain code for
multiple platforms on a daily basis without having the benefit of
working in a single, closed environment that you have ultimate control
of, like you guys at Apple do. In other words, it is easy to do as the
Romans do when you're in Rome, but for many of us the world is bigger
than that.
Again, thank you for listening and for providing this forum!
Best wishes,
Stephan
_______________________________________________
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