#169 faac fails to handle AdobeXMP chunks, result in audio glitch

[Arthur Yarwood]

Its seems faac doesn't handle Adobe XMP chunks in wav files. I don't know much about these, but it appears to be a fairly common chunk of metadata that can appear in all sorts of files. Its tends to manifest itself as a block of XML data near the end of the wav file, preceded by a "_PMT" chunk header. faac mistakenly reads it as part of the waveform, thus given an audible chunk of static in the resultant aac file - usually a fraction of second, followed by some silence - but enough to be audible and annoying.
Interestingly, not all players play this audio glitch, VLC cuts the file too soon. But Quicktime does play it.
I'm looking into a quick fix in code myself, but if you can sort anything, that would be great too. I'll try and add an example file asap.

[Arthur Yarwood]

Managed to sort out a quick fix, by tweaking your 'encoding loop' in main.c, line 1019:-

/* encoding loop */
#ifdef _WIN32
for (;;)
#else
while (running)
#endif
{
int bytesWritten;

if ( total_samples < infile->samples )
samplesRead = wav_read_float32(infile, pcmbuf, samplesInput, chanmap);
else
samplesRead = 0;

#ifdef HAVE_LIBMP4V2
if ( total_samples + (samplesRead / infile->channels) > infile->samples )
samplesRead = (infile->samples - total_samples) * infile->channels;

total_samples += samplesRead / infile->channels;
#endif

/* call the actual encoding routine */
bytesWritten = faacEncEncode(hEncoder,
(int32_t *)pcmbuf,
samplesRead,
bitbuf,
maxBytesOutput);

if (bytesWritten)
{
currentFrame++;
showcnt--;
totalBytesWritten += bytesWritten;
}

Basically, if I understand your code correctly, wav_read_float32() will just keep reading data until it runs out of file, which is bad as there could be data beyond the end of the 'data' riffsub chunk, like Protool 'bext' and 'regn' chunks or Adobe XMP '_PMX' chunks. This extra metadata chunk are being sent into faacEncEncode() and produce audible glitches at the end of the file.
I've fixed this, by truncating the 'samplesRead' variable, if it goes beyond the number of samples as given in the infile pcmfile_t structure.
Seems to do the job, but you'll probably want to tidy it up a bit before merging it in. ;-)

[Arthur Yarwood]

Not having much luck sort out an example file for you, all our wavs are huge and contain copyright material. Whenever I try to trim them down, many tools like ProTools and Soundforge ditch this Adobe XMP chunk! Wish I knew what app inserted it in the first place...
Anyway, I'm going to attach a wav file which I've cut loads out of using a binary editor. Take a gander in your hex editor to see the sort of metadata, I'm on about. Obviously not a good example to listen to or encode.
It has the JUNK chunk at the top, from my previous bug. After my comment (in hex), you'll see a regn chunk from Pro Tools, followed by the _PMX chunk with loads of XML in it.

[Arthur Yarwood]

Wav file containing JUNK, Pro Tools and Adobe XMP metadata chunks. Manually hacked out copyright material with bin editor, don't try playing or encoding!

[Krzysztof Nikiel]

I just commited your patch. It seems to work well.