Re: CAF file, testing chunk types?
Re: CAF file, testing chunk types?
- Subject: Re: CAF file, testing chunk types?
- From: Darren Minifie <email@hidden>
- Date: Wed, 30 Sep 2009 22:12:36 -0700
Ahh, I added a couple of extra lines to my previous method and i think i might know what is going on. Can somebody confirm if my assumption is correct? Here is the method:
-(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;
}
The reason I think this works is because when i use memcpy(), the function still copies the bytes in the "correct" order to properly fill the char array. In other words, if you consider little endian to be backwards, then memcopy() copies the bytes backwards as well, producing "normal" sequence of bytes in the array. Yes, no? Thanks again, i really appreciate any help.
On Wed, Sep 30, 2009 at 10:01 PM, Darren Minifie
<email@hidden> wrote:
On Wed, Sep 30, 2009 at 8:35 PM, Brian Willoughby
<email@hidden> wrote:
Darren,
An ASCII string is a sequence of bytes, and thus there is no difference between big-endian and little-endian. It's only when you deal with multi-byte numbers such as 16-bit integer or 32-bit integer or others that you must translate.
Thanks for your input here Brian. I have two problems with this still however. My first problem, which was partially answered, is the difference between:
'abcd'
"abcd"
When you say ASCII are you referring to the double quoted string literal? My understanding is that the first example is in fact an int - a 32 bit value which in hex would be 0x41424344. In this case endianness is important because a big endian machine would store this 4 byte type as:
41 | 42 | 43 | 44
and a little endian machine would store it as
44 | 43 | 42 | 41
I think what I'm confused about is, you say that an ASCII string is a sequence of bytes, so the order does not matter. However, isn't that what endienness is all about? The sequence in which the byes of a datatype are laid out.
UInt32 chars = 'ABCD';
would print out 'DCBA' on a little endian machine.
I appreciate you taking the time to help with this basic question
Brian Willoughby
Sound Consulting
On Sep 30, 2009, at 20:15, Darren Minifie wrote:
I have one other related question about CAF files and endian-ness:
I have a method that looks at an NSData object (which is a CAF file in memory). The method finds the chunk type and stores it as a string. In the spec, the chunk type is defined as a UInt32, and is a seuqence of 4 chars. Here is my method which produces correct output on a little endian machine:
-(NSString*)fileType{
if(!fileType){
char type [5];
type[4] = '\0';
memcpy(type, (char*)[fileData bytes], 4);
fileType = [[NSString stringWithCString:type encoding:NSASCIIStringEncoding] retain];
}
return fileType;
}
If CAF files are in big-endian format, why does this method produce the correct result? In other words why don't have i have to do a ntohl() in this case to flip the enianness, like i have to in the case of reading the chunk length etc.
Thanks again.
--
Darren Minifie
Computer Science Masters Candidate
University of Victoria, BC. Canada
My Rants:
www.noisyair.com
My Band:
www.ohsnapmusic.com
_______________________________________________
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