On Jul 22, 2009, at 10:45 AM, Tom Harrington wrote:
[Sorry, I did mean to send this to the list...]
Is it possible that the first buffer has no MP3 packet at all in it?
Here's how the hinting works in the format recognizer:
The format parsers can return YES, NO, or CANT DETERMINE to the question of whether the data is of their type.
First any ID3 tags are skipped .
Second, it asks the hinted format parser if the data is of that type. If it returns YES, then return.
Then it checks the data against all the file format parsers to see if any return YES. If one does then return.
Otherwise then as long as the hinted format parser does not return NO then we assume it is of that type.
The MP3 parser returns YES if the first bytes are an MP3 packet header, else it returns CANT DETERMINE.
So you may be in the situation where the first buffer does not start with a layer 3 packet and it does have some bytes that happen to look like a layer 1 packet.
Alternatively you could have a stream that does have a valid MP3 packet at the beginning, but there is a corrupt packet very soon afterwards.
If the parser cannot find several good packets in a row, then it may choose something else to return as the format.
If you start in the middle of random data that is not MP3 it may lock onto something wrong.
On Jul 22, 2009, at 10:43 AM, Tom Harrington wrote:
On Wed, Jul 22, 2009 at 10:09 AM, james mccartney<email@hidden> wrote:
On Jul 21, 2009, at 6:06 PM, james mccartney wrote:
Are you supplying a buffer whose first byte begins an MPEG Layer 3 packet
(optionally preceeded by an ID3 tag), or is it a buffer that starts in the
middle of some random header data after which, at some point, there is MP3
data. If the former, then the parser may be picking up on the first bytes
that look like an MPEG packet header and reporting that as the format.
oops. should be "if the latter". IOW starting in the middle of random data
is the not good scenario.
I had thought that hinting would resolve this-- I know that the stream
is MP3, so I specify kAudioFileMP3Type when calling
AudioFileStreamOpen(). That helps (without it I never get "ready to
produce packets") but apparently it's not enough of a clue?
I'm not familiar enough with shoutcast to be sure but it wouldn't
surprise me if it's starting the stream in the middle of an MP3
packet. Since hinting doesn't seem to be enough, does Core Audio
provide any way for me to discard bytes until the start of the next
packet?
I thought maybe I should be passing
kAudioFileStreamParseFlag_Discontinuity to AudioFileStreamParseBytes()
when I start receiving data, but that doesn't seem to have helped.
--
Tom Harrington
email@hidden
AIM: atomicbird1