I've found the cause of this problem- it is the iTUNSMPB atom.
For the afconvert-encoded 220500 frame pink noise file, the iTUNSMPB atom contains the following data:
type data (moov.udta.meta.ilst.----.data)
typeReserved = 0 (0x0000)
typeSetIdentifier = 0 (0x00)
typeCode = UTF-8 (0x01)
locale = 0 (0x00000000)
metadata = <116 bytes>
00000000 20 30 30 30 30 30 30 30 30 20 30 30 30 30 30 30 | 00000000 000000|
00000010 30 30 20 30 30 30 30 30 32 41 43 20 30 30 30 30 |00 000002AC 0000|
00000020 30 30 30 30 30 30 30 33 35 41 41 38 20 30 30 30 |000000035AA8 000|
00000030 30 30 30 30 30 20 30 30 30 30 30 30 30 30 20 30 |00000 00000000 0|
00000040 30 30 30 30 30 30 30 20 30 30 30 30 30 30 30 30 |0000000 00000000|
00000050 20 30 30 30 30 30 30 30 30 20 30 30 30 30 30 30 | 00000000 000000|
00000060 30 30 20 30 30 30 30 30 30 30 30 20 30 30 30 30 |00 00000000 0000|
00000070 30 30 30 30 |0000|
As far as I know, the second and third 8-character hex strings are the priming and remainder, and the fourth 16-character hex string is the total number of valid frames. So for this file
priming = 00000000 = 0
remainder = 000002AC = 0x2ac = 684
valid frames = 0000000000035AA8 = 0x35aa8 = 219,816
which jives with what afinfo says:
audio 219816 valid frames + 0 priming + 684 remainder = 220500
This is obviously incorrect- the valid frames should be 220500 (0x35d4).
I've done two things to test this:
1) Strip out the atom completely.
2) Manually change the iTUNSMPB total frames to 0x35d4.
In both of these cases, afconvert can recover the original wav.
Stephen