While these are likely to be extremely rare in the wild (I only noticed this now because I did some mass scanning over my audio files with Juce code), it would be nice if Juce could handle these somehow instead of just asserting. Would it be possible to have support for them? (The assert I bumped into happened in juce_WavAudioFormat.cpp’s copySampleData.)
Maybe at least change WavAudioFormat::createReaderFor to do the check for the bit depth, it’s kind of deceiving to not have this fail when the file can not actually be read anyway, when the function returns a valid reader object.
if (r->sampleRate > 0 && r->numChannels > 0 && r->bytesPerFrame > 0 && r->bitsPerSample<=32)
AIFF supports 64bit float also, and probably other codecs. Likely it would entail a sweep through all of the supported formats.
Was this determined an issue not worth fixing in the JUCE code?
I suspect this issue got expanded into a bigger task, adding proper 64 bit support, which then fell down the priority list. I’ll add the 32 bit check for now.
Bump. The need for 64 bit support will come as people develop a perception that 64 bit is “better”. And, so they will want 64 bit file support.
I have my plugins 64bit data ready for this very reason.
I vote that we stay ahead of the curve and have this capability ready in advance of the demand.
I agree, that roughly 1500 dB is really not enough dynamic range…
Unfortunately you are right, since there is 64bit audio and it is possible, users will ask for it.
I would love to say then “I templated all my classes, here you have 64 bit with no extra development cost”…
But I don’t know, what I would sacrifice for it, since it is always about priorities…