Hi guys,
i was trying to find sample points in a wave audio file which exceed certain threshold value. and stumbled into some calculations which I couldn’t figure out . (I just started audio programming so please bear with me if the questions are basic )
i have seen in most of the examples and code i found on the internet. that even 16 and 24 bit depth audio files are read as AudioSampleBuffer rather than AudioBuffer<int>. are there any advantages of converting fixed point to floating point and perform gain change and other operations.
and for converting int to float a multiplication factor 1.0f / 0x7fffffff is used so trying to understand why 0x7fffffff is used
I tried to read a 24 bit depth wave audio file into int buffer. as below
AudioBuffer<int> buffer(readerTmp->numChannels, samplesToCopy); readerTmp->read(buffer.getArrayOfWritePointers(), readerTmp->numChannels, currentSample, samplesToCopy, false);
but when i try to read individual samples (as int val = buffer.getSample(0, i);) some times i am getting values which exceed 24 bit depth range (i.e 8,388,608)
what’s the best way to check for threshold values.(the threshold value is given in db). i can think of two ways
i) convert dbToGain and use AudioBuffer to compare gain value
ii) convert dbToGain and convert the gain value to float and use AudioSampleBuffer to compare sample value
please suggest best approach (or any other approach)
AFAIK AudioBuffer<int> is not a thing in juce. All operations are designed to do floating point processing. You can convert from/to int using AudioDataPtr::convertSamples though.
having audio in this normalized range (-1, 1) makes it a lot easier to imagine the wave and their clipping points and a lot of algorithms are performed on audio in that form
since AudioFormatReader supports this function bool AudioFormatReader::read (int* const* destChannels, int numDestChannels, int64 startSampleInSource, int numSamplesToRead, bool fillLeftoverChannelsWithCopies) i thought its an option too
one reason i can think of is if convert fixed point to floating, we can handle fixed point and 32bit floating point and 64bit floating point wave audio files the same way
You are right, and of course it should work. But juce tries to abstract the diversity of audio file formats away. My advice was based on the posts I read before that several templates are problematic with integral types, e.g. if they calculate a proportion internally they often get a degraded output. So better read my answer: it’s possibe but expect dragons.
Some people forget, that the WAV audio format is a container format as well, so there can be different audio codecs embedded. Surely most of the time it’s PCM data, but it can also be a digital AC3 stream or bwav (which usually is PCM data as well with additional headers and 64 bit compliance).
Also the sample format in WAV files is not always int16 or int24, more and more you find 32 bit float samples there as well. Those formats can exceed 0 dBFS (= 1.0f or max int). I assume that’s what you are seeing, but that is guessing.
Modern processors work well with floating point numbers, other than in the early 90s when 16bit /44.1kHz was defined. The problems with overflowing int types outweigh every performance advantage, that’s why most audio engines got rewritten in the meantime to work with floats internally.
Integer audio processing is still used in low-spec embedded systems, where resources are thin.
TL;DR: check if the original file is indeed in 24 bit and if that’s the case check, if it might be a rounding error. Or if there is some other processing step I don’t know of, that could introduce such behaviour as well. I doubt that it is inter-sample-peaks, since they only occur on restoring the analog signal or when resampling.
But could be anything else…
thanks for taking time to give such a detailed explanation.
like you said floating point computations are faster on modern cpus that’s one advantage. i have read in one of the posts some other advantages of using floating point buffer but i am not able to locate it. will post it here if i find it
coming to my original problem samples exceeding 24 bit depth range. i don’t think its inter-sample peak because the values exceed quite often.
i looked into the AudioFormatReader code it is indeed a 24bit file because bytesPerFrame in below line of code is 6 for 2 channel auto bytesRead = input->read (tempBuffer, numThisTime * bytesPerFrame);(and AudioFormatReader bitsPerSample is also 24 bits)
after reading bytes 24 bit is converted to 32 bit using ReadHelper<AudioData::Int32, AudioData::Int24, AudioData::LittleEndian>::read (destSamples, startOffsetInDestBuffer, numDestChannels, sourceData, numberOfChannels, numSamples);.
i am assuming this were some value is added to original 24 bit to convert it to 32 bit because the value is finally converted to float using 0x7fffffff (i.e sample/ 0x7fffffff). 0x7fffffff is the max value a 32 bit can hold. if no values were added to 24 bit sample the sample would have been normalized with a maximum value a 24 bit can hold
now i have to find a way to present to the user a threshold range which is not 0 - 1. and convert it to a value between 0 - 1. please suggest if you have any leads
