checking if an audio files is really 24 bit precise
Dear all
I've been trying to open a 24bit audiofile and monitor its last 8
bits to see if my source was 24 bits... I've tried to use bitand~
with mode 1 and a mask bits 0000000000000000000000000001 and get
nowhere.
Any hints are welcome
pa
Quote: tremblap@gmail.com wrote on Thu, 18 September 2008 07:46
----------------------------------------------------
I've tried to use bitand~
> with mode 1 and a mask bits 0000000000000000000000000001 and get
> nowhere.
Hey PA,
This isn't an entirely straightforward problem.
1 - As soon as you load the file in max it's in 32bit float, which means that you wouldn't expect there to be bits in the last 8bits of the *float* format at all times - in fact I'd only expect them to have something in them when the value in the 24bit formst was big enough to go into the first 8bits (otherwise the floating point will have shifted the significant bits leftwards in the 32bit format and the last 8bits will be zeros).
2 - I'm not sure whether you'll EVER get something in the last bit or not - the floating point format is 1 sign bit, 7 bits of exponent and 23 bits of significand/mantissa - however, the 23bits actually represents 24 bits with an implicit leading 1 in most cases (chack wikipedia for more boring details). 24bit integer format (asfaik) is the equivalent of 23bits of precision plus a sign bit. What this means in real terms as far as I can deduce, is that there is nothing in a 24bit int sound file that ever equates to the final bit of a 32 bit float given a correct conversion.
So, what can you do? Well, if you have any values coming from your soundfile that are less than 1/65536 or possibly +/-1/32768 (I'm not sure which is correct) in value and also non-zero then you have more than 16 bits in your file file, which you should see I'd imagine. I think dividing by larger powers of 2 will answer whether there are more than the relevant number of bits in your file.
Really I can't think of a particularly great way of doing what you're essentially trying to do (make a bitmeter) in Max. You might be better off searching for a free bitmeter, or looking more directly at the bits in C or something. Anyway, the main problem though is understanding the conversion - that you shouldn't be expecting something in all 23bits of signicand at all times - I think you're expect more significant bits with a larger value and less with a lower one - in relation to the size of the exponent....
This is all just what I've figured out from thinking about 32bit floating point format. If anyone knows more, or can confirm/correct anything above please do.
Alex
Quote: tremblap@gmail.com wrote on Thu, 18 September 2008 07:46
----------------------------------------------------
> Dear all
>
> I've been trying to open a 24bit audiofile and monitor its last 8
> bits to see if my source was 24 bits... I've tried to use bitand~
> with mode 1....
Sorry. Looked at this again, and I stupidly misunderstood the way bitand~ was converting to integers.
However, you are using 2 arguments right? - like [bitand~ 1 1]
I'm pretty sure that should give you what you want, possibly reentering the mask bits using the bits to be sure what is going on.....
Alex
Quote: AlexHarker wrote on Thu, 18 September 2008 13:10
----------------------------------------------------
> Quote: tremblap@gmail.com wrote on Thu, 18 September 2008 07:46
> ----------------------------------------------------
> > Dear all
> >
> > I've been trying to open a 24bit audiofile and monitor its last 8
> > bits to see if my source was 24 bits... I've tried to use bitand~
> > with mode 1....
>
> Sorry. Looked at this again, and I stupidly misunderstood the way bitand~ was converting to integers.
Actually I've misunderstood this twice - when you convert to ints it seems to be truncating to an int, which means when in normal audio range (-1 to 1) you won't get anything out unless the input is 1 or -1. Therefore, you need to multiply your input by 2 to the power of 23 or 24 (again not quite sure which because of the sign bit issue) to get in in the right range. Then it *should* work.
Alex
Quote: tremblap@gmail.com wrote on Thu, 18 September 2008 16:07
----------------------------------------------------
> dear Alex
>
> None of your proposed methods worked... I've tried them all before
The below works perfectly well for me: You need to bang the bitmask into the object obviously.
If it doesn't work for you then perhaps you don't have a 24bit file... :-(
Alex
Quote: tremblap@gmail.com wrote on Fri, 19 September 2008 02:34
----------------------------------------------------
> Alex, you example does not work with 16 bit files...
Hi PA.
The *~ 256 should probably be a *~ 128. For a 24bit file I get stuff in all the bits. For a 16 bit file (such as any from the max examples) I don't get anything until the *10TH* LSB with the example I've send you (because I've shifted by 2^24, and it should be 2^23 because one of the bits in a integer format is for the sign). If you change it to *128 that'll shift to the 9th LSB (as you're probably expecting)
Anyway, it does distinguish between 16 and 24 bit files at least. The weird thing I'm getting though is to do with seeming to have more than 24 bits of precision when using a 24bit file (see the following patch), which means this may not be a valid test of a 24 bit source.
I'm not sure why this is happening, a multiply by a power of two should just affect the exponent and thus be exact. Perhaps something is going on inside sfplay for 24bit files that we don't know about.
With the patch below I get only integer multiples of 256 with 16 bit files, but although I'd expect only integers with 24bit files, I get fractional parts too....
This appears to happen when I record a 16bit source to a 24bit file as well, so it doesn't look like this will work...
Alex
Dear Alex
Thanks for your help
> With the patch below I get only integer multiples of 256 with 16
> bit files, but although I'd expect only integers with 24bit files,
> I get fractional parts too....
With 16bit files, I get all sorts of fractions as well... have you
tried different 16bit files?
pa
Sorry, my sampling rate was not the same, hence the interpolation
noise...
I'll check with a buffer read.
Quote: tremblap@gmail.com wrote on Fri, 19 September 2008 06:48
----------------------------------------------------
> With 16bit files, I get all sorts of fractions as well... have you
> tried different 16bit files?
The ones from the sounds folder of max + one or two that I have from recent mixes of recordings. I get no fractions in either case for 16 bit files (and I believe I get always multiples of 256, as the shift is 23bits to the left with the given multiplications)
I'm running intel MBP 10.4.11 in max 4.6 latest and in 5 - same results in both. What is your exact platform/system?
Alex
Quote: tremblap@gmail.com wrote on Fri, 19 September 2008 06:51
----------------------------------------------------
> Sorry, my sampling rate was not the same, hence the interpolation
> noise...
>
> I'll check with a buffer read.
I see - that's probably it.
BTW - I still get fractions with an index~ / buffer combination for 24bit files, which I really don't understand... I recorded one of the max sound examples to a 24bit file and it had fractional parts etc, thereby appearing to have 24bits of data by my check but obviously it doesn't, so I'm not sure how valid a method this is, or what exactly is going on in the 24bit case - the 16bit case is actually the one that works as I'd expect.
A.
My maths for the multiply may have been off by one (float 1.0f probably equates to (2^23 - 1) in a 24 bit file, as that's the largest value you can store, rather than (2^23)).
Hence this revised version. It doesn't give 0s in the last 8bits for a 16 bit file (unless the values in the file are 0), it seems to give either the last bit on, or all last 8 bits on, possibly float round-off error?
Anyway, the difference between a 16bit file and a 24bit one is really obvious, and it also works for a 24bit file that has had a 16bit file recorded into it (ie. can be used to identify files that are 24bit format but don't actually have 24 bits of precision).
Hope it works for you. Let me know if you got a 24bit recording or not!
Alex
> Hope it works for you. Let me know if you got a 24bit recording or
> not!
Here is my version. It does help to divid by 8bit, because some 24
bit files will have been scaled down... if you always have the same
digits after an integer, you know your resolution was 16 bits... btw
they were real 24bits...