Re: Crash Proof Apple Lossless
Re: Crash Proof Apple Lossless
- Subject: Re: Crash Proof Apple Lossless
- From: Dominic Feira <email@hidden>
- Date: Mon, 17 Nov 2008 14:42:28 -0500
Thanks for jumping in on this Bill. This sounds like a start. I would
really love it if the packet table entries and packet data were
written sequentially during recording. So we would have:
[packet info | packet data] [ packet info | packet data]
And then when the file is closed or after an AudioFileOptimize a full
packet table is built and a unified data is built. Then it would be
like this (which is how it currently is):
[packet table] [audio data]
I don't know if CAF is flexible enough to handle this arrangement
without breaking compatibility. This way the maximum amount of audio
that would be lost in the case of a crash would be one packet's
worth. Granted, AudioFileOptimize would have more work to do, but the
recording would be much more resilient. Perhaps AudioFileOptimize
would create a single packet table for efficiency when opening the
file and leave the redundant information in tact. Relative to the
size of the audio data being written the overhead is minimal and imo
well worth it.
What you have suggested sounds much better than the status quo.
Dominic Feira / Code Monkey / Ambrosia Software, Inc. -- http://www.AmbrosiaSW.com
On Nov 17, 2008, at 2:07 PM, William Stewart wrote:
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:
@apple.com
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