APE tag not found in files with both ID3v1 and Lyrics3 tags

[dae65]

ExifTool 12.05 is able to extract APE metadata from files where the APE segment is (i) at beginning of the file, or (ii) at the end of the file, or (ii) just before an ID3v1 segment. It is, however, unable to find APE metadata if (iv) there happens to be a Lyrics3 segment between the APE and the ID3v1 segments.

In order for ExifTool to be able to find APE tags in such places, I've expanded Image::ExifTool::APE, line 169, with the following code (adapted from MP3::Info, v1.24):

Code Select Expand


if ( $$et{DoneID3} == 2 )
{
  # from MP3::Info (2.14)
  my $offset;
  open my $fh, $$et{FILENAME};
  binmode $fh;
  seek $fh, 0 - 128 - 9 - 6, 2;
  read $fh, (my $buff), 128 + 9 + 6;
  close $fh;
  my $foot = substr $buff, 6, 9;
  my $lsz = substr $buff, 0, 6;
  if    ( $foot eq 'LYRICSEND' ) { $offset = 128 + 5100 }
  elsif ( $foot eq 'LYRICS200' ) { $offset = 128 + ( $lsz + 6 + length 'LYRICS200' ) }
  elsif ( substr ( reverse($buff), 0, 9 ) eq 'DNESCIRYL' ) { $offset = 5100 }
  elsif ( substr ( reverse($buff), 0, 9 ) eq '002SCIRYL' ) { $offset = reverse ( substr (reverse($buff), 9, 6 ) ) + 15 }
  else  { $offset = 128 }
  $footPos -= $offset;
}


As you can see, I didn't make use of the File::RandomAccess object to seek and read the Lyrics3 tag, but opened a regular filehandle using $$et{FILENAME} instead. I understand this is something we should probably change.

That should be enough for ExifTool to find such APE tags. If you want it also to support Lyrics3 tags, here are specifications for v1 and v2. It's a piece of cake.

Sincerely,
d

[Phil Harvey]

Thanks.  Can you provide a sample so I can test this?  You can mail it to me (philharvey66 at gmail.com).

- Phil

[dae65]

Sure. Thanks

[Phil Harvey]

Thanks.  ExifTool 12.06 will support Lyrics3.  I have built this into the ID3 module so it will also be supported for other file types that use ID3.

Just FYI: The Lyrics3 specification is incorrect wrt the metadata in the file you sent (and the example in their documentation).  It states:

All fields uses a simple structure that includes a three character field ID, six characters describing the size of the information and the actual information.

... but the size field is only 5 characters, not 6.

- Phil

[dae65]

... but the size field is only 5 characters, not 6.

(Great! Thanks a lot, Phil.) That's right. The specification is inconsistent. Having misleadingly said that a field size is 6 characters long, it says also towards the end that:

Here is a step by step description on how to read fields:

    Read 3 chars, which are the field ID.
    Read 5 characters as a number which contain the number of bytes of data for this field.

It seems they were confused about field size (5 chars) and the tag size in the footer (6 chars).