I am having some trouble generating MP3s from 24-bit source input using LAME (the library, not the command-line encoder).

There are two API candidates to choose from: lame_encode_buffer_long2 and lame_encode_buffer_int. On my system both longs and ints are 4 bytes, so scaling of these types isn't an issue. I wasn't sure which function would be best. In any case, I have used lame_encode_buffer_long2 to generate MP3s from 32-bit source input with no problems. When I attempt to do the same with 24-bit input, I get extremely garbled output.

I assume that since LAME doesn't support 24-bit input naturally, I need to rescale the 24-bit input to match 32-bit scaling. This is the gist I got from lame.h, anyway.

I've tried to rescale the input several different ways: source << 8, (source << 8) | (source & 0xFF), and even passing it straight through- all of which produce different (but equally garbled) output.

I should probably mention that the input is coming from a 24-bit AIFF file, and the data to be processed is coming from an AudioBufferList (on OS X).

Anyone have any ideas?

aiff files are high-byte first. are you sure you read the pcm-data properly?

I assume the 24-bit data is stored in a 32-bit integer. I am performing a swap to host byte order before I process the data. Also, I am on a PPC so even though AIFF are big-endian it is native byte order for me. Converting from 16-bit and 32-bit sources works correctly.

24-bit data is stored as 3*8 bytes in a aiff file.



you don't need to swap, as you are on a ppc as you stated.



that is a bit strange. are the 16 and 32-bit sources also aiff files?
perhaps it's really a problem with the lame-api, but i don't think so

Yes, I realized my mistake a little while ago. But I still am getting garbled sounding output. See below.



True, but for universal binaries you can never assume the host-endian byte order. For compatible code you always have to use swap macros, which compile differently based on the target architecture.



The 16- and 32-bit sources are also AIFF files. FWIW, I can also convert from an 8-bit source AIFF (by left shifting 8 and ORing in the low bits) successfully.

As I mentioned above, I am now able to get recognizable audio but it is still garbled.

I have grabbed the three bytes of PCM data from the AIFF file: MM XX LL (M = MSB, X = middle, L = LSB). Obviously no byte-swapping is required on single bytes. So, I am attempting to convert the 24-bit sample into a 32-bit sample using the following: ((MM << 24) | (XX << 16) | (LL << 8) | (LL & 0xFF)), with the result converted to host byte-order. I then pass the deinterleaved values to lame_encode_buffer_long2. Is this possibly an issue of signed vs. unsigned?

If you are converting to 32 bit, shouldn't you use floating point?

Maybe! I'm not sure how the resulting audio would sound when converted to a float versus promoting to 32-bit samples. Would there even be an audible difference? I'm also curious whether most folks would champion keeping the low bits or not (sample << 8 vs. (sample <<8) | (sample & 0xFF)).

I did get this to work, eventually. The problem turned out to be something related to unused high bits in the input that I forgot to OR out.