Lists

Terms and Conditions
Lists hosted on this site
Email the Postmaster
Tips for posting to public mailing lists

Re: Apple Lossless: working with 16 bit, silence with 24, 32 bit source data

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Apple Lossless: working with 16 bit, silence with 24, 32 bit source data

Subject: Re: Apple Lossless: working with 16 bit, silence with 24, 32 bit source data
From: William Stewart <email@hidden>
Date: Thu, 1 Jun 2006 10:37:17 -0700


On 31/05/2006, at 11:40 PM, Brad Ford wrote:

On May 31, 2006, at 7:50 PM, Stevo Brock wrote:
Several months ago I was able to get LPCM => Apple Lossless (into QT file) working with 16-bit source data. Now I'm trying to get the same working with 24 and 32 bit source data and all I get out is silence. I *believe* I have narrowed the problem down to the Audio Converter, but the pipeline in my app is pretty complex so perhaps there's something else I'm missing.

I have 3 source files, at 16, 24, and 32 bits uncompressed LPCM. Here are the Audio Converter setups for each conversion:
Source: 44100, 'lpcm', 0x0e, 4bpp, 1fpp, 4bpf, 2 channels, 16 bits
Dest: 44100, 'alac', 0x01, 0bpp, 4096fpp, 0bpf, 2 channels, 16 bits
Source: 44100, 'lpcm', 0x0e, 6bpp, 1fpp, 6bpf, 2 channels, 24 bits
Dest: 44100, 'alac', 0x03, 0bpp, 4096fpp, 0bpf, 2 channels, 24 bits
Source: 44100, 'lpcm', 0x0e, 8bpp, 1fpp, 8bpf, 2 channels, 32 bits
Dest: 44100, 'alac', 0x04, 0bpp, 4096fpp, 0bpf, 2 channels, 32 bits
I believe for 'alac', you aren't supposed to fill in mBitsPerChannel, as it's a compressed format, and the sample size of the source is already indicated in the mFormatFlags. You shouldn't need to do any of the below steps.

Yes... The idea of the bits per channel field is to express a characteristic that is true only of an uncompressed format - like Linear PCM. A compressed format doesn't contain in its packaged data, some bits that can be readily identified as the values for a particular sample. Of course a compressed format is compressing source data that was a particular bit depth - if this matters to a codec, this information is usually kept in a cookie at least, and we also add this to the format flags as Brad describes.

In fact, you can directly use the mBitsPerChannel field of an ASBD that is completely specified, to determine if the format you are dealing with is compressed (value is 0) or uncompressed (value is > 0). There are some more notes about this in the document on the Core Audio Format (CAF) File, that I think is worth browsing through.

Also, to set up the converter, when selecting 'alac' as the dest codec, I find the 'alac' component and call SoundComponentGetInfo(..., siCompressionParams, ...) and save the data that is returned. Then later in the process, I find the 'alac' component again and call SoundComponentSetInfo(..., siCompressionParams, ...) using the data that was saved previously SoundComponentSetInfo(..., siCompressionChannels, ...) SoundComponentSetInfo(..., siCompressionSampleRate, ...) SoundComponentGetInfo(..., siCompressionParams, ...) and save this data and then to finish setting up the converter, I call AudioConverterSetProperty(..., kAudioConverterCompressionMagicCookie, ...) with the final saved data.
You're may be sending the 'alac' encoder a bogus magic cookie. AudioConverter uses an 'aenc' type encoder for 'alac', not a SoundManager 'scom'. So the settings you get from 'scom'/'alac' are not necessarily compatible with those of the 'aenc'/'alac'.

In general, a cookie contains information about an encoded bit stream, and is generated by an encoder. So, when you are encoding, you *get* the cookie from the Converter. When you are decoding, you *set* the cookie on the converter, so that the decoder is able to be configured properly to decode that bitstream.

Bill

-Brad Ford
QuickTime Engineering
When I look at the first packet of output data, I see for the 16 bit process, lots of "random" binary data, but for 24 and 32 bit processes, lots of zeros. Is there something I'm doing wrong or something I'm missing in getting 24 and 32 bit Apple Lossless data?
-Stevo Brock
 Head of Development
 Monkey Tools
 www.monkey-tools.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: 40apple.com

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

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


Follow-Ups:

Re: Apple Lossless: working with 16 bit, silence with 24,	32 bit source data
From: Stevo Brock <email@hidden>


Prev by Date:
Re: Opening CoreAudio Examples in XCode

Next by Date:
Re: Opening CoreAudio Examples in XCode

Previous by thread:
Re: Opening CoreAudio Examples in XCode

Next by thread:
Re: Apple Lossless: working with 16 bit, silence with 24,	32 bit source data

Index(es):

Date
Thread