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 (https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/Metadata/Metadata.html#//apple_ref/doc/uid/TP40000939-CH1-SW35)). 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 (https://github.com/exiftool/exiftool/blob/6ef7fc5a2e65639a1d3883708d44cde6b9c18b15/lib/Image/ExifTool/QuickTime.pm#L3003-L3007) quotes AtomicParsley's documentation (http://atomicparsley.sourceforge.net/mpeg-4files.html) 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.
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
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.
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
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.