Detecting 64 bit depth WAV file?

General JUCE discussion
1

Since 64-bit WAV files still do not seem to be supported, is there a way in Juce to detect that a file the user selects is 64-bit? When we create a reader for the wav file, it reports the bit depth as 32, but the GetInfo pane says it is 64-bit. How can we detect that and let the user know that using this file will convert it to 32-bit floats?

2

I would expect the bit depth to be in the header. There’s definitely no confusion between bit depth of 64 and addressing of 64-bit (i.e. Wave64), right?

3

The problem is that this code says that the bitDepth is 32 when using a 64-bit WAV file:

    std::unique_ptr<juce::AudioFormatReader> reader (formatManager.createReaderFor (trackFile));
    if (reader.get() != nullptr)
    {
        numSamples = reader->lengthInSamples;
        formatStr = reader->getFormatName();
        sampleRate = reader->sampleRate;
        **bitDepth = reader->bitsPerSample;**

But using non-Juce methods, we can see that it is 64-bit. We’d prefer to use Juce than things like Microsoft’s Media Format code, if possible. But after creating the reader above, it gets changed from 64-bit to 32-bit, because some code down in that reader creation rejects 64-bit as a valid option. (Using Juce 7.0.5, btw.)

4

Creating the Juce WAV reader should just fail if the file audio data format is 64 bit. Are you sure you are detecting the bit depth correctly in the other software or softwares you are using? edit : Or hmm, is this about the WAV reader creation falling back to using some other format?

5

On Windows, it does indeed reject the file. But on Mac, it magically changes it to 32-bit. No idea how or where in the code that happens. Looks like it should just reject it.

6

What’s probably happening is that the CoreAudioFormat on Mac is used for WAV files if the primary Juce WAV reader creation fails. The CoreAudioFormat is a multi format one that supports WAV files among other ones and it always handles the audio data as 32 bit float regardless of the original file bit depth.

7

Yeah, that’s what we figured. So for Mac we have code to use CoreAudioFormat instead, and use the MS Media Format for PC, just so we know that the reason we won’t support the file the user drags in is because it is 64-bit, as opposed to some other more generic reason, so we can tell users we only support up to 32-bit files in our app. I would just prefer to not have to use platform-specific code like that whenever possible.

8