Geek check for the CS folks

[Hadasi]

I’m trying to mirror this code

            var buffer = output.ToArray();
            //The buffer length is divided by 2 because each sample in
            //the raw PCM format is encoded as a signed 16-bit integer,
            //which takes up 2 bytes of memory. Dividing the buffer
            //length by 2 gives the number of samples in the audio data.
            var result = new float[buffer.Length / 2];
            for (int i = 0; i < buffer.Length; i += 2)
            {
                short sample = (short)(buffer[i + 1] << 8 | buffer[i]);


                //The division by 32768 is used to normalize the audio data
                //to have values between -1.0 and 1.0.
                //The raw PCM format used by ffmpeg encodes audio samples
                //as signed 16-bit integers with a range from -32768
                //to 32767. Dividing by 32768 scales the samples to have
                //a range from -1.0 to 1.0 in floating-point format.
                result[i / 2] = sample / 32768.0f;
            }

with this these nodes

and I’m always feeling vertigo when I get near bit operations, I’m always assuming my output is somehow wrong.

How do I patch the above?

H

[bjoern]

You don’t need bitwise operations.

BytesToInt.vl (14.7 KB)

[Hadasi]

That’s pretty much the conclusion that I arrived at. The question within the question is what does << and | do in a patch? While our approach works fine, (and maybe that’s what, happening under the hood) My understanding was that << and | should effectively concatenate the bytes to produce the short, but I cant do GetBytes(Int16) and reverse engineer it.

(I’ll show a screen shot of what I mean later).

[tonfilm]

This would be the way it is in the code. It’s also re-using the array to avoid creating new spreads in every frame.

BytesToIntBitwise.vl (27.1 KB)

I left björns method in there, as it’s the most elegant. Performance-wise, you need to check which one is better.