AudioBuffer size vs Wav file size

General JUCE discussion
1

I’m sure there’s a simple answer but I’m trying to understand why an audio AudioBuffer size is larger than the wav file it comes from.

Example: I have a 2.3mb wav file, and when I load it into an AudioBuffer if I do a calculation (numSamples * numChannels * sizeof(float)) I end up with 3,45mb… What am I not calculating or taking into consideration? Is it the bitrate?

And finally, is there any way to have an AudioBuffer that has a size that matches the wav file? I’m sending the audio through sockets so anything that can save room is something I’m interested in.

Thanks!

2

This is most probably because the AudioBuffer stores samples as normalized 32Bit floating point values (aka float) while the wav format allows different types.

While there are 32 Bit float wav files, most of the time 24 Bit or 16 Bit integer will be used as the sample type of a wav file, leading to a smaller file size. However, as far as I know there is no direct way of using integer audio buffers in juce. If your main goal is less bytes to transfer, you could consider sending the wav file content directly and decoding it at the receiver side.

3

Thanks for the answer, that makes sense. I’ll need to brush up some more on this subject. My goal is less bytes to transfer, with the user case of someone dropping a sample and another user being able to hear it play as quick as possible.

Thinking out loud, I suppose the fastest way would be to convert to flac, write to file, then transfer just the audio data from the flac file over the socket, then read on player 2s side as it comes in.

4

Hey , I am working exactly on the same thing. Can you tell me how you converted the buffer into flac file.
Thanks in advance

5

Variable type for a 16 bit WAV file is short not integer

Rail

6

I’m not sure what you are referring to? When writing

I meant the technical numerical representation as integer in contrast to floating point. short is simply a C/C++ keyword for a 16 Bit integer on common platforms while e.g. int is a keyword for a 32 Bit integer on common platforms and so on. Or did you mean something entirely different?

7

short is 2 bytes, integer is 4 bytes

Rail

8

I’m still confused about what your point is here. There are multiple integer types. The short int or simply short type is one of them, the standard defines it as a small integer type with at least 16 bits = 2 bytes and indeed that’s the exact size of a short on both x86 and ARM. The int type is another one of them, the standard defines it as the basic integer type and also only guarantees that is has at least 16 bits = 2 bytes, although it has a size of 32 bits = 4 bytes on x86 and ARM.

I’m just quoting the Fundamental types page on cppreference here

Integer types

Standard integer types

int - basic integer type. The keyword int may be omitted if any of the modifiers listed below are used. If no length modifiers are present, it’s guaranteed to have a width of at least 16 bits. However, on 32/64 bit systems it is almost exclusively guaranteed to have width of at least 32 bits (see below).

Modifiers

Modifies the basic integer type. Can be mixed in any order. Only one of each group can be present in type name.

  • Signedness:

signed - target type will have signed representation (this is the default if omitted)
unsigned - target type will have unsigned representation

  • Size:

short - target type will be optimized for space and will have width of at least 16 bits.
long - target type will have width of at least 32 bits.

long long - target type will have width of at least 64 bits. (since C++11)

Note: as with all type specifiers, any order is permitted: unsigned long long int and long int unsigned long name the same type.

By the way, in order to access integer types with a specific bit with instead of a platform defined bit width the Fixed width integer types have been added to C++.

So again I conclude that the term “integer” is just a generic technical term for data types suitable to represent non fractional/decimal numbers without specifying any bit width by itself.

That being said, I’m not sure how helpful this discussion is for the follow-up question asked by @CoolHary5 here? :wink:

9

In a 16bit WAV file the data is stored using 2 bytes per value… when you load it you’ll need to factor in that… using juce::int16 (signed short)

You’ll need to use something like:

void convertFloatBufferToShort (AudioBuffer<float>& srcBuffer, ShortAudioBuffer<int16>& destBuffer)
{
    for (int i = 0; i < srcBuffer.getNumChannels(); ++i)
        {
        using DstSampleType = AudioData::Pointer<AudioData::Int16,   AudioData::NativeEndian, AudioData::NonInterleaved, AudioData::NonConst>;
        using SrcSampleType = AudioData::Pointer<AudioData::Float32, AudioData::NativeEndian, AudioData::NonInterleaved, AudioData::Const>;
        
        DstSampleType dstData (destBuffer.getWritePointer (i), srcBuffer.getNumChannels());
        SrcSampleType srcData (srcBuffer.getReadPointer (i));
        
        dstData.convertSamples (srcData, srcBuffer.getNumSamples());
        }
}

void convertShortBufferToFloat (ShortAudioBuffer<int16>& srcBuffer, AudioBuffer<float>& destBuffer)
{
    for (int i = 0; i < srcBuffer.getNumChannels(); ++i)
        {
        using DstSampleType = AudioData::Pointer<AudioData::Float32, AudioData::NativeEndian, AudioData::NonInterleaved, AudioData::NonConst>;
        using SrcSampleType = AudioData::Pointer<AudioData::Int16,   AudioData::NativeEndian, AudioData::NonInterleaved, AudioData::Const>;
        
        DstSampleType dstData (destBuffer.getWritePointer (i));
        SrcSampleType srcData (srcBuffer.getReadPointer (i), srcBuffer.getNumChannels());
        
        dstData.convertSamples (srcData, srcBuffer.getNumSamples());
        }
}

That’s my point.

Rail

10

short is a 2 byte integer, int is a 4 byte integer, etc.

Just accept PluginPenguin’s kind corrections of your confusing statements