Re: FLLR (compression ?) in AIFF file
Re: FLLR (compression ?) in AIFF file
- Subject: Re: FLLR (compression ?) in AIFF file
- From: William Stewart <email@hidden>
- Date: Wed, 13 Aug 2008 15:38:03 -0700
On Aug 13, 2008, at 12:53 PM, Stephan M. Bernsee wrote:
Hey Bill,
are you saying I don't know how to code up an AIFF file parser? I
already did this at a time where the only sound file format my Mac
would recognize was some strange thing called a "System 7
sound" ... :-)
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). You could not use your AIFF parsing code to do this kind of
operation.
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.
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
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.
Take a look at the miniAIFF API ( http://stephan.bernsee.com/MiniAiff.h
) which essentially uses the fopen/fwrite/fread syntax - you can't
make this any easier, especially when thinking about cross platform
compatibility (which is what this was designed for in 2003).
I am using ExtAudioFile for all audio I/O in our commercial
products, but for demoing new technology where all you need is a
quick and easy (ie. readable to people who don't know what an ABL or
ASBD is) and cross-platform way to access sound without cluttering
the code I usually prefer miniAIFF.
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 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.
If you want to promote your own products, please do so on your own
forums.
Bill
Best wishes,
Stephan
On 13.08.2008, at 21:17, William Stewart wrote:
I've no idea why you guys are doing this when AudioFile already
exists and does exactly this. The API is pretty straight forward
and we'll be happy to answer questions about its use. Its difficult
to know how to respond to a "I don't get this" complaint, which is
why you've not seen any responses from us previously.
We've seen in general more problems with these minimal file parsers
making all kinds of incorrect assumptions about the file layout,
and consequently many bad files as a result.
Bill
On Aug 13, 2008, at 11:24 AM, Stephan M. Bernsee wrote:
Hi François,
I am in the process of updating the miniAIFF lib and releasing its
source code on www.dspdimension.com. Email me off the list if you
want a preliminary copy that compiles on the iPhone.
Best wishes
Stephan
2008/8/7 Francois Baronnet <email@hidden>:
>>
>
> I think that the libMiniAiff.a cannot be linked from a iPhone
project.
> I've added it to my xCode project and when I compile:
>
> "_mAiffReadData", referenced from:
> -[SoundAnalyser readFile:] in SoundAnalyser.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
>
> The message is not very explicit I think...
>
> This lib has been build in 2005.
>
>
> --
> François Baronnet
>
_______________________________________________
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
_______________________________________________
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