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: Use of non 8/16/24-bit audio, like 12-bit audio (Read 17018 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Use of non 8/16/24-bit audio, like 12-bit audio

Reply #25 –
20-bit Cool Edit/Audition wav file attached. Basically just 20-bit padded to 24-bit with a slightly modified header.

Some programs cannot open these 20-bit files. A simple tool I made (oldsCool) can convert them to normal 24-bit files.
https://hydrogenaud.io/index.php?topic=97746.msg1004399#msg1004399

Re: Use of non 8/16/24-bit audio, like 12-bit audio

Reply #26 –
Cog now supports this format, thanks to FFmpeg. I accidentally disabled most of the PCM and ADPCM handlers, and this one depended on the PCM24LE codec.

Re: Use of non 8/16/24-bit audio, like 12-bit audio

Reply #27 –
Is there any tool that converts between WAVE versions, preserving bit depth (that is not a multiple of eight) - and, between WAVE and AIFF?

Here is the thing:
* The "audition 20-bit.wav" file is rejected by SoX (saying it has a premature EOF), FLAC, Also Monkey's Audio and TAK.
* WavPack can decode it, and restore it bit by bit as it usually does. OptimFROG as well. Surprisingly also TTA.
* wvunpack --wav forces a different .wav file out, presumably fixing something. But SoX/FLAC/MAC/TAK (and now also TTA) refuse that one too.
* Here's how to get a 20-bit that FLAC can eat:
wvunpack "audition 20-bit.wv" --caf-be - | ffmpeg -i - -codec copy "audition 20-bit.wv.ffmpegged-to.aiff"
It keeps the 20-bit flag. (Edit: because AIFF! Asking ffmpeg to output WAVE from little-endian wvunpack output yields [wav @ 0000000000580040] requested bits_per_coded_sample (20) and actually stored (24) differ - is there any way to override ffmpeg's misbehaviour here?)
* FLAC can encode this AIFF, and will decode it to a 20-bit WAVEFORMATEXTENSIBLE which "all codecs" handle. (Now, TTA is oblivious about the real bit depth and upconverts to 24-bit - as does SoX as does ffmpeg.)

This is not limited to 20-bits; using flac --lax, it would work with 17 or 23. (Though it seems that starting with a 9-bit-in-24-bit .wav , ffmpeg will output a 9-bit-in-16 .aiff.)

So this was a most cumbersome way - that by FLAC limitations need bit depth to be 4 to 24.
There must be some utility that does this without FLAC?!






Quote from: ktf on
I just hacked the FLAC encoder to accept 12-bit raw, so I'm no longer looking for tools to do this.
I'm late to that party, but fascinatingly: you didn't have to.

Re: Use of non 8/16/24-bit audio, like 12-bit audio

Reply #28 –
Quote from: Porcus on
(Edit: because AIFF! Asking ffmpeg to output WAVE from little-endian wvunpack output yields [wav @ 0000000000580040] requested bits_per_coded_sample (20) and actually stored (24) differ - is there any way to override ffmpeg's misbehaviour here?)
Have you tried ffmpeg directly with the wavpack file as input? ffmpeg -i "audition 20-bit.wv" -bits_per_raw_sample 20 output.aiff


Quote from: Porcus on
Quote from: ktf on
I just hacked the FLAC encoder to accept 12-bit raw, so I'm no longer looking for tools to do this.
I'm late to that party, but fascinatingly: you didn't have to.
Yes, I figured that out too. For the later editions of the FLAC testbench I used sox dither -p 12 and then used a hex editor to set the number of bits-per-sample to 12, which is accepted by FLAC.
Music: sounds arranged such that they construct feelings.

Re: Use of non 8/16/24-bit audio, like 12-bit audio

Reply #29 –
Quote from: ktf on
Have you tried ffmpeg directly with the wavpack file as input?
Yes, but does not work. Well obviously ffmpeg needs -acodec pcm_s24be or -acodec pcm_s24le to get >16 bits, but no; whether before or after _bits_per_raw_sample, it outputs 24-bit-in-24-bit.

Also even for formats that should very well support it, ffmpeg outputs 24-bit-in-24-bit
ffmpeg -i "audition 20-bit.wv"  -bits_per_raw_sample 20 output.wv
ffmpeg -i "audition 20-bit.wv"  -bits_per_raw_sample 20 output.flac
Doesn't matter whether I input a .wv or an .aiff or a .flac.

Now here are a few interesting bitrates, kbit/s reported by foobar2000:
858 for flac.exe -0
838 for ffmpeg's wavpack. I had to use wavpack.exe -j0 -f to get anything like that. Does ffmpeg really turn off stereo decorrelation in its default WavPack handling?

Anyway, I could get both WavPack/TAK/FLAC down to the low 400s here (FLAC best, probably stereo decorrelation is significant). (OptimFROG hits the 200s ...)

Re: Use of non 8/16/24-bit audio, like 12-bit audio

Reply #30 –
Quote from: Porcus on
Is there any tool that converts between WAVE versions, preserving bit depth (that is not a multiple of eight) - and, between WAVE and AIFF?

Yes! Here:
http://www-mmsp.ece.mcgill.ca/Documents/Software/Packages/AFsp/AFsp/AFsp.html

With source and a permissive license.

Re: Use of non 8/16/24-bit audio, like 12-bit audio

Reply #31 –
Oh my, this is not behaving well.  Tried "b bits in C-bit container" in various WAVE formats, since I could now hack and convert.
With quite ... diverging results.  Probably I should share some files ...

I'm getting flac.exe and Monkey's to write "empty" files here.  Going from flac 1.3.1 to 1.3.3 accepts more files and "upgrades" more of them from 0 bytes to writing headers but drops all audio and writes silent 0 kbit/s stream ... some of which verify as valid and some don't. 

Worst about FLAC: It takes 8/16/24 bits in 32-bit WAVEFORMATEXTENSIBLE and happily writes 0 kbit/s stream of correct length.  Yes also with --verify.  Enabling other bit depths with --lax: same result!
flac.exe writes silent streams to other files too (that I have hacked by hand, but which other codecs accept), but then foo_verifier says it is 0 seconds.  But flac -t is happy.
And some of these b bits in C-bit container files it also gets wrong in other severe ways, like 8 bit in 24: interpreted as 8 in 8 and spreads 24 bits out over 3 samples.
Could very well be non-standard files (or ambiguous standard), I should add.


... and judging from a few codecs, there are at least three kinds of WAVE formats:
* (1) A format where TTA recognizes the b-bit flag and handles it as it should; (2) A format where TTA don't cannot read that it is b bits, so it just upconverts; (3) A format TTA doesn't recognize as WAVE.
* (1) A format where refalac recognizes the b-bit flag and handles as it should if b is in 16/20/24/32, otherwise reject as unsupported (that is probably also handles as should); (2) A format where refalac will ignore the b-bits flag and just upconvert - except that 25 to 31 in 32 are rejected (but 1 to 24 in 32 are converted to 32!); (3) a format where refalac will reject the file unless b=C.
* (1) A format where TAK behaves well up to 24 bits; (2) A format where TAK behaves well except rejects if b=C-7 to C-1.  That is, for b-in-24-bit, b=1 to 16 is OK, but 17 to 23 are rejected.  And similar for 16.  (3) as ALAC's #3, accepting 24-in-24 and ditching b<24.


Oh, and foo_verifier gives funny messages like "Audio data format mismatch: 8000Hz 2ch  vs 8000Hz 2ch" - is it Monkey's that puts a whitespace after "ch" that ...?

Re: Use of non 8/16/24-bit audio, like 12-bit audio

Reply #32 –
Quote from: Porcus on
Oh my, this is not behaving well.  Tried "b bits in C-bit container" in various WAVE formats, since I could now hack and convert.
With quite ... diverging results.  Probably I should share some files ...

I'm getting flac.exe and Monkey's to write "empty" files here.  Going from flac 1.3.1 to 1.3.3 accepts more files and "upgrades" more of them from 0 bytes to writing headers but drops all audio and writes silent 0 kbit/s stream ... some of which verify as valid and some don't. 

Worst about FLAC: It takes 8/16/24 bits in 32-bit WAVEFORMATEXTENSIBLE and happily writes 0 kbit/s stream of correct length.  Yes also with --verify.  Enabling other bit depths with --lax: same result!
flac.exe writes silent streams to other files too (that I have hacked by hand, but which other codecs accept), but then foo_verifier says it is 0 seconds.  But flac -t is happy.
And some of these b bits in C-bit container files it also gets wrong in other severe ways, like 8 bit in 24: interpreted as 8 in 8 and spreads 24 bits out over 3 samples.
Could very well be non-standard files (or ambiguous standard), I should add.

Provide the files and inform @ktf . No way to know if this is a case of "garbage in garbage out" unless you share the files.

Re: Use of non 8/16/24-bit audio, like 12-bit audio

Reply #33 –
Here is nearly a megabyte of .wav files. 274 of them ...


*** What I did:

From http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/Samples.html I grabbed the M1F1-int24-AFsp.wav and M1F1-int24WE-AFsp.wav files. The site reports that WMP rejects the former ...

** Hex editor up.  Two originals, plus further 2*23 files, changed bit depth to 1, 2, 3, ... , 23:
Byte 0x22 in M1F1-int24-AFsp.wav , and byte 0x26 in M1F1-int24WE-AFsp.wav - hope those are correct.  If not, the next bulk of files should still be valid.

** Took that AFsp CopyAudio tool and created "WAVE-NOEX" and "WAVE-EX" files with b bits in C-bit container, all b=1 to C, for C=16, 24, 32.   (It doesn't do C=8.)
192 files after deleting duplicates.  192 so near-equal files that they 7-zipped to the size of four.

Now, say a 12-bit .wav file shall have a nonzero bit >12 - but at least the hex-edited ones have not done that.
And if nonzero lower bits, FLAC will reject with an error.  (Not sure if "error" is consistent given what is to follow, it could very well be relegated to warning. Or implement a -F on encode too.)  But WavPack will zero out those bits that should be zero.  So I wavpacked/wvunpacked (it accepts all the files).
** Ran a file duplicate remover after deleting all tags with Mp3tag. (CopyAudio tags with date.)
Turns out the "original" 24-bit file is an upconverted 16 (well the webpage even says that!) where bits 17+ were already zero.
Also, turns out that CopyAudio zeroes out bits in WAVE-NOEX files if b < C-8 ... so if I try to put a 6-bit in 16-bit container, it deletes some (but not if I put a 12-bit in 16.)
274 .wav files then. Generated with hopefully nearly-self-explanatory filenames.


Phew. So much for .wav's.  Now put the encoders to work.


*** SOME results
There are several cases where FLAC outputs a 0 kbit/s stream of correct length. That is not good.
Now a particular set is ... particular:

** First hex-edited section: M1F1-int24-AFsp_hexeditedto<number b>.wav and .LowerBitsZeroed_Afterwards.wav:
These are from M1F1-int24-AFsp.wav , hex-edited byte 0x22.  Unique feature - or fault! - of this set:
* TTA: accepts the 17 to 24 and cites the encoded files as 17 to 24.  These are the only where TTA is enable to encode to non-multiples of 8 (otherwise it upconverts to say 24 - or rejects the WAVE format altogether.) So those files are special - but, TTA behaving well is certainly no proof these files conform to anything.
* Here are the only files that OptimFROG reject: up to & including b=16.  It insists that for this WAVE type, a 24 bit container shall contain 17 or more. 

- FLAC misbehaves: on both 8's. Apparently it thinks that they are 8-in-8, as the time is 3x too long.  (Monkey's does the same.)
Nothing strange in the log output, except FLAC puts backspace symbols in the log?!  ;) .  Verify as OK. 
- FLAC misbehaves?: it rejects 16 with "ERROR: got partial sample".  The original 24-bit has odd number of samples, so that indicates FLAC thinks it is 16-in-16.
- FLAC gives "legacy WAVE file has format type 1" which is WARNING for 24-in-24 and ERROR for the remaining 1-7, 9-15, 17-23.
Not sure if that is good handling either.


For the rest ... try, I guess.

Re: Use of non 8/16/24-bit audio, like 12-bit audio

Reply #34 –
Quote from: Porcus on
There are several cases where FLAC outputs a 0 kbit/s stream of correct length. That is not good.

I think I've traced the origin of this problem to this bit of code:
https://github.com/xiph/flac/blob/a2fe43f64e7ce8057fb274c64996568d69b301b8/src/flac/encode.c#L2443-L2445

In other words: the flac command line program (not something in libFLAC) isn't equipped to handle wave files with 32-bit samples. When there are actually 25- 32 bits in the file, there is code sending the error ERROR: unsupported bits-per-sample, but in this corner case where each sample of x bits is stored in 32 bits the FLAC code only sends out an error in a debug build (asserts are only included in debug builds)

This should be fairly easy to fix.
Music: sounds arranged such that they construct feelings.

Re: Use of non 8/16/24-bit audio, like 12-bit audio

Reply #35 –
b-bits-in-C seem to produce silent streams in cases where
1) any bit number > b is nonzero.
2) C=32 & b<25, no matter whether there are nonzero lower bits.

Better than a silent file is no file at all. Of course, 24-in-32 could be treated as 24 or as 32, that is a choice.
Also, with nonzero lower bits that should be zero, FLAC can either choose to reject or to handle as b (zeroing out) - or do what TAK does, keep the bits AND the flag. Again, that is a choice. 


But there is something wrong about ... I'll have to look a bit more into the non-Extensible. 

Re: Use of non 8/16/24-bit audio, like 12-bit audio

Reply #36 –
I made some misjudgement based on what I thought WavPack would do, without checking. In the above 7z archive, the strings, ".LowerBitsZeroed_byCopyAudio" and ".LowerBitsZeroed_byCopyAudio_when1to8in16" should be removed from the respective file names, then those wouldn't be as misleading.


@bryant, you there and can enlighten the commons about when the following four WAVE thingys are valid with what bits? 
(Or @Peter on what fb2k does?)

** "Easy:" the two sections of WAVEFORMATEXTENSIBLE files.
* FLAC writes silent streams when the lower bits are not zero (and that b-in-32)
* Foobar2000 plays all files
* Everyone agrees upon the number of bits except that for "the manually hex-edited section" M1F1-int24WE-AFsp_hexeditedto01.wav etc, AFsp's InfoAudio.exe says nothing about number of bits. So ... at least some differences there are.
(* ... well TTA upconverts to 24 or to 16/24. And Monkey's won't decode all to "Insane".)

Here come the difficulties, the two sections of "non-EXTENSIBLE" WAVE files. 

** First, the manually hex-edited M1F1-int24-AFsp_hexeditedto01.wav and up to M1F1-int24-AFsp_hexeditedto23.wav (the unaltered "24" bits in 24 is OK with all)
* AFsp's InfoAudio.exe says nothing about number of bits.
* WavPack think they are valid b-bits-in-C and treats them as such - and they play back jolly good.
Now for 1 to 16:
* OptimFROG thinks they are invalid.
* FLAC and foobar2000 think that they are invalid except 8 bits, which both take to be three times as long (i.e. as 8 in 8 I guess) - and 16.  foo_bitcompare reports slightly different length between the two, but identical after truncating.  I can only conjecture that FLAC and foobar2000 take them as 16-in-16 not 16-in-24.
Then 17-23:
* FLAC and foobar2000 reject them. FLAC also for 20-bit, yes.
* foobar2000 displays correct number of bit for WAVE and TTA, but fails to decode either - TTA.exe does decode to the right .wav, so this seems to be foo_input_tta (which I think uses the official library?)
Seems - for 1 to 24 - that Monkey's and VLC are in line with FLAC and foobar2000, except VLC plays noise rather than refusing - and VLC plays TTA right.
... TAK and refalac refuse all but 24-in-24.

** Then, where CopyAudio.exe has generated by "WAVE-NOEX":
Here is where I did something wrong with the naming, because I overlooked what WavPack did.
M1F1-int24-AFsp_hexeditedto24THENCopyAudio-F_WAVE-NOEX.16containing07.LowerBitsZeroed_byCopyAudio_when1to8in16.wav
I thought CopyAudio had zeroed it because "decimating those bits by WavPack" produced bit-identical files.  Stupid me should have checked whether it was WavPack NOT zeroing out.  And it doesn't, because it sees it as 16 in 16.
For 1 to 8 bits in 16:
* AFsp's InfoAudio.exe says e.g. 7/16, consistent with CopyAudio of course - but at least I got confirmed that I didn't botch up the command that created it.
* But, WavPack and FLAC (edit: and TAK and refalac and Monkey's) and foobar2000 agree the file is 16 in 16.
Is it then?!
For 9 to 15 in 16:
* WavPack and foobar2000 agree with InfoAudio that they are 9 to 15.  (foobar2000 refuses to play it though.)
* FLAC rejects them all - including 12 bits. TAK too. And refalac.
In 24 bits:
* Story repeats itself except now up to 16 are taken as 24-in-24, and it is 17 to 23 that are treated as 9-15-in-16 (and rejected by the same encoders - including, both FLAC and ALAC reject 20.)
In 32 bits:
* Story repeats itself except now up to 24 are taken as 32-in-32, etc.
(TTA only plays 16 in 16 and 24 in 24 here. Monkey's seems to have some strange issues I haven't scrutinized in detail.)

Re: Use of non 8/16/24-bit audio, like 12-bit audio

Reply #37 –
More weirdnesses:

1) If I used refalac to output b-bit WAVE files from a 24-bit original, then it generates a 16 bit that TTA reads and a 24-bit that TTA doesn't. Yet another "WAVE type", or ...?

2)
Quote from: Porcus on
AFsp's InfoAudio.exe says nothing about number of bits
Yes it does, if I give InfoAudio -i 5 <filename>
Some need the -i 5 flag, others don't.

3) or rather eight:
I thought CopyAudio wasn't doing 8-bits, but I have to use "unsigned" format rather than integer. Did that. Attached.
At least everything agrees on the actual number of bits.
* WavPack and OptimFROG are happy.
* FLAC misbehaves the same way. Outputs 0 bytes when it errs over missing --lax, outputs silent when bits are not zeroed out.
* FLAC, Monkey's and TAK reject completely NOEX up to 7 out of being type-1. foobar2000 agrees.
* TTA rejects all.

4) Yes Monkey's seems to do report something weird about audio formats. Attached a .wav and an .ape and a .wv generated from it. Run them in foo_bitcompare. (I kinda cannot imagine that foo_bitcompare does this for .ape only, it must have come from the Monkey file format or SDK?)

Re: Use of non 8/16/24-bit audio, like 12-bit audio

Reply #38 –
Quote from: Porcus on
Yet another "WAVE type", or ...?
https://docs.microsoft.com/en-us/windows/win32/multimedia/waveform-structures
I suspect I encountered WAVEFORMATEX in a version of Adobe Audition, couldn't remember which one but newer than version 1.5. MPC-HC can play and oldsCool can parse/convert all of your test files including the previously posted 274 files, but the outcome may not be what you desired, as some files may output horribly loud and distorted square waves.

Quote
I thought CopyAudio wasn't doing 8-bits, but I have to use "unsigned" format rather than integer. Did that. Attached.
"unsigned" is still integer. 8-bit integer wave files are often unsigned, 128 denotes silence, 0 and 255 denotes full scale. Wave files above 8-bit are often signed, for example 0 denotes silence, -32768 and +32767 denote full scale in 16-bit files.

Re: Use of non 8/16/24-bit audio, like 12-bit audio

Reply #39 –
Quote from: bennetng on
some files may output horribly loud and distorted square waves.
Is that restricted to 8 in 16/24(/32?) being interpreted as 8-in-8? (Possibly "etc" - 16 in 24/32, 24 in 32.) If so, you apparently agree with FLAC and Monkey's and foobar2000.

Quote from: bennetng on
Quote from: Porcus on
I thought CopyAudio wasn't doing 8-bits, but I have to use "unsigned" format rather than integer. Did that. Attached.
"unsigned" is still integer. 8-bit integer wave files are often unsigned, 128 denotes silence, 0 and 255 denotes full scale. Wave files above 8-bit are often signed, for example 0 denotes silence, -32768 and +32767 denote full scale in 16-bit files.
Sure. What I was referring to, was the name of CopyAudio's format switch. CopyAudio requires you to type "unsigned" for unsigned integer and "integer" for signed integer.

Re: Use of non 8/16/24-bit audio, like 12-bit audio

Reply #40 –
This is "fun". There are 8-/12-/16-/20-/24-/32-bit integer files in the WavPack test suite: http://www.rarewares.org/wavpack/test_suite.zip
Although WavPack outputs what it is fed (and thus can and sometimes will round-trip even defective .wav files) I take it that they have less chances to be defective, than what I have hex-edited.

The wvunpack'ed 12- and 20-bit .wav files are rejected by flac.exe, even with --lax
Code: [Select]
12bit.wav: ERROR: legacy WAVE file has format type 1 but bits-per-sample=12
16bit.wav: wrote 2927092 bytes, ratio=0,553
20bit.wav: ERROR: legacy WAVE file has format type 1 but bits-per-sample=20
24bit.wav: WARNING: legacy WAVE file has format type 1 but bits-per-sample=24
24bit.wav: wrote 5545954 bytes, ratio=0,699
32bit_int.wav: WARNING: legacy WAVE file has format type 1 but bits-per-sample=32
32bit_int.wav: ERROR: unsupported bits-per-sample 32
8bit.wav: wrote 986838 bytes, ratio=0,373
If instead I decode the .wv using refalac -D - which preserves the 12- and 20-bit flags, unlike what ffmpeg does - then flac accepts them. (Of course not the 32-bit.)
As expected, WavPack and OptimFrog are happy with both.

Monkey's Audio, Takc.exe and foobar2000 agree with flac.exe: they
reject the 12- and 20- bits "type 1" .wav files but
accept the refalac -D-generated files.
(Observation: Monkey's can encode 32-bit integer to every mode but "Insane", which consistently fails.)

tta.exe ... it has a habit of being picky on .wav files, and rejects the refalac -D 24-bit file but accepts all the 16-bits. Also it has no support for 8 bits. The format nominally only supports 8/16/24 bits, and rejects both 12-bit files, but for 20 bits ... :
* it rejects wvunpack's 20-bit "type 1" .wav file
* it accepts refalac -D's 20-bit .wav file
* ... but encodes it to something that foo_input_tta cannot read (it outputs zero and is decoded to wrong length)
* ... but the audio is intact and tta.exe -d will decode it to .wav
* ... but then to a type 1 .wav. I.e. encoding with tta.exe and decoding with tta.exe produces something that tta.exe cannot read.
(How do I know the audio is intact? Because WavPack handles it.)

Re: Use of non 8/16/24-bit audio, like 12-bit audio

Reply #41 –
Because in WAVEFORMAT, nBlockAlign and nAvgBytesPerSec alone are good enough to describe any 8-based bit depth up to 64, theoretically including 40, 48 and 56 for type 1 files. Nothing can be used to describe whether the bits should be padded to MSB or LSB or somewhere in-between, so everything must be padded to MSB unless some codes are specifically written to change this behavior.

Among the WavPack test files, apart from the multichannel one, don't use WAVEFORMATEXTENSIBLE. Basically software show no error or warning with those files fully respects WAVEFORMAT, which means the files are neither corrupted nor malformed.

As mentioned in another thread, even Microsoft themselves are distributing a 24/96 file without using WAVEFORMATEXTENSIBLE.

Re: Use of non 8/16/24-bit audio, like 12-bit audio

Reply #42 –
Microsoft officially begs to differ (trying to restrict non-extensible to 8-in-8, 16-in-16 and float-32), even though as you point out, Windows 10 ships with a 24-bit counterexample.
Anyway, I find it questionable especially for audio-only compressors to reject a signal just because of a container that the format has no ambition of preserving. FLAC decodes writes to WAVEFORMATEXTENSIBLE when it thinks it is appropriate, but that is hardly an excuse for rejecting input container it can very well read. Settling for a warning is kinda acceptable, but erring out?!
[edit: wrote originally "FLAC/ALAC/TTA", but refalac doesn't reject 20-bits, it repairs - and TTA claims no support for 20-bits]

IMHO it is more defensible that encoders like TAK/Monkey's - who have an ambition of full file recreation - reject files they don't want to output, than FLAC/ALAC/TTA doing so. (WavPack/OptimFROG have chosen to accept those files.)

... Monkey's and 32-bit is a different story. At http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/Samples.html, there is a "M1F1-float32WE-AFsp.wav" that Monkey's processes - wrongly, thinking it is integer, maybe because it is WAVEFORMATEXTENSIBLE? @bennetng , do you see anything wrong with that file that could justify it being taken as integer?

Re: Use of non 8/16/24-bit audio, like 12-bit audio

Reply #43 –
Quote from: Porcus on
Code: [Select]
12bit.wav: ERROR: legacy WAVE file has format type 1 but bits-per-sample=12
16bit.wav: wrote 2927092 bytes, ratio=0,553
20bit.wav: ERROR: legacy WAVE file has format type 1 but bits-per-sample=20
24bit.wav: WARNING: legacy WAVE file has format type 1 but bits-per-sample=24
24bit.wav: wrote 5545954 bytes, ratio=0,699

Quote from: Porcus on
Anyway, I find it questionable especially for audio-only compressors to reject a signal just because of a container that the format has no ambition of preserving. FLAC decodes writes to WAVEFORMATEXTENSIBLE when it thinks it is appropriate, but that is hardly an excuse for rejecting input container it can very well read. Settling for a warning is kinda acceptable, but erring out?!
24-bit in non-extensible WAV is non-standard but unambiguous, so FLAC reads them but throws a warning. However, 20 or 12 bit per sample WAV is non-standard and ambiguous, because there is no specification of the alignment anywhere. Are bits left-padded to byte alignment, right-padded to byte-alignment or not aligned at all?

Here's the FLAC code for handling this.
Code: [Select]
if(wFormatTag == 1) {
	if(bps != 8 && bps != 16) {
		if(bps == 24 || bps == 32) {
			/* let these slide with a warning since they're unambiguous */
			flac__utils_printf(stderr, 1, "%s: WARNING: legacy WAVE file has format type %u but bits-per-sample=%u\n", e->inbasefilename, (uint32_t)wFormatTag, bps);
			if(e->treat_warnings_as_errors)
				return false;
		}
		else {
			/* @@@ we could add an option to specify left- or right-justified blocks so we knew how to set 'shift' */
			flac__utils_printf(stderr, 1, "%s: ERROR: legacy WAVE file has format type %u but bits-per-sample=%u\n", e->inbasefilename, (uint32_t)wFormatTag, bps);
			return false;
		}
	}
Music: sounds arranged such that they construct feelings.

Re: Use of non 8/16/24-bit audio, like 12-bit audio

Reply #44 –
Quote from: Porcus on
... Monkey's and 32-bit is a different story. At http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/Samples.html, there is a "M1F1-float32WE-AFsp.wav" that Monkey's processes - wrongly, thinking it is integer, maybe because it is WAVEFORMATEXTENSIBLE? @bennetng , do you see anything wrong with that file that could justify it being taken as integer?
Looks like an APE specific issue.

As for the the legacy WAVEFORMAT related issues, I supposed both WavPack and OptimFROG are one-man projects, and both of them are Audition/Cool Edit users so they have to take care of these formats. For collaborative works different developers could have different opinions though.

Re: Use of non 8/16/24-bit audio, like 12-bit audio

Reply #45 –
Quote from: ktf on
20 or 12 bit per sample WAV is non-standard and ambiguous, because there is no specification of the alignment anywhere.
Is that actually true? Hard to find everything through all Microsoft.com redesigns, but according to https://docs.microsoft.com/en-us/previous-versions/windows/hardware/design/dn653308(v=vs.85)#ambiguity-within-wave_format_pcm-1 - and I see the same both in versions of 2001, 2007 and 2017 - the EXTENSIBLE specification has no purpose to "resolve the ambiguity of wBitsPerSample for WAVE_FORMAT_PCM", and that must be taken to mean they leave it open?
And even if they were not, you would have legacy files.

But seriously, is it so that for a 12-bit file it is not even clear whether
0000 1000 0001 0000
represents a positive or a negative? Is there any actual disagreement among known applications?


Quote from: bennetng on
one-man projects [...]For collaborative works different developers could have different opinions though.
Microsoft might fall in the latter category, but who the hell knows.

Re: Use of non 8/16/24-bit audio, like 12-bit audio

Reply #46 –
The need for WaveFormatExtensible was discovered relatively recently, and codecs started making such files. I'm annoyed that I can't load them into Sound Forge 7 without changing the codec id to 1 or 3. Programs of that vintage happily worked at higher bit depths. Luckily, it's an in place edit with a hex editor, and programs that parse the header fully can ignore the extensible stuff.

Re: Use of non 8/16/24-bit audio, like 12-bit audio

Reply #47 –
To be fair to flac, Audition 1.5 and Sound Forge 4.5 refuse to open the 12-bit file. Sound Forge 4.5 does not support anything higher than 16-bit, so can't check the 20-bit one. The 20-bit one is probably a historical issue as the Event Gina/Darla/Layla were very popular 20-bit interfaces in the late 90s.

Audacity 2.3.3 and MPC-HC on the other hand are fine with both the 12 and 20-bit files. Audition only opens files with wBitsPerSample above 16 in case of such discrepancies.

The most basic WAVEFORMAT (not WAVEFORMATEX) does not include wBitsPerSample.
https://docs.microsoft.com/en-us/windows/win32/api/mmreg/ns-mmreg-waveformat

Re: Use of non 8/16/24-bit audio, like 12-bit audio

Reply #48 –
Quote from: Porcus on
But seriously, is it so that for a 12-bit file it is not even clear whether
0000 1000 0001 0000
represents a positive or a negative?
Yes, it isn't clear whether that is a positive or a negative number.

Quote
Is there any actual disagreement among known applications?
I don't know, it has been like this in FLAC for a long time now, don't know about others. As you stated, Microsoft explicitly left this ambiguous.
Music: sounds arranged such that they construct feelings.
 

Re: Use of non 8/16/24-bit audio, like 12-bit audio

Reply #49 –
Sounds weird. The 1.0 WAVE specification explicitly mentions both 12 and 20 bit WAVE_FORMAT_PCM, that 12 bit files in 16 bits WAVE should have the least significant half of the least significant byte zeroed and that the sample amplitude should be in the most significant bits of the integer.
It does say "nBitsPerSample" which I would assume is a typo for "wBitsPerSample"?


Well at least the first sentence suggests that 8 bits in 16 is invalid. (Edit: for WAVE_FORMAT_PCM, at least.)
Entire document preserved at http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/Docs/riffmci.pdf