Little Endian and AudioFormatReader question

General JUCE discussion
1

Hi,

I’m working on a AudioFormatReader that reads the audio tracks from quicktime movies. I got it all sorted out, but there is one last thing i need to get fixed.

I don’t know (and i’ve been trying all day) how to convert little endian data to 32 bit int data wich is needed in the AudioFormatReader::read callback.

I know this is not really a Juce releated question, but i thought there is probably someone on this forum who can help me out.

So my question is how to go from little endian to 32 int values that the reader needs?

Edwin

2

Hi,
I hope somebody can help me out, i’m willing to share the Quicktime reader when it’s finished.

I set Quicktime to convert the audio track to 16 bit audio samples.
I can choose different formats but it’s really not really well documented what ranges the formats will be in.

So i went for the k16BitLittleEndianFormat, i can also choose k16BitBigEndianFormat.
But i though it would be more usefull to use LittleEndian and swap it if the cpu is BigEndian.
I know that the rest of the code is working because when i use the k8BitOffsetBinaryFormat i can get sound (noisy though but that’s my fault).

Anyway the code below is taken from my QuicktimeAudioFormat class.
The soundData pointer is a pointer to the k16BitLittleEndianFormat formatted buffer.
Can anyone tell me how i convert from k16BitLittleEndianFormat to 32 bit int, pretty please :wink:

int* channel = destSamples[0];

for(int i=0; i< numSamples; i++)
{
	
	uint16 sample =  (uint16) (*soundData)[i+sampleOffset];
	
	*channel++ = sample ???;
	
}
3

well, as they’re both int types, surely it’s just a case of

  • make sure it’s the correct endianness for the processor
    [you could use a #define to select the correct format from quicktime in the first place instead, though that’s more hassle than it’s worth :)]
  • cast to the type you want
    the only other thing you could need is some kind of scaling between the two forms; i presume that 16bit and 32bit int formats both use the whole of their headroom for their dynamic range, so you may need to multiply it by some power of two (i’m guessing x128, but haven’t given it much actual thought)

surely there’s no other mystical process involved?