according to the spec at http://www.cnpbagwell.com/aiff-c.txt [1]:

"Dealing with Unrecognized Local Chunks

When reading an IFF file, your program may encounter local chunk types
that it doesn't recognize, perhaps extensions defined after your
program was written. [...]  Clearly your
program cannot process the contents of unrecognized chunks.  So what
should your program do when it encounters unrecognized chunks in an
IFF FORM?  The safest thing is to simply discard them while reading
the FORM.  If your program copies the FORM without edits, then it 's
nicer [but not necessary] to copy unrecognized chunks, too.  But if
your program modifies the data in any way, then it must discard all
unrecognized chunks.  That's because it can't possibly update the
unrecognized data to be consistent with the modifications."

ie: unrecognized chunks should be just skipped when reading, and not
copied if the file is modified, so both deleting the _skiplist or
applying the patch posted in issue 2259 would fix this bug according to
spec.

a limited workaround for known format files is to append the offending
chunk IDs to the _skiplist before reading, ie:

>>> import aifc
>>> f = aifc.open('test.aiff')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/sw/lib/python2.6/aifc.py", line 929, in open
    return Aifc_read(f)
  File "/sw/lib/python2.6/aifc.py", line 341, in __init__
    self.initfp(f)
  File "/sw/lib/python2.6/aifc.py", line 320, in initfp
    raise Error, 'unrecognized chunk type '+chunk.chunkname
aifc.Error: unrecognized chunk type FLLR
>>> aifc._skiplist += ('FLLR',)
>>> f = aifc.open('test.aiff')
>>> f
<aifc.Aifc_read instance at 0x76f80>

(Apple's Sountrack Pro adds an 'FLLR' padding chunk to AIFF files, so
_every_ file created by it will fail in the same way).