Handle "twos" in addition to "sowt" encoding

[voxsystems]

"twos" has been showing up in encoded files coming from various Apple products.

[ktmf01]

Has this been documented (by Apple) anywhere yet?

[voxsystems]

Has this been documented (by Apple) anywhere yet?

I couldn't find anything. The report is actually anecdotal; we received information from a customer that the files were encoded "by Apple", but couldn't verify which product.

[H2Swine]

Half a year ago I went searching for the most current AIFF spec from Apple (at least one new enough to permit 4 GiB files), and apparently they have removed everything to try to enforce CAF. But I found data types for the QuickTime format, and who knows whether something has done a "codec copy" to it.

According to https://developer.apple.com/documentation/quicktime-file-format/sound_sample_descriptions , QuickTime permits

• NONE or unspecified. Unwanted, use "raw" or "twos" instead.
• raw. Do ffmpeg -i Unsigned8bit.wav -codec copy outfile.aiff and you will get an AIFF of type 'raw', but nothing else says it should be a thing.
• twos. For 8-bit signed or 16-bit.
• sowt. For 16 bit only.
• in24. Without saying anything about endianness.
• in32. Ditto.

[H2Swine]

FFmpeg seems to produce "twos" AIFFs by codec copy big-endian 16-bit from .mov . As reported by MediaInfo, but just in case I attach:

• 4 PCM files - the ones with no ".mov." in the filename - were created by flac -d using -o testshort.aiff, --force-aiff-c-sowt-format or --force-aiff-c-none-format
• Then four .mov files were created by looping through ffmpeg -i filename -acodec copy -vn -sn filename.mov. But two were removed after a duplicate check that reported testshort.aiff.mov=testshort.aifc-none.aifc.mov and testshort.wav.mov=testshort.aifc-sowt.aifc.mov .
• Check MediaInfo: ffmpeg writes "twos" or "sowt" codec types to .mov.
• The two remaining .mov files were converted to .mov.aif by ffmpeg -i filename.mov -acodec copy -vn -sn filename.mov.aif
• Check MediaInfo: Those have "twos" and "sowt" codec IDs.

Not that FFmpeg is the authority on compliance, but if FFmpeg produces these files, it explains why they exist. For what it is worth, I don't get "twos" out when doing the same with CAF as intermediate. (Not attached.)

testshort.zip

[voxsystems]

FFmpeg seems to produce "twos" AIFFs by codec copy big-endian 16-bit from .mov . As reported by MediaInfo, but just in case I attach:

Wow, thanks for that great summary of where it seems to have come from!

[H2Swine]

Question is then of course, what to do about it. (Can I suggest in any case that you amend the title into "sowt" for "swot"? Makes it potentially easier to search up later.)

I would guess that "raw" and ~~sowt~~ edit: "twos", of course! should be treated the same way. And likely they aren't supposed to be a thing. So flac can either

• Ignore and reject. It's not flac's job to facilitate this - if people use FFmpeg, then tell them that they can fix misbehaFFiour by going ->caf->aiff and problem solved.
• Take it on board with --keep-foreign-metadata support and everything. Objection to this: then not only will flac facilitate things that should not be, but flac -d --keep-foreign-metadata should get you the original file back. Should flac produce wrong files even if it was fed wrong files?
• Encode (maybe with a warning) if user does not want foreign metadata to be stored. Object if user wants to do --keep-foreign-metadata (-if-present).

Up to developer's discretion I think, but again: natural to give "raw" and ~~sowt~~ "twos" the same treatment.

[voxsystems]

(Can I suggest in any case that you amend the title into "sowt" for "swot"? Makes it potentially easier to search up later.)

I'm happy to do that, but it's in the commit comment, so I'll have to re-fork and submit another PR. Which I'm happy to do if there's a chance of it being merged.

* Ignore and reject. It's not flac's job to facilitate this - if people use FFmpeg, then tell them that they can fix misbehaFFiour by going ->caf->aiff and problem solved.

But I'm confused by this -- what is the difference between "sowt" and "twos" that makes it not flac's job? Isn't this a "standard" from Apple, like "sowt" itself? Or are they just recognizing the "standard" that FFmpeg is (uniquely?) writing?

[rillian]

I'm happy to do that, but it's in the commit comment, so I'll have to re-fork and submit another PR. Which I'm happy to do if there's a chance of it being merged.

If you're able to use command-line git, you can git commit --amend to edit the commit message, and then git push --force to update the PR.

[voxsystems]

If you're able to use command-line git, you can git commit --amend to edit the commit message, and then git push --force to update the PR.

I did this, but it required a new PR; I don't know if that improves search.

[c72578]

If you're able to use command-line git, you can git commit --amend to edit the commit message, and then git push --force to update the PR.

I did this, but it required a new PR; I don't know if that improves search.

Please, no new PR. This leads to unnecessary duplication.

The last commit in the branch twos-aiff-c of your fork is still the same as here in the PR: a1daf0f Branch: https://github.com/voxsystems/flac/commits/twos-aiff-c/ Fork: https://github.com/voxsystems/flac/commit/a1daf0ffe3d62563304045411176a868c21c861f Here: https://github.com/xiph/flac/pull/850/commits/a1daf0ffe3d62563304045411176a868c21c861f

So, there has been no force-push to the branch twos-aiff-c so far. Could you please try again in your flac fork?

git checkout twos-aiff-c
git commit --amend
git push --force

[H2Swine]

Apologize that I might have caused another PR ...

But I'm confused by this -- what is the difference between "sowt" and "twos" that makes it not flac's job? Isn't this a "standard" from Apple, like "sowt" itself? Or are they just recognizing the "standard" that FFmpeg is (uniquely?) writing?

No ... or "maybe". Here is what I found and not (edited to be cleared about where and how). First about AIFF/AIFF-C:

• Old AIFF and still-old-but-with-AIFF-C specs: nothing about "twos". "sowt" is "twos" spelled backwards, but the AIFF-C ID for big-endian, was "NONE".
• Try to find current AIFF spec at Apple's website. I found nothing! I also tried - around the entire webz - to find a newer spec that would allow for 4 GiB files and not just 2 GiB. (Essentially use unsigned for the chunk size.) Found no AIFF spec that allowed it, but IIRC a CAF document said use CAF because AIFF is limited at 4 GiB.
• I see that Apple is even trying to kill off sowt: https://lists.apple.com/archives/coreaudio-api/2009/Mar/msg00358.html , from the dev team manager ... and they have tried to push users over at CAF.

But what I listed in comment https://github.com/xiph/flac/pull/850#issuecomment-3274051023 is not for AIFF, it is for the QuickTime format.

• NONE: deprecated, don't use.
• twos: use that for big-endian! And for signed 8-bit. But there are other types for 24 and 32.
• sowt: use that for little-endian 16-bit (only!)
• raw: use that for unsigned 8-bit.

I have found no source that "twos" AIFF should even exist - now or ever; it seems it should be "NONE". But FFmpeg does create them when doing codec copy from .mov. On the other hand, I do have a source indicating that the "raw" might be a thing: https://ss64.com/mac/afconvert.html says that AIFF-C can carry unsigned-integer 8-bit, and then there must be a way they are indicated. However, that is apparently not supported by Apple (anymore) according to https://developer.apple.com/library/archive/documentation/MusicAudio/Conceptual/CoreAudioOverview/SupportedAudioFormatsMacOSX/SupportedAudioFormatsMacOSX.html .

[H2Swine]

( ... can someone with Appleware run afconvert on the .mov files? )

[H2Swine]

A turn of events, with help from hydrogenaudio:

Apple's "afconvert" CLI does indeed convert these .mov files to "twos" and "raw" AIFF-C.

[voxsystems]

Please, no new PR. This leads to unnecessary duplication.

PR closed, apparently no way to delete.

The last commit in the branch twos-aiff-c of your fork is still the same as here in the PR: a1daf0f Branch: https://github.com/

Apologies, pushed to wrong branch. Fixed now.