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 (https://id3.org/Lyrics3v2) 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 (https://github.com/exiftool/exiftool/blob/7e2737c0ea4e812ff81f189db3693cd55dc0485b/lib/Image/ExifTool/APE.pm#L169), with the following code (adapted from MP3::Info (https://metacpan.org/pod/MP3::Info), v1.24):
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 (https://id3.org/Lyrics3) and v2 (https://id3.org/Lyrics3v2). It's a piece of cake.
Sincerely,
d
Thanks. Can you provide a sample so I can test this? You can mail it to me (philharvey66 at gmail.com).
- Phil
Sure. Thanks
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
Quote from: Phil Harvey on September 08, 2020, 10:25:56 AM
... 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:
QuoteHere 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).