Topics covered:
-InnerFidelity history (interesting, not super useful)
-Discussion of limitations of current audio measurements (super interesting)
-Discussion of EQ in analogue vs digital domains (tl;dr, it’s better to use EQ cuts than gains in digital, lots of interesting stuff about how LPs were mastered & cuts)
-More discussion of measurements and what they tell you about a headphone (gold)
-Stuff about gaming audio
-Probably other stuff, still watching the stream.
They talk somewhat about digital audio, leading to my question:
Does anyone know if audio data is stored as INT32 or FP32?
Pretty sure the data in is integer format. If you need more precision, it’d be easier & faster to add more bits (48, 64) than decimals. But I’m not sure what would need more than 32 bits for a pure audio stream; if you different data (e.g. positioning, filters, etc) that could be in a separate data stream.
The short answer is that it depends.
It depends on the audio file format (FLAC for example doesn’t support floating point at all but I’m of the opinion that it doesn’t really suffer from the lack). It depends on the precision of the audio - no point using 32 bits in the file to store 16 bits of data - you can implement any word size you want in a file if you’re prepared to go the extra mile. FLAC supports integer word sizes of anywhere from 4 bits to 32 bits (although nobody has implemented more than 24-bits).
An Integer in C++ for example is 16 bit, long int pushes that to 32. That is why I asked the way I did.
For Floats, they are usually 32-bit, allthough 64-bit (= double precision) is quite common for engineering applications. 16-bit float is gaining popularity for graphics (since some GPU-architectures can run FP16 operattions at double the speed that they can FP32)
Actually it’s implementation dependent; a long int is usually 64 bits on a 64-bit system; conventionally int was usually the same as the processor word size but seems to have stopped at 32-bits. Which is why explicit sizes are common in lower-level programming (i.e. int64 or u_int64).
But whilst code dealing with audio data may well use u_int32 internally (or double or long double), the actual audio data is as in the file (i.e. 4-24 bits).