• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Crash Proof Apple Lossless
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
References: 
 >Re: Crash Proof Apple Lossless (From: Dominic Feira <email@hidden>)
 >Re: Crash Proof Apple Lossless (From: Brian Willoughby <email@hidden>)
 >Re: Crash Proof Apple Lossless (From: Dominic Feira <email@hidden>)
 >Re: Crash Proof Apple Lossless (From: William Stewart <email@hidden>)

  • Prev by Date: Re: clocks
  • Next by Date: Re: Basic Description
  • Previous by thread: Re: Crash Proof Apple Lossless
  • Next by thread: Matrix Mixer - setting input bus volume.
  • Index(es):
    • Date
    • Thread