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: Stevo Brock <email@hidden>
Date: Thu, 1 Jun 2006 17:17:35 -0700

Hi Brad and Bill,

Thanks for your responses and helpful insights. I have made, what I believe to be, the appropriate changes, but I am still not getting valid audio out of the converter.

Updated in and out AudioConverter setups:

Source: 44100.000000, 'lpcm', 0x0000000e, 4bpp, 1fpp, 4bpf, 2 channels, 16 bits Dest: 44100.000000, 'alac', 0x00000000, 0bpp, 0fpp, 0bpf, 2 channels, 0 bits

Source: 44100.000000, 'lpcm', 0x0000000e, 6bpp, 1fpp, 6bpf, 2 channels, 24 bits Dest: 44100.000000, 'alac', 0x00000000, 0bpp, 0fpp, 0bpf, 2 channels, 0 bits

Source: 44100.000000, 'lpcm', 0x0000000e, 8bpp, 1fpp, 8bpf, 2 channels, 32 bits Dest: 44100.000000, 'alac', 0x00000000, 0bpp, 0fpp, 0bpf, 2 channels, 0 bits

After setting up the AudioConverter, I call AudioConverterGetProperty(..., kAudioConverterCompressionMagicCookie, ...) and pass that in when adding samples to the QT file.

The resulting 16 bit QT file plays fine, the 24 bit file is quiet noise, and the 32 bit file is silence. My call to AudioConverterFillComplexBuffer looks like AudioConverterFillComplexBuffer(..., &packetCount, mDestBufferList, tempBuffer) where UInt32 packetCount = 1; mDestBufferList points to 1 buffer of 65536 bytes tempBuffer points to a block of 200K

My dev environment is 10.3.9/QT 6.5.2 and that's where I'm able to examine variables and memory. I'm running my app on 10.4.6/QT7.0.4 in testing and the resulting files are identical. I am also running the afconvert example on 10.4.6 / QT 7.0.4 to compare what it does to what I'm doing. As far as I can tell, I am following the identical steps. I also see that my app generates the same size packets as afconvert, but the packets are filled with mostly 0s. I also see afconvert return a packet description from ACFCB, but that info doesn't get returned in my app (all 0s).

At this point, I'm again at a loss as to what I'm doing incorrectly. It looks to be very straightforward and as far as I can tell I am not altering the alac encoder setup in any way. I would also be glad to pass along my output files if looking at the bit pattern would provide any insight.

-Stevo Brock
 Head of Development
 Monkey Tools
 www.monkey-tools.com

On Jun 1, 2006, at 10:37 AM, William Stewart wrote:

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: 40apple.com

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:  
  >Re: Apple Lossless: working with 16 bit, silence with 24,	32 bit source data (From: William Stewart <email@hidden>)




Prev by Date:
Sample rate property listener

Next by Date:
Converting AudioTimeStamp between two devices

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

Next by thread:
Sample rate property listener

Index(es):

Date
Thread