Handling of null-terminated strings about id3-parser HOT 5 CLOSED

Looks good. I will have a look as soon.

from id3-parser.

Here is ID3v1 protocol. As it says, ID3v1 would be like:

Property like Artist may does not need 30 bytes, so, it will be padding with binary 0.

However, for lib's readUTF8String util, it will break reading when get 0x00. So I don't think we have to use /(^\s+|\s+$|\0.*$)/g.

from id3-parser.

And it's great if you can offer a counterexample.

Use

let buf = fs.readFileSync('xxxxx.mp3')
buf = buf.slice(buf.length - 128)

to extract the id3v1 part.

from id3-parser.

It might be so for the v1 part, I had no issue with that one. I had a set of MP3s created by a clearly non standard-compliant software (of which, many exists) which happened to be in ID3v2, encoded with ISO8859 and null-terminated. This module included the null in the resulting string. Though it looked Ok when printed through console.log, when that string was stored in a SQLite database (not an unusual thing, MediaMonkey does that) with its automatic typecasting, it stored the string not as of type TEXT but as BLOB and that simply because of the non-visible null at the end of the string. I fixed it by stripping that null, but I wouldn't recommend my patch for this library module. A more generic fix could be to use the same regular expression you use for v1 tags for both v1 and v2, but that would have required moving whiteRe out of the function it is declared in and have the ability to strip both blanks and nulls.

from id3-parser.

Get it. I'll assess whether to change whiteRe.

from id3-parser.