parseFile error: Buffer length must be even

[JL102]

Bug description
This was originally discovered by a user of MediaMonkeyServer (https://github.com/mediamonkeyserver/mms/): https://www.mediamonkey.com/forum/viewtopic.php?t=101151
Upon calling mm.parseFile for certain music files, the promise is rejected with the following error message: Uncaught Error: Buffer length must be even

Expected behavior
N/A (The promise is rejected, so we don't get the metadata)

Reproduction example & stack trace

> mm.parseFile('./Alexander Hacke (Sanctuary) - 01 Minnie & Me.mp3')
Promise {
  <pending>,
  [Symbol(async_id_symbol)]: 246,
  [Symbol(trigger_async_id_symbol)]: 5,
  [Symbol(destroyed)]: { destroyed: false }
}
> Uncaught Error: Buffer length must be even
    at swapBytes (C:\Users\draki\Downloads\Sanctuary\node_modules\music-metadata\lib\common\Util.js:44:15)
    at Object.decodeString (C:\Users\draki\Downloads\Sanctuary\node_modules\music-metadata\lib\common\Util.js:72:29)
    at FrameParser.readData (C:\Users\draki\Downloads\Sanctuary\node_modules\music-metadata\lib\id3v2\FrameParser.js:91:35)
    at Function.readFrameData (C:\Users\draki\Downloads\Sanctuary\node_modules\music-metadata\lib\id3v2\ID3v2Parser.js:64:36)
    at ID3v2Parser.parseMetadata (C:\Users\draki\Downloads\Sanctuary\node_modules\music-metadata\lib\id3v2\ID3v2Parser.js:158:40)
    at ID3v2Parser.parseId3Data (C:\Users\draki\Downloads\Sanctuary\node_modules\music-metadata\lib\id3v2\ID3v2Parser.js:113:32)
    at async MpegParser.tryReadId3v2Headers (C:\Users\draki\Downloads\Sanctuary\node_modules\music-metadata\lib\id3v2\AbstractID3Parser.js:55:13)
    at async MpegParser.parseID3v2 (C:\Users\draki\Downloads\Sanctuary\node_modules\music-metadata\lib\id3v2\AbstractID3Parser.js:39:9)
    at async MpegParser.parse (C:\Users\draki\Downloads\Sanctuary\node_modules\music-metadata\lib\id3v2\AbstractID3Parser.js:24:13)
    at async Function._parse (C:\Users\draki\Downloads\Sanctuary\node_modules\music-metadata\lib\ParserFactory.js:160:9)> mm.parseFile('./Alexander Hacke (Sanctuary) - 02 Sister.mp3')

Audio file demonstrating the problem
If applicable, please drag and drop the zipped audio file(s) which caused the problem into the bug report.
Please create additional issues if you experience different problems for each file.
Sanctuary.zip

I attempted to manually edit one metadata item at a time (using Windows' built-in music properties editor) to see if manually "refreshing" one of the values would stop the errors from occurring, but with no luck.

[Borewit]

Thanks for reporting the issue @JL102

The ID3v2.3 TLEN field has invalid encoded 16 bit unicode string. It seems to have an extra 00 between the BOM field and the octets representing the string value.

I will prevent the error from being throws and capture this in the returned quality.warnings.

[JL102]

Working, thank you!

[Kyant0]

Is this TLEN field informal or invalid? Do all of the TLEN has invalid utf-16 string? Or can the workaround be approved in such case? I can't find there is a standard regarding it.

[Kyant0]

And the encoding of the TLEN field is UTF-16 (LE), but the BOM of UTF-16 BE (0xFEFF) is used.

[Borewit]

Do all of the TLEN has invalid utf-16 string?

No this is very exceptional, most encoders comply with the standard.

But maybe you mean: is any TLEN field with an UTF-16 string invlid?

Absolutely, should be ISO-8859-1.
BOM fields do not belong in this field, neither in any other field in ID3.

I can't find there is a standard regarding it.

Both for id3v2.3.0 & id3v2.4.0:

TLEN The ‘Length’ frame contains the length of the audiofile in milliseconds, represented as a numeric string.

id3v2.3.0:

All numeric strings and URLs [URL] are always encoded as ISO-8859-1.

id3v2.4.0:

If nothing else is said, strings, including numeric strings and URLs [URL], are represented as ISO-8859-1 [ISO-8859-1] characters in the range $20 - $FF