| From Joel Bouchat <email@example.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: firstname.lastname@example.org
> > To: email@example.com
> > 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.
> > SteveThat extra space does allow the file to play on the problem iPod
> 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 ?
concerned, and is allowable in the AIFF specification.
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.
iTunes deletes the optional chunks if you create
an AIFF version of the file, so that is the apparent workaround for
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).
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.