Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: 32-bit floating-point (WAV) files "in the wild" (Read 20636 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

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

Reply #26
I won't. The author obviously has great knowledge in algorithms and such. For example, 7-Zip, WavPack and Monkey have much poorer compression ratio than ofr.exe for this test file. The author may simply have a different way of thinking than ordinary users.

It is also possible that the version of Audition the author uses showed different result than mine, who knows.

APE developer(s)? completely evaded this issue by not supporting int32 in Cool Edit and Audition. WavPack offers manual override option. In case of false positive BitSort and oldsCool may say the file's max sample value is several hundred dB above full scale and such, so should be pretty easy to notice.

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

Reply #27
A "slightly different" question. To identify whether a given 32-bit float signal can be fit into 24 bit (or less) integer with no other loss than a volume normalization - I could read a BitSort log and subtract min from max, but is there any quicker method (or other quicker tool)?

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

Reply #28
Knowing the min and max values does not guarantee a file can be losslessly converted to a fixed bit depth because the intermediate values are not shown. The most reliable method is to check every sample. It sounds like a slow operation but in practice still much faster than typically used operations like dither, resample and so on.

The readme file mentioned oldsCool can check if converting a 16.8 or 24.0 file to a normal file is lossy or not, this operation checks all samples, or until it finds the first lossy sample.


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

Reply #30
ALAC (requires refalac.exe) support added. Also changed the fallback SoX command to demonstrate the scale factor feature of stat. With -s 256 sample values will be displayed as 24-bit, and -s 65536 for 16-bit and so on. In SoX, max and min amplitude values are signed, while BitSort and oldsCool display max and min absolute values.

I am not confident to correctly explain the meaning of every item displayed by SoX, better check the SoX manual.

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

Reply #31
https://hydrogenaud.io/index.php?topic=122263.msg1009279#msg1009279
Real world example that oldsCool shows the HDCD files posted by @koawmfot  only used 17 bits while SoX and Audition showed something else. It is recommended to save the files as flac or 7zip as they are smaller and have built-in error check so that we know the downloaded files are not corrupted.

SoX
Code: [Select]
Input File     : 'E:\download\SW Decode - ffmpeg.wav'
Channels       : 2
Sample Rate    : 44100
Precision      : 24-bit
Duration       : 00:00:15.00 = 661500 samples = 1125 CDDA sectors
File Size      : 3.97M
Bit Rate       : 2.12M
Sample Encoding: 24-bit Signed Integer PCM

In:100%  00:00:15.00 [00:00:00.00] Out:662k  [ =====|=====-]        Clip:0
             Overall     Left      Right
DC offset   0.000009  0.000009 -0.000004
Min level  -0.603907 -0.495191 -0.603907
Max level   0.536741  0.536741  0.481397
Pk lev dB      -4.38     -5.40     -4.38
RMS lev dB    -21.43    -21.23    -21.64
RMS Pk dB     -16.77    -16.77    -18.34
RMS Tr dB     -29.31    -29.20    -29.31
Crest factor       -      6.19      7.29
Flat factor     0.00      0.00      0.00
Pk count           2         2         2
Bit-depth      24/24     23/24     24/24
Num samples     662k
Length s      15.000
Scale max   1.000000
Window s       0.050
Done.

Input File     : 'E:\download\SW Decode - CUETools.wav'
Channels       : 2
Sample Rate    : 44100
Precision      : 24-bit
Duration       : 00:00:15.00 = 661500 samples = 1125 CDDA sectors
File Size      : 3.97M
Bit Rate       : 2.12M
Sample Encoding: 24-bit Signed Integer PCM

In:100%  00:00:15.00 [00:00:00.00] Out:662k  [ =====|=====-]        Clip:0
             Overall     Left      Right
DC offset   0.000009  0.000009 -0.000004
Min level  -0.603907 -0.495192 -0.603907
Max level   0.536739  0.536739  0.481396
Pk lev dB      -4.38     -5.40     -4.38
RMS lev dB    -21.43    -21.23    -21.64
RMS Pk dB     -16.77    -16.77    -18.34
RMS Tr dB     -29.31    -29.20    -29.31
Crest factor       -      6.19      7.29
Flat factor     0.00      0.00      0.00
Pk count           2         2         2
Bit-depth      20/20     19/20     20/20
Num samples     662k
Length s      15.000
Scale max   1.000000
Window s       0.050
Done.

oldsCool
Code: [Select]
-------------------------------------------------------------------------------
E:\download\SW Decode - ffmpeg.wav
00:00:15 = 1323000 samples / 2-ch @ 44100Hz
24-bit fixed point
Bit    Count            Percent
0      118          0.008919124
8      199           0.01504157
9      426           0.03219955
10     847           0.06402116
11     1730           0.1307634
12     3303           0.2496599
13     6834           0.5165533
14     13527           1.022449
15     27112           2.049282
16     54488           4.118518
17     107067          8.092744
18     205345          15.52116
19     346154          26.16432
20     382560           28.9161
21     161670          12.21995
22     11612          0.8777022
23     8           0.0006046863
-------------------------------------------------------------------------------
E:\download\SW Decode - CUETools.wav
00:00:15 = 1323000 samples / 2-ch @ 44100Hz
24-bit fixed point
Bit    Count            Percent
0      118          0.008919124
8      199           0.01504157
9      426           0.03219955
10     847           0.06402116
11     1730           0.1307634
12     3303           0.2496599
13     6834           0.5165533
14     13527           1.022449
15     27112           2.049282
16     54488           4.118518
17     107067          8.092744
18     205345          15.52116
19     346154          26.16432
20     382560           28.9161
21     161670          12.21995
22     11612          0.8777022
23     8           0.0006046863
-------------------------------------------------------------------------------
.WAV file(s) processed: 2

To identify whether a given 32-bit float signal can be fit into 24 bit (or less) integer with no other loss than a volume normalization
I am thinking about adding this check, as well as other things like more advanced wBitsPerSample analysis and such. I upgraded my PC and still don't have Visual Studio and other stuff installed so it may take some time.

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

Reply #32
1.0.0.2
  • Combined BitSort and oldsCool into one executable.
  • Added action "LSB Trim".
  • Added signed max and min values in float reports.
  • Shows available actions at end of reports.
  • Uses advanced parsing rules to find nonstandard and malformed files.
  • Always update progress in console without speed penalty.
  • Fixed incorrect length report with some types of files.
  • oldsCool will enter read-only mode without prompt.

Download link:
https://1drv.ms/u/s!AvzB71jO7t0-gYwnoZKDu2Dr3TrAiQ?e=OnUhXp
SHA256:
8d82b8c79ec2ac85825fcc0ad03f6666ed19fdbfdc0f4beb7230c203cc465684

The CMD scripts attached in older posts are not compatible with BitSort 1.0.0.2, use the scripts included in the archive above. Other details are included in the updated readme file.

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

Reply #33
1.0.0.3
  • Added feature "Round Trip".
  • Fixed incorrect Abs.min value in some files.

Download link:
https://1drv.ms/u/s!AvzB71jO7t0-gYxSXo8wLrAYuWOuUw
SHA256:
daed1b4c095f2f7d284632c38b5b07f059898a909d2dac665c4765becd34c735

Also added foobar2000 x64 specific info in the readme file.

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

Reply #34
After some tests I found that the logic of foobar2000 x64's "Highest BPS mode supported" is that choosing 32-bit float will also include 32-bit fixed, but not the other way around. Therefore BitSort users should always set "Highest BPS mode supported" to 32-bit float, there is no need to create two BitSort presets like what I mentioned in the readme file.

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

Reply #35
1.0.0.4
  • Upgraded "Round Trip" to detect 2 to 31 bits with bit shift detection.

Download link:
https://1drv.ms/u/s!AvzB71jO7t0-gYxXHoM-nm9xnQTgBQ
SHA256:
f5eb7a73b9a1399d7906dfbbd00b0d7b5bbfbf2dd54d75878dcfd7b9410988ed

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

Reply #36
Through the years there have been quite a few people asking for float support in FLAC. Implementing this gives quite a few challenges, so at some point I pondered whether it would be useful to have some utility (perhaps the flac command line program) able to losslessly convert float files that have 'the right characteristics' to 32-bit int. This would involve a reversible (and thus lossless) normalisation step.

Of course, this means the input cannot have NaN or Inf samples, and the dynamic range is limited to what can be contained by 32-bit int. This conversion would have to be done in two passes over the input, first to find the required normalisation, the dynamic range of the signal and whether the file contains non NaN or Inf samples.

So, this gets me back to the original question: what do 32-bit floating point PCM files in the wild look like? If about 99% of those files can be losslessly contained in 32-bit integer PCM, the suggestion above would make sense. If a much larger share than 1% of those files cannot be converted using this method, it is probably not a good idea to implement it, as it would cause a lot of disappointment I suppose.

Is this something BitSort can do, reporting how much bits a 32-bit float file would use when converted to a non-float representation?

edit: this approach has the additional benefit that the playback application does not need to know about floating point representations, and that (crude) normalisation has already taken place.
Music: sounds arranged such that they construct feelings.

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

Reply #37
Is this something BitSort can do, reporting how much bits a 32-bit float file would use when converted to a non-float representation?
BitSort internally converts 32/64-bit float input to 32-bit fixed. If lossless conversion is possible, it will further check if fewer bits can be used or not.

WavPack still has an advantage to preserve non-audio data integrity in some cases, even if the files are not float.

BTW, I just found that my HTML readme file has incorrect syntax by using the "<" symbol literally instead of "&lt;" though it seems that browsers can still render the page without issue.

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

Reply #38
Use astats filter from FFmpeg instead, astats bit depth calculation is 64bit.

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

Reply #39
Just to clarify when BitSort/oldsCool receive audio samples, the stats are calculated in 64-bit float precision, and calculates 32-bit float and fixed point values in parallel. Otherwise it is not possible to detect integer overflow when converting to fixed point and denormal underflow when checking the Cool Edit/Audition float formats. Check the bundled ReadMe file for more details.

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

Reply #40
So, this gets me back to the original question: what do 32-bit floating point PCM files in the wild look like? If about 99% of those files can be losslessly contained in 32-bit integer PCM, the suggestion above would make sense. If a much larger share than 1% of those files cannot be converted using this method, it is probably not a good idea to implement it, as it would cause a lot of disappointment I suppose.
It is more likely that lower than 1% of 32-bit float files in the wild can be losslessly converted to fixed point by simple bit-shifting. Most software DAWs and plugins internally use floating point processing. For non-destructive operations (e.g. drawing a volume/pan envelope, or using insert/aux effects), processed 32/64-bit float data will pass through the master bus and subsequently the file renderer. If the DAW user export to fixed point the result will look like the Sound Liaison example I mentioned in the ReadMe file when the rendering pipeline uses 32-bit float. For destructive operations, even if a DAW supports 64-bit float processing, it may store intermediate results in disks (e.g. undo data and bounced tracks) using 32-bit float, so the ideal export format will still be 32-bit float.

So it is the other way around: 32-bit fixed point files in the wild has a higher chance to achieve lossless results when being converted to 32-bit float.

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

Reply #41
FWIW, the 32bit integer file that I used for comparison is the RMAA test signal.
That's no good. RMAA's int32 file is converted from the float32 signal, and if you carefully look at the "stereo crosstalk" spectrogram, all integer formats are clipped, the only unclipped one is the float signal. Luckily RMAA only uses that signal to measure crosstalk and ignores the clipping. The clipping can be easily identified even with a low precision analyzer like Spek. Notice the vertical lines in the integer file, those parts are clipped.
[attach type=image]22897[/attach]
Saving the 32-bit int RMAA signal without including the crosstalk signal, the result will round trip to 32-bit float.
X
Code: [Select]
-------------------------------------------------------------------------------
E:\download\Test signal (44 kHz 32-bit).wav
00:01:00.5132653 = 5337270 samples / 2-ch @ 44100 Hz
32-bit fixed point
Bit    Count            Percent
0      1646379         30.84684
1      424387          7.951387
2      6            0.000112417
3      6            0.000112417
4      7           0.0001311532
5      10          0.0001873617
6      13          0.0002435702
7      15          0.0002810426
8      21          0.0003934596
9      40          0.0007494468
10     61           0.001142906
11     96           0.001798672
12     167           0.00312894
13     264          0.004946349
14     495          0.009274404
15     953           0.01785557
16     1824          0.03417477
17     3541          0.06634478
18     7026           0.1316403
19     14094          0.2640676
20     29706          0.5565767
21     91781           1.719624
22     32315          0.6054593
23     18736          0.3510409
24     38079          0.7134546
25     71325           1.336357
26     147799          2.769187
27     278214          5.212665
28     410494          7.691085
29     612116          11.46871
30     1070134         20.05021
31     437166          8.190817
Round Trip: 32f
-------------------------------------------------------------------------------
oldsCool 1.0.0.4

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

Reply #42
Compression test. On float files I found in the wild. 13 of them. 5 from the same artist and another 2 from another artist, effectively down to 8. One of them is an 80 minutes podcast - many songs yes, but I guess the whole thing has been through the same (lossy?) processing first.
All found on Soundcloud except one from a netlabel. Description and most download links at the end - you need a Soundcloud account to download the WAVE I think.

Why even bother to test? Float is potentially a quite different beast compression-wise, than integer. And there are now actually four codecs that handle floating-point - five if you count the adaptive-mode ALS as a separate codec with the same name (it kinda is).
So, are we in for any surprises? Maybe? But first, a non-surprise:

TL;DR: Use WavPack, unless you have some very particular preferences.


Warning on Monkey's:
Very bad compression ratio - and worse the slower settings!  Yes, "Fast" compresses best and "Insane" worst - not only in average, but in most single tracks too.
If you are already using Monkey's over WAVE in some audio software plugin, sure it does improve slightly, and now you can use it on float too - so kinda it defends its existence, and in a setting where you likely would use "fast" anyway I guess?
No 3rd party support. (Monkey's float is too new, may or may not be coming.)

Warnings on OptimFROG (which, if you are willing to wait, gets you smallest files - frog doing frog things).
I got it to crash, several times.  It seems it was when compressing with wildcard, off *.wav, not on FOR looping.  Memory management?
Luckily I did not get it to produce corrupted files.
Also, OptimFROG isn't supported by ffmpeg or anything - but official tools are available for several OSes and include a fb2k component.

Warnings on MPEG-4 ALS (for the morbidly curious)
Nothing else can decode this.  ffmpeg and VLC have ALS decoding support you say? Oh no, not for floating-point. (And in any case, not for the -z codec.)
Although I did not make it misbehave on float, I have earlier on provoked the ALS reference encoder/decoder to produce files it cannot read (and nothing else can!).  It seems not even those who care about ALS at all (the dev team?), bother about -z.


Performance then? Most like expected, except Monkey's doing bad. And, slower Monkey's doing even worse (but only like 0.0 to 0.2 percentage points, I omit them from table).
Timings are very rough. Used timer64, but not all were re-run. YMMV, but the big picture is kinda ... well perhaps WavPack -h and -hh didn't appear that expensive in decompression speed compared to in ktf's tests, that is maybe a mild surprise?
Also the last file in the below list was added after timing, and is only included in the sizes and percents.

No manual check for any CoolEdit files, no option to correct for that applied.

unw.avg %sz-wghtWAVE = 3469880566enc.timedec.timecodec/setting/b]comment
86,0%85,3%29601218563610NTFS compact /C /EXE: LZXNew compression in Win10?
79,9%78,3%27177384024440Monkey fastfast = smallest and insane = largest, hands down - not only in averages, but in most files
60,3%61,3%21265540523727wavpack -f
58,6%58,9%204289607444541ALS default
58,6%58,7%20377502286339wavpack -hx
58,5%59,4%20609322746671OptimFROG fastest= --mode fast --optimize none
57,8%57,3%198862468124min18s467ALS -z1
57,8%57,3%198803518836min40s41wavpack -hhx6
57,7%57,8%200513382011287OptimFROG default
57,6%57,0%197787712827min13s1387ALS-z3
57,5%56,9%197323500867min34149ALS -7 -p
57,0%56,4%195760277829min37618OptimFROG heaviest= --mode ultranew-light --optimize high
Underlined: The two "fastest" OptimFROG do benefit from the ordering by unweighted - they are not equally good on the biggest file. Otherwise, weighted and unweighted order are the same.

Since I am obviously touting WavPack here, how about some more figures comparing more settings and with ffmpeg's implementation?
unwwghtencWavPack:
60,5%62,2%46ffmpeg @ default
60,3%61,3%37-f
59,4%60,3%46-g (default)
58,6%58,7%63-hx
58,0%57,9%646-hx4
58,0%58,1%6HOURS10minffmpeg-wavpack @ -compression_level 8
57,8%57,3%36min40s-hhx6
No big surprises here either I'd say, it is known that ffmpeg's compression level "8" is not ... efficient. I did include it to see if this stupid level of effort could push the limits. It couldn't, not even spending 10x the time of -hhx6 (it also seems to decode slightly slower, but who cares?). Unweighted size is bigger than reference wavpack.exe at -hx4.


Files, most can be downloaded with a Soundcloud account, with annotations; percents are "lower is better"; I did remove all metadata first.

CVLT CAST Doom 2016 (yep, a podcast on doom metal)
https://soundcloud.com/cvltnation/cvlt-cast-episode-one-doom-2016 , 79 minutes - several songs, but it is one podcast, I assume they have all been through the same processing.
WARNING of an extreme peak of 9.312567. Have not checked whether that is a CoolEdit format thing.
This varies a lot in compression ratio: OptimFROG got it to 55.2%, WavPack -hhx6 to 56.2%, WavPack up to 64.0 for ffmpeg-default - and then Monkey's at 77 and NTFS at 81.

Kosey: "Sensual Desire" (House)
https://soundcloud.com/kosey-1/kosey-sensual-desire-original-mix-free-download-wav-320kps-links-in-description
65.5 to 68.6 except Monkey's (80) and NTFS (91)

SNCHZ "Destrudo" and "Hate VIP", averaged together before applying unweighted averages
https://soundcloud.com/deceiverdubz/destrudo-free-download and https://soundcloud.com/deceiverdubz/hate-1
71.7 to 73.3 percent for everything but Monkey's (81) and NTFS (90)

The Opium Cartel (that features Tim Bowness of No-Man): "Silence Instead" (prog)
https://soundcloud.com/termo-records/silence-instead
60.3 to 63.3 except Monkey's (82.6) and NTFS (92)

Treha Sektori's "Music, Blood and Spirit", track 1 (dark ambient, 23 minutes) 
http://web.archive.org/web/20170206220402/http://timeisdivine.com/soz/download/Treha_Sekori-MBAS_OST-WAV-SOZ.zip
IIRC, it has been processed as integer (witnessed by signs of clipping) before converted to float.
53.7 to 58.3 except Monkey's (78) and NTFS (91)

Captain Flanger: "Groove On" (Electronic) - user has deleted themselves from Soundcloud.
16 bits exported to 32 - that happens from time to time.  That means it compresses to 30% to 33% except it fools Monkey's big time (80 percent) - the NTFS compression makes it to 60, that is better than Monkey's.
Also the only 48kHz file among these.

And then five tracks off a metal band that has taken their WAVE files off Soundcloud, sorry. The music, for those who care.
I averaged the five tracks together before taking unweighted averages.
62.5 to 64.9 except Monkey's (84) and NTFS (92)

Xiena Project: "I Can Feel The Rhythm" (dance)
https://soundcloud.com/xiena_project/wav-format-upload-test-can-feel-the-rhythm-192khz-32bit-high-resolution   
192kHz file found and added afterwards; all timings are without this one! (also I forgot to remove the RIFF chunk before compressing, but it was only 34 bytes - no huuge embedded image.)
56.8 to 58.6 except Monkey's (76) and NTFS (91)


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

Reply #44
Here is a 40 minutes file that exhibits something-above-my-paygrade about CoolEdit/Audition and how the codecs handle it:
https://soundcloud.com/okiamjordank/iamjordank-playlist-project-32bit-44100

810 MB WAVE.
1 GB OptimFROG with --mode normalnew, returns the warning:
WARNING: Adobe Audition bug analyzer found 96439823 corrupted zero samples.
         You should use --correct_audition to correct these corrupted zero
         samples back to 0 and significantly improve compression ratio.

656 MB OptimFROG with --correct_audition --mode normalnew, with the message
Adobe Audition bug: corrected 96439823 corrupted zero samples back to 0.
640 MB WavPack -hx
Then, what happens if I use WavPack's -a?
1 GB there too.

Geeh, this isn't easy for a novice to understand.

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

Reply #45
If your downloaded copy is not corrupted, it should be a normal 32-bit fixed point file. Try ofr.exe, not off.exe

SHA256
644985b14ca018c74f560328e5d26a3660748b3cb0d4aa8c8303a2b02aa3b6af
iamjordank - playlist project - 32bit-44100 .wav

Code: [Select]
-------------------------------------------------------------------------------
E:\download\iamjordank - playlist project - 32bit-44100 .wav
104216 extra bytes at 850200700
00:40:09.8658049 = 212550164 samples / 2-ch @ 44100 Hz
32-bit fixed point
Bit    Count            Percent
0      214         0.0001006821
1      195         9.174305E-05
2      393         0.0001848975
3      769          0.000361797
4      1542        0.0007254758
5      3105         0.001460832
6      6020         0.002832273
7      11337          0.0053338
8      19245        0.009054333
9      28080           0.013211
10     33140         0.01559161
11     33947         0.01597129
12     41510         0.01952951
13     47350         0.02227709
14     52243         0.02457914
15     64629         0.03040647
16     91045         0.04283459
17     132761        0.06246102
18     189495        0.08915307
19     275697         0.1297092
20     425448         0.2001636
21     724422          0.340824
22     1332435        0.6268803
23     2487198          1.17017
24     4601880          2.16508
25     8450132         3.975594
26     15410568         7.25032
27     27242207        12.81684
28     44333960        20.85812
29     58329023        27.44248
30     42912026        20.18913
31     5268148         2.478543
-------------------------------------------------------------------------------
oldsCool 1.0.0.4

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

Reply #46
Yeah, as @bennetng says, that file is not a 32-bit float file at all. It’s 32-bit integers, and that’s what the WAV header says it is. It was created by Adobe Media Encoder (whatever that is) according to the RIFF info at the end.

If you interpret it as float then the compression is going to be really bad (which is what -a is forcing WavPack to do). I’m not sure what Florin means by “correcting corrupted zeros”, but interpreting integer data as float gives wacky stuff.

I can also tell that this file was originally 32-bit float data because the new --optimize-32bit option in WavPack (the one suggested by @bennetng) improves compression by 12%.

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

Reply #47
Assumption is the mother of all .f**c-up, yeah.

As you guys might have guessed, I just took off.exe to be the answer to whether it was float. Because feeding it integer will usually make it throw the error
Code: [Select]
Exception UNKNOWN in file unknown, line 0
description: sample type not yet implemented
Apparently it does not for 32-bit. Tried both extensible and old WAVE ... uh, at least I think I did.

This is not the nicest of bugs. Compressing bad but losslessly is well, at worst only an unfroggish thing to do. But this one asks the user to apply an operation that just destroys the audio.
I should have listened to it before I posted too - this is so destructive I won't even call it "lossy".


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

Reply #48
As you guys might have guessed, I just took off.exe to be the answer to whether it was float.
FWIW off.exe always treat all input files as float, either in standard type 3, or in Cool Edit 16.8 and 24.0 formats, so it must not be used as a tool to identify if a particular input file is float or not. In the case of this 810MB file Audition 1.5 also knows it is not a float file and can be correctly opened without any issue, unlike the example I posted in Reply #24 where Audition misinterprets as 16.8 float even when I have Audition's format detection option disabled.

WavPack's --optimize-32bit is very useful for identifying if the file is originated from float or not (or vice versa). oldsCool shows "Round Trip: 32f" only when the whole file can be losslessly converted, which means even when there is only one lossy sample it will not round trip. WavPack's --optimize-32bit does not have this limitation.

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

Reply #49
As you guys might have guessed, I just took off.exe to be the answer to whether it was float.
FWIW off.exe always treat all input files as float,
Maybe (... likely ...) all 32 bit files, but certainly not 24 or 16, cf the error message I pasted above.

WavPack's --optimize-32bit is very useful for identifying if the file is originated from float or not (or vice versa)
Originated from, that is question for when input file is integer. ("32-bit integer"?). BTW, to other readers: that option is as of now only in a beta.
I have yet to see WavPack mis-identify input files.

(Not counting all the times I have been scared by wvunpack's "not compatible with this version of WavPack file!" error, which it throws when by mistake I have called wvunpack on something that is not a WavPack file at all.)