Re: Crash Proof Apple Lossless
Re: Crash Proof Apple Lossless
- Subject: Re: Crash Proof Apple Lossless
- From: William Stewart <email@hidden>
- Date: Mon, 17 Nov 2008 11:07:29 -0800
ok - so I think we can add something here that might mitigate this
For non-VBR data, CAF is "crash - proof".
The problem for VBR is that we have a packet table external to the
audio data that needs to be written to the file. We don't do this as a
matter of course because it means seeking the disc every time you
write it (it is not contiguous with the audio data).
So, a strategy that we think will work is the following:
(1) Before you start recording, set the audio file property to reserve
duration to be longer than you would expect to record
(2) Introduce a notion that will allow the application to flush the
packet table (and any other state that would make the file well
constructed) without changing the file's general layout. Optimise
currently has the notion of making the file as small, compact and well
laid out as possible - so even if you reserve a duration it will
potentially move data to make an optimal file for these criteria
We would have to add something like this, and if we did, I would
imagine the application's responsibility would be to periodical call
an API on audio file to carry out this task.
Does that seem useful?
Bill
On Nov 16, 2008, at 10:13 AM, Dominic Feira wrote:
This is what I am finding out from experimentation. It is crash
proof with formats that don't have a packet table. It looks like I
may end up writing my own file format to contain the apple lossless.
-- Dominic Feira
On Nov 15, 2008, at 8:48 PM, Brian Willoughby wrote:
I believe that CAF was designed to be crash-proof. Check the
specification, available from Apple, or perhaps someone else here
can confirm. I believe that only SDII and CAF are crash-proof.
However, if you're using CAF to hold Apple Lossless encoding, then
I'm not sure whether the crash-proof feature would be fully
possible. On that note, I'm not sure that any compressed coding
will preserve as much audio data during a crash as an uncompressed
coding. You may have to choose between the space-savings of
compression and the reliability of a fully crash-proof format.
Brian Willoughby
Sound Consulting
On Nov 15, 2008, at 16:53, Dominic Feira wrote:
On Nov 15, 2008, at 3:03 PM, tahome izwah
2008/11/14 Dominic Feira <email@hidden>:
Hi. I rely quite heavily on Apple Lossless audio. I would like
to crash
proof recording to Apple Lossless. MPEG-4, CAF, and QuickTime
Movie all
require that the file is closed properly in order to open them.
Just curious: Where did you get that info from?
We're accessing files that are open for writing from a separate
ExtAudioFile instance (for reading) without problems in one of our
apps. You might need to call AudioFileOptimize() to flush data to
the
file before you can read them but other than that we've not had any
problems with it...
--th
My concern is recovering from a crash. In all of the mentioned
formats if the app crashes before the file is closed the packet
table is never written to the file. It isn't possible to flush
data to the file if the app has crashed.
-- Dominic Feira
_______________________________________________
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