Seemingly valid WAV file not being parsed for tags

[ffxsam]

Bug description
I've run across a WAV file that's completely valid (I can play it, edit it, etc), but its ID3 tags are not being read by music-metadata. I can even edit the tags in something like kid3 but music-metadata still won't see them.

The strange thing is, if I do this:

$ ffmpeg -y -i unreadable-tags.wav -c copy new.wav

Then I can edit the ID3 tags in kid3 and save it, and music-metadata will see those new tags.

Expected behavior
I would expect the ID3 tags to be read correctly.

Audio file demonstrating the problem
This is a customer's music track from an upcoming TV series so I can't share it here. Could you please provide me some secure way to send it to you?

[ffxsam]

BTW, we are now a sponsor. 🎉 music-metadata is a huge help to our service, so thank you!

[Borewit]

Thank you so much for your sponsorship @ffxsam! I hope you received my e-mail, otherwise let me know.

[Borewit]

Initial analysis

The corresponding WAV is not a regular WAV, but it is based the includes Broadcast Wave Format (BWF), which is an extension to the Microsoft WAF file.

In PR #618 I added some support for [includes Broadcast Wave Format (BWF)]. What is not mentioned in this PR is that reality the implementation is in-mature, yet I decided to merge it (after 2 years being an open PR) as caused no harm for other formats. I was also lacking good sample and context.

Following code snippet shows how to extract the EXIF metadata from the BWF:

  const filePath = path.join(wavSamples, 'unreadable-tags.wav');
  const metadata = await mm.parseFile(filePath);
  const exif = mm.orderTags(metadata.native.exif);
  assert.isObject(exif);

One fundamental thing which is messing from the decoding is format.coded, which should indicate the payload encoding (e.g. PCM).

What about the ID3 header?

ID3 header probably starts at offset at 28508986₁₀ (or 28509010₁₀, but probably an overwritten tag header), but it is not decoded.

It seems that the WAV decoder is loosing chunk sync after reading the RIFF/WAVE/bext chunk. This is because the assumption is made that the BFS tag header is the equal to the chunk payload.
However the chunk payload is larger.

[Borewit]

Solved in v7.12.4