AIFF files will not play on iPod, will on iTunes

[audio_pete]

Stupid question, but are there no firmware updates that could correct this behaviour on older iPods?
Interestingly that Aple products do not abide by their house-made specifications. I'd expected this rather from MS.

Not following you on this, what faux pas did apple commit?

[audio_pete]

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.

Not sure I follow this either.
I have a new iPod classic,
the last 3 characters do not match any of the old iPod values
as reported on Apple.com.

I am on Version 2.0.4
there is no newer version, I also checked

So I am puzzled why Koz's newer iPod will play files and mine won't

Just puzzled not really interested in pursuing too much.

[Gale Andrews]

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.

Not sure I follow this either.
I have a new iPod classic,
the last 3 characters do not match any of the old iPod values
as reported on Apple.com.

I am on Version 2.0.4
there is no newer version, I also checked

So I am puzzled why Koz's newer iPod will play files and mine won't

Each iPod series (Classic, Nano, Touch and the others) have their own operating system. At the moment we assume the operating systems and/or firmware for later series of iPods do not have the apparent bug that they cannot cope with a text chunk that has an odd number of characters. This bug manifests itself for example if you export multiple with a label that says "A" (an odd number of characters) instead of "AA" (an even number of characters).

The Audacity-written chunks themselves are proved correct to Apple's specification for AIFF. If there are an odd number of characters and so an odd number of bytes, we pad with one extra zero character in the chunk to make the bytes an even number.


Gale

[steve]

Not following you on this, what faux pas did apple commit?

The AIFF format specification was largely written by Apple, thus the irony that the iPod Classic is not fully compliant with that standard.

Not sure I follow this either.
I have a new iPod classic,

The 6th generation iPod Classic was released in September 2007 and the 2nd (final) revision was released September 9th 2009. Although it is still in production (a testament to the high quality design) 4 years is a long time in this high tech field (2007 was the year that Windows Vista was released and there was no such thing as an iPad until 2010. Technology has come a long way since then).

Stupid question, but are there no firmware updates that could correct this behaviour on older iPods?

Unfortunately it appears not. The last firmware update was 2.0.4 (6.5G) in 2009 which is the version that audio-pete has.

audio-pete, perhaps I missed this, but I was wondering why you don't use a high bit rate compressed format such as 320 kbps AAC.

[audio_pete]

The Audacity-written chunks themselves are proved correct to Apple's specification for AIFF. If there are an odd number of characters and so an odd number of bytes, we pad with one extra zero character in the chunk to make the bytes an even number).
Gale

http://home.roadrunner.com/~jgglatt/tech/aboutiff.htm

Steve's linked article is all over even numbers

So, all IFF files are made up of several chunks (ie, groups of data). Each group of data starts with a convenient ID (so that a program can ascertain what kind of data is in the chunk) and a ULONG size (so that a program can ascertain how many bytes of data are in the chunk). There are a few other details to note. A chunk cannot have an odd number of data bytes (such as 3). If necessary, an extra zero byte must be written to make an even number of data bytes. The chunk Size doesn't include this extra byte.

This is the underlying IFF spec.

On the AIFF page

The data field is the data specific to the application. The application determines how many bytes are stored here, and what their purpose are. A trailing pad byte must follow if that is needed in order to make the chunk an even size....
The text field contains the comment itself, followed by a pad byte if needed to make the text field an even number of bytes.

Even seems to be the correct format
back to IFF

The reason for this extra "pad byte" for odd-sized chunks has to do with Motorola's 68000 CPU requiring that LONGs be aligned to even memory addresses. IFF files were first used on 68000 based computers, and padding out odd-sized chunks made it easier to load and parse an IFF file on such a computer. (ie, If you load the entire file into a single block of RAM starting upon an even address, all of the chunk IDs and Sizes will conveniently fall upon even memory addresses).

allowing odd chunks seems to be an applications way of overlooking an uncouth IFF

[audio_pete]

Sorry Robert's links

[audio_pete]

audio-pete, perhaps I missed this, but I was wondering why you don't use a high bit rate compressed format such as 320 kbps AAC.

Do you think it is better?
After all not filling a huge auditorium
just the void between my ears ; )

[steve]

There are several advantages to using compressed format on iPods. The two main ones are that you can fit a lot more songs into the device (for 320 kbps files you can fit more than 4 times as many songs), and compressed files improve battery life (because disk reads are relatively heavy on battery power). What a lot of iPod users do is to export from Audacity in WAV format, then use iTunes to convert from WAV to AAC and add metadata (iTunes has a very good AAC encoder). It's a bit more long winded than just exporting from Audacity, but apparently (I don't have an iPod) it produces very good quality files with metadata that works in the iPod, improved battery life, better "anti-skip" performance and uses less disk space on the iPod. Optionally the WAV file can then be archived on an external hard drive as a back-up.

[audio_pete]

Oh.........


We are back to multi export files are practically perfect in every way.......


and let's tell the developer(s) of riff-pad
their product is broken too


basta

[Robert J. H.]

Oh.........


We are back to multi export files are practically perfect in every way.......


and let's tell the developer(s) of riff-pad
their product is broken too


basta

Let us be thankful that Riff-Pad shows the same buggy behaviour as the iPod.
I doubt that I would have noticed the relationship between odd text chunks and non-playback if this had not been the case.
The multiple export of Audacity is after al behaving correctly and compliant with the specifications.
However, I am not sure if those 3 extra text chunks are necessary - all information is in the ID3 tag too.
And the values are assigned haphazardly.
Why goes the artist name in the author chunk? It could as well be the composer or simply "Audacity" - the encoding program. I've not looked into this, but music players might indeed take those chunks to display title and artist if no ID3 tag has been created. But then, again, it won't make sense to assign the track number to the name chunk.
Furthermore, those text chunks do not seem to be respected by 3rd party programs. When converting, the ID3 tags are taken into account, but all other things thrown away.
In general, making use of those chunks seems not the "modern" way of doing this.
It would be interesting to see what other audio applications do in this regard.