Just a quick update on what we know so far. I think that Koz and Gale are still looking at some other details, but here's what we have established from the most recent tests.
From the AIFF specification (
AIFF-1.3.pdf):
An AIFF file is composed of "Chunks".
Some Chunks (such as the one that holds the audio data) are compulsory.
Some Chunks (such as those that contain metadata) are optional.
Each Chunk
must start on a 2 byte boundary.
Chunks are in the following form:
4 bytes that hold the Chunk ID (ckID)
4 bytes that say how many data bytes are in the Chunk (ckSize)
The Chunk data (ckData)
If the data has an odd number of bytes, an extra "zero" byte must be added as padding to the end of ckData so that the next chunk begins on a 2 byte boundary.
ckSize is the number of data bytes - it does not include the 8 bytes used by ckID and ckSize or the pad byte (if present).
Both your iPod and Riff-Pad have problem when "Text Chunks" have an odd number of bytes.
In the case of Riff-Pad we can see exactly what is going on, and that is what provided the clue for why your iPod (and Koz's older iPod) failed with some AIFF files but not others. Riff-Pad was failing on the same files as the iPods.
In the case of Riff-Pad, if there is an odd number of bytes in a Text Chunk, Riff-Pad tries to start reading ckData from the next byte after the end of ckSize, which fails because the data is offset by 1 byte (the "padding" byte). It gets worse - because the byte count is now offset by one byte, the next chunk cannot be read at all because the last byte of ckData is being misread as the first byte of the ckID of the next chunk.
Riff-Pad and the iPods read AIFF files correctly
provided that there is an even number of bytes in each chunk.
For the COMM chunk this is not a problem because this chunk always has 18 bytes.
For the SSND chunk this will usually not be a problem because for 16 bit, 32 bit and stereo audio there will always be an even number of bytes (it might be interesting to test a mono 24 bit file that has an odd number of samples as this would have an odd number of bytes in the SSND chunk).
For Text chunks there may be an odd or even number of bytes, depending on the number of text character. This is where we see a repeatable problem for your iPod, Koz's older iPod and Riff-Pad. It appears that Apple have fixed the problem on newer iPod models as Koz's newer iPod will play these files.
iTunes avoids the potential problem of Text chunks by deleting the entire chunk. This is allowed under the AIFF specification for applications that
process the audio, but is prohibited by the specification if the file is simply
copied. This probably accounts for why transferring files one way via iTunes works but transferring another way does not work, though to be honest I could not follow your description of what you were doing (not helped by the fact that I don't have iTunes or an iPod). iTunes also uses non-standard chunks that appear to always have an even number of bytes (though I've not tested this thoroughly).
Having identified this issue, we now need to work out the best way to deal with it. There are several options that are currently being considered. I'll keep you informed.
This forum is for Audacity on macOS 10.4 and later.