Incorrect stsd atom for Apple Lossless files?
Incorrect stsd atom for Apple Lossless files?
- Subject: Incorrect stsd atom for Apple Lossless files?
- From: "Stephen F. Booth" <email@hidden>
- Date: Tue, 13 Feb 2007 15:08:12 -0800
I've been having great difficulty getting Core Audio generated MPEG-4
Audio (Apple Lossless) files to work properly in iTunes. I know it's
been mentioned on here before, but I wanted to ask something similar
yet different.
The issue is that alac files generated by Core Audio do not show up
as having a bitrate in iTunes. This is easily verifiable by taking a
WAV file and using the afconvert tool to create an Apple Lossless file:
afconvert -f 'm4af' -d 'alac' input.wav output.m4a
output.m4a, when imported into iTunes, does not show up as having a
bitrate.
I did some experimentation by creating a single-channel, single-
sample WAV file and creating an alac file from it using Core Audio
and iTunes. The 'mdhd' and 'stsz' atoms were identical, but the
'stsd' atoms were not. Here are the two atoms for reference:
iTunes-generated m4a file:
size = 00000058 (88)
type = 'stsd' (Sample Description)
version = 00
flags = 000000
number of entries = 00000001
sample desc size = 00000048 (72)
data format = 'alac'
reserved = 000000
data reference = 00
00000001 (entry count)
00000000 00000000 (reserved)
0001 (channels)
0010 (sample size)
0000 (pre_defined- compression id?)
0000 (reserved- packet size?)
AC44 (sample rate)
00000000 0024616C
61630000 00000000
10000010 280A0E01
00FF0000 000A0000 <--
035D0000 AC44 <--
I've placed some educated guesses as to the codec-specific data
(magic cookie) in parentheses. (Data fields according to ISO/IEC
14496-12:2005(E)).
Core Audio-generated m4a file:
size = 00000058 (88)
type = 'stsd' (Sample Description)
version = 00
flags = 000000
number of entries = 00000001
sample desc size = 00000048 (72)
data format = 'alac'
reserved = 000000
data reference = 00
00000001 (entry count)
00000000 00000000 (reserved)
0002 (channel count !!)
0010 (sample size)
0000 (pre_defined)
0000 (reserved)
AC44 (sample_rate)
00000000 0024616C
61630000 00000000
10000010 280A0E01
00FF0000 50010000 <--
00000000 AC44 <--
Interestingly, the file shows up as having two channels! The weird
thing is, when opening the file in iTunes or QuickTime Player it is
reported as mono. What have I missed in this analysis?
Finally, it's obvious the final two bytes are the sample rate (44100
in this case). So, the 16 bytes before the final 2-byte sample rate
are different between the two. Could this be causing the issue? Is
this where iTunes stores the bitrate?
Stephen
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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