I've uploaded a patch for the aifc module (http://bugs.python.org/issue2847). I'm still working on the testsuite.
Comments are welcome!


On Thu, May 29, 2008 at 5:39 PM, Quentin Gallet-Gilles <qgallet@gmail.com> wrote:

On Thu, May 29, 2008 at 4:56 PM, Lars Immisch <lars@ibp.de> wrote:

       Issue 2847 - the aifc module still imports the cl module in 3.0.
       Problem is that the cl module is gone. =) So it seems silly to have
       the imports lying about. This can probably be changed to critical.

   It shouldn't be a problem to rip everything cl-related out of aifc.
   The question is how useful aifc will be after that ...

Has someone already used that module ? I took a look into it, but I'm a bit confused about the various compression types, case-sensitivity and compatibility issues [1]. Are Apple's "alaw" and SGI's "ALAW" really the same encoding ? Can we use the audioop module for ALAW, just like it's already done for ULAW ?

There is just one alaw I've ever come across (G.711), and the audioop implementation could be used (audioop's alaw support is younger than the aifc module, BTW)

The capitalisation is confusing, but your document [1] says: "Apple Computer's QuickTime player recognize only the Apple compression types. Although "ALAW" and "ULAW" contain identical sound samples to the "alaw" and "ulaw" formats and were in use long before Apple introduced the new codes,  QuickTime does not recognize them."

So this seems just a matter of naming in the AIFC, but not a matter of two different alaw implementations.

- Lars

Ok, I'll handle this issue. I'll be using the audioop implementation as a replacement of the SGI compression library. I'll also create a test suite, as Brett mentioned in the bug tracker the module was missing one.