'Genre' field parsed inconsistently when there are multiple values

[mxro]

Thanks for this great library!

I have a number of files that have more than one value for the 'Genre' field. This is rendered inconsistently - sometimes with a ; character between the genres and sometimes with no character between them at all.

This it is how the Genre field for a particular track is rendered in MusicBee:

This it is how it is displayed in MP3Tag

And this is what node-id3 reads when using NodeID3.read(filePath);:

"TCON": "Hip Hop10sRated-4List-The DriveList-The WorkList-High PowerList-Sadness",
 "genre": "Hip Hop10sRated-4List-The DriveList-The WorkList-High PowerList-Sadness",

In order to check if JSON.stringify() masks any 'strange' characters, such as NULL, I have implemented the following method to verify the separation character is not in the genre.

export function printGenreMetadata(genre: string): string {
  if (!genre) return '';

  return Array.from(genre).map(char => {
    if (char.charCodeAt(0) <= 127) {
      return char;
    }
    return `{${char.charCodeAt(0)}}`;
  }).join('');
}

This yields the same string:

Hip Hop10sRated-4List-The DriveList-The WorkList-High PowerList-Sadness

It seems like the field is only calculated correctly if there are ; characters between the genres. Such as for the following track, that returns a matching string to what is displayed in MP3tag:

[pbricout]

According to the documentation about id3 v2.4 here in the section "4.2. Text information frames" it is specified the following:

The text information frames are often the most important frames,
containing information like artist, album and more. There may only be
one text information frame of its kind in an tag. All text
information frames supports multiple strings, stored as a null
separated list, where null is represented by the termination code
for the character encoding.

The node-id3 library does not split text fields with the separating 0 for complicated reasons (there are other issues opened about it and this is currently pending design implementation choices) but you can do it yourself easily with a split, here is a simple example:

$ node
> "foo\x00bar".split("\x00")
['foo', 'bar']
> ['foo', 'bar'].join("\x00")
'foo\x00bar'

From a quick test I did with MusicBee this is indeed encoded with 0 as a separator:

This should unblock you.

[mxro]

Thank you very much for looking into the issues.

Yeah, when looking around online, I saw there seems to be a lot of confusion around separating values, so I can fully understand this needs some careful design.

For your reference, here some more info about the problem I faced.

I can confirm that I can read out files correctly that have been saved with MusicBee. I think the problem are actually files I saved with node-id3, like File 2 below.

File 1:

File 2:

For now as a workaround, I read out the metadata using the music-metadata library, then convert it to the format node-id3 expects and then save the updated tags with node-id3.

import NodeID3 from "node-id3";
import { Track, getLastModifiedDate } from "./readMetadataIntoDB";

import { inspect } from "util";

// Function to read metadata and update the map
import { parseFile } from 'music-metadata';

function cleanString(input?: string): string | undefined {
  if (!input) return undefined;
  return input.split('').map(char => char.charCodeAt(0) === 65279 ? '; ' : char).join('');
}

export async function readMetadata(
  filePath: string,
): Promise<Track | undefined> {
  try {
    // const nodeID3Tags = NodeID3.read(filePath);
    const tags = await parseFile(filePath);

    // console.log(nodeID3Tags.genre?.split("\x00"));
    // console.log(inspect(altTags, { showHidden: false, depth: null }));
    if (tags) {
      const compressed: NodeID3.Tags = {
        genre: cleanString(tags.common.genre?.join('; ')),
        // genre: tags.raw?.TCON,
        title: tags.common.title,
        artist: tags.common.artist,
        album: tags.common.album,
        comment: tags.common.comment && { text: tags.common.comment?.join(''), language: 'eng' },  
        year: tags.common.year?.toString(),
      };
      return {
        fileName: filePath,
        original: compressed,
        playlists: [],
        lastReadTimestamp: new Date().toISOString(),
        lastModifiedTimestamp: (
          await getLastModifiedDate(filePath)
        ).toISOString(),
        current: { ...compressed },
        changes: {},
      };
    } else {
      console.warn(`No metadata found for file: ${filePath}`);
    }
  } catch (error) {
    console.error(
      `Error reading metadata for file ${filePath}: ${(error as Error).message}`
    );
  }
  return undefined;
}

[pbricout]

My point was that with node-id3 you should be able to both read and save.

When you read split the string with value.split("\x00") to retrieve all the values in an array, to save join your array with myArray.join("\x00") and put the string in the field.

That should work as expected by the standard and MusicBee.

[mxro]

Thank you for your response. Sorry I feel like I might be misunderstanding, so I couldn't come to a working solution with node-id3 yet.

Here is what I've tried - as said, sorry if this is misunderstanding your advise!

Genres in Sample File

As displaying in MP3Tag editor:

Binary of genre field:

000004d0: 1000 0000 506f 7000 5475 726b 6973 6820  ....Pop.Turkish
000004e0: 506f 7054 4954 3200 0000 0800 0000 596f  PopTIT2.......Yo

Using music-metadata

import { parseFile } from 'music-metadata';
const tags = await parseFile('test.mp3');
console.log(tags.common.genre);
// ==> [ 'Pop', 'Turkish Pop' ]

Using node-id3

import NodeID3 from "node-id3";
const tags = NodeID3.read(filePath);
console.log(tags.genre.split("\x00"));
// ==>  [ 'PopTurkish Pop' ]

To me, it seems there is no character (00 or otherwise) that is placed in the genre string separating the genres. I added the split as you instructed, but it doesn't seem to be making any difference.

As said, I can totally understand if this is not supported, and I've got a workaround with music-metadata for now. Just supplying this information here in case it can improve the library, and my apologies again if I misunderstand the workaround you are suggesting.

[Zazama]

This behavior is because we are actively removing the \0 characters from the string https://github.com/Zazama/node-id3/blob/0.2/src/ID3Util.js#L59
There is currently no way for library users to split the string themselves because we remove the marker.

Changing that would imo only make sense in a new major version (0.3 is enough on the 0.x version), as this could be a breaking change. However, this doesn't solve the problem that multiple genres are not handled by the library itself