Re: AudioFileStream unable to read m4a data
Re: AudioFileStream unable to read m4a data
- Subject: Re: AudioFileStream unable to read m4a data
- From: Stephen Davis <email@hidden>
- Date: Mon, 31 Mar 2008 09:46:51 -0700
On Mar 31, 2008, at 9:24 AM, Jens Alfke wrote:
On 28 Mar '08, at 3:23 PM, I wrote:
I'm using AudioFileStream to parse audio data arriving over a TCP
socket; on the other end, the sender is using AudioFile to read the
contents of the file starting at offset 0. [...] it's failing on
every AAC (.m4a) file. AudioFileStreamParseBytes keeps returning
the error code 'typ?'.
I spent a lot of time struggling with this over the weekend, and I'm
still really frustrated. I could really, really use some advice.
Here's what I've figured out:
* AAC files begin with a magic number, and then a large (circa 32K)
header before the audio data starts. I think this is a packet table;
it seems to consist of a list of 32-bit offsets.
* AudioFileReadBytes skips this table: if you ask for bytes at
offset zero, you get the beginning of the compressed audio itself.
* But AudioFileStreamParseBytes needs to read the entire file,
including the magic number and packet table. If you just start
feeding it the audio, it can't parse it.
So it looks as though one can't stream AAC files using AudioFile on
the sending end and AudioFileStream on the receiver. You have to
stream the raw .m4a file in its entirety. Which is a shame because
this increases latency — I was having trouble when starting the
stream because audio files may have up to 100K of non-audio at the
beginning, especially ones with large hi-res album cover art
embedded. This wastes several seconds of network bandwidth before
the receiver can even start to buffer any audio.
I know that AAC is used for streaming audio, so I imagine there must
be a way to avoid that packet table at the beginning. Do I have to
set some parameters in the encoder or something?
You can't skip that packet table at the beginning or put it at the
end. The decoder/parser *must* have access to that packet table in
order to know where each compressed packets start. As you determined,
you must send the entire file over the wire in order for the other end
to parse correctly.
.m4a/.m4p files are MPEG-4 (based on QuickTime) files so the ~32KB
chunk you are seeing is most likely the 'moov' atom. It's a publicly
documented format in case you want to dig into it. The minor
differences from a QuickTime file that make it an MPEG-4 file are not
really relevant to this particular discussion. Short answer: it is
not a streaming format so you have to send the whole thing.
MPEG-4 supports an entirely different mechanism for streaming AAC
audio so that would be how to avoid the latency in that case. I have
no knowledge of the streaming architecture though so you're definitely
on your own there. Current Shoutcast-style streaming AAC is done use
MPEG-2 ADTS format where the packet headers precede each packet so you
can stream it by dropping in at any point.
hth,
stephen _______________________________________________
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