homepage

It appears that aifc, as well as wave, does not support audio files other 
than 44100 hz 16-bit format.
--
>>> f = aifc.open('Track 06')
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File 
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/aifc.py", 
line 928, in open
 return Aifc_read(f)
 File 
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/aifc.py", 
line 341, in __init__
 self.initfp(f)
 File 
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/aifc.py", 
line 321, in initfp
 chunk.skip()
 File 
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/chunk.py", 
line 158, in skip
 self.file.seek(n, 1)
 File 
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/chunk.py", 
line 111, in seek
 raise RuntimeError
RuntimeError
--
Could it be that the 'Chunk' class in chunk module may be returning improper 
values...? In any case, aifc refuses to open a 24bit 44100hz audio file. 
Does anyone have insights on this?

I looked into the problem, and found that current aifc impelementation 
assumes that SSND chunk is aligned (in Audio-IFF). But it is not always 
true. SSND chunk might not be aligned.
Here I'd like to submit a set of patches for this issue.
I'd like to donate these patches to python.

Patch for chunk.py that skip() method may get an optional arguments, 
that it will skip in aligned or not.

Patch for aifc.py that will use chunk.skip(True) in SSND chunk.

Can I ask someone to review the patch files, and to merge into the code 
base if those patches are ok?

Hello Kawai,
I see you are attemping to kill two bugs in one stone (or ... whack!) by eliminating the _skiplist ... Beautiful :-) As we discussed in the Mixi Python thread, I was going to give those patches a set of runs, but I'm completely swamped until Saturday morning, JST...
On 2008年3月12日 17:09:17 +0000, HiroakiKawai wrote:
> 
> HiroakiKawai <kawai@apache.org> added the comment:
> 
> Can I ask someone to review the patch files, and to merge into the code 
> base if those patches are ok?
> 
> __________________________________
> Tracker <report@bugs.python.org>
> <http://bugs.python.org/issue2259>
> __________________________________
> _______________________________________________
> Python-bugs-list mailing list 
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-bugs-list/moki%40u01.gate01.com
> 
>

Killing two birds with one stone is actually a bad idea when it comes to
patches. I would recommend breaking this patch into its two independent
pieces, the alignment fix and the skiplist fix, and attaching the
skiplist fix to issue 2245 as a proposed fix there.
Both issues need tests.

Killing one or two is not the point in this issue ticket. The ticket is 
opened per issue what one experienced. Thus there might be different 
tickets that needs the same patch.
For this issue, the problem is "Poor support other than 44.1khz, 16bit 
audio files?". I posted one patch for this issue. I think the patch 
could not be separated, and should not be. I could not see it resonable 
to separate the patch into two. :(
If you do really want to have separate patches, I can prepare. Or anyone 
can prepare.

The issue isn't whether the patch(es) are on one issue or not, if you
want to keep them here, that's fine. This patch is so small that
breaking it up isn't strictly necessary, either, though I still think it
would be cleaner and more likely to get applied if you did so. (My
thought after reading the developer documentation is that each patch
file should consist of the minimum amount of independently testable
changes, regardless of whether or not they unltimately fix a single
issue.) But I could be wrong, it's just my opinion :)
What we do for sure need in order to get this closer to having the devs
accept it is unit (or doctest) test cases that demonstrate the problem
and thereby demonstrate that the patch fixes the problem.
In case you didn't see it, it was also suggested, on the other ticket,
that the 'else: pass' could just be dropped.
(I'm one of the people doing ticket triage, by the way, in case you
wonder what my role is...my goal is to get tickets resolved, by getting
tickets up to a high enough quality that the devs can easily accept or
reject them.)

If you can provide a small audio file that demonstrates the problem that
might be enough to get both of these issues moving, since I could write
a test using that.

In r72100 I applied the skiplist part of this patch. In order to apply
the remainder I need a small auido test file that demonstrates the
current failure.

Hello,
My apology for failing to reply ... Here's a small AIFF file (24-bit, 
48000hz). Try this file to see if it can be opened using aifc. Thank you!

Hello,
My apology for failing to reply ... Here's a small AIFF file (24-bit, 
48000hz). Try this to see if it can be opened using aifc. Thank you!

Adding a test that opens the 24b48k.aif file, gets some information and does navigation on it. I'm aware that it doesn't triggers any extra failure against the actual tip (5a1bb8d4afd7) but it does if r72100 is undone (with some small rework :)). I'm not sure if that is the kind of test needed (if not just ignore it).

Well, if the test doesn't fail before applying the remainder of the patch, then it doesn't test the bits that haven't been applied yet.
I don't know enough about aifc to construct a test that fails or to understand the remainder of the fix well enough to feel comfortable committing it *without* a test that fails first. So I'm hoping someone else will be able to figure it out :) Thanks for trying.

From AIFF-C Draft '91, Section 5, Sound Data Chunk:
"If soundData[] contains an odd number of bytes, a pad byte with a value of zero is added at the end to preserve an even length for this
Chunk."
So I think aifc.patch is wrong.
However, Chunk.skip() is broken for non-seekable files, I added a trivial patch

Oops. Misread the code, that part of skip() is fine. Patch removed. Sorry about that.

I tested 2.6, 2.7, 3.2, 3.3, and 3.4. All of them read and write 24b48k.aif. Currently 2.7, 3.3, and 3.4 have tests for 24-bit aifc files. Seems this issue is not more actual.