Re: where to start with converting an mp3 file to pcm
Re: where to start with converting an mp3 file to pcm
- Subject: Re: where to start with converting an mp3 file to pcm
- From: Mo DeJong <email@hidden>
- Date: Tue, 20 Sep 2011 13:35:24 -0700
See iOS example #3 for code that implements decompressing an audio
file with the ext audio file API: The example uses IMA4 compressed
audio, but the idea is the same.
http://www.modejong.com/iOS/#ex3
On newer iOS releases, you would likely be better off just exporting
an audio file using the avasset library. The API is way way easier to
use than CoreAudio. Dealing directly to samples in a file is a lot
easier than decompressing and doing all that buffer management on the
fly.
cheers
Mo DeJong
On Tue, Sep 20, 2011 at 6:42 AM, Morgan Packard
<email@hidden> wrote:
> Hi All,
> Thanks for the thoughts and guidance. Here's why I think expanding the mp3s
> is a good idea: the mp3 are samples which I'll be using for granular
> synthesis (of a sort) inside my (iOS) app. So they really need to be
> converted to PCM data at some point so I can have precise control over
> playback position, apply envelopes, and do any other dsp I want. There may
> be a more "Apple" way to do this where I could avoid directly converting an
> entire MP3 file to PCM, but I'd like to keep my code simple and leave open
> the possibility of a port to another platform.
> I realize I could probably do this mp3-to-pcm conversion every time the user
> starts the app, but I'm guessing that I'll be able to make startup faster if
> I populate buffers from PCM files rather than mp3 files. So the idea would
> be to decompress the files only once, after download, and have startup be as
> streamlined as possible after that.
> Does this make sense?
> -Morgan
>
> On Mon, Sep 19, 2011 at 10:57 PM, Brian Willoughby <email@hidden>
> wrote:
>>
>> Agreed that expanding MP3 audio to an uncompressed files gains nothing.
>> Agreed that ExtAudioFile is the best API for the original task. Also
>> agreed that CAF is the best format choice unless you need Windows
>> compatibility.
>>
>> However, CAF is more than just a container file format. IMA4 is 4-to-1
>> compressed and surely has to be lossy, so you're better off using the
>> 'native' sample format of CAF (I don't know whether there is a unique name
>> for the native sample format of CAF, but it certainly isn't IMA4). CAF is
>> also a container format, just like IFF/FORM is the chunk container format
>> for AIFF and RIFF is the chunk container format for WAV. CAF happens to use
>> 64-bit chunks instead of 32-bit chunks.
>>
>> IMA4 is just the typical example for Apple sample source, but even they do
>> not recommend using it for production code.
>>
>> Brian Willoughby
>> Sound Consulting
>>
>>
>> On Sep 19, 2011, at 15:30, Steven Winston wrote:
>>>
>>> ExtAudioFile is definitely a good candidate to do this too. I pointed
>>> at Audio Queue due to the existing online doc.
>>>
>>> I'd also point out that .caf is a container format; I think what
>>> you'd want is IMA4.
>>>
>>> On Mon, Sep 19, 2011 at 3:21 PM, Chris Adamson <email@hidden>
>>> wrote:
>>>>
>>>> Agreed with Steven that the premise seems dubious in the first place.
>>>>
>>>> That said, directly using the Audio Conversion functions would be more
>>>> direct than an Audio Queue, although it's not as easy to find good docs or
>>>> sample code. We do have an example in the book. You'd then have to write
>>>> the PCM sample buffers to a file with Audio File Services.
>>>>
>>>> The cleanest way to do it would be with an ExtAudioFile, which would
>>>> give you MP3-to-PCM conversion and file I/O to the container of your
>>>> choice(*) in one fell swoop.
>>>>
>>>> (*) - if your app is the only thing that's ever going to read the
>>>> converted files, I'd argue that .caf would be superior to .aiff or .wav.
>>>>
>>>> --Chris
>>>>
>>>> On Sep 19, 2011, at 5:06 PM, Steven Winston wrote:
>>>>>
>>>>> Erm... why do you want to expand the file to PCM on the user's hard
>>>>> drive? Why not keep it as mp3? You get the same quality as the fact
>>>>> that it was mp3 at some point means there's already a degradation of
>>>>> signal all you could possibly get is less time decoding it in
>>>>> software; but nearly every device I can think of has hardware mp3
>>>>> decoders; so that doesn't make sense either.
>>>>> In any case; it's actually quite trivial to do. You can use offline
>>>>> render from audio queue services. Documentation for that is online.
>>>>>
>>>>> On Mon, Sep 19, 2011 at 1:59 PM, Morgan Packard
>>>>> <email@hidden> wrote:
>>>>>>
>>>>>> Hello list,
>>>>>> I'd like to ship my app with mp3s and expand them to pcm files (aif or
>>>>>> wav)
>>>>>> on the user's hard drive. I'd be grateful if anyone could point me
>>>>>> toward
>>>>>> the most appropriate technologies for the job. Even better would be to
>>>>>> point
>>>>>> me toward some sample code.
>>>>>> thanks!
>>>>>> -Morgan
>>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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
>
>
_______________________________________________
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