Pictures cannot display in windows file browser. about node-taglib-sharp

[benrr101]

Hmmm... I played around with it for a bit this evening and so far haven't been able to directly reproduce your issue. I do however notice neither windows nor Foobar2000 seem to recognize ID3v2 tags placed at the end of the file with node-taglib-sharp. It's worth noting as well that Foobar2000 seems to cache tags when a file is added to a playlist. I wasn't able to get the scenario you had where Windows doesn't show the picture but Foobar2000 does, but this might be because Foobar2000 needed to reload the tags.

node-taglib-sharp by default creates new ID3v2 tags at the beginning of the file, but if a file already has ID3v2 tag at the end of the file, it will write any changes (via dest.tag) to that tag. As a workaround, you could try removing and re-adding the tag so that it is added at the end of the file.

const file = taglib.File.createFromPath("pathtofile");
const cover = taglib.Picture.fromPath("pathtopicture");

const oldId3v2 = file.getTag(taglib.TagTypes.Id3v2, false);
file.removeTags(0xFFFFFFFF);

const newId3v2 = file.getTag(taglib.TagTypes.Id3v2, true);
oldId3v2.copyTo(newId3v2, true);

// make changes via file.tag

file.save();
file.dispose();

Inspecting the file I tested with, I see the image is being added to the tag and node-taglib-sharp can see it. However, the fact neither foobar2000, vlc, nor windows can see the tag means something is wrong.

[RogerChen2005]

Thanks for your help, I accidentally got two samples today, one cover displays properly and the other doesn't.

Compared the content of two files, I notice that the tag type of two samples are different, and 'id3v2.3' can display properly,

Thus, I suppose that explorer.exe can't read newer tag type.
Thanks again for your help, have a nice day.

[RogerChen2005]

taglib.Id3v2Settings.forceDefaultVersion=true;
taglib.Id3v2Settings.defaultVersion=3;

After forcing the version of id3v2, The problem has been solved.

[benrr101]

Hi @RogerChen2005 yes, ID3v2.4 still isn't supported in nearly as many places as ID3v2.3 is. Glad you found a workaround. The investigation for your issue also uncovered a related issue with ID3v2 tags at the end of a file. I'll track that in a separate issue, but thanks for helping bring it to my attention.