On 13 August 2013 22:05, Gale Andrews <gale@audacityteam.org> wrote:

| From Joel Bouchat <bouchat@hotmail.com>
| Tue, 13 Aug 2013 22:05:50 +0200
| Subject: [Audacity-devel] Metadata in RIFF files (was: Back to ID3v2 metadata in WAV files)
> Steve wrote:
> ----------------------------------------
> > Date: Tue, 13 Aug 2013 16:31:52 +0100
> > From: stevethefiddle@gmail.com
> > To: audacity-devel@lists.sourceforge.net
> > Subject: [Audacity-devel] Metadata in RIFF files (was: Back to ID3v2 metadata in WAV files)
> >
> > I've not been following this (Back to ID3v2 metadata in WAV files)
> > thread closely as I don't generally use metadata, but as the topic is
> > about changing the metadata in RIFF files I think it is relevant to
> > mention an issue that has recently been identified on the Audacity
> > forum concerning metadata in AIFF files.
> >
> > Currently Audacity includes "NAME", "AUTH", "ANNO" and "ID3 " chunks.
> > "NAME" contains Audacity "Track Title"
> > "AUTH" contains Audacity "Artist Name"
> > "ANNO" contains Audacity "Comments"
> > "ID3 " contains Audacity "Album Title, Track Title, Track Number,
> > Comment, Artist Name, Year, Genre"
> >
> > Unfortunately, if NAME, AUTH or ANNO contain an odd number of bytes,
> > then the file will fail completely in iPod Classics and show errors in
> > several applications, including> (Mac OS X) iTunes, Amadeus, Peak LE
> > and (Windows) Riff-Pad.
> >
> > The problem is that Audacity is correctly adding a padding byte when
> > necessary to make the number of bytes even, and correctly *not
> > including* that pad byte in ckSize, but iPod Classics and these
> > applications are incorrectly forgetting about the padding and looking
> > for the next chunk after ckSize bytes (thus the next chunk is offset
> > by one byte).
> >
> > Probably the easiest solution would be to not write the (optional)
> > Text chunks, but we would not want to do that if there are
> > applications that use those chunks.
> >
> > Steve
> >
> Hello Steve,
> i do not know the problem and i have no way for testing this but
> maybe that a simple solution would be to add a space character at the
> end of every even string rather than adding padding ?

That extra space does allow the file to play on the problem iPod
concerned, and is allowable in the AIFF specification.

Yes, I manually repaired a file that previously showed the problem by replacing the padding and incrementing ckSize and that solved the problem

Given the bugs in old Mac apps, I don't know if adding a trailing space
could itself cause a problem. It's possible we could test that, given

iTunes itself has no problem in playing AIFF files where the optional
chunks have an odd number of bytes, and does not show any error
messages for them.
Thanks for the clarification Gale, I was confused about that (you'll understand why ;-)

iTunes deletes the optional chunks if you create
an AIFF version of the file, so that is the apparent workaround for
the problem.

My guess is it would be too complicated to offer users a choice
of not exporting certain chunks (where the format exports more
than one chunk for a piece of metadata).

An option to disable all metadata need not be confusing, and would solve the problem of tracks not playing on the iPod Classic. All that would be required in the interface is a checkbox in the metadata editor. If it also greyed out the text fields in the editor then it would be blindingly obvious. This would also be useful in other cases where metadata is not wanted (it is all too easy for unwanted metadata to slip into multi-track projects if audio is imported).


Yes I guess to limit a regression risk we could kill the optional chunks
only when encoding on Mac OS X.

I noticed in Joel's patch that moves the LIST chunk to the end
and adds "PAD ", the optional chunks now appear at the bottom
of the file as well as at the top.

Also that patch writes two SSND chunks if there is a LIST chunk.
I think that might be a problem, so I'll retest with the patch version
that does not duplicate the LIST chunk.