--force-aiff-c-sowt-format results in non-interoperable files unless the original sample size is 16 bits

[jkcalhoun]

The 'sowt' data format was defined by the old Macintosh Sound Manager as follows:

k16BitLittleEndianFormat      = 'sowt',		/*16-bit little endian*/

and this is how it's interpreted when encountered in an AIFF-C by multiple parsers, including Apple's for macOS and iOS.

Via use of --force-aiff-c-sowt-format the flac tool can be used to write an AIFF-C file indicating the 'sowt' data format regardless of sample size, and this can result in in 24- or 32-bit LPCM being interpreted as 16-bit.

Interoperable carriage in AIFF-C of little-endian 24- and 32-bit LPCM has apparently never been well documented, but it's definitely not via use of 'sowt'. It's probably better for the flac tool to fail if directed via --force-aiff-c-sowt-format to write 24- or 32-bit LPCM.

(It's possible to gain interoperability with libsndfile by writing '42ni' instead of 'sowt' as the AIFF-C "compression type" for 24-bit little endian and '23ni' for 32-bit little-endian.)

[H2Swine]

Seems you got a point.

I don't have appleware, but I did some detective work (linked to at the issue at #767 (comment) ). It seems that

• The then-manager of the CoreAudio team says they wanted to obsolete sowt long ago ...
• ... even more so than they want to obsolete AIFF/AIFC altogether, Apple seems to have even removed any spec they once published.
• Closest (?) thing we get is the QuickTime type description which agrees that sowt is for 16-bit;
• That also introduces the raw type (8-bit unsigned like WAVE), that I have never seen in any (old) AIFF/AIFC specification, but afconvert seems to produce it. (ffmpeg can produce it. Now also WavPack supports it ...)
• That also says that NONE should not be used, and if it is found it is to be interpreted as raw for 8-bits and twos for 16-bits. I have no idea whether it makes sense to observe that for AIFC (after all, this document is for a different file format!).

[H2Swine]

Forgot: #850 . Wherein there is a comment that links to sox which now supports "42ni" ("in24" backwards, in24 being big-endian and 42ni being little endian) and "23ni", as those are apparently produced by afconvert. What is the fruit company doing?

[jkcalhoun]

What the fruit company did is just barely possible to piece together from archived documentation. At the time — prior to the introduction of CoreAudio — "decompression params" for configuring a decoder or transcoder were communicated via a list of QuickTime-style atoms, which are also known as "boxes" in MPEG-4 parlance. Decompression params could be serialized in this form either to a QuickTime movie file or to an AIFF-C file: in a QuickTime movie file they would be written as the contents of a 'wave' atom as a sound description extension, and in AIFF-C files they would be written as the contents of a 'wave' chunk that followed the 'COMM' chunk. For example, you can create an AIFF-C file with a 'wave' chunk by using afconvert on macOS to compress or to transfer audio in the QDesign Music 2 format ('QDM2').

For the uncompressed audio formats 'in24', 'in32', 'fl32', and 'fl64' as defined in the old Macintosh header file Sound.h, an atom list containing "decompression params" was optional but if provided comprised a format atom ('frma'), an endian atom ('enda') to indicate endianness, and a terminator atom (0), as shown by legacy documentation. When written to a file, along with the atom or chunk header the lot of it may well have earned the distinction of being the world's very first 38-byte flag.

With the introduction of CoreAudio and its adoption by QuickTime 7, all of that was deprecated for system frameworks and for QuickTime movie files, which have ever since carried LPCM audio using the unified coding name 'lpcm'. Further, a proposal for MPEG-4 to adopt the old hodgepodge of Sound Manager data formats for LPCM from the 1990's, including the above as well as 'raw ', 'twos', and 'sowt', was superseded by a streamlined proposal that was adopted and published as ISO/IEC 23003-5. That specification defines only 'ipcm' and 'fpcm' for the ISO coding name namespace, along with the easily-smaller-than-38-byte 'pcmC' box for indicating sample size and endianness.

However, the fruit company never upgraded its older file format AIFF-C in the same way. To the best of my knowledge, while current macOS will still read big- or little-endian LPCM audio from AIFF-C files that employ the conventions described above it will write only big-endian LPCM to AIFF-C, still using the data formats from Sound.h.

Rather than adopting bloated and never explicitly documented decompression params for selected LPCM "compression types" in AIFF-C, I think it would be fair for the flac tool to choose interoperability with sox or libsndfile over interoperability with the above. (Those fruit company guys are still in business, as far as I know, so maybe it's still possible for them to follow suit.) That said, neither sox nor libsndfile expects 'sowt' for 24- or 32-bit LPCM, so 'sowt' should properly be right out.