• 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: [coreAudio] Detecting corrupted files
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [coreAudio] Detecting corrupted files


  • Subject: Re: [coreAudio] Detecting corrupted files
  • From: William Stewart <email@hidden>
  • Date: Tue, 7 Mar 2006 12:39:02 -0800

Alexander

Firstly, can you please file a bug report (http:// bugreporter.apple.com) with the MP3 file that is giving you problems so we can look at this.

There's also a bug in the MP3 file parser that Jens discovered a couple of months ago. It should be an easy workaround - if you are opening an MP3 file, then you should first ask it for the number of packets in the file. This will cause the parser to parse the contents of the file (so it can take some time), but it also does workaround the problem of this code hanging when doing some operations with MP3 files. I don't know if your hang is caused by this bug, but it is certainly worth investigating.

Thanks

Bill

On 07/03/2006, at 12:14 PM, Alexander v. Below wrote:

In my converter, I have discovered that the CoreAudio hangs in

err = AudioFileGetProperty(inAudioFile, kAudioFilePropertyMaximumPacketSize,
&propertySize, &fileMaxPacketSize);



Almost forever, returning only after a serious, serious amount of time. I then tried to open the file (mp3) in QuickTime, which reports an error -2048.


So, fair enough, let us assume that file is junk. But how would I tell? I can successfully call:

	err = AudioFileOpen(&ref, fsRdPerm, 0, &inAudioFile);

and

err = AudioFileGetProperty(inAudioFile, kAudioFilePropertyDataFormat, &propertySize, &srcFmt);

on it, each time getting "no error". The returned source format is:

mSampleRate		12000
mFormatID 			'.mp3'
mFormatFlags		0
mBytesPerPacket 	0
mFramesPerPacket 	576
mBytesPerFrame 	0
mChannelsPerFrame	2
mBitsPerChannel	0

Should this be giving me a hint, i.e. mBytesPerPacket == 0 and mBytesPerFrame == 0, that this file is potentially junk and I should discontinue to work with it?
Could someone briefly add up which parameters have to be set to make something a valid file?


For the experts, this is the stack trace where the call hangs:

#0  0x9004a86c in pread ()
#1  0x90b45bcc in BasicRead ()
#2  0x90b45904 in PBReadForkSync ()
#3  0x90b45864 in FSReadFork ()
#4  0x94101fec in MacFile_DataSource::ReadBytes ()
#5  0x941026f8 in Cached_DataSource::ReadBytes ()
#6  0x9415cfc8 in MP3AudioFile::UpdatePacketTable ()
#7  0x94103ce8 in MP3AudioFile::GetProperty ()
#8  0x940f1564 in AudioFileGetProperty ()

Alex
 _______________________________________________
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

--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________ __
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________ __


_______________________________________________
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


References: 
 >[coreAudio] Detecting corrupted files (From: "Alexander v. Below" <email@hidden>)

  • Prev by Date: [coreAudio] Detecting corrupted files
  • Next by Date: Re: Streaming Graph to file
  • Previous by thread: [coreAudio] Detecting corrupted files
  • Next by thread: Re: [coreAudio] Detecting corrupted files
  • Index(es):
    • Date
    • Thread