• 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: CAF file, testing chunk types?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CAF file, testing chunk types?


  • Subject: Re: CAF file, testing chunk types?
  • From: William Stewart <email@hidden>
  • Date: Thu, 1 Oct 2009 19:12:18 -0700

And to that point, really the best (and most efficient) way to do this is:

(1) read the num bytes you want to read into a field to contain that value (so, pread (4) for the chunk type, into an int)
(2) call BigToNative on this int to convert the big-endian ordered int to the native endian order int.


You will need to do this for the chunk sizes anyway (except that these are 8 byte values, not 4), and you also have some values that are float32 and float64 values. So the string technique you are developing has very limited utility

In our SDK code, there is a directory called PublicUtility (on Snow Leopard it is in /Developer/Extras/CoreAudio, in Leopard, /Developer/ Examples/CoreAudio)

There's a CAByteOrder.h file and it has the endian flipping routines (depending also on the routines you can get from CFByteOrder.h)

You should be able to use these with all of the primitive data types you will need to deal with.

There is also methods here called OSTypeToString (and its reverse) - I'm not sure which header they are in (maybe CAComponent.h) - that deal with the completely correct way to convert from these 4 char coded ints to and from strings.

HTH

Bill

On Sep 30, 2009, at 10:27 PM, Brian Willoughby wrote:

In the first example, you are casting the data type to a multi-byte type, a 32-bit unsigned, and then dereferencing it. This technique is byte-order-dependent, and produces the wrong result when reading a big-endian file like CAF on a little-endian processor like Intel.

In the second example, you are casting the data type to a single- byte type, a character (array), and thus you're not actually changing the order of anything.

Note: The CAF chunk types appear in the file as a byte sequence which reads correctly left-to-right. If you read this byte (character) sequence on any computer, little or big, you'll get the right result. Just avoid casting or dereferencing 32-bit variables (or 16-bit, etc.) and you'll be fine. You won't be able to avoid this for the chunk length, though, so be prepared to use different techniques for those pieces of CAF.

Brian Willoughby
Sound Consulting


On Sep 30, 2009, at 22:12, Darren Minifie wrote:
-(NSString*)fileType{

if(!fileType){
// debug code:
UInt32 letters = *(UInt32*)[fileData bytes];
// The proper output should be 'caff', but as i expected, this prints out
// 'ffac' instead
printf("****** the value of letters in hex is %x*****\n", letters);


// This is the original code. it produces the correct output on a little endian system
// i.e. fileType consains the string "caff"
char type [5];
type[4] = '\0';
memcpy(type, (char*)[fileData bytes], 4);
fileType = [[NSString stringWithCString:type encoding:NSASCIIStringEncoding] retain];
}
return fileType;
}


_______________________________________________
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
  • Prev by Date: Re: AU, Obj-C and names
  • Next by Date: Re: ExtAudioFileRead performance
  • Previous by thread: Re: ExtAudioFileRead performance
  • Next by thread: request for auval
  • Index(es):
    • Date
    • Thread