32-bit floating-point (WAV) files "in the wild"

Topic: 32-bit floating-point (WAV) files "in the wild" (Read 3191 times) previous topic - next topic

0 Members and 2 Guests are viewing this topic.

32-bit floating-point (WAV) files "in the wild"

2017-10-22 20:05:08

There are a few of these out on the 'net by now. I can only speculate that more artists use software that work with such files, and more often than before an artist will upload a file without having to worry whether to save bandwidth by going mp3.

But why? Of course there will always be someone who on purpose will upload the biggest files they can, but I know that not all of my files were intended to be uploaded in that format ...
Is it so that these DAWs do not even tell you that these are not your "usual" WAV files? (What does Audition do? I'm too lazy to download a trial version just for this.)

Just curious.

Re: 32-bit floating-point (WAV) files "in the wild"

Reply #1 – 2017-10-22 20:18:26

In my little world of Linux/Unix and Windows command line, I use the utility sox (the command name is actually soxi), and that is how I normally determine what kind of data/sample rate in a wav/mp3/flac/etc file. The utiiliies that I write also automatically display the data type/rate. My own 'normal' data type is 32bit float (or 24bit signed int for flac), even though I normally produce 16bit to send to others. So, the best bet that costs NO money is to use the command line soxi. Also, I happen to know that Audacity (free GUI audio software) displays the data type also ( i use Audacity once in a while.) A wonderful (almost lossless) tradeoff is to use 24bit signed flac, which ends up being not far different from a 16bit wav file in size.

John

Re: 32-bit floating-point (WAV) files "in the wild"

Reply #2 – 2017-10-22 20:29:17

A very horrible thing with float 32 file is they can be encoded in different "normalized" fashions. If the decoder misinterpret the format, the result will be horrible full scale square wave-ish like crap which may destroy your equipment. I experienced this nightmare several times, sometimes in foobar2000, sometimes in Audition.

Of course, in DAWs if people find the decoded waveform looks like crap, they won't hit the play button, but that's not the case with typical audio players.

https://forum.cockos.com/showthread.php?t=85641

Re: 32-bit floating-point (WAV) files "in the wild"

Reply #3 – 2017-10-23 01:37:40

Quote from: bennetng on 2017-10-22 20:29:17

A very horrible thing with float 32 file is they can be encoded in different "normalized" fashions. If the decoder misinterpret the format, the result will be horrible full scale square wave-ish like crap which may destroy your equipment. I experienced this nightmare several times, sometimes in foobar2000, sometimes in Audition.

Of course, in DAWs if people find the decoded waveform looks like crap, they won't hit the play button, but that's not the case with typical audio players.

https://forum.cockos.com/showthread.php?t=85641

oh my!!! Most of the files that I have dealt with are +-1.0 floating point, but I do know that it is theoretically possible to sent out files with bigger numbers. I always believed that +-1.0 floating point is the same as +-32767 for 16 bit signed -- and so be it... So, you have seen different? But of course, invalid files with >+-1.0 (assumed that they were invalid) should be clipped and/or flagged. In between running my Unix pipelines, I do (incorrectly, I believe) SOMETIMES during my experiments, take advantage of being able to deal with greater than normal floating point values. For example, I might have an expander whose output might peak at +-2.828 (just as an example) due to exceptional material, but then future normalization stages will fix it. On the other hand, 'sox' will complain about such files, and probably should process the file if the results are correctly normalized, or MAYBE SHOULD BASED UPON COMMAND LINE FLAGS simply bounce the file somehow?.

Your point about nonstandard floating point values is definitely a valid issue, however. (By the way, the term normalized/un-normalized has a specific meaning the the floating point realm -- when the term different 'normalization' was used -- I assumed being able to handle differing/odd ranges of values, right?)
So, to me, it seems like the FP format should be standardized, or avoided for interchange. I suspect that for most (all) PRACTICAL purposes, the signed 24 bit should be sufficient, but wonder if it also has such scaling issues? (I use 24bit only so that I can use flac with reasonably high resolution.)

John Dyson

Re: 32-bit floating-point (WAV) files "in the wild"

Reply #4 – 2017-10-23 08:01:40

Thanks for the warning. And thanks to ReplayGain and fb2k's preamp option that turns down files w/o RG info ...

There could be a lot of different signals in a WAVE file (https://msdn.microsoft.com/en-us/library/windows/hardware/dn653308.aspx - date says 2007, but a version was around before y2k), but I don't think I have seen music published as anything but 16-bits integer, 24-bits integer, whatever-32-bits-that-WavPack-can-contain - and one single IMA ADPCM.

Re: 32-bit floating-point (WAV) files "in the wild"

Reply #5 – 2017-10-24 02:39:00

David made a change to WavPack to permit the storage of floating point audio using the same compression method as for integer audio (around the time I was developing TransPCM - which can output Float16 audio from several different inputs).

For Float16, I made use of the full range, i.e. ±65504 at the top end to ±5.96046E-08 as the minimum subnormal, giving a range of 1,098,975,582,421:1 (or approximately 40 bits) with up to 11 significant bits.

Re: 32-bit floating-point (WAV) files "in the wild"

Reply #6 – 2021-01-25 11:29:07

Quote from: bennetng on 2017-10-22 20:29:17

A very horrible thing with float 32 file is they can be encoded in different "normalized" fashions. If the decoder misinterpret the format, the result will be horrible full scale square wave-ish like crap which may destroy your equipment. I experienced this nightmare several times, sometimes in foobar2000, sometimes in Audition.

Of course, in DAWs if people find the decoded waveform looks like crap, they won't hit the play button, but that's not the case with typical audio players.

https://forum.cockos.com/showthread.php?t=85641

OK I made a tool to automatically detect these kinds of files, and convert them to the standard formats as shown here. Of course, you need to have these kinds of files to try it.

The detection methodology is also somewhat relevant to this thread as well, as my program showed more accurate result than others (SoX, Bitter, Adobe Audition). For example, here is a 8-bit file, with 1dB volume reduction, then dithered to 16-bit.
https://hydrogenaud.io/index.php?topic=120395.0

Quote from: marcoxD95 on 2021-01-06 00:04:35

I search for a tool that can check my 24bit downloads I have purchased over the years. Honestly its just a handful compared to my whole 16bit FLAC collection but I often wondered whether these 24bit files are actually true or just upconverted 16bit.

Quote from: j7n on 2021-01-06 04:10:44

You could try a bit meter. A few are available as VST plugins, for example Bitter.

My result:

Download link:
https://1drv.ms/u/s!AvzB71jO7t0-gYwfVGulbuFbVFZcmg?e=uN2p8Z

SHA256:
ee3a919fb267b9afec9494a0ae7f9b3ebd4fad97b8a03cc65245839ec2138d4f

Re: 32-bit floating-point (WAV) files "in the wild"

Reply #7 – 2021-01-25 20:50:35

equipment doesn't get destroyed from its intended use (playing sounds), this is some urban legends.
it can destroy ears if you accidentally play it too loud, though.

Re: 32-bit floating-point (WAV) files "in the wild"

Reply #8 – 2021-01-26 01:05:56

Tweeters are almost never capable of outputing maximum power in high frequencies that clipping or integer overflow can create.

A 1 dB volume adjustment with dither can also be detected on a histogram of byte values where some are more likely to occur than others. All bytes of a sample are overlapped on the same chart, but the effect is still clear. This can be run on a fadeout portion to detect smaller discontinuities. But a mild bass boost is enough to make the histogram smooth again.

I was unable to run this program because it requires NET Framework. Would it describe a file with bass boost and phase shift in a way that is detectable? Or in other words, what else besides a volume adjustment can it detect?

Maybe you could output a pseudographic bar chart in the analysis output to get a histogram that is easier to parse by eye (more symbols: greater value).

Re: 32-bit floating-point (WAV) files "in the wild"

Reply #9 – 2021-01-26 05:23:50

Quote from: j7n on 2021-01-26 01:05:56

I was unable to run this program because it requires NET Framework. Would it describe a file with bass boost and phase shift in a way that is detectable? Or in other words, what else besides a volume adjustment can it detect?

The ReadMe mentioned these things already if you cannot run it. To elaborate, BitSort is used to assist the development of oldsCool so that I don't need to convert everything to .wav files during analysis. It reads the data bytes in files in integer and float with different ranges and guess the format as the header information could be unreliable. So anything resembles a bit meter is just a side effect rather than the main function of the software. For example, BitSort will still detect 16.8 float content if the files are being saved in WavPack as it is lossless and supports both 32-bit integer and float.

Re: 32-bit floating-point (WAV) files "in the wild"

Reply #10 – 2021-01-26 07:46:40

Anyway, here is how the 8-bit RMAA signal looks like with bass EQ, peak normalization (to avoid clipping) and dither. The highlighted parts are still correlated to the original file, not scattered around. Of course, it cannot be compared in this way if there is no reference file, and if you resample, it falls apart anyway.

The frequency response of the EQ looks like this:

I don't like the presentation of Bitter as the UI is too small and it is pretty hard to count the number of lines, especially when they move quickly.

Notice