This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Support Apple AIFF-C pseudo compression in aifc.py
Type: enhancement Stage: resolved
Components: Library (Lib), macOS Versions: Python 3.11
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: serhiy.storchaka Nosy List: lukasz.langa, ned.deily, ronaldoussoren, serhiy.storchaka, thruston, xiang.zhang, yussuf.ozkan
Priority: normal Keywords: patch

Created on 2017-04-15 18:44 by thruston, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 1156 closed thruston, 2017-04-15 18:46
PR 24449 merged yussuf.ozkan, 2021-02-04 21:57
Messages (8)
msg291727 - (view) Author: Toby Thurston (thruston) * Date: 2017-04-15 18:44
aifc.py fails to open AIFF files containing the compression type "sowt" in the COMM chunk with an "unsupported compression type" error.

This compression type is an Apple specific extension that signals that the data is not actually compressed but is stored uncompressed in little Endian order.  

Supporting it would require a trivial change to allow the compression type as a byte-string and to add a do-nothing _convert routine. 

This would allow aifc.py to be used with AIFF files on Apple macOS.
msg291761 - (view) Author: Xiang Zhang (xiang.zhang) * (Python committer) Date: 2017-04-16 17:26
Anyway, such a function addition could only get into 3.7.
msg291762 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-04-16 17:29
Seems the "sowt" compression is not just a no-op operation. Perhaps it should change a byte order.

Needed tests and test files for the new compression.
msg291766 - (view) Author: Toby Thurston (thruston) * Date: 2017-04-16 21:50
I think it's probably better as a no-op.  Currently in my patch I just put 

    return data

You could do

    return data[::-1]

to reverse the sample, so that it came out as big endian, but if you leave it as a no-op then the data is returned in the native format for Intel Mac OS, which is the whole point of the "sowt" encoding.  Either way, the user can easily reverse the data in a `unpack` format if they want to, but in my own testing it seemed easier and simpler just to leave it in the native format. Then basically "it just works".

The patch as I've proposed it works fine on my MacOS boxes, but I have only tested it with AIFF-C files from one source.
msg386497 - (view) Author: Yussuf Özkan (yussuf.ozkan) * Date: 2021-02-04 21:57
If you read a normal uncompressed AIFF with aifc, the samples are in big-endian order and need to be converted before they can be played on little-endian systems.

As all other compression schemes produce big-endian data, so should 'SOWT' encoded AIFF. Therefore, the bytes of each sample should be swapped on read and write.

See also: https://en.wikipedia.org/wiki/Audio_Interchange_File_Format#AIFF_on_Mac_OS_X
msg399529 - (view) Author: Łukasz Langa (lukasz.langa) * (Python committer) Date: 2021-08-13 11:31
New changeset e4ed9d21534c2ed4397fdee0bb530a6e6a2c5af8 by dnknth in branch 'main':
bpo-30077: Add support for Apple aifc/sowt pseudo-compression (GH-24449)
https://github.com/python/cpython/commit/e4ed9d21534c2ed4397fdee0bb530a6e6a2c5af8
msg399530 - (view) Author: Łukasz Langa (lukasz.langa) * (Python committer) Date: 2021-08-13 11:33
Thanks for reporting and the initial patch, Toby. And thanks for pushing this across the finish line, Yussuf! ✨ 🍰 ✨
msg399558 - (view) Author: Toby Thurston (thruston) * Date: 2021-08-13 20:44
Hey!  thanks for letting me know, glad it got there in the end.  T.

On Fri, 13 Aug 2021, at 12:33, Łukasz Langa wrote:
> 
> Łukasz Langa <lukasz@langa.pl> added the comment:
> 
> Thanks for reporting and the initial patch, Toby. And thanks for 
> pushing this across the finish line, Yussuf! ✨ 🍰 ✨
> 
> ----------
> resolution:  -> fixed
> stage: patch review -> resolved
> status: open -> closed
> versions: +Python 3.11 -Python 3.8
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue30077>
> _______________________________________
>
History
Date User Action Args
2022-04-11 14:58:45adminsetgithub: 74263
2021-08-13 20:44:39thrustonsetmessages: + msg399558
2021-08-13 11:33:51lukasz.langasetstatus: open -> closed
versions: + Python 3.11, - Python 3.8
messages: + msg399530

resolution: fixed
stage: patch review -> resolved
2021-08-13 11:31:28lukasz.langasetnosy: + lukasz.langa
messages: + msg399529
2021-02-04 21:57:31yussuf.ozkansetnosy: + ned.deily, yussuf.ozkan, ronaldoussoren
messages: + msg386497
pull_requests: + pull_request23249

components: + macOS
keywords: + patch
2018-03-09 20:13:26ned.deilysetversions: + Python 3.8, - Python 3.7
2017-04-16 21:50:03thrustonsetmessages: + msg291766
2017-04-16 17:29:15serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg291762

assignee: serhiy.storchaka
stage: patch review
2017-04-16 17:27:10xiang.zhangsetcomponents: + Library (Lib), - Extension Modules
versions: + Python 3.7, - Python 3.6
2017-04-16 17:26:51xiang.zhangsetnosy: + xiang.zhang
messages: + msg291761
2017-04-15 18:46:28thrustonsetpull_requests: + pull_request1287
2017-04-15 18:44:39thrustoncreate