Bug: wrong Compilation data-type flag in MP4

Started by dae65, August 07, 2020, 12:08:56 AM

Previous topic - Next topic

dae65

Dear Phil,

In this post, I'll simply report a bug in ExifTool 12.03 about the Compilation tag in QuickTime ItemList (aka cpil atom in MP4). In a follow-up post in the metadata subforum, I'll discuss why I think there is probably something wrong with almost all integer tags in ItemList.

ExifTool currently writes the moov.udta.meta.ilst.cpil.data atom with a 0x16 data-type flag. It should be 0x15 instead. Otherwise, Apple iTunes (12.06) and AtomicParsley (0.9.6) flatly ignore it. The 0x16 (22) flag means unsigned integer; 0x15 (21) would mean signed integer (QuickTime File Format Specification). To fix it, the format key for cpil should be int8s instead of int8u.

Now, a comment to the cpil definition in Image::ExifTool::QuickTime::ItemList quotes AtomicParsley's documentation as the source for int8u. There is something wrong with AtomicParsley's documentation, though; on the one hand, a row in the Known iTunes Metadata Atoms table does indeed say that cpil is "uint8" (unsigned); however, the same row says cpil is of data-type class 21 (0x15 = signed). Accordingly, AtomicParsley 0.9.6 itself writes cpil with a 0x15 flag:


$ AtomicParsley file.m4a --compilation yes --overWrite
Updating metadata...
$ AtomicParsley file.m4a -T 1 | grep -w cpil
                 Atom cpil @ 78844 of size: 25, ends @ 78869
$ hexdump -C -s 78844 -n 25 file.m4a
000133fc  00 00 00 19 63 70 69 6c  00 00 00 11 64 61 74 61  |....cpil....data|
0001340c  00 00 00 15 00 00 00 00  01                       |.........|
00013415


And iTunes also writes cpil as 0x15:

$ hexdump -C -s 0x12d49 -n 25 itunes.m4a
00012d49  00 00 00 19 63 70 69 6c  00 00 00 11 64 61 74 61  |....cpil....data|
00012d59  00 00 00 15 00 00 00 00  01                       |.........|
00012d62


But ExifTool 12.03 writes it as 0x16:


$ exiftool -ItemList:Compilation=Yes exiftool.m4a
    1 image files updated
$ hexdump -C -s 0x12d68 -n 25 exiftool.m4a
00012d68  00 00 00 19 63 70 69 6c  00 00 00 11 64 61 74 61  |....cpil....data|
00012d78  00 00 00 16 00 00 55 c4  01                       |......U..|
00012d81


Thank you.

Phil Harvey

Thanks.  It looks like we should be doing a sweep to see which other tags should be changed.  I think it would be best to try to conform with Apple iTunes whenever possible.  I'll change this one, but it would be good to do them all at the same time.

Note that the ExifTool -v3 output will show this information:

  | | | | Compilation = 1
  | | | | - Tag 'cpil', Type='data', Flags=0x16 (1 bytes, int8u):
  | | | |     0756: 01                                              [.]


- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

dae65

#2
Thanks, Phil. Apologies for reporting those one by one, as I thought I should somehow justify my reports. The thing is, I'm having a hard time figuring out what exactly is wrong, and I'm starting to think that either the Quicktime File Format Specification about data-type flags under ilst is wrong, or Apple iTunes doesn't comply with it.

Phil Harvey

In this case, I think the only justification that is required is "this is what iTunes writes" since most other software out there should be concerned about iTunes compatibility, and changing these formats won't break anything as far as ExifTool is concerned.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

dae65

Right. So, I'll share my findings in another post about all integer ItemList tags, but will leave it for you to decide what to do next.

Thanks.